ib@wupperonline.de (Ingo Brueckl) writes:
I'm a git novice and have a comprehension question concerning branches.
Within a git repository, I do:
git branch test
git checkout test
# edit foo.bar
git checkout master
I'd expect that master is in the exactly same unchanged state it was at
branching time, but what a surprise, foo.bar is modified here, too!
No. Local modification that are not committed do not belong to any
branch. Rather it belongs to your work tree and the index, and follow you
when you switch branches.
This is one of the most useful features. For example, it is an essential
part of supporting the workflow described here:
http://gitster.livejournal.com/25892.html
On the other hand, there are cases that you do not want to see your local
changes to foo.bar appear when you switch back to master, and the most
obvious case is "I started working on something, and I used a separate
branch 'test' because the change will be involved. I am in the middle of
the work, the changes so far I made to foo.bar is far from ready, but I
have to handle emergency fix on the master branch". For that kind of
situation, you can use "git stash", like:
http://gitster.livejournal.com/29577.html
Junio C Hamano [off-list ref] 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?
Ingo
Ingo Brueckl wrote:
Junio C Hamano [off-list ref] writes:
quoted
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.
quoted
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@op5.se
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.