git-cherry filter

git-cherry filter

[Neal Kreitzinger]

Is there a way to add a pre-git-patch-id filter to git-cherry?

e.g.,

(a) perform "keyword contraction" to the patch before generating the 
git-patch-id.

e.g.  I want to run a git-cherry to see if two patches are identical other 
than keyword expansion values like $User: foo$ vs. $User: bar$.  (I would 
have to tell git-cherry which keyword formats to "contract".)

(b) ignore comments in the source code.

e.g.  I want to run a git-cherry to see if the patches are identical in 
regards to executable source.  (I would have to tell git-cherry what the 
comment rules are for the various source files.)

(c) exclude certain files from the diff (ie., binaries, comment files, 
etc.).

e.g.  I want to run a git-cherry to see which source code fixes from the old 
system have already been applied to the new system regardless of whether 
certain files differ (ie., binaries (ie, compile date), comment files (ie., 
fixed a typo), etc.).  (I would have to tell git-cherry which 
paths/filenames to disregard.)

I suppose these may be git-patch-id options that are passed via git-cherry 
like the git-fetch options passable via git-pull.


v/r,
neal 

Re: git-cherry filter

[Jeff King]

On Mon, Feb 13, 2012 at 10:20:59PM -0600, Neal Kreitzinger wrote:

> Is there a way to add a pre-git-patch-id filter to git-cherry?

Not directly, but see below.

> (a) perform "keyword contraction" to the patch before generating the 
> git-patch-id.
> 
> e.g.  I want to run a git-cherry to see if two patches are identical other 
> than keyword expansion values like $User: foo$ vs. $User: bar$.  (I would 
> have to tell git-cherry which keyword formats to "contract".)

Shouldn't these be contracted already in the canonical versions in the
repo?

> (b) ignore comments in the source code.

This one is tough, because you are talking about arbitrary
transformation of the diff.

> (c) exclude certain files from the diff (ie., binaries, comment files, 
> etc.).

This one is perhaps easier, and git-cherry could learn to use the
regular pathspec-limiting when generating patch-ids.


In any case, git-cherry is basically just comparing the set of patch ids
in one set to the patch-ids in the other set. So you could do all of
the above transformations by hacking together something like:

  merge_base=`git merge-base $upstream $head`
  get_patch_ids() {
    git rev-list $merge_base..$1 |
      git diff-tree --stdin -p -- $path_limiters |
      munge_your_diff_however_you_like |
      git patch-id
  }
  get_patch_ids $head >head
  get_patch_ids $upstream | cut -d' ' -f1 >upstream
  perl -l <<-\EOF
  open(my $head, '<', 'head');
  open(my $upstream, '<', 'upstream');
  my %upstream = map { $_ => 1 } <$upstream>;
  while (<$head>) {
          chomp;
          my ($patch, $commit) = split;
          print exists($upstream{$patch}) ? '+' : '-',
                ' ',
                $commit;
  }
  EOF

-Peff