From: Matthias Andree <matthias.andree@gmx.de>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Wincent Colaiuta <win@wincent.com>,
Nicolas Pitre <nico@fluxnic.net>,
Jonathan Nieder <jrnieder@gmail.com>,
578764@bugs.debian.org, git@vger.kernel.org
Subject: Re: Please default to 'commit -a' when no changes were added
Date: Sat, 24 Apr 2010 00:35:41 +0200 [thread overview]
Message-ID: <4BD220BD.8090808@gmx.de> (raw)
In-Reply-To: <87aastx6sa.fsf@frosties.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]
Am 23.04.2010 22:17, schrieb Goswin von Brederlow:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
>>>
>>> You all say the index is such a great thing. So I might use it
>>> eventually. Other people might use it 1 out of 10 times. Yet other
>>> people use it 9 out of 10 times. Can you at least accept that the use of
>>> the index feature is different for each person?
>>>
>>> My suggested change, with the --a-if-empty option, would not impose
>>> anything on existing usage. But it would benefit those that rarely use
>>> an index and would like git to be smart enough to know when to use the
>>> index and when not. Yes, it would mean the use of the index ideology is
>>> not force upon people anymore. But isn't that a good thing? Free
>>> software is about freedom. That should include the freedom not to use
>>> the index method.
>>
>> Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.
>>
>> But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too.
>>
>> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.
>
> But you are already rejecting it in the design phase before there even
> is a patch.
>
>> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less "surprising" for users coming from other systems, but we'd be throwing away something valuable in the process.
>
> If I would ask to disable the indexing feature then you would have a
> point. But I am not. I'm asking to add something that allows to use git
> in a less "surprising" mode that, with the --a-if-empty option, does not
> alter anything else. Git would still have all its great, big, shiny,
> differentiating features to set it apart from other SCMs without forcing
> them down the users throat.
>
>> I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index "the Git way" bring, that it's hard to imagine how I ever lived without it.
>>
>> Cheers,
>> Wincent
>
> I personaly have to work with different SCMs every day and every time I
> have to switch minds to work with each specific one. Making git commit
> work less surprising would be one less thing to keep in mind.
You are trying to make Git more difficult to understand for the user.
This is easily perceived as non-determinism.
Before introducing a code branch (à la "if $(git diff-index --quiet
HEAD)", think twice. It doubles testing efforts, it makes explanations
long-winded. What's so difficult about typing
[Arrow-Up] [Space] [-] [a] [Enter] if git commit comes up empty.
With your option, I need to remember that Git is overzealous and will
commit the whole index if nothing is staged, possibly git reset HEAD^
and clean up the mess. This is inconsistent and inefficient.
Try git gui or git citool if you can't be bothered to remember how to
add changes to your commit. Git isn't alone. Think BitKeeper, DARCS.
For other systems, there are extensions to help with committing, and to
emulate what DARCS has pioneered, for instance "hg record", an extension
for Mercurial.
> You like that Git is different so don't use the --a-if-empty option. You
No. I for one like the ability to stage changes and commit logically
cohesive changes without having to save files to temporary files.
> will have lost nothing by allowing that option in. So far I have read
> arguments from people saying they don't want to USE the option. But no
> arguments why there could not be such an option. And I'm not the only
> one that would welcome such an option. Is there no room for a compromise?
"Bloat". If I were the maintainer, I'd point you to aliases. If Git
itself can't do it, tossing a dozen shell lines into git's libexec would
do the job. git diff-index --quiet is your friend.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]
next prev parent reply other threads:[~2010-04-23 22:35 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100422151037.2310.2429.reportbug@frosties.localdomain>
2010-04-22 15:58 ` Please default to 'commit -a' when no changes were added Jonathan Nieder
2010-04-22 18:37 ` Goswin von Brederlow
2010-04-22 19:03 ` Nicolas Pitre
2010-04-22 19:08 ` Sverre Rabbelier
2010-04-22 20:37 ` Goswin von Brederlow
2010-04-22 21:25 ` Nicolas Pitre
2010-04-23 9:03 ` Goswin von Brederlow
2010-04-23 9:31 ` Miles Bader
2010-04-23 16:01 ` Wincent Colaiuta
2010-04-23 20:17 ` Goswin von Brederlow
2010-04-23 20:26 ` Michael Witten
2010-04-23 20:33 ` Daniel Grace
2010-04-23 21:01 ` Nicolas Pitre
2010-04-24 21:15 ` Goswin von Brederlow
2010-04-24 21:40 ` Jonathan Nieder
2010-04-24 22:08 ` Goswin von Brederlow
2010-04-24 22:42 ` Jonathan Nieder
2010-04-25 2:47 ` Miles Bader
2010-04-25 3:33 ` Jonathan Nieder
2010-04-23 22:35 ` Matthias Andree [this message]
2010-04-24 1:43 ` Junio C Hamano
2010-04-22 21:28 ` Junio C Hamano
2010-04-22 21:40 ` Matthieu Moy
2010-04-22 21:57 ` Michael Witten
2010-04-23 9:09 ` Goswin von Brederlow
2010-04-23 9:22 ` Tomas Carnecky
2010-04-23 17:00 ` Michael Witten
2010-04-23 9:27 ` Matthieu Moy
2010-04-23 9:35 ` Tor Arntsen
2010-04-22 21:48 ` Adam Brewster
2010-04-22 22:27 ` Jonathan Nieder
2010-04-23 9:15 ` Goswin von Brederlow
2010-04-23 10:39 ` The index (Re: Please default to 'commit -a' when no changes were added) Jonathan Nieder
2010-04-22 22:38 ` Please default to 'commit -a' when no changes were added Jon Seymour
2010-04-23 0:04 ` Adam Brewster
2010-04-23 9:25 ` Goswin von Brederlow
2010-04-23 9:14 ` Goswin von Brederlow
2010-04-23 9:39 ` Björn Steinbrink
2010-04-23 11:44 ` Sergei Organov
2010-04-23 11:57 ` Sverre Rabbelier
2010-04-23 12:20 ` Sergei Organov
2010-04-23 14:23 ` Goswin von Brederlow
2010-04-23 18:59 ` Matthias Andree
2010-04-23 19:34 ` Michael Witten
2010-04-23 22:18 ` Matthias Andree
2010-04-23 22:25 ` Eric Raymond
2010-04-23 23:38 ` Michael Witten
2010-04-24 4:38 ` Eric Raymond
2010-04-24 9:05 ` Michael Witten
2010-04-24 9:09 ` Eric Raymond
2010-04-23 23:26 ` Michael Witten
2010-04-24 13:26 ` Tor Arntsen
2010-04-24 9:40 ` 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added) Jakub Narebski
2010-04-24 9:56 ` 'commit -a' safety Miles Bader
2010-04-24 10:05 ` Andreas Schwab
2010-04-24 10:26 ` Jakub Narebski
2010-04-24 13:29 ` Miles Bader
2010-04-24 18:23 ` Nicolas Pitre
2010-04-25 0:16 ` Jakub Narebski
2010-04-25 2:43 ` Miles Bader
2010-04-24 11:10 ` 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added) Wincent Colaiuta
2010-04-24 11:48 ` 'commit -a' safety Jakub Narebski
2010-04-24 14:28 ` Joey Hess
2010-04-24 15:11 ` Mike Hommey
2010-04-24 16:42 ` 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added) Petr Baudis
2010-04-24 16:59 ` Bug#578764: " Wincent Colaiuta
2010-04-24 17:47 ` Petr Baudis
2010-04-24 18:35 ` Nicolas Pitre
2010-04-24 18:54 ` Petr Baudis
2010-04-24 19:09 ` Nicolas Pitre
2010-04-24 19:35 ` Jacob Helwig
2010-04-24 19:44 ` Nicolas Pitre
2010-04-24 19:57 ` Jacob Helwig
2010-04-24 23:47 ` 'commit -a' safety Jakub Narebski
2010-04-25 1:13 ` Junio C Hamano
2010-04-25 8:01 ` Jakub Narebski
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=4BD220BD.8090808@gmx.de \
--to=matthias.andree@gmx.de \
--cc=578764@bugs.debian.org \
--cc=git@vger.kernel.org \
--cc=goswin-v-b@web.de \
--cc=jrnieder@gmail.com \
--cc=nico@fluxnic.net \
--cc=win@wincent.com \
/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).