public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@imag•fr>
To: git@vger•kernel.org
Subject: Re: [FAQ?] Rationale for git's way to manage the index
Date: Sun, 06 May 2007 19:34:16 +0200	[thread overview]
Message-ID: <vpqk5vlamav.fsf@bauges.imag.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.0705061851411.4015@racer.site> (Johannes Schindelin's message of "Sun\, 6 May 2007 18\:51\:48 +0200 \(CEST\)")

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

> Hi,
>
> On Sun, 6 May 2007, Matthieu Moy wrote:
>
>> [...]
>>
>> % git satus -a
>> % git commit -a -m "..."
>> 
>> In the former case, I have more commands to type, and in the second
>> case, I loose part of the stat-cache benefit: If I run "git status -a"
>> twice, the second run will actually diff all the files touched since
>> the last run, since "git status -a" actually updated a temporary
>> index, and discarded it afterwards, so it doesn't update the stat
>> information in the index (while "git status" would have).
>
> Have you tried "git status" _without_ "-a"?

Reading my message (including the last 5 words of the sentence you're
quoting) would have told you that ;-).

>> In both cases, I can't really see the benefit.
>
> The benefit is a clear distinguishing between DWIM and low level. The 
> index contains _exactly_ what you told it to contain. 

In other systems, commit commits _exactly_ the content of files on
disk. And most people seem happy with that.

> By forcing users to use "-a" with "git commit",

Does this mean that the normal way to use "commit" is to use "-a"?

> you make it clear that a separate update steo is involved,

Well, with those kind of arguments, I could have my web browser not do
DNS resolution for me, because it would make it clear that a separate
step from HTTP request is involved. Still, this low-level thing brings
no benefit to the user, and I know no web browser forcing the user to
make this distinction.

> and if you made an error (which you see from the file list), you can
> abort, and start over with the original index.

You don't necessarily see your error from the file list:

% vi foo.c
% git add foo.c
% vi foo.c
% git commit -m foo
[...]
 create mode 100644 foo.c
%

This commited the old content of foo.c, while I hardly see any
scenario where this is the expected behavior.

Then, being able to repare the error if I made it is interesting, but
I don't get the reason why the error could not just be avoided.

Well, indeed, I just found a thread talking about this:

  http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html

I'll go through it, I might understand better after that ;-).

Thanks,

-- 
Matthieu

  reply	other threads:[~2007-05-06 17:34 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 16:10 [FAQ?] Rationale for git's way to manage the index Matthieu Moy
2007-05-06 16:51 ` Johannes Schindelin
2007-05-06 17:34   ` Matthieu Moy [this message]
2007-05-06 17:43     ` Junio C Hamano
2007-05-09 12:52       ` Petr Baudis
2007-05-09 13:57         ` Johannes Schindelin
2007-05-09 14:24           ` [PATCH] git-commit: Reformat log messages provided on commandline Petr Baudis
2007-05-09 14:59             ` Matthieu Moy
2007-05-09 15:11               ` Petr Baudis
2007-05-09 15:32                 ` Matthieu Moy
2007-05-09 15:01             ` Johannes Schindelin
2007-05-10  0:45             ` Junio C Hamano
2007-05-12  0:25               ` Jakub Narebski
2007-05-06 18:22     ` [FAQ?] Rationale for git's way to manage the index Dana How
2007-05-06 23:42     ` Johannes Schindelin
2007-05-06 17:25 ` Linus Torvalds
2007-05-06 18:23   ` Matthieu Moy
2007-05-06 19:54     ` Linus Torvalds
2007-05-06 22:53     ` Julian Phillips
2007-05-07  6:35       ` Karl Hasselström
2007-05-08  1:41         ` Shawn O. Pearce
2007-05-08  7:15           ` Johannes Sixt
2007-05-08 10:28             ` Karl Hasselström
2007-05-08 12:40               ` J. Bruce Fields
2007-05-08 14:53                 ` Karl Hasselström
2007-05-09  3:45                   ` J. Bruce Fields
2007-05-09  9:40                     ` Johannes Schindelin
2007-05-08  7:37           ` Karl Hasselström
2007-05-08 14:52             ` Shawn O. Pearce
2007-05-06 23:51     ` Johannes Schindelin
2007-05-07  8:02       ` Matthieu Moy
2007-05-07 11:05         ` Johannes Schindelin
2007-05-09 13:07           ` Petr Baudis
2007-05-08  3:16     ` Martin Langhoff
2007-05-08  4:45       ` Linus Torvalds
2007-05-08  5:35         ` Martin Langhoff
2007-05-09 13:41         ` Petr Baudis
2007-05-09 15:52           ` Linus Torvalds
2007-05-09 16:29             ` Carl Worth
2007-05-11  1:28               ` Jakub Narebski
     [not found]                 ` <7vd518gkyo.fsf@assigned-by-dhcp.cox.net>
2007-05-11 11:26                   ` Jakub Narebski
2007-05-11 16:45                     ` Junio C Hamano
2007-05-11 23:06                       ` Jakub Narebski
2007-05-12  0:40                         ` Junio C Hamano
2007-05-12  1:06                           ` Jakub Narebski
2007-05-12  9:35                           ` Jakub Narebski
2007-05-09 16:33             ` Dana How
2007-05-09 17:18               ` J. Bruce Fields
2007-05-09 17:26                 ` Petr Baudis
2007-05-09 17:29                   ` J. Bruce Fields
2007-05-09 17:39             ` Daniel Barkalow
2007-05-09 18:16               ` Linus Torvalds
2007-05-10  0:31             ` Junio C Hamano
2007-05-10  2:27               ` Steven Grimm
2007-05-10  2:39                 ` Linus Torvalds
2007-05-10  8:00                   ` Matthieu Moy
2007-05-10 22:06               ` Shawn O. Pearce
2007-05-10 22:51                 ` Petr Baudis
2007-05-08 11:07       ` Johannes Schindelin
2007-05-15  1:00         ` David Kågedal
2007-05-15 23:27           ` Johannes Schindelin
2007-05-09 17:18     ` Matthieu Moy
2007-05-07 11:40 ` Guilhem Bonnefille
2007-05-07 12:16   ` Karl Hasselström
2007-05-07 12:36     ` David Kastrup
2007-05-07 12:55   ` Johannes Schindelin
2007-05-07 19:31     ` Junio C Hamano
2007-05-09 13:14     ` Petr Baudis
2007-05-07 22:23   ` Daniel Barkalow
2007-05-15  0:57   ` David Kågedal
2007-05-15  8:29     ` Karl Hasselström

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=vpqk5vlamav.fsf@bauges.imag.fr \
    --to=matthieu.moy@imag$(echo .)fr \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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