Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html