[Webkit-unassigned] [Bug 32834] svn-apply should handle git patches with similarity index, rename and copy directives

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32834





--- Comment #4 from David Kilzer (ddkilzer) <ddkilzer at webkit.org>  2010-01-28 08:08:58 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > For the purpose of submitting Git patches, it seems there can be (at least) two
> > > approaches:
> > > 
> > > (1) Make a "create-patch" script that supports creating a patch in standard
> > > format from both SVN and Git.
> > > 
> > > (2) Make svn-apply and svn-unapply support both Git and SVN format.
> > > 
> > > (Combining both approaches may also make sense -- e.g. to address the
> > > issue in this bug report.)
> > > 
> > > From what I can tell, we currently do (2) to some extent, but not (1).  Has
> > > anyone given much thought to these approaches?  Are there any reasons to
> > > prefer (2) over (1) or vice versa, or to not do (1)?
> > 
> > I think (2) is a higher priority than (1) because git's own diff subcommand
> > (with the --binary switch) is sufficient to capture all of the changes in a
> > patch.
> 
> I gave an example here of a case where the "git diff" command doesn't generate
> a patch in the standard format (at least with the way that I was running it):
> 
> https://lists.webkit.org/pipermail/webkit-dev/2010-January/011495.html
> 
> The example occurred because "git diff" doesn't run fixChangeLogPatch.

It'd be great if you could post the example here.  I think I know what you're
referring to, but it's always best to have a concrete example.

I don't think this has been an issue in practice because:

- There is no "loss of information" if the unaltered ChangeLog patch is not
fixed up, and it may optionally be fixed up at any point in the future.  All
the pieces are there, just not in the optimal order for applying it to the top
of the ChangeLog file.

- The commit queue uses svn-apply to apply patches which fixes up the ChangeLog
patch before applying it.  Individual contributors may also be using svn-apply
to apply patches, or they may be using resolve-ChangeLogs afterwards.

- Even in the case where the patch is completely rejected, there's still enough
information in the *.rej file to reconstruct the original patch, fix it up,
then apply it.  (I don't think fixChangeLogPatch() works with non-unified diff
format, though, so this may not work properly today.)

Having said that, if you feel that (1) is more important than (2), then I'd
focus on that first.

For whatever reason, this issue hasn't come up much.  Maybe that's because the
ChangeLog patches end up getting applied successfully to the middle of the
ChangeLog file instead of at the beginning, but look "okay" otherwise, and no
one has noticed/complained about it yet.  (I think I've seen this behavior in
the commit queue, but I though it was due to something else at the time.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.