EGit equivalent for git format-patch and git am - egit

I work with some other guys over EGit, but we don't have a central place to push/pull from. Now rather than sending our entire repos each time, I'd like to use git-format-patch/am but with EGit. Is this supported?

This is not yet supported. You can export a commit in the "email" format using the history view context menu "Create Patch...". But when applying the patch, it is not automatically committed as it would be with git am.

Related

Merging git hub repository with perforce depot

I have project A. The project A is in perforce as well as in github( Business decision). They are both out of sync. I see that I can use git-p4 tool http://git-scm.com/docs/git-p4 to submit git changes to perforce. Problem is first instruction of it says is:
git p4 clone //depot/path/project
This command will create a new repo in git hub. I do not want that. I want my existing perforce depot to connect to exiting github repo and then sync files from github to perforce. Is it possible?
No. git p4 is basically just a wrapper around Perforce. It reads changes to a Git repo and issues the proper Perforce commands to commit them (and vice-versa -- it reads changes to a Perforce checkout and issues the proper Git commands to update a Git repo accordingly). So you need to have a Perforce checkout and a local Git repo that can talk to that Perforce checkout.
Fundamentally you have two different histories for the same project, so you need to find some way to reconcile them.
git-p4 can sync from Perforce (create a new git repository), then you can add a new remote pointing to github, and sync the branches from there.
However that doesn't help with the problem of merging the histories.
You can either:
Go with Perforce, and rewrite github history
Go with Github history, and get your perforce admin/Perforce (company) to rewrite your Perforce history.
2 is probably (politically) impossible. May be impossible technically. Perforce is designed to prevent history from being altered.
1 will break anyone cloned from your github repository.
You may want to take a look at Git Fusion, which is a bridge between Git and Perforce:
http://www.perforce.com/git-fusion
This KB article gives an example of how you may wish to work with a project that is both in Perforce and a public Git repo:
http://answers.perforce.com/articles/KB/7481/
Hope this helps!

How to remove unsynced commits in github for windows?

I have two unsynced commits using GitHub (Windows), but don't want to commit them now. How can I revert or drop them?
As mentioned in "How to reach some commands on Github for windows", you best course of action would be to use to git CLI (command line interface), opening a shell from "GitHub for Windows", or using msysgit.
Then a git reset HEAD^2 (or even git reset --hard HEAD^2 if you really want to remove those files as well as any work in progress) would drop those commits (as in "How do I delete unpushed git commits?" or "How to delete a 'git commit'").
After a refresh, GitHub for Windows should display no more unsynced commit.
Other answers below mention the recent addition of "Undo most recent commit", which achieve the same reset:
As I mentioned in "GitHub undo a discard", the "discard changes" feature would achieve the same as a git reset.
In the newest version of GitHub (Windows) under the Settings button, next to the "Sync" icon/button there is the option "Undo most recent commit", that will take care of those unsynced commits.
Latest version of GitHUb for Windows have this option. The option will be enabled in case you have any unsynced commit. This is a very useful update from GitHub.
There is an undo button. Right click on the file to commit and select "Discard changes".
https://github.com/blog/1441-undo-button-in-github-for-windows
I would suggest, based on the way the questions is phrased, and what searches it comes up for, that people may want to use "FETCH_HEAD when resetting via the git CLI/ ("Open in Git Shell") in the GitHub for Windows menu.
Once in the shell, run:
git reset FETCH_HEAD --hard
This will reset you back to where you were when you last pulled down changes from your remote - which is what it seems like some people hitting this page are looking to do.

tortoise hg creating 'sibling' branches

I'm just starting working with Mercurial and Tortoise HG. I've created two uncoupled changes, one is a bug fix and one is a new experimental feature.
What is the best way to set this up (using bookmarks, tags or branches or something else) so that I can commit both but push only one of the groups of changesets to the remote repository.
And can this be done easily in Tortoise HG or is command line knowledge of mercurial required?
You can do this from both the CLI and from TortoiseHg. Note that using bookmarks, tag, etc.. has no influence on what you can push.
Using TortoiseHg v1.X.X
Identify the outgoing changesets and then right-click on the head of the branch you'd like to push and select push this branch.
Using TortoiseHg v2.X.X
You must first configure the tool to allow pushing new named branches by clicking Options and selecting the following:
Using the Target option in the Synchronize view, select the branch you want to share and perform the push. This will only share the selected branch. Unchecking Target will cause every new changeset to be pushed.

Creating a git Patch in eclipse across commits

I'm using git via the Eclipse egit plugin. I am new at using git as my VCS and was wondering if there was a way to create a patch that captures the changes across multiple commits from within Eclipse. For example:
Work on a new feature
Commit work
Fix a bug
Commit work
Create patch of code added since #1
Can this be done from within eclipse using egit? If not, what is the command line for doing this?
The git command you're looking for is:
git diff HEAD~2 HEAD
HEAD means your current commit, and ~2 means "two commits before".
I'm not sure if egit can do this, but I'd look for some sort of arbitrary diff functionality: "diff against... [commit]".

Git/Mercurial locally ontop of local cvs checkout

I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.