Re: git-scm.com refresh

From: Junio C Hamano <gitster@pobox.com>
Date: May 8, 2012, 16:51 UTC
Message-ID: <7vlil2wr8k.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vipg77wg1.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 21 quoted lines

> But what I have been discussing was the use of "diff" in the "Basic
> Snapshotting" section.  I actually very often use "diff" paired with
> "apply" for my own work, not when working to integrate others' work.  
>
> Also I do not think anybody would use "apply" to accept patches (that is
> what "am" is for), so listing it in "Email" section is doubly wrong.  If
> for some reason the command Reference does not want to have "apply" next
> to "diff" listed in "Basic Snapshotting", I do not think there is any
> category on that page for the command to belong to.
>
> The above two were the primary things that triggered my reaction.
>
> When reshaping a multi-commit series, "git diff $rev1 $rev2 >P.diff"
> followed by "git apply <P.diff" (either with or without editing P.diff in
> between) is sometimes a more versatile and even more natural solution than
> repeated use of "rebase -i" is, depending on what kind of reshaping
> I want to do.
>
> For example,...  Of course this
> does not have to be "rebase" but picking only part of good infrastructure
> change from totally unrelated branch.  A concrete example is ...

I encountered another example yesterday after sending the above message [*1*]. I was fixing one small bug, and had a commit that updates code and adds a test vector. It is a single commit on top of the current branch tip, which allegedly as a buggy code.

Then I wanted to double check that the bug really existed before the fix.

	git checkout HEAD^
        git show @{-1} t/ | git apply
        make test

The above gave me the pristine state plus only new tests to let me see the old code was indeed buggy.

I also hit another example use case yesterday.

A series was posted that was a fix that should go to "maint" but the pathces were based on "master". The usual "git am -s3c" on "maint" didn't exactly grok the series, as there were semantic conflicts (a new field was added between "maint" and "master" to the structure the patch touches to add yet another field). So here is what I had to do:

	git checkout -b jk/status-porcelain-z-b master
        git am -s ./+mbox
        git checkout -b jk/maint-status-porcelain-z-b
        git rebase --onto maint master
        ... fix conflicts, resolving semantic conflicts along the way

	git checkout -B jk/status-porcelain-z-b master
        ... at this point, jk/status-porcelain-z-b@{1} is what the series
        ... applied to 'master' as the poster intended.
        git merge jk/maint-status-porcelain-z-b
        ... conflicts, which is more or less a squashed version of the
        ... mess I dealt with when I rebased the original to maint
        ... rerere will replay the mechanical part.
	... look at the conflict in "git diff" (no other
	... arguments) and making sure that it mostly makes sense.
	git add -u
        git diff
        git diff HEAD
        ... but the semantic conflict part is still missing, which
        ... can be eyeballed like this.
        git diff -R jk/status-porcelain-z-b@{1}
        ... then transport the remaining changes.
        git diff -R jk/status-porcelain-z-b@{1} | git apply --index
	... and then double check the result
        git diff HEAD

And I had exactly the same use case today for another series.

It turns out that "nobody uses apply while accepting patches" is not quite true. I do use "apply" while accepting patches. But I do not use it on "format-patch" output. That is what "am" is for.

In any case, the latter part of the write-up above was done primarily because I thought it would be illustrative for others who need to flip commits (whether it comes in patch form, or you develop your own) between multiple code bases. As people say, just my two cents ;-)

[Footnote]
 
*1* I admit that I use "apply" so often that I do not have to think when
using it, and I realize use cases of it only during the course of the
usual work day, not during a theoretical "I do not think anybody uses 'git
apply' on 'git diff' output" discussion.