From: "Martin Langhoff" <martin.langhoff@gmail.com>
To: paul@hibernia.jakma.org
Cc: "Andreas Ericsson" <ae@op5.se>, "git list" <git@vger.kernel.org>
Subject: Re: impure renames / history tracking
Date: Thu, 2 Mar 2006 07:05:44 +1300 [thread overview]
Message-ID: <46a038f90603011005m68af7485qfdfffb9f82717427@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603011558390.13612@sheen.jakma.org>
On 3/2/06, Paul Jakma <paul@clubi.ie> wrote:
> 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:
> 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,
next prev parent reply other threads:[~2006-03-01 18:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-01 14:01 impure renames / history tracking Paul Jakma
2006-03-01 15:38 ` Andreas Ericsson
2006-03-01 16:27 ` Paul Jakma
2006-03-01 17:13 ` Linus Torvalds
2006-03-01 18:50 ` Paul Jakma
2006-03-01 17:43 ` Andreas Ericsson
2006-03-02 21:10 ` Paul Jakma
2006-03-02 22:06 ` Andreas Ericsson
2006-03-01 18:05 ` Martin Langhoff [this message]
2006-03-01 19:13 ` Paul Jakma
2006-03-01 19:56 ` Junio C Hamano
2006-03-01 21:25 ` Paul Jakma
2006-03-01 22:12 ` Andreas Ericsson
2006-03-01 22:28 ` Paul Jakma
2006-03-01 22:46 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2006-03-02 22:24 linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46a038f90603011005m68af7485qfdfffb9f82717427@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=paul@hibernia.jakma.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).