From: Goswin von Brederlow <hidden> Date: 2016-06-15 22:48:41
Wincent Colaiuta [off-list ref] writes:
El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
quoted
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 like that Git is different so don't use the --a-if-empty option. You
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?
MfG
Goswin
From: Michael Witten <hidden> Date: 2016-06-15 22:48:41
On Fri, Apr 23, 2010 at 15:17, Goswin von Brederlow [off-list ref] wrote:
But you are already rejecting it in the design phase before there even
is a patch.
...
You like that Git is different so don't use the --a-if-empty option. You
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?
My sincere advice is just to write the patch and submit it with an
example usage to illustrate your feature.
Prose aren't well received on this list (especially without concrete
code to reference).
From: Daniel Grace <hidden> Date: 2016-06-15 22:48:41
On Fri, Apr 23, 2010 at 3:17 PM, Goswin von Brederlow [off-list ref] wrote:
Wincent Colaiuta [off-list ref] writes:
quoted
El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
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.
This is common in open-source. If you come to the mailing list talking
about a feature, without a patch, the maintainers let you know how
likely they are to want to write or maintain that feature. You haven't
given them a patch they could trivially merge in, so it reads as if
you're asking them to write the feature. Why write a feature that they
would never use?
Writing it yourself is one way to get a feature included that the
maintainers wouldn't use themselves. But you have to realize that
they're still thinking about having to maintain that feature. Every
new feature adds work to them, making sure that their future work does
not break it. There will be some features that are just deemed not
worth that effort by the people that control the official repository.
This is why forking is sometimes (rarely, but sometimes) acceptable.
quoted
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.
Nothing is being forced down anyones throat by Git. Git doesn't
somehow force you to use Git from here into eternity. You state later
that you *have* to use many different systems. But it's not Git that
forces you to do so.
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.
This sounds to me like you should try to simplify your setup. I know
that sometime it's not possible, but you're fighting an unwinnable
battle. If you're truly using that many different systems with
overlapping functionality you are destined to be confused. Period.
Most SCMs now do a good job of migrating data and in some cases (git
svn, for instance) sharing data on an ongoing basis. There are also
tools around that handle multiple SCMs behind one consistent
interface.
You like that Git is different so don't use the --a-if-empty option. You
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?
I'm not one of the maintainers, so maybe I'm speaking out of turn, but
as I pointed out above, they are losing something for letting in
options. They will have entered into an implied contract with their
users to keep that feature working in the future, putting a burden on
future development efforts. This is not without cost.
Daniel
http://www.doomstick.com
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:48:41
On Fri, 23 Apr 2010, Goswin von Brederlow wrote:
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.
Please make yourself some git aliases and your problem will be solved.
After all, the alias mechanism was created for a reason.
You like that Git is different so don't use the --a-if-empty option. You
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?
I suggest you have a look at all the examples (some are simple, some are
complex) here: https://git.wiki.kernel.org/index.php/Aliases. It should
be simple to make an alias with all the safety valves you might think
of, and then it could even be contributed to section 7 of that page.
Nicolas
Am 23.04.2010 22:17, schrieb Goswin von Brederlow:
Wincent Colaiuta [off-list ref] writes:
quoted
El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
quoted
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.
quoted
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.
quoted
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.