Ingo Brueckl wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
This is one of the most useful features.
Wow. I'm sursprised to hear that, because I consider it at the moment as a
very strange one.
For example, it is an essential
part of supporting the workflow described here:
http://gitster.livejournal.com/25892.html
Here is what I'd expect to do with git (described with my own words, not in
git commands):
1. commit the quick fix to the release branch
2. push this single commit to origin and master
Now that all branches have the commit a later push and pull should notice
this and "skip" it.
This leads to a second question I have. Assuming I have three patches in my
repo (#1, #2 and #3), is it possible to push only #2 (because it is a
quick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and
#4?
If they're on different branches, yes. If they're on the same branch, no.
This is because a commit in git is named uniquely not only by its contents,
but also by its ancestry.
You can, however, run "git rebase --interactive" and re-order the commits
before you push them, so that #2 becomes #1 and vice versa. Then you can
push only #1 (the old #2) while leaving #2 (the old #1), #3 and #4 on
your machine only. This involves knowing the commit identifier of #1
though. Assuming it's "deadbeef", you can update the remote branch "foo"
to hold your new commit by running the following command:
git push <remote> deadbeef:refs/heads/foo
HTH
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html