On Sunday 08 February 2009 18:13:00 you wrote: > On Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Now what is that topic branch is for? Yes, it is about adding this new > > feature, and nothing else. Don't pull other people's changes made on my > > tree into it. That will make your topic branch "one new feature and > > everything else" and useless as a topic branch. > > Fair enough, but I don't understand what is referred to by "my tree" above? Junio means his git tree. Which is where we get releases from. > > $ git checkout -b bg/no-progress origin/master > > ... work on e802880 ... > > ... test it ... > > $ git commit ;# record that on bg/no-progress topic > > > > $ git checkout master > > $ git merge bg/no-progress > > ... test the result of the merge ... > > Refering to that git merge bg/no-progress command above. You said not > to merge from master to bg/no-progress at this early stage, which > makes sense, but now you are going in the reverse via master <-- > bg/no-progress. Well, master is not a topic branch, so merging a topic branch into it is not necessarily bad. > And here I do not see a commit, but that command is > followed straight way with a "git checkout bg/no-progress" below. Is > that just for testing the merge with the intent of just throwing the > changes away? Merge automatically does a commit unless there are conflicts. > In other words, is this next "git checkout > bg/no-progress" command going to silently throw away the "git merge > bg/progress" step at this point? No, it doesn't throw it away. However, it never made any changes to pg/no- progress just to master, so bg/no-progress will not show the results of the merge. > Similar question: Is this next "git checkout bg/no-progress" below > going to loose the conflicts I would have just resolved above > (referring to the most recent "... resolve conflicts ..." line above)? It's going to but you back on bg/no-progress, which doesn't have Junio's latest changes, so there won't be any conflicts immediately. > > which may conflict again (but that would be the same conflict you saw > > with your "git pull" from me, and rerere may remember it). > What does "rerere" mean, or is that a typo? REuse REcorded REsolutions. It's a git option to remember how you resolved merge conflicts and automatically apply those resolutions later. > > and reorder, squash, and fix them. > What do you mean by "reorder, squash" mean here? Is that something > that is done as a part of the -i option to git rebase? Reordering and squashing can be done via rebase -i, but it's basically just the practice of "prettying" your changes. http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ has more prose on the subject. > > $ git checkout bg/no-progress^0 > What is the significance of the ^0 construct tacked onto the end of > "bg/no-progress" at this point, versus just "git checkout > bg/no-progress" without the "^0"? It took me a second, but I believe this checks out bg/no-progress and detaches HEAD. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
