2 questions/nits about commit and config

Hi.

Well, I went ahead and put my current project under git. So far so good.

Two nits: (yeah, I'm a "recovering" CVS user)

1) git commit -m"this is a commit message"  doesn't work. 
   It has to have a space between -m and the first '"'. 
   I *think* this is due to git-commit.sh and how it parses
   the args, but I'm not quite sure of how to try to patch
   that without mucking up the whole works. Very odd
   and hard to figure out what was "wrong" for a CVS user.

2) I can descend into subdirectories in my project, and 
   git diff, git status both work fine, but git commit
   gets annoyed and says "fatal: Not a git repository: '.git'".
   Irksome to say the least, and not a little suprising.
   Is that something which can be fixed, or is there a 
   magic incantation (perhaps in .git/config) to make
   git commit work anywhere in the source tree?

Incidentally, I groped around my git mailbox, and google, looking for some definitive list/examples of what can go in the .git/config file. Seems there must be more than what is listed in the manpage...

Thanks for all the cool work.

Michael

Michael Fischer <michael@visv.net> writes:

Well that is a minor inconvenience and would be trivial to accomodate, but please do not send patches in yet. I do not know if you have been following the list discussion, but it seems very likely that we will update the way git-commit command works slightly in other semantic aspects and I do not want to worry about trivialities. Duly noted and I'll try to remember that command line parsing issue when we do a rewrite.

This is more or less deliberate, and I personally do not have a strong reason to change it (except perhaps making the error message a bit more helpful) even when we do a rewrite.

Unlike CVS that does version control per file basis, commit in git is really about the whole tree state, so even if we changed 'git commit' to work from subdirectories that would commit everything, which would probably be more confusing. That is, until somebody comes up with a good semantics and rationale why allowing that semantics is a good change and the code to do so.

An example of such semantic change would be: if I am in subdirecotry foo/, commit changes to files in that subdirectory and subdirectory alone. But that is actively _encouraging_ partial commits (commits that records a state that never existed in your working tree as a whole) so I personally am not so enthused to buy such a _feature_.

Junio C Hamano <junkio@cox.net> writes:

Before people start complaining about it, I take this part back. "git commit -a" inside a subdirectory "foo" is not much different from "git commit foo/a foo/b foo/c" from the toplevel directory to explicitly say "Don't worry about what I told the index so far; I want to check in changes only to these paths", and making a partial commit out of the current HEAD and the specified working tree files using a temporary index (while updating the main index at the same time), so I am inclined to say we should support it that way, since during the previous discussion we have pretty much settled how we would want "git commit paths..." and "git commit --include paths..." commands to behave.

On Saturday 04 February 2006 22:24, Junio C Hamano wrote:

And I did describe a use case this morning in another thread for this very thing. For convenience I repeat it here

[Incidentally there is a use case that doesn't seem to have been discussed in this thread which I use cg-commit all the time for and will now have to see if there is a use index file equivalence for.  That is, I am developing a web application and in the running version the database framework (iBatis) is using Tomcats connection pooling.  In order to run my JUnit test harness, I don't have tomcat, so I need to define a different version of iBatis configuration file to used its own database connection.  So I have created a test branch and edited the configuration file in that branch, and I update both code and tests in a edit/compile/fix and text loop until I have written or changed both code and tests.  I then do a cg-commit which lists the files I have changed.  I ONLY commit those in the test harness - by deleting the others from cogito's list of files to commit - and then repeat the commit commiting the rest].  I then switch back to my master branch and cherry pick commit that is the code changes - not the text harness]

In this case the tests, and the code that it was testing were in different subdirectories, so the ability to go into one directory and commit all in that directory, followed by the ability to go into the other and do the same would be extremely useful.

On Sat, 2006-02-04 at 14:24 -0800, Junio C Hamano wrote:

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...
  

Keith Packard <keithp@keithp.com> writes:

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.

Junio C Hamano <junkio@cox.net> writes:

Before I started writing this message, I meant to address an excellent point Carl Worth raised in an earlier thread. "What would I do for final sanity check before committing?". So here is a follow-up.

"git diff --cached HEAD".

This is for people who work by taking advantage of the power of the index file, i.e. perform "checking in without committing" by running update-index whenever the changes so-far look good. Combined use of "git diff --cached HEAD" (to look at diffs for paths other than paths...) and "git diff HEAD paths..." would be the _full_ "final sanity check", but in practice "git diff HEAD paths..." or even "git diff paths..." would be more useful for these people. They've verified the changes so-far were sane when they did update-index already.

"git diff HEAD paths...".

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

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.

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.

Agreed.

	-Daniel
*This .sig left intentionally blank*