git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

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