git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Zenaan Harkness <zen@freedbms.net>
Cc: git@vger.kernel.org
Subject: Re: sane, stable renames; when a commit should commit twice
Date: Sat, 22 Dec 2007 18:50:58 -0800	[thread overview]
Message-ID: <7v4peaw2ct.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20071223020310.GA22450@freedbms.net> (Zenaan Harkness's message of "Sun, 23 Dec 2007 13:03:10 +1100")

Zenaan Harkness <zen@freedbms.net> writes:

> When should a commit, commit twice?
>
> When one or more git mv file renames/ moves are involved.
> ...
> Does this make sense?

Anything that feels right to you is right for _your_ project, so
asking that question does not add much value, but I would not
personally do that myself.  I may have pure rename commits that
move files around without changing any contents in my history,
but that is only because there happened to be no need to change
the contents in those commits, not because I followed an
artificial "a rename-only commit, followed by a commit that
edits" dogma you seem to be suggesting.

If I move file common.c to lib/common.c and common.h to
include/common.h, I would definitely NOT record that as two
events, if common.c used to include common.h.  My commit that
moves these two files will definitely contain edit to common.c
(now lib/common.c) that changes at least one line:

	-#include "common.h"
        +#include "../include/common.h"

in the same commit.  If you split this as two events, your first
"rename only" commit would not even build.

      parent reply	other threads:[~2007-12-23  2:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-23  2:03 sane, stable renames; when a commit should commit twice Zenaan Harkness
2007-12-23  2:26 ` David Symonds
2007-12-23 16:29   ` Jakub Narebski
2007-12-23  2:50 ` Junio C Hamano [this message]

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=7v4peaw2ct.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=zen@freedbms.net \
    /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).