In the past couple weeks, I have had several occasions where a collaborator has
sent a patch, which does not have information about where the patch forked from
master. I wrote the following scripts to try to discover where the patch
should be applied. Is there a better way?
create_awk.pl:
----------------------->8------------------------------------------
#! /usr/bin/env perl
print <<HEADER;
BEGIN {
i = 0
}
HEADER
print "/";
my $numseen=0;
my $nummatches = 0;
while(<STDIN>){
if(/^index ([0-9a-f]+)\.\..+$/){
$hash = $1;
} else {
next;
}
if($hash =~ /^0*$/) {
next;
}
print "|" if($numseen > 0);
$numseen = 1;
++$nummatches;
print "$hash";
}
print "/{ i += 1; print \$0}\n";
print <<FOOTER;
END {
if( i == $nummatches) {
print "FOUND IT";
exit 1;
}
print "i =",i;
exit 0;
}
FOOTER
----------------------->8------------------------------------------
To find the place where the patch applies, I then would run something like
git rev-list --all | \
while read commit; do \
git ls-tree -r $commit | \
awk "$(perl ~/programs/git-hacks/create_awk.pl < <patch file>)" > /dev/null || \
echo $commit; \
done
Nathan Panike
On Thu, May 05, 2011 at 01:17:41PM -0500, Nathan W. Panike wrote:
In the past couple weeks, I have had several occasions where a collaborator has
sent a patch, which does not have information about where the patch forked from
master. I wrote the following scripts to try to discover where the patch
should be applied. Is there a better way?
What you have is more or less the best way. As you probably realized,
there could be any number of commits that match the preimage of the diff
exactly. So you are not necessarily finding the fork point, but rather
an appropriate place to apply the patch.
I have to wonder, though, whether it is worth the trouble. If you apply
the patch to your tip, especially using "git am -3", then one of two
things will happen:
1. The patch will apply cleanly. Either because your tip matched the
preimage exactly, or because it was close enough and git was able
to apply anyway.
2. There are conflicts between what you did and what the patch does.
In this case, though, what you are doing by searching for the fork
point will recreate the history locally that your collaborator has.
But when you go to merge their history, you will end up getting the
exact same conflicts that you would if you applied to your tip now.
So what is the value in applying their patch to the original fork point?
It better represents the history of what happened. But if you care about
that, I wonder if you should just be pulling from them directly via git
(or if that isn't convenient for some reason, passing around bundles).
To find the place where the patch applies, I then would run something like
git rev-list --all | \
while read commit; do \
git ls-tree -r $commit | \
awk "$(perl ~/programs/git-hacks/create_awk.pl < <patch file>)" > /dev/null || \
echo $commit; \
done
Wow, dynamically generating awk using perl. That's a new one for me. :)
-Peff
On Thu, May 05, 2011 at 03:55:56PM -0400, Jeff King wrote:
On Thu, May 05, 2011 at 01:17:41PM -0500, Nathan W. Panike wrote:
quoted
In the past couple weeks, I have had several occasions where a collaborator has
sent a patch, which does not have information about where the patch forked from
master. I wrote the following scripts to try to discover where the patch
should be applied. Is there a better way?
What you have is more or less the best way. As you probably realized,
there could be any number of commits that match the preimage of the diff
exactly. So you are not necessarily finding the fork point, but rather
an appropriate place to apply the patch.
Yes. I thought there might be some feature of git-apply that would help me,
but now I will stop thinking that.
I have to wonder, though, whether it is worth the trouble. If you apply
the patch to your tip, especially using "git am -3", then one of two
things will happen:
1. The patch will apply cleanly. Either because your tip matched the
preimage exactly, or because it was close enough and git was able
to apply anyway.
2. There are conflicts between what you did and what the patch does.
In this case, though, what you are doing by searching for the fork
point will recreate the history locally that your collaborator has.
But when you go to merge their history, you will end up getting the
exact same conflicts that you would if you applied to your tip now.
The patches were emailed as raw diffs, not as format-patch messages, so I
thought git-am was not applicable. Also, I was applying the patches to the git
repository on behalf of local colleagues when they ran into problems using
'git-apply'. I did not want to deal with merge conflicts---my colleagues can
handle the conflicts themselves. So a clean merge was optimal from my
perspective.
So what is the value in applying their patch to the original fork point?
It better represents the history of what happened. But if you care about
that, I wonder if you should just be pulling from them directly via git
(or if that isn't convenient for some reason, passing around bundles).
Oh, I keep forgetting about bundles. Next time, I might ask them to send a
bundle rather than a patch or ask them to use format-patch.
Wow, dynamically generating awk using perl. That's a new one for me. :)
You might say it is awk-ward.
Thanks,
Nathan Panike
-Peff
On Thu, May 05, 2011 at 03:12:05PM -0500, Nathan W. Panike wrote:
The patches were emailed as raw diffs, not as format-patch messages, so I
thought git-am was not applicable. Also, I was applying the patches to the git
repository on behalf of local colleagues when they ran into problems using
'git-apply'.
Git-am is basically just a wrapper around git-apply that will split an
email message into a raw diff and a commit message. If you have raw
diffs in an email, it may handle them OK, or it may be simple enough to
massage them into the right form.
As far as I know, there isn't a convenient way to get "git apply" to do
the same merge magic for a raw diff that "git am -3" does. It should be
possible, as the only relevant input is the raw diff; I just don't think
anybody has bothered to do it.
I did not want to deal with merge conflicts---my colleagues can
handle the conflicts themselves. So a clean merge was optimal from my
perspective.
Ah, that makes more sense. I have been in a similar "helping people with
git" situation myself.
quoted
Wow, dynamically generating awk using perl. That's a new one for me. :)
You might say it is awk-ward.
Ouch. :)
-Peff