Daniel Barkalow [off-list ref] 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: [off-list ref]).
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,
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
On Wed, 19 Nov 2008, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
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: [off-list ref]).
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*