From: "Patrick Häcker" <patrick.haecker@lss.uni-stuttgart.de>
To: git@vger.kernel.org
Subject: Improvement of git commit interface
Date: Fri, 6 May 2011 14:03:20 +0200 [thread overview]
Message-ID: <201105061403.27242.patrick.haecker@lss.uni-stuttgart.de> (raw)
[-- 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 --]
next reply other threads:[~2011-05-06 12:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 12:03 Patrick Häcker [this message]
2011-05-06 16:10 ` Improvement of git commit interface Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105061403.27242.patrick.haecker@lss.uni-stuttgart.de \
--to=patrick.haecker@lss.uni-stuttgart.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).