git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: <git@vger.kernel.org>, Ron Garret <ron1@flownet.com>,
	Avery Pennarun <apenwarr@gmail.com>,
	Pete Harlan <pgit@pcharlan.com>
Subject: Re: [PATCH] Documentation: clarify git-mv behaviour wrt dirty files
Date: Wed, 03 Feb 2010 13:56:19 -0800	[thread overview]
Message-ID: <7v3a1idlvg.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <c43166fa73391a40b43c27153ec142121fdb71d1.1265231310.git.trast@student.ethz.ch> (Thomas Rast's message of "Wed\, 3 Feb 2010 22\:12\:12 +0100")

Thomas Rast <trast@student.ethz.ch> writes:

> Clearly point out that the rename happens separately for worktree and
> index.  This confused users, as they are apparently told that git-mv
> == git-rm && mv && git-add, which it is not.

I may be confused too as I had to read these three lines three times and I
do not think these two sentences mesh well together.

What happens with "git mv A B" is that it moves a work tree file A to B
and moves the index entry for A to B, hence all of:

 (1) the fact that you do not have A anymore;

 (2) the fact that you now have B instead; and

 (3) the fact that your work tree file B (which used to be A) has changes
     from its corresponding index entry

are _consistently_ kept between the work tree and the index.

I don't think "happens separately for" makes sense.  At best, it is an
implementation detail that doesn't help users understand what the command
does and what it is used for better.

Of course, it is different from

    "git rm -f --cached A && mv A B && git add B"

which would add changes that you were not prepared to add (i.e. you had
output from "git diff A" before you started).  I think that was a buggy
way old scripted version of "git mv" used to work, by the way.

> While there, move the synposis to the synopsis section, which so far
> was rather useless, and reword the first sentence to eliminate the
> mentions of 'script'.

That's a good change regardless.

> +For every renamed file or symlink, the worktree and index contents are
> +renamed separately, preserving both staged and unstaged changes....

I'd just say:

    While renaming paths, changes in the files in the work tree that you
    have not added are preserved.

> +....  You
> +will still have to commit the rename.

I don't understand why you want to say "You will still have to commit the
rename" here.  It is like saying in "git add" manpage that "You will still
have to commit the added contents" because "add" only affects the index
and does not make a commit.  Drop it.

      reply	other threads:[~2010-02-03 21:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03 18:25 git-mv redux: there must be something else going on Ron Garret
2010-02-03 18:48 ` Avery Pennarun
2010-02-03 19:23   ` Ron Garret
2010-02-03 19:47     ` Avery Pennarun
2010-02-03 20:30       ` Ron Garret
2010-02-03 19:53     ` Nicolas Pitre
2010-02-03 20:27       ` Ron Garret
2010-02-03 20:31         ` Ron Garret
2010-02-03 20:40         ` Avery Pennarun
2010-02-03 22:33           ` Ron Garret
2010-02-03 23:18             ` Avery Pennarun
2010-02-03 23:55               ` Jay Soffian
2010-02-04  0:10                 ` Ron Garret
2010-02-04  0:10               ` Ron Garret
2010-02-04  0:48             ` Junio C Hamano
2010-02-03 20:44         ` Nicolas Pitre
2010-02-03 20:12   ` Pete Harlan
2010-02-03 20:34     ` Ron Garret
2010-02-03 21:12       ` [PATCH] Documentation: clarify git-mv behaviour wrt dirty files Thomas Rast
2010-02-03 21:56         ` 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=7v3a1idlvg.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pgit@pcharlan.com \
    --cc=ron1@flownet.com \
    --cc=trast@student.ethz.ch \
    /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).