Git commit won't add an untracked file given on the command line

Hi,

When I try: 

git commit -m "New file." .gitignore

Where .gitignore is not yet tracked, I get: 

error: pathspec '.gitignore' did not match any file(s) known to git.

Is that result by design, sloth or bug (or me being stupid)?

Thanks,

Mark

Le Tuesday 18 November 2008 22:12:37 Mark Burton, vous avez écrit :

You must "git add .gitignore" first. And yes, this is by design.

You could also have done git commit -a -m "themessage".

Hi Francis,

Err, that's a bit odd isn't it because "git add" stages the content into the index but the whole point of specifying files on the command line to "git commit" is to commit the changes in the specified files while ignoring what's currently in the index (so says the man page for commit).

Cheers,

Mark

Hi,

On Tue, 18 Nov 2008, Mark Burton wrote:

It may be a traditional wart, but a helpful one. Remember, you can also say:

	git commit that/directory/

I do _not_ want Git to add all untracked (and unignored) files in that directory automatically.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I agree, but it would kinda handy to have an exception for files explicitly named on the command line.

-Miles

Hi,

On Wed, 19 Nov 2008, Miles Bader wrote:

Only if you do not have a clear picture of what the staging area is about, IMHO.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

That's such a vague statement, I've not sure how to take it.

I use the staging area a lot, so I think I have a pretty clear idea of what it's "about", but I also often use "commit FILE" or "commit -a" for simple cases; even when splitting a change into multiple commits, it's often more convenient to do "commit FILE..." instead of "add FILE; commit".

I agree that having "commit DIR" add new files would likely be more annoying than helpful (it's not uncommon to have some temporary files laying around), but given that "commit FILE" is _explicitly_ naming the new file, it seems hard to imagine somebody would be surprised if it worked even when FILE was a new file...

-Miles

Hi,

On Wed, 19 Nov 2008, Miles Bader wrote:

What I meant was this: the "commit <file>" paradigm is not what you should do most of the time. In order to work with the staging area efficiently, you should make staging and committing two separate steps.

I regularly encounter people who never call "git diff --cached" before committing, and guess who introduces all kinds of debug statements and other cruft into their commits? Exactly.

So my point is this: stage first, verify, then commit. That saves you a lot of embarrassment.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

You seem to be saying that you think that using staging area explicitly is necessary or somehow "more efficient" for making good commits, but on the face of it, that's simply not true.

I'm extremely careful about committing clean changes, and do a lot of testing and pre-commit diffing. For complex changes which need to be split, the staging area is indeed a very useful tool, and I'm very glad git has it -- but it's hardly necessary for _all_ commits, and my experience is that in practice, many commits are indeed the simple sort which for which it's superfluous. My goal is not to "work with the staging area efficiently", it's to "make good/clean/tested commits, efficiently".

Obviously this depends on work style, and subject matter. Sometimes one _needs_ to make biggish changes and split them for commiting, and some people like to use that work style even when it's not strictly necessary. Other times, changes are more obviously independent, and can be done, tested, and commited in a serial fashion without any splitting.

Perhaps, given your work style or the type of work you, you use the staging area 99% of the time. For your case, maybe any git features which bypass the staging area are simply unneeded complexity. However, my own experience suggests that this is not universally true. I'd say I use the staging area for maybe 50% of commits.

One of the nice thing about git is the way that it tries to cater to multiple work styles, so it seems wrong to reject a useful feature simply because you want to "encourage" people to use your preferred work style, when that work style is not obviously better. [Of course there can be other good reasons to reject this feature -- maybe it's too dangerous or mucks up the code.]

[I'm not sure what the point of that was... for the record, no I'm not one of "those people". When I use the staging area, I use "git diff --cached"; when I don't use the staging area, I "git diff" instead...]

-Miles

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Yes, very much so.

Although it is conceivable that we may want to change that to behave more like "git add that/directory && git commit that/directory", that is a rather large UI semantics change (even if it could be a useful one) that needs to wait for a major version bump, perhaps in 1.7.0.

I think Mark's update to the documentation is a good thing to have in any case, so I've applied it.

Hi,

Yes, I can see the wisdom in not automatically adding the contents of a directory specified on the command line. So that's probably the answer to my original question.

As for "knowing what the staging area is about", I use the staging area almost all the time as I consider it one of git's major improvements over "traditional" SCM systems. I especially like how I can use tools like git gui to browse and select the changes to be staged for the next commit.

Having said that, I still like the concept of being able to add named files without touching the index.

Feature request for the git gui people:

  It would be nice if git gui was able to stage a highlighted region
  rather than either the whole hunk or just the line under the cursor
  as I believe it behaves now. I might be wrong but I don't think it
  can do that at the moment. I think that would be useful because
  although it's a step forward to be able to stage individual lines in
  a hunk, it can be laborious if you want to pick out more than just a
  couple of lines.

Cheers,

Mark

Hi,

On Wed, 19 Nov 2008, Mark Burton wrote:

That's just impossible. You cannot create a tree object, let alone a commit object, without touching the index (AKA staging area).

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I do not think Mark really _means_ "not in the index".

The wish is more like "I want to let git know that I am interested in this path, but I'm not ready to say what exact content I want for that path in the next commit, not just yet".

I do not think that is an unreasonable wish. On the other hand, it is unreasonable for anybody to insist that we satisfy the wish without touching the index. The index is the most natural place to do that.

We have a half (probably a quarter) of what we need for that implemented already, by the way.

Hi,

Sorry, poor choice of words on my part - you have to remember my viewpoint is one of user more than developer.

My wish was really just based on the advertised behaviour that specifying a file on the command line would commit the contents of that file while leaving the index intact. Whether the index was temporarily used/altered during the execution of the commit didn't cross my mind.

Hey, it's not a big deal and with the accepted patch to the documentation it need not take any more of anyone's time.

Cheers,

Mark

On Wed, 19 Nov 2008, Junio C Hamano wrote:

I don't think that's what Mark wants, in this case. He's looking for the ability to have "git commit" act on a temporary index created by adding to the parent commit explicitly named files which aren't in the non-temporary index. That is, Mark doesn't want to touch *the* index, which is fine; git can commit with *an* index.

I've looked into what you're suggesting on occasion; the main issue is getting the various index users to avoid getting confused. I was stumped by the diff code, which was confusing the "intent to add something" token with its "compare against the work tree" token. I'd say, it's half implemented, but testing is a major unstarted undertaking.

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow <barkalow@iabervon.org> writes:

Ah, I think that it would not be an entirely unreasonable thing to do (cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).

You can say "git add that/directory" and .gitignore mechanism protects you from crufts in that/directory, so fearing "git commit that/directory" to add random junk to the next commit is not a reason to fear it.

But that is a huge behaviour change. For example, I have a handful test scripts in my t/ directory (all named following the usual t????-*.sh naming convention) that I do not want to commit. Today, after making changes to the tracked test scripts, I can rely on "git commit t/" not to include them in the commit, and I've _learned_ to trust that behaviour. I'd be surprised if others who have used git for more than a few months haven't done so as well.

Allowing what Mark wants without any explicit user customization will be a disaster to the end user experience.

Hi,

If the ability to commit a currently untracked file/tree whilst preserving the index is really worth having (and that's debatable, as the git user community has survived until now without that capability) then another option (say, -O) could be added to git-commit that does what -o does but allows untracked files/trees to be specified - that way, the current behaviour would remain unchanged and the above mentioned disaster averted.

Cheers,

Mark

Mark Burton <markb@ordern.com> writes:

Heh, I apparently failed to convey what I wanted to say with "without any explicit user customization" part of my message. IOW, I think you are saying the same thing as what I wanted to say from the opposite angle.

On Wed, 19 Nov 2008, Junio C Hamano wrote:

There are two possible limits that would preserve your case while handling Mark's case: one is to only look at untracked files at all for names that don't match any tracked files, and the other (independantly) is to treat names as single filenames instead of patterns for untracked files.

Either of these (or both) should keep the existing behavior for using a pattern on the command line as a filter for which of the tracked files to commit (since any pattern of tracked files won't be the name of an individual untracked file).

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow <barkalow@iabervon.org> writes:

Perhaps. I am starting to think that "Did you forget to 'git add'?" is actually the best behaviour we can have ;-)

On  0, Mark Burton <markb@ordern.com> wrote:

git-cola can do that. http://cola.tuxfamily.org/

Francis Galiegue <fge@one2team.com> writes:

If it's by design, then it's a documentation bug:

     -o, --only
        Make a commit only from the paths specified on the
        command line, disregarding any contents that have been
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        staged so far. This is the default mode of operation of
        ^^^^^^^^^^^^^
        git-commit if any paths are given on the command line,

We have here a case where having staged content before doing commit -o actually changes its behavior.

Looking at the code, this happens because the "file" list is actually a pattern list (so that you can "git commit '*.txt'" or so), and the pattern is looked for in the index (the error is raised in "list_paths").

Well, he could have done that, but then the result would have been different ;-).