Improvement of git commit interface

Improvement of git commit interface

[Patrick Häcker]

[-- Attachment #1: Type: Text/Plain, Size: 2099 bytes --]

Hello,

I introduce git to students and thus see, where they have a harder time than 
necessary to understand git.

Thus, I was thinking about a CLI improvement regarding "git commit". It 
follows from the observation, that the staging area is a very valuable 
thing, but it should not be needed for very simple workflows and thus should 
not be the first concept, the students have to learn about.

After a file has been added to the repository once, you can use git without 
knowing anything about the staging area, with "git commit <filename>". 
Shouldn't we allow "git commit <filename>" for files never added to git, as 
well?
Then, IMHO this would be more consistent, as in a small project a typical 
commit (with a new file) consists of adding a new file to the repository and 
changing an existing file (e.g. to call a function located in the new file). 
ATM this is done with "git add <newfile> <oldfile> && git commit". But as we 
track content and not files, it were perfectly logical, if "git commit 
<newfile> <oldfile>" were possible, as then it were completely consistent to 
only change an existing file without adding a new file, which is "git commit 
<oldfile>".

So I suggest to change "git commit <filename>" so that if <filename> cannot 
be found in the repository, it is also looked for in the working directory 
and basically a "git add <filename> && git commit" is done if the <filename> 
is found.

I do _not_ suggest to change "git commit -a" to include all files never 
added to git, because that would be rather error prone. So after the change 
we would have an inconsistency between "git commit <newfile>" and "git 
commit -a", but I think this inconsistency is better than having the 
inconsistency between "git commit <oldfile>" and "git commit <newfile>".

Kind regards
Patrick

P.S. Please CC, as I am not subscribed


-- 
Patrick Häcker
Universität Stuttgart 
Lehrstuhl für Systemtheorie und Signalverarbeitung 
Tel: +49 711 685 67362
E-Mail: patrick.haecker@lss.uni-stuttgart.de
URL: http://www.lss.uni-stuttgart.de

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Improvement of git commit interface

[Junio C Hamano]

Patrick Häcker  <patrick.haecker@lss.uni-stuttgart.de> writes:

> After a file has been added to the repository once, you can use git without 
> knowing anything about the staging area, with "git commit <filename>". 
> Shouldn't we allow "git commit <filename>" for files never added to git, as 
> well?

This and its extreme form "git commit *" (also "git update-index *"), do
not to touch untracked files. It was a very conscious and deliberate
design to avoid mistakenly adding unnecessary/unwanted cruft, e.g. object
files and editor backups, to the index.  The primary reason we were extra
careful about adding cruft by fat fingers was because these operations
came before we had usable .gitignore support (in other words, this design
is back from Linus's git days in early 2005).

In theory, as we have gitignore support, we now could change them and the
end result would arguably be more consistent _as long as_ you always
maintain spiffy-clean gitignore list, but you need a very careful planning
to migrate existing scripts and millions of users' fingers without
breaking them.  Currently, the safety kicks in if you do this:

	$ >testing-01.c
        $ git commit *.c *.h
	error: pathspec 'testing-01.c' did ot match any file(s) known...

and people are used to and do rely on this safety to keep them from
accidentally committing throw-away experiments, debugging aids, etc.  You
could argue that people _should_ teach their gitignore about "testing-*.c"
but in practice that won't fly because throw-away stuff bye their own
nature come and go without planning, and catching things in gitingore
pattern is all about planning.

> I do _not_ suggest to change "git commit -a" to include all files never 
> added to git, because that would be rather error prone.

We discussed "git commit -A" for this exact purpose in the past.  It is
just as error prone as making "git commit *" to add new paths, but "-A"
has a distinct advantage that it is _explicitly_ asking to add new paths,
and also it did not exist so there is no migration to worry about.

> P.S. Please CC, as I am not subscribed

No need to say this, as the convention on this list is never cull Cc:
unless there is a good reason.