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

From: Brent Goodrick <bgoodr@gmail.com>
Date: Feb 9, 2009, 00:13 UTC
Message-ID: <e38bce640902081613v3e93c1e3g716118c38ce861ab@mail.gmail.com>
In-Reply-To: <7vy6wgwqjp.fsf@gitster.siamese.dyndns.org>

Much thanks for your extensive writeup, Junio! I will try to follow your advice on a brand new git clone'ed repository and just reapply my changes there into the topic branch (makes sense for these small sets of changes; but not for larger sets ... read my comments below).

But for my education, I've interspersed below some questions where I am still misunderstanding the situation or intent behind your recommendation:

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?

>
> What would make your life easier would be:
>
>        $ git pull ;# to get up to date with me on your master branch

I am concluding that I need to throw away (well, saving it off first) my current repo and then do the git pull only from within a fresh git clone?

Show 8 quoted lines

>        $ 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. 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? 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?

Show 16 quoted lines

>
>        $ git checkout bg/no-progress
>        ... work on style fix ...
>        ... test it ...
>        $ git commit ;# again record it on bg/no-progress topic
>
>        $ git checkout master
>        $ git merge bg/no-progress
>        ... test the result of the merge ...
>
>        $ git pull ;# to get up to date with me
>        ... resolve conflicts ...
>
> Then after you are convinced that everything on bg/no-progress is worthy
> of sending to the list [*A*], but its tip is stale because things have
> progressed on my end, you can do this:

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)?

Show 6 quoted lines

>
>        $ git checkout bg/no-progress
>        $ git rebase origin/master      ;# and rebase to the upstream
>
> 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?

Show 17 quoted lines

>
> Review and test the result and then:
>
>        $ git format-patch origin/master
>
> There can be variants in the last few steps.  For example, your commits on
> bg/no-progress may be full of "Oops, this is to fix my own mistake made in
> earlier commits since I forked from the upstream".  You would not want to
> have them in your submission (instead, you would want to pretend as if you
> never made these mistakes in the first place).  For that, you may want to
> do, after you feel the tip of bg/no-progress is in a good shape at point
> *A* above:
>
>        $ git checkout bg/no-progress
>        $ git rebase -i origin/master   ;# and rebase to the upstream
>
> 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?

Show 14 quoted lines

>
> Also you may feel that at point [*A*] what you have is very precious and
> you would not want yourself breaking it by the final rebase (which is a
> very reasonable thing to feel).  In such a case, the final rewrite could
> be:
>
>        $ git checkout bg/no-progress^0
>        $ git rebase -i origin/master   ;# and rebase to the upstream
>        ... test and review the result.
>        ... convince yourself it is indeed better than
>        ... what you earlier thought to be "very precious".
>        ... and then finally
>        $ git branch -f bg/no-progress
>        $ git format-patch origin/master ;# send this

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"?

I made the mistake of reading the "SPECIFYING REVISIONS" section in git-rev-parse(1) manual, which states:

    A suffix ^ to a revision parameter means the first parent of that
    commit object. ^<n> means the <n>th parent (i.e. rev^ is
    equivalent to rev^1). As a special rule, rev^0 means the commit
    itself and is used when rev is the object name of a tag object
    that refers to a commit object.

I'm having a hard time translating "tag object" and "commit object" into things I understand w.r.t. the repo I see from my end.

Show 5 quoted lines

>
> And to finish it off, you may do:
>
>        $ git checkout master
>        $ git merge --ours bg/no-progress

The --ours option to git-merge does not seem to be documented (at least it is not in the user manual). There is a --ours option indicated in the git-checkout man page.

Show 9 quoted lines

>
> The above is a suggestion based on a design to allow you keep sticking to
> your merge based workflow as much as possible, but you could instead
> choose to keep rebasing.  I have some observations at the end of
>
>    http://gitster.livejournal.com/24080.html
>
> comparing the merge based workflow and the rebase based one.
>

The rebase flow would work better for this given that I do eventually want to send my changes upstream. So, for my/our future Googling reference: I quote the section out of http://gitster.livejournal.com/24080.html that I believe applied to me _before_ I messed things up so badly:

your_blog> Another advantage of rebasing your personal patch constantly is that your_blog> it forces you a discipline to adjust your changes to the changes in your_blog> the upstream as early as possible. If you do not rebase and choose to your_blog> use merge in your workflow, your personal changes will be buried deep your_blog> in the history. When one of your many later merges with the upstream your_blog> made you resolve the conflicts with such old changes, two things your_blog> happen: your_blog> your_blog> * You do not remember what your own change was about, and have a your_blog> hard time resolving the conflict; your_blog> your_blog> * You may be able to resolve the conflict, but what you can your_blog> extract from "git log --no-merges origin.." will not be your_blog> something you can eventually send upstream. You will need to your_blog> rebase before submitting.

Again, much MUCH thanks for your assistance!

Brent