[webkit-dev] [webkit-changes] [52439] trunk/WebCore

[David Kilzer]

If you want to make sure you're not going to lose history, you should use svn directly.  The svn-apply script already knows all the magic to do the right thing...if you used svn-create-patch to create the patch *and* if you're committing to an svn repository.

The "git svn dcommit" command (especially in newer versions of git) will try to relate source files that are moved or copied, but it only uses a heuristic when committing.  Using the "--dry-run" switch may provide some insight into whether git will show copied/moved files or not, but I've never tested it to make sure how accurate it is compared to the actual commit.

If the commit-queue is using a git repository, it will only work as well as git's heuristic does.

Setting "[diff] renames = copies" in ~/.gitconfig or in your .git/config file for each project will make git diff try to do rename detection when creating a patch.  (You may also use "--find-copies-harder" or "--find-copies-harder -C" switches on the command line.)  This will provide hints in the git diff about file renames, but it still only uses a heuristic, and svn-apply currently doesn't know about these hints:

Bug 32834: svn-apply should handle git patches with similarity index, rename and copy directives
https://bugs.webkit.org/show_bug.cgi?id=32834

Also note that --find-copies-harder doesn't work on small files (files under a certain number of lines), although I don't know what that threshold is off the top of my head.

I've also seen git think that a new header file (whose license text is larger than the header code itself) is actually a copy of another similarly short header file when doing large merges.

Again, you should use svn if you want to ensure file history.

Dave


On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote:

> If such git magic exists, it would be possible to teach svn-apply to use it.
> 
> -eric
> 
> On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler wrote:
> > On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote:
> >
> >> Sorry about that - it was git's decision.
> >
> > It that’s the case, then please consider not using git for this type of change 
> in the future. We don’t want to unnecessarily lose repository history when such 
> changes occur.
> >
> > If a git expert can show you how to do such changes with git while preserving 
> the Subversion history, then that gives you another option.
> >
> >    -- Darin
>