Re: impure renames / history tracking

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Mar 1, 2006, 18:05 UTC
Message-ID: <46a038f90603011005m68af7485qfdfffb9f82717427@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0603011558390.13612@sheen.jakma.org>

On 3/2/06, Paul Jakma <paul@clubi.ie> wrote:

Show 6 quoted lines

> I mean:
>
>         $ git checkout project
>         $ git pull . master
>         $ git checkout -b tmp project
>         $ git diff project..master | <git apply I think>

The moment you 'merge' by using git-diff | patch you lose all the support git gives you, because you are discarding all of git's metadata! git's metadata is about all the commits you are merging, and is good enough that it will help future merges across renames.

You should really use git-pull/git-merge at that point.

My guess is that you do this to achieve what you describe later:

Show 6 quoted lines

> Presume that 'project' in the workflow is defined as
>
>         "achieve one goal with one commit to the master"
>
> So by definition, it always correct that the project only ever has
> one commit.

What happens if you rephrase that to read: "achieve one goal with one merge to the master"? Long term, it gives you much better support from the SCM. If a particular commit broke something, you can use whatchanged, log, annotate and bisect to figure out in which /small/ commit things went astray.

And you can modify your practices ever so slightly to match the benefits of the old model:

 - force merge message editing in git-merge, and prepare appropriate
commit messages for your merges
 - write a modified git-log that displays only the merges to master

that way, you get the best of both worlds.

> The trouble is that /sometimes/ projects do indeed 'rename and
> rewrite' a file. At present, chances are git might not notice this,

It will, if you preserve git's metadata.

The thing is that with any scm that tracks metadata of some kind, the moment you bypass its tools and do diff|patch to discard the metadata... well, you lose its benefits...

And what I've found, managing a project with 13K files, is that in practice git does far better tracking renames than several SCMs that do explicit tracking. Don't be distracted by the 'we don't track renames posturing'. We do, and it's so magic that it just works.

cheers,