Re: Trouble testing out a patch on a branch new scratch git.git repository

["Boyd Stephen Smith Jr." <bss@iguanasuicide.net>]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

On Sunday 08 February 2009 18:13:00 you wrote:
> On Sun, Feb 8, 2009 at 1:46 PM, Junio C Hamano <gitster@pobox.com> 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@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]