Re: 2 questions/nits about commit and config

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 5, 2006, 06:14 UTC
Message-ID: <Pine.LNX.4.64.0602050053280.6773@iabervon.org>
In-Reply-To: <7vu0bemkce.fsf@assigned-by-dhcp.cox.net>

On Sat, 4 Feb 2006, Junio C Hamano wrote:

Show 9 quoted lines

> Here is me thinking aloud again.
> 
>  - "git commit" without _any_ parameter would keep the current
>    behaviour.  It commits the current index.
> 
>    We have two choices.  (1) we disallow this form to be run in
>    a subdirectory, or (2) we do the whole index even when this
>    form was run from a subdirectory.  I am inclined to say the
>    latter.

I'd guess this would primarily happen when the user goes into a subdirectory to look at related files when resolving a conflicted merge. If you're committing the prepared index, the working tree isn't particularly important, so the pwd isn't, either.

Show 13 quoted lines

>  - "git commit paths..." acquires a new semantics.  This is an
>    incompatible change that needs user training, which I am
>    still a bit reluctant to swallow, but enough people seem to
>    have complained.  It
> 
>    1. refuses to run if $GIT_DIR/MERGE_HEAD exists (maybe
>       remind trained git users that the traditional semantics
>       now needs -i flag).
>    2. refuses to run if named paths... are different in HEAD and
>       the index (ditto about reminding).
>    3. reads HEAD commit into a temporary index file.
>    4. updates named paths... from the working tree in this
>       temporary index (similar to -i form, we never --add).

I think the following sequence should be permitted:

% git add foo % git commit foo

I think this means we want --add in step 4, but want to check that the named paths exist in the index in step 3, although they're allowed to not exist in HEAD.

Show 25 quoted lines

>    5. does the same updates of the paths... from the working
>       tree to the real index.
>    6. makes a commit using the temporary index that has the
>       current HEAD as the parent, and updates the HEAD with this
>       new commit.
> 
>    The first check is needed because otherwise during a merge
>    you would end up inserting an unrelated commit between the
>    original HEAD and the eventual merge result.  The second
>    check is to prevent "skewed commit" from confusing people.
>    If you updated index, modified the file further and then used
>    "git commit paths..." to make a commit, next "git commit"
>    without paths would record a partial revert otherwise.
> 
>    For this one, I think running from subdirectory is a natural
>    thing to allow.
> 
>  - "git commit --all".  Now what should we do about this?  As
>    you reminded me, it is equivalent to "git commit -i ." if run
>    from the toplevel (because of the "index must match HEAD on
>    named paths" requirements for the partial commits with named
>    paths, it is equivalent to "git commit ." only if your index
>    is clean).  I am inclined to say that this should commit all
>    changes in the whole working tree, regardless of where it is
>    run.

Agreed.

	-Daniel
*This .sig left intentionally blank*