From: Junio C Hamano <junkio@cox•net>
To: Keith Packard <keithp@keithp•com>
Cc: git@vger•kernel.org
Subject: Re: 2 questions/nits about commit and config
Date: Sat, 04 Feb 2006 21:43:29 -0800 [thread overview]
Message-ID: <7vu0bemkce.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <1139094055.4200.6.camel@evo.keithp.com> (Keith Packard's message of "Sat, 04 Feb 2006 15:00:54 -0800")
Keith Packard <keithp@keithp•com> writes:
> making '-a' equivalent to '.' then? Seems like '.' is a whole lot more
> understandable than '-a', but maybe that's just my naïvité showing
> again. I expected the '-a' flag to commit the whole tree from wherever
> you were inside it...
Good point.
Because I _never_ use 'git commit paths...' form myself, I
admit that I did not even know that "git commit ." meant
"commit all the changed files in this directory and under".
But it apparently does ;-).
I would not personally be confused if "cd foo/ && git commit -a"
committed things outside foo/ directory, but I am not sure about
others.
We have had enough discussion on what the "git commit paths.."
semantics should be, and I think we settled most of the issues.
Until this latest "committing from subdirectory" monkey wrench
was thrown into it, that is X-<.
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.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
So subdirectory semantics depends entirely on what we do for
the parameterless form. Also note that we allow --remove but
never --add; this is what we do for "git commit paths.."
currently.
- "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).
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.
next prev parent reply other threads:[~2006-02-05 5:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-04 21:23 2 questions/nits about commit and config Michael Fischer
2006-02-04 22:13 ` Junio C Hamano
2006-02-04 22:24 ` Junio C Hamano
2006-02-04 22:59 ` Alan Chandler
2006-02-04 23:00 ` Keith Packard
2006-02-05 5:43 ` Junio C Hamano [this message]
2006-02-05 5:58 ` Junio C Hamano
2006-02-05 6:14 ` Daniel Barkalow
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=7vu0bemkce.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=keithp@keithp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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