Re: Aborting "git commit --interactive" discards updates to index

From: demerphq <demerphq@gmail.com>
Date: Jan 7, 2012, 14:16 UTC
Message-ID: <CANgJU+WGEBMMQzsGyQSnMBK3Q8Z2XZdbDx4nr-tB-s0uYEU9CQ@mail.gmail.com>
In-Reply-To: <7vvcoogkw8.fsf@alter.siamese.dyndns.org>

On 7 January 2012 06:08, Junio C Hamano <gitster@pobox.com> wrote:

Show 27 quoted lines

> demerphq <demerphq@gmail.com> writes:
>
>> On 27 June 2011 17:59, Junio C Hamano <gitster@pobox.com> wrote:
>>> The latest feature release Git 1.7.6 is available at the usual
>>> places:
>>>
>>>  http://www.kernel.org/pub/software/scm/git/
>> [snip]
>>>  * Aborting "git commit --interactive" discards updates to the index
>>>   made during the interactive session.
>>
>> Hi, I am wondering why this change was made?
>
> I wasn't directly involved in this particular part of the design of what
> should happen to the index when a commit is aborted, so I would be a bad
> person to give you the first answer, but let's try.
>
> If a "commit" session is aborted, it is logical to revert whatever has
> been done inside that session as a single logical unit, so I do not
> particularly find the current behaviour so confusing. It might even make
> more sense if we update "commit -i" and "commit -a" to also revert the
> index modification when the command is aborted for consistency.
>
> You are welcome to rehash the age old discussion, though. Personally I do
> not care very deeply either way. I would never use "commit --interactive"
> myself, and I would not encourage others to use it, either, even if we do
> not worry about the behaviour when a commit is aborted.

If I were to provide a patch to make this behavior configurable would you have any objections? I personally much prefer the old behaviour. I want it to leave the stuff in my index.

Show 5 quoted lines

>
> One thread of interest (there are others, as this change was rerolled at
> least a few times) may be
>
>    http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173035

Thanks.

Show 8 quoted lines

> Having said all that,...
>
>> .... I am writing this after spending about 45 minutes showing a
>> colleague how to use git commit --interactive, when we realized that
>> we had forgotten to add a file....
>
> ... if your partial commit is so complex that you need to spend 45 minutes
> to sift what to be commited and what to be left out, you are much better

I was showing a colleague how to use the features it provides on a large patch where the committer wanted to keep various bits and not keep others.

> off to run "git add -i" to prepare the index, "git stash save -k" to check
> out what is to be committed (and stash away what are to be left out) so
> that you can make sure what you are committing is what you thought are
> committing (by asking "git diff" and "make test" for example), and after

Isnt this what the diff option in commit interactive is for? Personally I tend to review patches in detail before I push them, not necessarily before I commit them.

> convincing yourself that you made a good state in the index, make a commit
> with "git commit" (without any other arguments) and conclude it with "git
> stash pop" to recover the changes that you decided to leave out.

I personally have never had an issue with git commit --interactive so this procedure seems really convoluted to me, and a lot harder to teach to a colleague than "use git commit --interactive". Is there a real problem it solves?

> "commit --interactive" robs me from that crucial "verification" step, and
> that is why I wouldn't be a user or an advocate of this "misfeature".

I understand. But that is a workflow directed to statically testable library code. Our workflow doesn't really depend on a "make test" phase. Also, if I calling git commit --interactive (or git add -i), then I am as confident my code works as I can be, and the reason I am doing an interactive step is for instance to edit out debug lines, or separate out whitespace changes from code changes, or to break my change set into several logical groups.

> By the way, why did you draw Ævar into this discussion? I do not think he
> was involved in any way with the design or implementation of this command.

He is a git hacker, and is a friend and colleague. We both work for a largish dotcom which uses git as our primary version control and we have collaborated on a tool I wrote to use git to manage our rollout processes. So when something git comes up it is natural to me to CC him.

cheers, Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"