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

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

[Mark Burton]

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

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

[Francis Galiegue]

Le Tuesday 18 November 2008 22:12:37 Mark Burton, vous avez écrit :
> 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)?
>

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

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

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris

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

[Mark Burton]

Hi Francis,

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

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

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

[Johannes Schindelin]

Hi,

On Tue, 18 Nov 2008, Mark Burton wrote:

> Hi Francis,
> 
> > You must "git add .gitignore" first. And yes, this is by design.
> 
> 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).

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

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

[Miles Bader]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.

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

-Miles

-- 
Apologize, v. To lay the foundation for a future offense.

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

[Johannes Schindelin]

Hi,

On Wed, 19 Nov 2008, Miles Bader wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 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.
> 
> I agree, but it would kinda handy to have an exception for files 
> explicitly named on the command line.

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

Ciao,
Dscho

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

[Miles Bader]

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.
>
> Only if you do not have a clear picture of what the staging area is about, 
> IMHO.

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

-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

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

[Johannes Schindelin]

Hi,

On Wed, 19 Nov 2008, Miles Bader wrote:

> 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.
> >
> > Only if you do not have a clear picture of what the staging area is 
> > about, IMHO.
> 
> 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".

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

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

[Miles Bader]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 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".
>
> 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.
>
> So my point is this: stage first, verify, then commit.  That saves you a 
> lot of embarrassment.

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

[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

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

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

[Junio C Hamano]

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

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

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.

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

[Mark Burton]

Hi,

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

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

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

[Johannes Schindelin]

Hi,

On Wed, 19 Nov 2008, Mark Burton wrote:

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

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

Ciao,
Dscho

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

[Junio C Hamano]

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

> On Wed, 19 Nov 2008, Mark Burton wrote:
>
>> Having said that, I still like the concept of being able to add named 
>> files without touching the index.
>
> That's just impossible.  You cannot create a tree object, let alone a 
> commit object, without touching the index (AKA staging area).

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.

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

[Mark Burton]

Hi,

> > That's just impossible.  You cannot create a tree object, let alone a 
> > commit object, without touching the index (AKA staging area).
> 
> 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.

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

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

[Daniel Barkalow]

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Wed, 19 Nov 2008, Mark Burton wrote:
> >
> >> Having said that, I still like the concept of being able to add named 
> >> files without touching the index.
> >
> > That's just impossible.  You cannot create a tree object, let alone a 
> > commit object, without touching the index (AKA staging area).
> 
> 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.

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.

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

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*

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

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

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.

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

[Mark Burton]

Hi,

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

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

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

[Junio C Hamano]

Mark Burton <markb@ordern.com> writes:

>> Allowing what Mark wants without any explicit user customization will be a
>> disaster to the end user experience.
>
> 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.

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.

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

[Daniel Barkalow]

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

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > 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.
> 
> 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.

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*

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

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

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

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

[David Aguilar]

On  0, Mark Burton <markb@ordern.com> wrote:
> 
> Hi,
> 
> 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


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


-- 

	David

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

[Matthieu Moy]

Francis Galiegue <fge@one2team.com> writes:

> Le Tuesday 18 November 2008 22:12:37 Mark Burton, vous avez écrit :
>> 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)?
>>
>
> You must "git add .gitignore" first. And yes, this is by design.

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

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

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

-- 
Matthieu