Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> That said, I actually think the newer "git read-tree -m" behaviour makes
> sense. So I think we're much better off adding "-i" to git-commit.sh, than
> to force "-i" on when doing the one-way merge. The latter change just
> effectively disables a possible check entirely, the former at least allows
> other users to actually use that form if they ever want to.
Thanks, I agree.
> (Looking at git-commit.sh, the thing I *really* think we should do is to
> have a "GIT_INDEX_FILE_OUTPUT" environment variable that does locking on
> the input file, but writes the result to another file: rigth now
> git-commit.sh (a) wastes time copying the old index file by hand and (b)
> as a result doesn't even honor any locking on it. I think whether it uses
> "-i" or not is actually less important - if you commit only a subset of
> files, maybe the extra checks in git-read-tree are actually ok?)
Good point on locking.
The reason missing -i matters because it defeats the previous
158d0577:
commit 158d0577891441c01457bbcaf45585d3b50f5d75
Author: Junio C Hamano <junkio@xxxxxxx>
Date: Sat Dec 9 22:32:43 2006 -0800
git-commit: allow --only to lose what was staged earlier.
The command used to have a safety valve to prevent this sequence:
edit foo
git update-index foo
edit foo
git diff foo
git commit --only foo
The reason for this was because an inexperienced user might
mistakenly think what is shown with the last-minute diff
contains all the change that is being committed (instead, what
the user asked to check was an incremental diff since what has
been staged so far). However, this turns out to only annoy
people who know what they are doing. Inexperienced people
would not be using the first "update-index" anyway, in which
case they would see the full changes in the "git diff".
Signed-off-by: Junio C Hamano <junkio@xxxxxxx>
and that is why I noticed this issue.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html