What is missing from Git v2.0

What is missing from Git v2.0

[Felipe Contreras]

Hi,

I had already given up on merging important features to Git upstream,
and then one of the features I've had in git-fc (my fork) for quite
some time suddenly got attention (the @{publish} branch), but
everybody forgot I already did the work. So maybe there's other
features in a similar situation.

= The publish tracking branch =

Git's triangular workflow support is definitely lacking, and although
there are many ideas and workarounds, the simplest and most
user-friendly way to fix the issues is by introducing the concept of a
publish tracking branch, similar to the upstream tracking branch.

Fortunately this might actually get into v2.0.

[1][2]

= Reject non-fast-forward pulls by default =

Many new-comers end up making merges by mistake when they pull because
they don't understand what is a non-fast-forward and what they should
actually be doing. Most people, even Linus Torvalds, agreed that by
default `git pull` should fail and guide the user, instead of silently
making a merge which might not be what the user wants (even though he
doesn't know it), and messing up the project's history, which affects
other people.

The patches were sent, the issues were addressed, people agreed, and
yet nothing happened.

[3][4]

= Use "stage" instead of "index" =

Everybody, and by everybody I literally mean everyone except Junio,
have agreed that "index" is a horrible name of the high-level concept
(not the actual index file) of the pace where the user drafts a
commit. Different actions were proposed to move towards a saner name,
and the simplest sensible one seems to be to start renaming the
confusing --cached and --index options to --stage and --no-work, and
also to add a new `git stage` command.

Nothing happened.

[5][6][7][8]

= Default aliases =

Every single version control tool out there has default aliases (e.g.
co = checkout) except Git.

Every argument against default aliases was basically refuted, yet my
patches went nowhere. And the users still expect these aliases.

[9]

[1] http://thread.gmane.org/gmane.comp.version-control.git/235981
[2] http://thread.gmane.org/gmane.comp.version-control.git/240030
[3] http://thread.gmane.org/gmane.comp.version-control.git/240030
[4] http://thread.gmane.org/gmane.comp.version-control.git/235981
[5] http://thread.gmane.org/gmane.comp.version-control.git/233295
[6] http://thread.gmane.org/gmane.comp.version-control.git/197111
[7] http://thread.gmane.org/gmane.comp.version-control.git/166675
[8] http://thread.gmane.org/gmane.comp.version-control.git/115666
[9] http://thread.gmane.org/gmane.comp.version-control.git/235145

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Felipe Contreras]

On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

> [3] http://thread.gmane.org/gmane.comp.version-control.git/240030
> [4] http://thread.gmane.org/gmane.comp.version-control.git/235981

Actually:

[3] http://thread.gmane.org/gmane.comp.version-control.git/233554
[4] http://thread.gmane.org/gmane.comp.version-control.git/234295

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Sebastian Schuberth]

On 21.04.2014 00:41, Felipe Contreras wrote:

> = Default aliases =
>
> Every single version control tool out there has default aliases (e.g.
> co = checkout) except Git.
>
> Every argument against default aliases was basically refuted, yet my
> patches went nowhere. And the users still expect these aliases.

+1 about having default aliases in general, and I'd also add these:

br = branch
cp = cherry-pick
dt = difftool
mt = mergetool

BTW, in my experience people tend to stick to predefined aliases instead 
of redefining them to something (completely) different. This means that 
having default aliases will very likely enable one to use the same short 
commands on one's colleague's PC (instead of you running into issues 
because the same alias was defined to a different command).

If we don't standardize this now people will come up with their own 
definitions [1] [2] (and many others if you just search GitHub) which 
are again likely to differ (slightly), hindering interoperability.

[1] https://github.com/github/msysgit/pull/27
[2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig

-- 
Sebastian Schuberth

Re: What is missing from Git v2.0

[Felipe Contreras]

Sebastian Schuberth wrote:
> On 21.04.2014 00:41, Felipe Contreras wrote:
> 
> > = Default aliases =
> >
> > Every single version control tool out there has default aliases (e.g.
> > co = checkout) except Git.
> >
> > Every argument against default aliases was basically refuted, yet my
> > patches went nowhere. And the users still expect these aliases.
> 
> +1 about having default aliases in general, and I'd also add these:
> 
> br = branch
> cp = cherry-pick
> dt = difftool
> mt = mergetool

I have these aliases as well, except br => b, and cp => pi. 'br' is probably
better, but not sure as 'cp' which can be confusing.

> BTW, in my experience people tend to stick to predefined aliases instead 
> of redefining them to something (completely) different. This means that 
> having default aliases will very likely enable one to use the same short 
> commands on one's colleague's PC (instead of you running into issues 
> because the same alias was defined to a different command).
> 
> If we don't standardize this now people will come up with their own 
> definitions [1] [2] (and many others if you just search GitHub) which 
> are again likely to differ (slightly), hindering interoperability.
> 
> [1] https://github.com/github/msysgit/pull/27
> [2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig

FTR color.ui = true is not needed any more, also hopefully mergetool.prompt =
false wouldn't be either [1].

[1] http://article.gmane.org/gmane.comp.version-control.git/246601

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Sebastian Schuberth]

On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

> I have these aliases as well, except br => b, and cp => pi. 'br' is probably
> better, but not sure as 'cp' which can be confusing.

If by confusing you refer to "cp" to copy files, that's actually what
I like about it: cherry-pick is somewhat like copying commits, thus
"cp" makes much sense to me.

> FTR color.ui = true is not needed any more, also hopefully mergetool.prompt =
> false wouldn't be either [1].

Thanks!

-- 
Sebastian Schuberth

Re: What is missing from Git v2.0

[Theodore Ts'o]

On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> 
> > I have these aliases as well, except br => b, and cp => pi. 'br' is probably
> > better, but not sure as 'cp' which can be confusing.
> 
> If by confusing you refer to "cp" to copy files, that's actually what
> I like about it: cherry-pick is somewhat like copying commits, thus
> "cp" makes much sense to me.

The problem is that between "git rm" and "git mv", if we default "git
cp" to mean "cherry-pick" there could easily be user confusion.

I'm not sure that cherry-pick is used that often it really needs a two
character shortcut.  Maybe just "git pick"?

Personally, "git branch" and "git checkout" are finger macros that I
type very quickly, so creating two character alias probably wouldn't
save me that much time.  But I do appreicate that there are folks for
which such aliases might be useful.

						- Ted

Re: What is missing from Git v2.0

[Felipe Contreras]

Theodore Ts'o wrote:
> On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> > On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > 
> > > I have these aliases as well, except br => b, and cp => pi. 'br' is probably
> > > better, but not sure as 'cp' which can be confusing.
> > 
> > If by confusing you refer to "cp" to copy files, that's actually what
> > I like about it: cherry-pick is somewhat like copying commits, thus
> > "cp" makes much sense to me.
> 
> The problem is that between "git rm" and "git mv", if we default "git
> cp" to mean "cherry-pick" there could easily be user confusion.
> 
> I'm not sure that cherry-pick is used that often it really needs a two
> character shortcut.  Maybe just "git pick"?

I'm in favor of having both 'git pick', and 'git pi'.

> Personally, "git branch" and "git checkout" are finger macros that I
> type very quickly, so creating two character alias probably wouldn't
> save me that much time.  But I do appreicate that there are folks for
> which such aliases might be useful.

I bet I can type 'g b' and 'g co' faster :)

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Sebastian Schuberth]

On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

>> The problem is that between "git rm" and "git mv", if we default "git
>> cp" to mean "cherry-pick" there could easily be user confusion.
>>
>> I'm not sure that cherry-pick is used that often it really needs a two
>> character shortcut.  Maybe just "git pick"?
>
> I'm in favor of having both 'git pick', and 'git pi'.

Please let's stick to one clear default alias for some central
commands, and not introduce ambiguity between aliases. That said, I'd
prefer pick over pi, but still cp would be my personal favorite.

-- 
Sebastian Schuberth

Re: What is missing from Git v2.0

[Felipe Contreras]

Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> 
> >> The problem is that between "git rm" and "git mv", if we default "git
> >> cp" to mean "cherry-pick" there could easily be user confusion.
> >>
> >> I'm not sure that cherry-pick is used that often it really needs a two
> >> character shortcut.  Maybe just "git pick"?
> >
> > I'm in favor of having both 'git pick', and 'git pi'.
> 
> Please let's stick to one clear default alias for some central
> commands, and not introduce ambiguity between aliases. That said, I'd
> prefer pick over pi, but still cp would be my personal favorite.

I think porcelain commands should eventually change names (and maybe become
more friendly) 'git ls-files' => 'git ls', 'git cherry-pick' => 'git pick', and
so on.

If 'cherry-pick' evolves into 'pick', it would make sense to have the 'pi'
alias, and in preparation for that I don't see why a temporary 'pick' alias
would hurt.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Junio C Hamano]

Sebastian Schuberth <sschuberth@gmail.com> writes:

>> Every argument against default aliases was basically refuted, yet my
>> patches went nowhere. And the users still expect these aliases.
>
> +1 about having default aliases in general, and I'd also add these:

I think it might be OK to implement them as the lowest priority
fallback alias, so that '[alias] co = "user's definition"' anywhere
in the various configuration locations will override it.  I am a bit
hesitant about adding start-up overhead, though.  Also I am not sure
if people can agree with (1) a broadly wide selection of aliases and
(2) the actual definitions for them (I am OK with "co === checkout"
myself, but I'd rather not to even think about my Git wasting cycles
parsing extra configuration items to support "br === branch" at all,
for example).

If we squat on "co" and other short-and-sweet friends by adding them
as built-in aliases (i.e by adding them to git.c:commands[]), the
only effect would be to annoy people who have them defined somewhat
slightly differently, so that won't fly well.

> If we don't standardize this now people will come up with their own
> definitions [1] [2] (and many others if you just search GitHub) which
> are again likely to differ (slightly), hindering interoperability.

I am afraid that that ship has sailed long time ago, though.

Re: What is missing from Git v2.0

[Sebastian Schuberth]

On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:

>> If we don't standardize this now people will come up with their own
>> definitions [1] [2] (and many others if you just search GitHub) which
>> are again likely to differ (slightly), hindering interoperability.
>
> I am afraid that that ship has sailed long time ago, though.

That's most likely true, but it does not get better by postponing this
even more. I still think there's value in introducing this now, Git
still attracts new developers every day. In fact, I currently see a
leap forwarding in the Windows world towards Git, caused by some
rethinking and structural changes in some big companies.

-- 
Sebastian Schuberth

Re: What is missing from Git v2.0

[Felipe Contreras]

Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> >> If we don't standardize this now people will come up with their own
> >> definitions [1] [2] (and many others if you just search GitHub) which
> >> are again likely to differ (slightly), hindering interoperability.
> >
> > I am afraid that that ship has sailed long time ago, though.
> 
> That's most likely true, but it does not get better by postponing this
> even more. I still think there's value in introducing this now, Git
> still attracts new developers every day. In fact, I currently see a
> leap forwarding in the Windows world towards Git, caused by some
> rethinking and structural changes in some big companies.

Exactly. If one thinks in terms of years, sure, it might make sense to not
change the status quo created by years back. But think about Git in a decade or
two, at that point surely you would have wished that you had considered these
kinds of changes sooner.

Junio at some point suggested to think about features for v1.8.0 as if we were
starting from scratch[1]. I'd say if there has every been a time to add default
aliases after v1.0 it's certainly v2.0.

Our future users who might have not touched Git yet would certainly welcome
this.

[1] http://article.gmane.org/gmane.comp.version-control.git/165735

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Junio C Hamano]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>>> If we don't standardize this now people will come up with their own
>>> definitions [1] [2] (and many others if you just search GitHub) which
>>> are again likely to differ (slightly), hindering interoperability.
>>
>> I am afraid that that ship has sailed long time ago, though.
>
> That's most likely true, but it does not get better by postponing this
> even more.

As I already said:

    I think it might be OK to implement them as the lowest priority
    fallback alias, so that '[alias] co = "user's definition"'
    anywhere in the various configuration locations will override
    it.  I am a bit hesitant about adding start-up overhead, though.
    Also I am not sure if people can agree with (1) a broadly wide
    selection of aliases and (2) the actual definitions for them (I
    am OK with "co === checkout" myself, but I'd rather not to even
    think about my Git wasting cycles parsing extra configuration
    items to support "br === branch" at all, for example).

I am not fundamentally opposed.  I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.

A few thinking points that are necessary to be worked out, even
before we start imagining a plan to introduce them, off the top of
my head, are these:

 * Should we add many random aliases, or should we limit ourselves
   only to a narrow set that everybody can agree on?

 * What is the additional cognitive load do we feel comfortable
   burdening with the new users?

 * What is the exact mechanism to give these built-in aliases?

Imagine that somebody says "[alias] ci = commit" and a handful of
vocal people on this list agree that it is a good idea.  Many random
websites start mentioning "git ci -a" in their beginner examples.

Users are led to think "ci" is a command just like "commit" and does
the same thing.  Some of them want to always commit everything
before moving to their next task, and want to alias it further, e.g.
"[alias] ci = ci -a"---which would not work.  At that point, the
users need to learn the distinction between native subcommands
(e.g. "commit"), built-in fallback aliases (e.g. "ci") and aliases
of their own in their ~/.gitconfig, and need to learn that only the
first kind and not the second kind cannot be used to define their
own alias (and the users need to learn "commit" at that time as
well).

That could be solved by making "ci" not a built-in fallback alias,
but a new subcommand (then there is no "'foo' in 'git foo' could be
a command or a built-in alias and they behave differently" issue),
and additionally somehow allowing a native subcommand overriden by
end-user alias, but I do not think anybody designed how such an
override would work so far.

So even if we agree that it would be a good idea to have some
default fallback aliases, the set of such aliases we ship must be
limited to a set that everybody can agree on, both in the sense that
"adding alias XX is good" and also in the sense that "alias XX must
be defined as YY".

As you allueded to, the Git userbase is a lot larger than it used to
be back in 2006, one alias, e.g. "[alias] br = branch", that is
reported as either useless or needed to be further tweaked by a
person on this list would mean that we would be either spending
unnecessary start-up cycles (for "useless" case) or adding cognitive
load of having to differente between "branch" and "br" (for "needs
further tweak" case) for thousands of users who would be better off
if we didn't have that specific alias.

So while I understand the desire to have a bit more handholding and
am not fundamentally opposed to the desire, I am not optimistic that
an attempt to implement these "aliases" would result in a very
useful addition to the system, even if done after careful thought.

In any case, this definitely is not a 2.0 material.  I agree that it
would be good to start discussing it early (rather than later) if we
ever want to do such a change.

Re: What is missing from Git v2.0

[Felipe Contreras]

Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:
> 
> > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >>> If we don't standardize this now people will come up with their own
> >>> definitions [1] [2] (and many others if you just search GitHub) which
> >>> are again likely to differ (slightly), hindering interoperability.
> >>
> >> I am afraid that that ship has sailed long time ago, though.
> >
> > That's most likely true, but it does not get better by postponing this
> > even more.
> 
> As I already said:
> 
>     I think it might be OK to implement them as the lowest priority
>     fallback alias, so that '[alias] co = "user's definition"'
>     anywhere in the various configuration locations will override
>     it.  I am a bit hesitant about adding start-up overhead, though.
>     Also I am not sure if people can agree with (1) a broadly wide
>     selection of aliases and (2) the actual definitions for them (I
>     am OK with "co === checkout" myself, but I'd rather not to even
>     think about my Git wasting cycles parsing extra configuration
>     items to support "br === branch" at all, for example).
> 
> I am not fundamentally opposed.  I just do not think it would add
> much value to new people at this point, and it will actively hurt
> if we shoved barely cooked one in 2.0.

You are probably biased in that you've used Git far much more than the average
user has (or future new users).

> So even if we agree that it would be a good idea to have some
> default fallback aliases, the set of such aliases we ship must be
> limited to a set that everybody can agree on, both in the sense that
> "adding alias XX is good" and also in the sense that "alias XX must
> be defined as YY".
> 
> As you allueded to, the Git userbase is a lot larger than it used to
> be back in 2006, one alias, e.g. "[alias] br = branch", that is
> reported as either useless or needed to be further tweaked by a
> person on this list would mean that we would be either spending
> unnecessary start-up cycles (for "useless" case) or adding cognitive
> load of having to differente between "branch" and "br" (for "needs
> further tweak" case) for thousands of users who would be better off
> if we didn't have that specific alias.

I think it's reasonable to follow these guidelines:

 1) Each default alias should have two characters
 2) Each default alias should map to a command without arguments
 3) Each default alias be widely used in the wild

This set matches the above:

  co = checkout
  ci = commit
  rb = rebase
  st = status
  br = branch
  dt = difftool
  mt = mergetool

You might not like 'br', but there's tons of people already using that alias,
so it's not "useless". I can go find links to many examples if you would like.

> So while I understand the desire to have a bit more handholding and
> am not fundamentally opposed to the desire, I am not optimistic that
> an attempt to implement these "aliases" would result in a very
> useful addition to the system, even if done after careful thought.

The fact that you are not optimistic about it doesn't mean it's impossible.

> In any case, this definitely is not a 2.0 material.  I agree that it
> would be good to start discussing it early (rather than later) if we
> ever want to do such a change.

Why is not material for v2.0? Because you say so? Are you going to wait another
ten years to introduce this to v3.0?

This is actually the perfect time to do it.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Matthieu Moy]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Why is not material for v2.0? Because you say so? Are you going to wait another
> ten years to introduce this to v3.0?

There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to user-defined aliases, there's no backward
compatibility issue, it can very well be a 2.1, or whatever number comes
after 2.0.

> This is actually the perfect time to do it.

Junio has just tagged a -rc for 2.0, so it's clearly too late to start
discussing new features for this particular release.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: What is missing from Git v2.0

[Felipe Contreras]

Matthieu Moy wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Why is not material for v2.0? Because you say so? Are you going to wait another
> > ten years to introduce this to v3.0?
> 
> There's no need to wait for a 3.0 to introduce this. If these would
> be low-priority compared to user-defined aliases, there's no backward
> compatibility issue, it can very well be a 2.1, or whatever number comes
> after 2.0.

Can it? I would like Junio to say so.

Still, v2.0 is a better time for this.

> > This is actually the perfect time to do it.
> 
> Junio has just tagged a -rc for 2.0, so it's clearly too late to start
> discussing new features for this particular release.

And whose fault is that? I never saw any warning about the -rc tag, and I never
saw any discussion about possible features missing in v2.0.

Given that the next backward-incompatible release might be in a decade, I would
have expected people to have put more thought into v2.0, but I guess the Git
project is not really interested in progressive features.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Why is not material for v2.0? Because you say so? Are you going to wait another
>> ten years to introduce this to v3.0?
>
> There's no need to wait for a 3.0 to introduce this. If these would
> be low-priority compared to user-defined aliases, there's no backward
> compatibility issue, it can very well be a 2.1, or whatever number comes
> after 2.0.

I do not think the discussion has analysed the issue deeply enough
for us to tell what the final proposal would look like, in order to
judge what kind of issues, whether related to backward compatibility
or not, are involved.  My hunch is that this may not have to wait
for a big version bump, but I am not sure about that at this point.

Also I do not think 3.0 has to wait for ten years, either.

We started discussing incompatible updates for 2.0 in earnest during
the v1.8.2 timeframe, which was tagged mid-March 2013 with a release
notes with a "B/c notes for 2.0" section, but IIRC the discussion of
many of the "let's make things consistent (even if that means we
have to break existing users), and devise ways to make the transtion
for them as smooth as possible" changes that finally is going to
happen in v2.0 have been in the works since the v1.7.x era (tagged
late January 2012).  While I do not want to rush things late in a
cycle (notice how many topics are still cooking in 'next' and will
continue to be in preparation for 2.1 right now), I do not think it
is warranted to have a panic "3.0 will be ten years out, and we will
miss the boat if we do not cram this in some shape into 2.0"---that
kind of haste simply is not necessary.

Even if we end up having to wait for 3.0, it will happen within two
years max, if not earlier.

Re: What is missing from Git v2.0

[Theodore Ts'o]

On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
> > I am not fundamentally opposed.  I just do not think it would add
> > much value to new people at this point, and it will actively hurt
> > if we shoved barely cooked one in 2.0.
> 
> You are probably biased in that you've used Git far much more than
> the average user has (or future new users).

I think Junio has a really strong point.  If the goal is to make life
easier for new users, allowing them to save a few keystrokes is
probably not the most significant thing we can do.  And we have to
balance this with the additional cognitive load in remembering how a
particular two character alias maps to the "real" command.  This is
especially true for commands which might not be used as often -- e.g.,
"rebase", and for commands where the meaning of "git commit" without
any argument is qualitatively different from what "ci" (for checkin)
means in most other source management systems.

So I do think it's worth thinking about this very carefully.  For
certain, I would **not** recommend using shortcuts in example command
sequences.  If the user reads "git rebase" or "git cherry-pick" it
means a lot more than if they see a series of apparent chicken
scratches filled with things like "git rb", "git pi", "git st", etc.

In fact, to be fair, you may be getting biased because you're used to
using the two character shortcuts, so for you, of *course* "rb" and
"pi" and "ci" make a lot of sense.  But for someone who is starting
from scratch, I really question how much it helps, and how much it
might hurt, to see the two character shortcuts or even to have to
remember the two character shortcuts.  And for a command like "rebase"
where the user can very easily shoot themselves in the foot to begin
with, I'd actually suggest that it's a _good_ thing that they have to
type it out in full.

						- Ted

Re: What is missing from Git v2.0

[Felipe Contreras]

Theodore Ts'o wrote:
> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
> > > I am not fundamentally opposed.  I just do not think it would add
> > > much value to new people at this point, and it will actively hurt
> > > if we shoved barely cooked one in 2.0.
> > 
> > You are probably biased in that you've used Git far much more than
> > the average user has (or future new users).
> 
> I think Junio has a really strong point.

What is that point?

> If the goal is to make life easier for new users, allowing them to save a few
> keystrokes is probably not the most significant thing we can do.

No, but it's *one* thing we can definetly do, and since we are not doing
anything else, we might as well do this one thing.

> And we have to balance this with the additional cognitive load in remembering
> how a particular two character alias maps to the "real" command.

What cognitive load? You don't *need* to remember the default aliases; you
don't need to use them at all.

> This is especially true for commands which might not be used as often --
> e.g., "rebase", and for commands where the meaning of "git commit" without
> any argument is qualitatively different from what "ci" (for checkin) means in
> most other source management systems.

ci means commit in Mercurial.

> So I do think it's worth thinking about this very carefully.  For
> certain, I would **not** recommend using shortcuts in example command
> sequences.  If the user reads "git rebase" or "git cherry-pick" it
> means a lot more than if they see a series of apparent chicken
> scratches filled with things like "git rb", "git pi", "git st", etc.

Certainly, but that is orthogonal.

> In fact, to be fair, you may be getting biased because you're used to
> using the two character shortcuts, so for you, of *course* "rb" and
> "pi" and "ci" make a lot of sense.

I can't be biased to those because I don't use them, mine are one character
shortcuts.

And if that hypothesis was correct, why does Mercurial, Bazaar, Subversion,
CVS, and pretty much everything uses aliases? And why does pretty much every
.gitconfig has similar aliases? That would imply that the whole world is
biased.

> But for someone who is starting from scratch, I really question how much it
> helps, and how much it might hurt, to see the two character shortcuts or even
> to have to remember the two character shortcuts.

Here you are talking from your own bias.

It would help when the user starts to think "Geez, I seem to be typing
`git checkout` an awful lot, I wonder if there's a shortcut", which if the
.gitconfigs out there are any indication, it happens all the time.

> And for a command like "rebase" where the user can very easily shoot
> themselves in the foot to begin with, I'd actually suggest that it's a _good_
> thing that they have to type it out in full.

And now you contradict yourself; you actually want to make life harder for new
users, on purpose.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Theodore Ts'o wrote:
>
>> This is especially true for commands which might not be used as often
>> -- e.g., "rebase", and for commands where the meaning of "git commit"
>> without any argument is qualitatively different from what "ci" (for
>> checkin) means in most other source management systems.
>
> ci means commit in Mercurial.

Does it mean "commit the staging area"?

>> In fact, to be fair, you may be getting biased because you're used to
>> using the two character shortcuts, so for you, of *course* "rb" and
>> "pi" and "ci" make a lot of sense.
>
> I can't be biased to those because I don't use them, mine are one
> character shortcuts.

Which you created yourself, on your own responsibility.

> And if that hypothesis was correct, why does Mercurial, Bazaar,
> Subversion, CVS, and pretty much everything uses aliases? And why does
> pretty much every .gitconfig has similar aliases? That would imply
> that the whole world is biased.

Most .profile files define aliases as well.  Doing this on the user's
initiative is harmless since it will not have its usage leak into
scripts intended for use by others.

> It would help when the user starts to think "Geez, I seem to be typing
> `git checkout` an awful lot, I wonder if there's a shortcut", which if
> the .gitconfigs out there are any indication, it happens all the time.

Actually, it happens very rarely if you are talking about _real_
gitconfigs deployed by projects as compared to _sample_ gitconfigs
demonstrating Git features for _personal_ rather than project-wide use.

>> And for a command like "rebase" where the user can very easily shoot
>> themselves in the foot to begin with, I'd actually suggest that it's
>> a _good_ thing that they have to type it out in full.
>
> And now you contradict yourself; you actually want to make life harder
> for new users, on purpose.

Life's hardness is not proportional to the number of typed characters or
APL would be the easiest programming language narrowly followed by Perl.
Life does not become easier by lowering input redundancy until it
becomes hard to tell apart from line noise.  Keyboards are highly
efficient input devices, or we would not be conversing in whole
sentences in technical mailing lists but rather in telegraphy style.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Theodore Ts'o wrote:
> >
> >> This is especially true for commands which might not be used as often
> >> -- e.g., "rebase", and for commands where the meaning of "git commit"
> >> without any argument is qualitatively different from what "ci" (for
> >> checkin) means in most other source management systems.
> >
> > ci means commit in Mercurial.
> 
> Does it mean "commit the staging area"?

It means "hg commit".

> > It would help when the user starts to think "Geez, I seem to be typing
> > `git checkout` an awful lot, I wonder if there's a shortcut", which if
> > the .gitconfigs out there are any indication, it happens all the time.
> 
> Actually, it happens very rarely if you are talking about _real_
> gitconfigs deployed by projects as compared to _sample_ gitconfigs
> demonstrating Git features for _personal_ rather than project-wide use.

There's no such thing as gitconfigs deployed by projects, and if there were
they would be irrelevant.

We are talking about *people* using Git's command line interface, and people
have *personal* configs, that's it.

And it's only those configs we have access to, and the only sources of
information we have to make a guess if users ask the question "Geez, I seem to
be typing `git checkout` an awful lot, I wonder if there's a shortcut".

> >> And for a command like "rebase" where the user can very easily shoot
> >> themselves in the foot to begin with, I'd actually suggest that it's
> >> a _good_ thing that they have to type it out in full.
> >
> > And now you contradict yourself; you actually want to make life harder
> > for new users, on purpose.
> 
> Life's hardness is not proportional to the number of typed characters

It is. Why do you think people set aliases? To make their life harder?

Anyway, if you disagree change one of your frequently used passwords to a
chapter of The Lord of the Rings for a day. Let's see if you still think that.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> David Kastrup wrote:
>
>> Life's hardness is not proportional to the number of typed characters
>
> It is. Why do you think people set aliases? To make their life harder?
>
> Anyway, if you disagree change one of your frequently used passwords
> to a chapter of The Lord of the Rings for a day. Let's see if you
> still think that.

See?  You made your life easier by typing a lot of hogwash, saving
yourself the effort of finding a compelling argument.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Andreas Krey]

On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:
...
> Anyway, if you disagree change one of your frequently used passwords to a
> chapter of The Lord of the Rings for a day. Let's see if you still think that.

Proving that one extreme isn't the optimum doesn't prove the other is.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: What is missing from Git v2.0

[Felipe Contreras]

Andreas Krey wrote:
> On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:
> ...
> > Anyway, if you disagree change one of your frequently used passwords to a
> > chapter of The Lord of the Rings for a day. Let's see if you still think
> > that.
> 
> Proving that one extreme isn't the optimum doesn't prove the other is.

It's called hyperbole, and it's a very common and very effective rhetorical
device.

Nobody argued that the extreme opposite was best.

My point was that the amount of characters you type _does_ matter, and I think
I proved my point.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Andreas Krey wrote:
>> On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:
>> ...
>> > Anyway, if you disagree change one of your frequently used passwords to a
>> > chapter of The Lord of the Rings for a day. Let's see if you still think
>> > that.
>> 
>> Proving that one extreme isn't the optimum doesn't prove the other is.
>
> It's called hyperbole, and it's a very common and very effective rhetorical
> device.

Let us conclude this discussion by declaring you the best rhetor then.

-- 
David Kastrup

Re: What is missing from Git v2.0

[David Lang]

On Tue, 22 Apr 2014, Theodore Ts'o wrote:

> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
>>> I am not fundamentally opposed.  I just do not think it would add
>>> much value to new people at this point, and it will actively hurt
>>> if we shoved barely cooked one in 2.0.
>>
>> You are probably biased in that you've used Git far much more than
>> the average user has (or future new users).
>
> I think Junio has a really strong point.  If the goal is to make life
> easier for new users, allowing them to save a few keystrokes is
> probably not the most significant thing we can do.  And we have to
> balance this with the additional cognitive load in remembering how a
> particular two character alias maps to the "real" command.  This is
> especially true for commands which might not be used as often -- e.g.,
> "rebase", and for commands where the meaning of "git commit" without
> any argument is qualitatively different from what "ci" (for checkin)
> means in most other source management systems.
>
> So I do think it's worth thinking about this very carefully.  For
> certain, I would **not** recommend using shortcuts in example command
> sequences.  If the user reads "git rebase" or "git cherry-pick" it
> means a lot more than if they see a series of apparent chicken
> scratches filled with things like "git rb", "git pi", "git st", etc.
>
> In fact, to be fair, you may be getting biased because you're used to
> using the two character shortcuts, so for you, of *course* "rb" and
> "pi" and "ci" make a lot of sense.  But for someone who is starting
> from scratch, I really question how much it helps, and how much it
> might hurt, to see the two character shortcuts or even to have to
> remember the two character shortcuts.  And for a command like "rebase"
> where the user can very easily shoot themselves in the foot to begin
> with, I'd actually suggest that it's a _good_ thing that they have to
> type it out in full.

agreed, of all the things that people complain about regarding learning git, the 
fact that the commands are words instead of cryptic 2 letter abberviations is 
not one of them.

The complaints tend to be far more about how there are inconsistancies between 
commands, or they don't understand what's happening.

Adding a new inconsistancy, or changing words to abbreviations is a further 
barrier against new users, not an advantage for them.

David Lang

Re: What is missing from Git v2.0

[Felipe Contreras]

David Lang wrote:
> agreed, of all the things that people complain about regarding learning git,
> the fact that the commands are words instead of cryptic 2 letter
> abberviations is not one of them.

It is when they start to use Git seriously and type them a lot.

> The complaints tend to be far more about how there are inconsistancies
> between commands, or they don't understand what's happening.

Yes, but you don't see anybody trying to improve those, do you?

This is low-hanging fruit we can actually change.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Lang]

On Wed, 23 Apr 2014, Felipe Contreras wrote:

> David Lang wrote:
>> agreed, of all the things that people complain about regarding learning git,
>> the fact that the commands are words instead of cryptic 2 letter
>> abberviations is not one of them.
>
> It is when they start to use Git seriously and type them a lot.

If that was such a significant factor, nobody would use Java with it's horribly 
long function names.

People are far more bothered about all the switches to remember and the options 
for them than they are the fact that they have to type entire words.

David Lang

>> The complaints tend to be far more about how there are inconsistancies
>> between commands, or they don't understand what's happening.
>
> Yes, but you don't see anybody trying to improve those, do you?
>
> This is low-hanging fruit we can actually change.
>
>

Re: What is missing from Git v2.0

[Felipe Contreras]

David Lang wrote:
> On Wed, 23 Apr 2014, Felipe Contreras wrote:
> 
> > David Lang wrote:
> >> agreed, of all the things that people complain about regarding learning git,
> >> the fact that the commands are words instead of cryptic 2 letter
> >> abberviations is not one of them.
> >
> > It is when they start to use Git seriously and type them a lot.
> 
> If that was such a significant factor, nobody would use Java with it's horribly 
> long function names.

There are these things called IDE's where people don't end up typing the whole
function names. Take a look.

> People are far more bothered about all the switches to remember and the options 
> for them than they are the fact that they have to type entire words.

This is, again, a red herring. The fact that B is more important doesn't mean A
shouldn't be done.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[James Denholm]

Felipe Contreras wrote:
>>David Lang wrote:
>> agreed, of all the things that people complain
about regarding learning git,
>> the fact that the commands are words instead of
cryptic 2 letter
>> abberviations is not one of them.
>It is when they start to use Git seriously and type
them a lot.

Felipe, I think you refute your own point here, because people _learning_
git aren't power-users. They might be one day, but not that day.

If power-users are complaining that "commit" is too long, but aren't
setting their own aliases, it's quite possible they just don't know about
aliases. Because if they _did_ know about aliases, they'd set one.
Even a shell alias,
not nessecarily a git alias.

I submit to you (with the backing of all my prior experience contributing to
git... Which is too say none) that the problem is not that git has a
single, good,
obvious and memorable commit command.

The problem is that those specific power-users don't know to use aliases.

--
James Denholm

Re: What is missing from Git v2.0

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras wrote:
> > It is when they start to use Git seriously and type them a lot.
> 
> Felipe, I think you refute your own point here, because people _learning_ git
> aren't power-users. They might be one day, but not that day. If power-users
> are complaining that "commit" is too long, but aren't setting their own
> aliases,

This is a false dichotomy; there aren't just two kinds of Git users.

There is such a category of Git users who are not fresh-out-of-the-boat, yet
not power users either.

> it's quite possible they just don't know about aliases.  Because if they
> _did_ know about aliases, they'd set one.

Unless the aliases are already there by default.

And if default aliases were such a bad idea, why do most (all?) version control
systems out there have them?

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[James Denholm]

Felipe Contreras wrote:
>This is a false dichotomy; there aren't just two kinds
> of Git users.
>
> There is such a category of Git users who are not
> fresh-out-of-the-boat, yet not power users either.

Oh, I didn't mean to suggest a dichotomy of any kind. However these
are the two groups (I
suggest) are the most immediately relevant - one calls for change, and
the other would be negatively impacted.

> Unless the aliases are already there by default.

Others, with knowledge far beyond mine, have pointed out the problems
with this. I'd suggest the
argument most relevant to my own statements is how it impacts the
learning proccess, and makes it
more likely that users will learn aliases _as_ commands, which of
course is incorrect and
potentially harmful.

> And if default aliases were such a bad idea, why do
 most (all?) version control
 systems out there
> have them?

I'm so tempted just to sass and say that it's because they aren't git...

But on a more serious note, a feature (any feature) being in one vcs
doesn't mean, by default,
that it's right for git. The status quo may be a mistake on the part
of it's followers.

(And, historically, has been many times - for an
transculturally-acceptable example, consider the
rejection of Galileo's astronomical research by the Vatican of the time.)

Just because Mercurial et. all does something doesn't mean git needs
to, or even should. It needs
objective consideration, not to just be ushered through on the basis
of tradition.

--
James Denholm

Re: What is missing from Git v2.0

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras wrote:
> >This is a false dichotomy; there aren't just two kinds
> > of Git users.
> >
> > There is such a category of Git users who are not
> > fresh-out-of-the-boat, yet not power users either.
> 
> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
> two groups (I suggest) are the most immediately relevant - one calls for
> change, and the other would be negatively impacted.

Nobody would be negatively impacted. Who would be impacted negatively by having
default aliases?

> > Unless the aliases are already there by default.
> 
> Others, with knowledge far beyond mine, have pointed out the problems
> with this.

And I have showed they are not problems.

> I'd suggest the argument most relevant to my own statements is how it impacts
> the learning proccess, and makes it more likely that users will learn aliases
> _as_ commands, which of course is incorrect and potentially harmful.

That is an assumption. Why would a user think 'co' is a command?

> > And if default aliases were such a bad idea, why do most (all?) version
> > control systems out there have them?
> 
> I'm so tempted just to sass and say that it's because they aren't git...
> 
> But on a more serious note, a feature (any feature) being in one vcs doesn't
> mean, by default, that it's right for git.

How is Git different from any other version control systems?

Commands are commands.

> The status quo may be a mistake on the part of it's followers.

Yes, it might, but it's not.

> (And, historically, has been many times - for an transculturally-acceptable
> example, consider the rejection of Galileo's astronomical research by the
> Vatican of the time.)

Yes, I'm perfecly aware that everybody _can_ be wrong, that doesn't mean they
_are_.

> Just because Mercurial et. all does something doesn't mean git needs to, or
> even should. It needs objective consideration, not to just be ushered through
> on the basis of tradition.

Again, this is a red herring. Nobody argued that Git should do this because
others are doing it.

You failed to answer the question, so I'm asking it again:

If default aliases were such a bad idea, why do most (all?) version control
systems out there have them?

Your answer seems to be along the lines of: they made a mistake and they are
all wrong. Is it?

But, surely if it's a mistake on their part you should be able to find people
affected by this horrible error. This would validate the arguments that others
have put forward; if we do X we will have problem Y. Well, other projects have
done X, do they have problem Y?

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> James Denholm wrote:
>> Felipe Contreras wrote:
>> >This is a false dichotomy; there aren't just two kinds
>> > of Git users.
>> >
>> > There is such a category of Git users who are not
>> > fresh-out-of-the-boat, yet not power users either.
>> 
>> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
>> two groups (I suggest) are the most immediately relevant - one calls for
>> change, and the other would be negatively impacted.
>
> Nobody would be negatively impacted. Who would be impacted negatively
> by having default aliases?

The people having to read and understand scripts written in the
expectation of default aliases.

> And I have showed they are not problems.

You managed to convince yourself, so feel free to put aliases in every
Git you use and distribute.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > James Denholm wrote:
> >> Felipe Contreras wrote:
> >> >This is a false dichotomy; there aren't just two kinds
> >> > of Git users.
> >> >
> >> > There is such a category of Git users who are not
> >> > fresh-out-of-the-boat, yet not power users either.
> >> 
> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
> >> two groups (I suggest) are the most immediately relevant - one calls for
> >> change, and the other would be negatively impacted.
> >
> > Nobody would be negatively impacted. Who would be impacted negatively
> > by having default aliases?
> 
> The people having to read and understand scripts written in the
> expectation of default aliases.

Which are imaginary.

> > And I have showed they are not problems.
> 
> You managed to convince yourself, so feel free to put aliases in every
> Git you use and distribute.

There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> David Kastrup wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > James Denholm wrote:
>> >> Felipe Contreras wrote:
>> >> >This is a false dichotomy; there aren't just two kinds
>> >> > of Git users.
>> >> >
>> >> > There is such a category of Git users who are not
>> >> > fresh-out-of-the-boat, yet not power users either.
>> >> 
>> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the
>> >> two groups (I suggest) are the most immediately relevant - one calls for
>> >> change, and the other would be negatively impacted.
>> >
>> > Nobody would be negatively impacted. Who would be impacted negatively
>> > by having default aliases?
>> 
>> The people having to read and understand scripts written in the
>> expectation of default aliases.
>
> Which are imaginary.

And I prefer them to stay that way since then one does not need to worry
about them.

>> > And I have showed they are not problems.
>> 
>> You managed to convince yourself, so feel free to put aliases in
>> every Git you use and distribute.
>
> There is evidence for the claim that there won't be those
> problems. You have absolutely no evidence there there will.

As I said: you managed to convince yourself and may milk that for all
that it's worth.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > David Kastrup wrote:
> >> The people having to read and understand scripts written in the
> >> expectation of default aliases.
> >
> > Which are imaginary.
> 
> And I prefer them to stay that way since then one does not need to worry
> about them.

If everybody was afraid of moving because of imaginary fears like you, nothing
would get done in this world. Rational people distinguish the imaginary from
the real.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Lang]

On Thu, 24 Apr 2014, Felipe Contreras wrote:

> David Kastrup wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>> David Kastrup wrote:
>>>> The people having to read and understand scripts written in the
>>>> expectation of default aliases.
>>>
>>> Which are imaginary.
>>
>> And I prefer them to stay that way since then one does not need to worry
>> about them.
>
> If everybody was afraid of moving because of imaginary fears like you, nothing
> would get done in this world. Rational people distinguish the imaginary from
> the real.

The exact same thing could be said for your position that typing rebase instead 
of rb causes a major problem

Calm down and stop accusing everyone of sticking their heads in the ground

David Lang

Re: What is missing from Git v2.0

[Theodore Ts'o]

On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
> 
> There is evidence for the claim that there won't be those problems. You have
> absolutely no evidence there there will.

Felipe,

It's clear that you've not been able to produce evidence that can
convince most of the people on this thread.  Simply repeating the same
assertions over and over again, in a shrill fashion, is not likely to
convince those of us who that this would not be a good idea for git
v2.0.

Creating a ~/.gitconfig file if one doesn't already is one I agree
with, and at least on Unix systems, telling them that the config file
lives in ~/.gitconfig, or where ever it might happen to be on other
platforms, is a good one.  If it's in some really weird place on
Windows, then sure, we can tell them about "git config -e".  But the
point is to let the user look at the default .gitconfig file, where we
can put in comments to help explain what is going on, and perhaps have
links to web pages for more information.

I don't even think we need to query the user to fill out all of the
fields.  We can prepopulate a lot of the fields (name, e-mail address,
etc.) from OS specific defaults that are available on most systems ---
specifically, the default values we would use the name and e-mail
address are not specified in a config file.

We can just tell the user that we have created a default .gitconfig
file, and tell them how they can take a look at it.

In the long term, if the worry is how to bridge the gap between
complete newbies, one way of dealing with this is to have a tutorial
mode (off by default, on in the default .gitconfig) which despenses
some helpful hints at certain strategic points (i.e., after five
commits, give a message that introduces git log --oneline, after the
third merge commit is created by the user, give a message which
introduces git log --merge, and so on).  The challenge is not strawing
over the line to the point where the hints become as annoying as
"clippy", but that is what UX labs are for, to tune the experience for
completely new users to git.

Without doing a formal UX experiment, all of us are going to making
assertions without formal evidence --- at best some of us who have
tutored a few newbies might have some anecdates, but remember the old
saying about the plural of anecdote not being data.

Cheers,

						- Ted

Re: What is missing from Git v2.0

[Stefan Beller]

> I don't even think we need to query the user to fill out all of the
> fields.  We can prepopulate a lot of the fields (name, e-mail address,
> etc.) from OS specific defaults that are available on most systems ---
> specifically, the default values we would use the name and e-mail
> address are not specified in a config file.

Please don't. Or you end up again with Commiters like sb@localhost,
sbeller@(None) or alike. I mean it's just one question once you setup
a new computer, so I'd really like to see that question and then
answer myself (at university/employer I might put in another email
address than at home anyway, and I'm sure my boxes have no sane
defaults)

2014-04-24 15:41 GMT+02:00 Theodore Ts'o <tytso@mit.edu>:
> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
>>
>> There is evidence for the claim that there won't be those problems. You have
>> absolutely no evidence there there will.
>
> Felipe,
>
> It's clear that you've not been able to produce evidence that can
> convince most of the people on this thread.  Simply repeating the same
> assertions over and over again, in a shrill fashion, is not likely to
> convince those of us who that this would not be a good idea for git
> v2.0.
>
> Creating a ~/.gitconfig file if one doesn't already is one I agree
> with, and at least on Unix systems, telling them that the config file
> lives in ~/.gitconfig, or where ever it might happen to be on other
> platforms, is a good one.  If it's in some really weird place on
> Windows, then sure, we can tell them about "git config -e".  But the
> point is to let the user look at the default .gitconfig file, where we
> can put in comments to help explain what is going on, and perhaps have
> links to web pages for more information.
>
> I don't even think we need to query the user to fill out all of the
> fields.  We can prepopulate a lot of the fields (name, e-mail address,
> etc.) from OS specific defaults that are available on most systems ---
> specifically, the default values we would use the name and e-mail
> address are not specified in a config file.
>
> We can just tell the user that we have created a default .gitconfig
> file, and tell them how they can take a look at it.
>
> In the long term, if the worry is how to bridge the gap between
> complete newbies, one way of dealing with this is to have a tutorial
> mode (off by default, on in the default .gitconfig) which despenses
> some helpful hints at certain strategic points (i.e., after five
> commits, give a message that introduces git log --oneline, after the
> third merge commit is created by the user, give a message which
> introduces git log --merge, and so on).  The challenge is not strawing
> over the line to the point where the hints become as annoying as
> "clippy", but that is what UX labs are for, to tune the experience for
> completely new users to git.
>
> Without doing a formal UX experiment, all of us are going to making
> assertions without formal evidence --- at best some of us who have
> tutored a few newbies might have some anecdates, but remember the old
> saying about the plural of anecdote not being data.
>
> Cheers,
>
>                                                 - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What is missing from Git v2.0

[tytso]

On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
> > I don't even think we need to query the user to fill out all of the
> > fields.  We can prepopulate a lot of the fields (name, e-mail address,
> > etc.) from OS specific defaults that are available on most systems ---
> > specifically, the default values we would use the name and e-mail
> > address are not specified in a config file.
> 
> Please don't. Or you end up again with Commiters like sb@localhost,
> sbeller@(None) or alike. I mean it's just one question once you setup
> a new computer, so I'd really like to see that question and then
> answer myself (at university/employer I might put in another email
> address than at home anyway, and I'm sure my boxes have no sane
> defaults)

But that's no worse than what we have today.  What if we print what
the defaults were, which might help encourage the user to actually run
the "git config -e" command?

					- Ted

Re: What is missing from Git v2.0

[Stefan Beller]

I may have missunderstood.

So today you cannot commit if you don't provide an email address
(usually the first time you try to commit, git asks to "git config
--global author.email=<you@mail.here>"), if I remember correctly, so
there is definitely a valid (i.e. user approved) email address.

2014-04-24 17:47 GMT+02:00  <tytso@mit.edu>:
> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
>> > I don't even think we need to query the user to fill out all of the
>> > fields.  We can prepopulate a lot of the fields (name, e-mail address,
>> > etc.) from OS specific defaults that are available on most systems ---
>> > specifically, the default values we would use the name and e-mail
>> > address are not specified in a config file.
>>
>> Please don't. Or you end up again with Commiters like sb@localhost,
>> sbeller@(None) or alike. I mean it's just one question once you setup
>> a new computer, so I'd really like to see that question and then
>> answer myself (at university/employer I might put in another email
>> address than at home anyway, and I'm sure my boxes have no sane
>> defaults)
>
> But that's no worse than what we have today.  What if we print what
> the defaults were, which might help encourage the user to actually run
> the "git config -e" command?
>
>                                         - Ted

Re: What is missing from Git v2.0

[Jonathan Nieder]

Stefan Beller wrote:

> I may have missunderstood.
>
> So today you cannot commit if you don't provide an email address
> (usually the first time you try to commit, git asks to "git config
> --global author.email=<you@mail.here>"), if I remember correctly, so
> there is definitely a valid (i.e. user approved) email address.

Not true.  But you do get a big wall of text when you make your
first commit without an EMAIL envvar or configured [user] section,
including

| You can suppress this message by setting them explicitly:
|
|     git config --global user.name "Your Name"
|     git config --global user.email you@example.com
|
| After doing this, you may fix the identity used for this commit with:
| 
|     git commit --amend --reset-author

Ciao,
Jonathan

Re: What is missing from Git v2.0

[Felipe Contreras]

Jonathan Nieder wrote:
> Stefan Beller wrote:
> 
> > I may have missunderstood.
> >
> > So today you cannot commit if you don't provide an email address
> > (usually the first time you try to commit, git asks to "git config
> > --global author.email=<you@mail.here>"), if I remember correctly, so
> > there is definitely a valid (i.e. user approved) email address.
> 
> Not true.  But you do get a big wall of text when you make your
> first commit without an EMAIL envvar or configured [user] section,
> including

Only if you don't have a fully qualified hostname.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Jeff King]

On Thu, Apr 24, 2014 at 01:26:33PM -0500, Felipe Contreras wrote:

> Jonathan Nieder wrote:
> > Stefan Beller wrote:
> > 
> > > I may have missunderstood.
> > >
> > > So today you cannot commit if you don't provide an email address
> > > (usually the first time you try to commit, git asks to "git config
> > > --global author.email=<you@mail.here>"), if I remember correctly, so
> > > there is definitely a valid (i.e. user approved) email address.
> > 
> > Not true.  But you do get a big wall of text when you make your
> > first commit without an EMAIL envvar or configured [user] section,
> > including
> 
> Only if you don't have a fully qualified hostname.

No, we alway warn if the values weren't explicitly provided:

  $ git config --global --unset user.email
  $ git commit --allow-empty -m foo
  [master 1e987ba] foo
   Committer: Jeff King <peff@sigill.intra.peff.net>
  Your name and email address were configured automatically based
  on your username and hostname. Please check that they are accurate.
  You can suppress this message by setting them explicitly:
  
      git config --global user.name "Your Name"
      git config --global user.email you@example.com
  
  After doing this, you may fix the identity used for this commit with:
  
      git commit --amend --reset-author

but we will consider several sources explicit, like
$GIT_COMMITTER_EMAIL, $EMAIL, and of course user.email:

  $ EMAIL=whatever@example.com git commit --allow-empty -m foo
  [master e75f17a] foo

We die when the values are implicitly derived from the system _and_ they
look bogus:

  $ sudo rm /etc/mailname
  $ sudo hostname bogus
  $ git commit --allow-empty -m foo

  *** Please tell me who you are.
  
  Run
  
    git config --global user.email "you@example.com"
    git config --global user.name "Your Name"
  
  to set your account's default identity.
  Omit --global to set the identity only in this repository.
  
  fatal: unable to auto-detect email address (got 'peff@bogus.(none)')

-Peff

Re: What is missing from Git v2.0

[Felipe Contreras]

Stefan Beller wrote:
> I may have missunderstood.
> 
> So today you cannot commit if you don't provide an email address
> (usually the first time you try to commit, git asks to "git config
> --global author.email=<you@mail.here>"), if I remember correctly, so
> there is definitely a valid (i.e. user approved) email address.

That's not true, that's only the case if you don't have a fully qualified
hostname, like 'localhost', but if you do, like localhost.redhat, then Git
assumes your email is user@localhost.redhat, and it's valid.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Felipe Contreras]

tytso@ wrote:
> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
> > > I don't even think we need to query the user to fill out all of the
> > > fields.  We can prepopulate a lot of the fields (name, e-mail address,
> > > etc.) from OS specific defaults that are available on most systems ---
> > > specifically, the default values we would use the name and e-mail
> > > address are not specified in a config file.
> > 
> > Please don't. Or you end up again with Commiters like sb@localhost,
> > sbeller@(None) or alike. I mean it's just one question once you setup
> > a new computer, so I'd really like to see that question and then
> > answer myself (at university/employer I might put in another email
> > address than at home anyway, and I'm sure my boxes have no sane
> > defaults)
> 
> But that's no worse than what we have today.  What if we print what
> the defaults were, which might help encourage the user to actually run
> the "git config -e" command?

In addition we shouldn't consider user@host a valid e-mail. In the vast
majority of cases it's not.

http://article.gmane.org/gmane.comp.version-control.git/232027

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Matthieu Moy]

tytso@mit.edu writes:

> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:
>> > I don't even think we need to query the user to fill out all of the
>> > fields.  We can prepopulate a lot of the fields (name, e-mail address,
>> > etc.) from OS specific defaults that are available on most systems ---
>> > specifically, the default values we would use the name and e-mail
>> > address are not specified in a config file.
>> 
>> Please don't. Or you end up again with Commiters like sb@localhost,
>> sbeller@(None) or alike. I mean it's just one question once you setup
>> a new computer, so I'd really like to see that question and then
>> answer myself (at university/employer I might put in another email
>> address than at home anyway, and I'm sure my boxes have no sane
>> defaults)
>
> But that's no worse than what we have today.

It is. Currently, Git displays a very big and scary warning when you use
commit and Git had to guess your identity.

If you explicitly fill-in the config file with guessed values, then Git
will have no way to know if the config values are real or guessed.

OTOH, a prompt with a default value (i.e "type 'return' to get the
default") would make sense.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: What is missing from Git v2.0

[Philippe Vaucher]

> > I don't even think we need to query the user to fill out all of the
> > fields.  We can prepopulate a lot of the fields (name, e-mail address,
> > etc.) from OS specific defaults that are available on most systems ---
> > specifically, the default values we would use the name and e-mail
> > address are not specified in a config file.
>
> Please don't. Or you end up again with Commiters like sb@localhost,
> sbeller@(None) or alike. I mean it's just one question once you setup
> a new computer, so I'd really like to see that question and then
> answer myself (at university/employer I might put in another email
> address than at home anyway, and I'm sure my boxes have no sane
> defaults)

Yes, try to guess a good default but let the user change it if he
wants to, and if he presses enter the default is used. It's not a big
deal to have to press enter a few times the first time you use git.

That or make a new "git setup" command which interactively sets up
your .gitconfig.

Philippe

Re: What is missing from Git v2.0

[Felipe Contreras]

Theodore Ts'o wrote:
> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
> > 
> > There is evidence for the claim that there won't be those problems. You have
> > absolutely no evidence there there will.
> 
> It's clear that you've not been able to produce evidence that can
> convince most of the people on this thread.

Which only proves you don't want to be convinced, no evidence could convince
you.

> I don't even think we need to query the user to fill out all of the
> fields.  We can prepopulate a lot of the fields (name, e-mail address,
> etc.) from OS specific defaults that are available on most systems ---
> specifically, the default values we would use the name and e-mail
> address are not specified in a config file.

Most systems don't have a configured $EMAIL, so those defautls would be wrong.

It's so evident that no evide could convince you that you don't even bothere to
answer my question:

Why does Mercurial, Bazaar, Subversion, CVS, and pretty much everything uses
aliases?

Since you are conveniently not answering, I'll answer for you:

Because such hypothetical problems wouldn't actually occur in reality with Git,
just like they don't occur in other tools.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[luc.linux]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:
> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
> Creating a ~/.gitconfig file if one doesn't already is one I agree
> with, and at least on Unix systems, telling them that the config file
> lives in ~/.gitconfig, or where ever it might happen to be on other
> platforms, is a good one.  If it's in some really weird place on
> Windows, then sure, we can tell them about "git config -e".  But the
> point is to let the user look at the default .gitconfig file, where we
> can put in comments to help explain what is going on, and perhaps have
> links to web pages for more information.

I think the idea of a commented gitconfig is a good solution. We could
include default aliases commented, so that a new user would just have to
uncomment them. That way, he will understand they are aliases and not
commands, learn how to tune them to its own needs and it won't annoy
anyone because they will be commented by default, ideally with explicit
commentaries around them.

Furthermore, this could be a good way to show a new user all the
possibilities of git, or at least its configuration. Documentation is a
good thing when you know what you are looking for, but when you are
beginning, you don't know what can be done, and reading a complete and
commented example configuration could be a good way to discover it.


[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: What is missing from Git v2.0

[Javier Domingo Cansino]

Felipe's
=======

= The publish tracking branch =
I still have problems getting upstream branches correctly configured
as to have this introduced, anyway, I suppose it's optional, so
nothing to add on that.

By the way, remote branch managing has improved a lot,  one of the
best things I see for branching and remotes is the "git remote show"
command, but I think further work should be done. Help messages FTW!

= Reject non-fast-forward pulls by default =
Not having this introduced yet allows newbie people to use git with
just 4 commands, without bothering around with fetch and merge and so.

= Use "stage" instead of "index" =
Totally agree with this.

= Default aliases =
I hate aliases, make scripts more difficult to read and understand. I
would instead try to improve knowledge on this feature. I have to
agree with David Lang's first message, and

The cherry-pick => pick thing would be the only thing I would see with
good eyes, just because it's too long and has a dash.


Juno's
======
The idea about ~/.gitconfig seems incredible simple and effective to
me. I would however try to keep it simple, and minimize the form.


Mine
====
I have taught (or tried to) a lot of people Git. And this is some of
the stuff I have seen they have difficulties with:
- Remembering the commands, for example, remembering add, commit push
and pull, which I think we can all agree is the most core and simple
combination of Git commands.
- What command comes for what they need. If I want to share
everything, what should I do?
- Most of them, have real difficulties on remembering the flows. There
are too many commands for the start.

I wouldn't nevertheless suppress any of them, I would rather do a tuto
on-the-go.

Here are some ideas I have thought of:

== Command Output==
At the moment, there are several commands that don't output any help
text, and many others, that although they have become more verbose
with the years, they aren't too verbose yet.

One of the things I most recommend to anyone is to run "git status"
just before any command (push, commit, add, etc.) to get sure they are
doing what they thing they will.

For example, running git add won't tell you what you just added, nor
what you could do now. I would put some output there, maybe the git
status output or something similar that helps the user to know what
just happened.

Git status doesn't say much about remotes, and suggesting pushing if a
remote is outdated, would be fantastic.

Checkout command has decreased verbosity from a previous version,
where it stated which branch it came from and to which branch it was
switching to.

As an extreme thing, I would consider adding a configuration parameter
default, core.helptext=True that could switch off all this stuff.

==Running git==
This is a very basic idea, and I suppose it isn't too helpful or
realistic, but might give someone an idea.

I would first make that running git, just git, tell the user the
possibilities he has. I don't know of any power user that uses git to
remember the commands. At the moment, git[1] just tells many of the
commands available, without any classification, maybe classifying them
as "commiting" "branching" and "remote" could help a little.

Regards,

Javier Domingo Cansino

[1] git output:
----------------------------------------------------
javier@frodo:~$ git
usage: git [--version] [--help] [-C <path>] [-c name=value]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find by binary search the change that introduced a bug
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty Git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and integrate with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG

'git help -a' and 'git help -g' lists available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
----------------------------------------------------

Re: What is missing from Git v2.0

[Felipe Contreras]

Javier Domingo Cansino wrote:
> Felipe's
> =======
> 
> = The publish tracking branch =
> I still have problems getting upstream branches correctly configured
> as to have this introduced, anyway, I suppose it's optional, so
> nothing to add on that.

I did so too, until I patch `git branch -v` to be useful.

> = Reject non-fast-forward pulls by default =

> Not having this introduced yet allows newbie people to use git with
> just 4 commands, without bothering around with fetch and merge and so.

I don't understand what you are trying to say. There is no change for those
people, when the pull fails they would be told to use `git pull --merge` if not
sure.

> = Use "stage" instead of "index" =
> Totally agree with this.
> 
> = Default aliases =
> I hate aliases, make scripts more difficult to read and understand.

You are assuming that everyone will start to use aliases in scripts, which is
not going to happen enough to be a problem.

Try to find svn or hg scripts with aliases, let's see how many you find.

> Mine
> ====
> I have taught (or tried to) a lot of people Git. And this is some of
> the stuff I have seen they have difficulties with:
> - Remembering the commands, for example, remembering add, commit push
> and pull, which I think we can all agree is the most core and simple
> combination of Git commands.
> - What command comes for what they need. If I want to share
> everything, what should I do?
> - Most of them, have real difficulties on remembering the flows. There
> are too many commands for the start.
> 
> I wouldn't nevertheless suppress any of them, I would rather do a tuto
> on-the-go.

I think you are on the right track but the solution is not to shrug shoulders.
We should acknowledge there are serious problems with the interface, list them,
and try to fix them. One example is `git add $tracked_file` being wrong, it
should be `git stage $tracked_file`.

The real problem is that the core developers of Git don't acknowledge these
user-interface issues, according the them the interface doesn't require any
major changes. Which goes contrary to what most of the world believes.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Philippe Vaucher]

> I think you are on the right track but the solution is not to shrug shoulders.
> We should acknowledge there are serious problems with the interface, list them,
> and try to fix them. One example is `git add $tracked_file` being wrong, it
> should be `git stage $tracked_file`.

I agree. The "stage area" is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.


> The real problem is that the core developers of Git don't acknowledge these
> user-interface issues, according the them the interface doesn't require any
> major changes. Which goes contrary to what most of the world believes.

I think most people agree with these interfaces issues but it's a hard
problem to solve, so  they are reluctant to talk about it because they
fear the can of worm. If someone came with a good solution most people
would be willing to consider it.

I think starting by documenting the issues is a good idea, maybe on a
wiki, and start some draft of a proposed solution that would improve
in an iterative process.

Philippe

Re: What is missing from Git v2.0

[Felipe Contreras]

Philippe Vaucher wrote:
> > I think you are on the right track but the solution is not to shrug shoulders.
> > We should acknowledge there are serious problems with the interface, list them,
> > and try to fix them. One example is `git add $tracked_file` being wrong, it
> > should be `git stage $tracked_file`.
> 
> I agree. The "stage area" is a very important concept in git, why not
> talk git commands that refers to it? Then we could add flags like
> --new-files or --deleted-files for better granularity than the current
> --all flag.

Like this:
http://thread.gmane.org/gmane.comp.version-control.git/236127

> > The real problem is that the core developers of Git don't acknowledge these
> > user-interface issues, according the them the interface doesn't require any
> > major changes. Which goes contrary to what most of the world believes.
> 
> I think most people agree with these interfaces issues but it's a hard
> problem to solve, so  they are reluctant to talk about it because they
> fear the can of worm. If someone came with a good solution most people
> would be willing to consider it.
> 
> I think starting by documenting the issues is a good idea, maybe on a
> wiki, and start some draft of a proposed solution that would improve
> in an iterative process.

Yes, it would be good to document these issues, but it wouldn't matter if the
developers ignore them.

For example the move away from the 'index' name was backed up by literally
everyone, except Junio, so it doesn't matter if the issue is documented, and
there are patches with good solutions, if Junio thinks it's not an issue; it's
ignored.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Theodore Ts'o]

On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
> 
> I agree. The "stage area" is a very important concept in git, why not
> talk git commands that refers to it? Then we could add flags like
> --new-files or --deleted-files for better granularity than the current
> --all flag.

One caution: The term "stage/staged" is already a little overloaded.
We generally use the word "staged" to refer to changes that are in the
index, but the term "stage" as a noun generally refers to referencing
the different versions of a file during a merge operation (cf "git
ls-files --stage").

> I think starting by documenting the issues is a good idea, maybe on a
> wiki, and start some draft of a proposed solution that would improve
> in an iterative process.

And it would be nice if the issues were discussed in a way that
acknowledged that all changes have tradeoffs, both positive and
negative, and to clearly articulate whether the concern is just
someone going "uh, 'index' is a wierd term", but once they learn it,
it's pretty clear, versus a case where there is continuous confusion
due to overloaded meanings, or for people for whom English might not
be the first language.

And most importantly, to avoid rheteroic.  In fact, given that strong
use of rhetoric is often used to disguise a weakness of a position
that can't be defended using logic and data, someone who tries to win
arguments using the "last post wins" style of discourse, and a heavy
use of rhetoric, may find that people just simply decide that it's a
better use of their time not to engage and to just kill the entire
thread.

Regards,

						- Ted

Re: What is missing from Git v2.0

[Philippe Vaucher]

>> I agree. The "stage area" is a very important concept in git, why not
>> talk git commands that refers to it? Then we could add flags like
>> --new-files or --deleted-files for better granularity than the current
>> --all flag.
>
> One caution: The term "stage/staged" is already a little overloaded.
> We generally use the word "staged" to refer to changes that are in the
> index, but the term "stage" as a noun generally refers to referencing
> the different versions of a file during a merge operation (cf "git
> ls-files --stage").

I agree, but I think it's better than "index" tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.


>> I think starting by documenting the issues is a good idea, maybe on a
>> wiki, and start some draft of a proposed solution that would improve
>> in an iterative process.
>
> And it would be nice if the issues were discussed in a way that
> acknowledged that all changes have tradeoffs, both positive and
> negative, and to clearly articulate whether the concern is just
> someone going "uh, 'index' is a wierd term", but once they learn it,
> it's pretty clear, versus a case where there is continuous confusion
> due to overloaded meanings, or for people for whom English might not
> be the first language.

Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.


> And most importantly, to avoid rheteroic.  In fact, given that strong
> use of rhetoric is often used to disguise a weakness of a position
> that can't be defended using logic and data, someone who tries to win
> arguments using the "last post wins" style of discourse, and a heavy
> use of rhetoric, may find that people just simply decide that it's a
> better use of their time not to engage and to just kill the entire
> thread.

Unfortunately yes, I see many people being silly in order to win
arguments, both in the pro-changes and against-changes side of the
discussion. I'd be much simpler to simply gather arguments on some
wiki and eventually do a vote when the list is complete about the
proposed change.

Philippe

Re: What is missing from Git v2.0

[Theodore Ts'o]

On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote:
> 
> I agree, but I think it's better than "index" tho. That one is heavily
> overloaded and easily confused with other meaning in other softwares.

There is a big difference between being used in a difference sense
than other software --- there is a one-time learning curve after which
point people can generally understand that a term in a given context
has a single meaning --- and when we have two very easily confused
terms (i.e., "stage versus staged") or a single identical term,
overloaded within a single context.  So I'm much more worried about
the git documentation using the same term or two closely related terms
in an overloaded fashion, much more than I am with "index" meaning one
thing for databases, and another thing for book publishers, and yet
another for compilers.

> Yes, of course there should be a list of both positive and negative
> tradeoffs. But I think the "overloaded" argument can be easily solved
> by renaming one of the overloads.

And renaming one of a term also has costs, especially if it is one
that is in use in large amounts of documentation, both in the git man
pages, and in web pages across the web.

And my plea for data extends even here.  For example, things like
this:

www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q

> Unfortunately yes, I see many people being silly in order to win
> arguments, both in the pro-changes and against-changes side of the
> discussion. I'd be much simpler to simply gather arguments on some
> wiki and eventually do a vote when the list is complete about the
> proposed change.

Voting is not a good way to do software development.  That way lies
people wanting to whip up clueless folks using rhetoric (exhibit one:
Fox News) to "vote" and so it's not necessarily the best way to make
thoughtful decisions.  Using hard data, including possibly formal UX
experiments, is a much better way to make such decisions.

Cheers,

						- Ted

Re: What is missing from Git v2.0

[Philippe Vaucher]

>> Yes, of course there should be a list of both positive and negative
>> tradeoffs. But I think the "overloaded" argument can be easily solved
>> by renaming one of the overloads.
>
> And renaming one of a term also has costs, especially if it is one
> that is in use in large amounts of documentation, both in the git man
> pages, and in web pages across the web.

It's just impossible to change terms and have previous documentation
still be valid. Sure, you can list it in the "cons" section as an
argument, but it's not very convincing in itself because it applies to
pretty much any interface changes. I think the main idea is to
_improve_ the interface, which means rename things so it is more
consistent and so concepts are easier for new comers to grasp. We
could still support old terms for a while and eventually deprecate
them.


> www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q

I think this comparison is a bit bogus, searching for "git stage"
yields more accurate results, we can see the searches are related:

http://www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index%2C%20git%20stage&cmpt=q


>> Unfortunately yes, I see many people being silly in order to win
>> arguments, both in the pro-changes and against-changes side of the
>> discussion. I'd be much simpler to simply gather arguments on some
>> wiki and eventually do a vote when the list is complete about the
>> proposed change.
>
> Voting is not a good way to do software development.  That way lies
> people wanting to whip up clueless folks using rhetoric (exhibit one:
> Fox News) to "vote" and so it's not necessarily the best way to make
> thoughtful decisions.  Using hard data, including possibly formal UX
> experiments, is a much better way to make such decisions.

Interesting, but then who's to say which data is more important than
anothers? For example, I consider improving the interface to be more
important than having old documentation on blogs/tutorial for a while
until people catch up, but maybe you consider old documentation to be
more important... who decides what really counts? I guess it's a mix
of general consensus and old timers credibility.

Anyway, having some data as a list of pros/cons would greatly simplify
the debate.

Philippe

Re: What is missing from Git v2.0

[Felipe Contreras]

Philippe Vaucher wrote:
> >> Yes, of course there should be a list of both positive and negative
> >> tradeoffs. But I think the "overloaded" argument can be easily solved
> >> by renaming one of the overloads.
> >
> > And renaming one of a term also has costs, especially if it is one
> > that is in use in large amounts of documentation, both in the git man
> > pages, and in web pages across the web.
> 
> It's just impossible to change terms and have previous documentation
> still be valid. Sure, you can list it in the "cons" section as an
> argument, but it's not very convincing in itself because it applies to
> pretty much any interface changes. I think the main idea is to
> _improve_ the interface, which means rename things so it is more
> consistent and so concepts are easier for new comers to grasp. We
> could still support old terms for a while and eventually deprecate
> them.

And that's exactly what I did in my patch series: start introducing the --stage
options along the current ones.

http://thread.gmane.org/gmane.comp.version-control.git/236127/focus=236128

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Felipe Contreras]

Theodore Ts'o wrote:
> On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
> > 
> > I agree. The "stage area" is a very important concept in git, why not
> > talk git commands that refers to it? Then we could add flags like
> > --new-files or --deleted-files for better granularity than the current
> > --all flag.
> 
> One caution: The term "stage/staged" is already a little overloaded.
> We generally use the word "staged" to refer to changes that are in the
> index, but the term "stage" as a noun generally refers to referencing
> the different versions of a file during a merge operation (cf "git
> ls-files --stage").
> 
> > I think starting by documenting the issues is a good idea, maybe on a
> > wiki, and start some draft of a proposed solution that would improve
> > in an iterative process.
> 
> And it would be nice if the issues were discussed in a way that acknowledged
> that all changes have tradeoffs, both positive and negative,

They have been discussed at length:

http://thread.gmane.org/gmane.comp.version-control.git/197111
http://thread.gmane.org/gmane.comp.version-control.git/166675
http://thread.gmane.org/gmane.comp.version-control.git/115666
http://thread.gmane.org/gmane.comp.version-control.git/236127

When I say literally everbody agreed to move away from the name "index" (except
Junio and another guy) I mean it. I even composed a list:

http://article.gmane.org/gmane.comp.version-control.git/233469

Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.

> or for people for whom English might not be the first language.

People whom English is not their first language also agreed "index" is a
terrible term.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Jeff King]

On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:

> When I say literally everbody agreed to move away from the name "index" (except
> Junio and another guy) I mean it. I even composed a list:
> 
> http://article.gmane.org/gmane.comp.version-control.git/233469
> 
> Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.

With reference to my name, your email says:

  Jeff King:
  "staging area" makes perfect sense

But here's that statement in context[1]:

  So the term "staging area" makes perfect sense to me; it is where we
  collect changes to make a commit. I am willing to accept that does not
  to others (native English speakers or no), and that we may need to
  come up with a better term. But I think just calling it "the stage" is
  even worse; it loses the concept that it is a place for collecting and
  organizing.

In other words, I was saying that the term makes sense to me, and
primarily comparing favorably to a worse proposal. I am not commenting
at all on a plan to change names, which is what you are claiming above.

I do think the term "staging area" is fine, but picking a term is only
step one of a plan. The rest is deciding how to make the change, and
whether it is worth it. I remain undecided on the latter bits. Please
don't quote me out of context in a way that implies that I am decided.

-Peff

[1] http://article.gmane.org/gmane.comp.version-control.git/168012

Re: What is missing from Git v2.0

[Felipe Contreras]

Jeff King wrote:
> On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:
> 
> > When I say literally everbody agreed to move away from the name "index" (except
> > Junio and another guy) I mean it. I even composed a list:
> > 
> > http://article.gmane.org/gmane.comp.version-control.git/233469
> > 
> > Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.
> 
> With reference to my name, your email says:
> 
>   Jeff King:
>   "staging area" makes perfect sense
> 
> But here's that statement in context[1]:
> 
>   So the term "staging area" makes perfect sense to me; it is where we
>   collect changes to make a commit. I am willing to accept that does not
>   to others (native English speakers or no), and that we may need to
>   come up with a better term. But I think just calling it "the stage" is
>   even worse; it loses the concept that it is a place for collecting and
>   organizing.
> 
> In other words, I was saying that the term makes sense to me, and
> primarily comparing favorably to a worse proposal. I am not commenting
> at all on a plan to change names, which is what you are claiming above.
> 
> I do think the term "staging area" is fine, but picking a term is only
> step one of a plan. The rest is deciding how to make the change, and
> whether it is worth it. I remain undecided on the latter bits. Please
> don't quote me out of context in a way that implies that I am decided.

I specifically said everybody agreed to "move away from the name 'index'", I
didn't say everybody agreed on the "staged area" although the vast majority
did, and I didn't say anybody agreed on my patches, although some did.

I think I was clear.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Jeff King]

On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:

> I specifically said everybody agreed to "move away from the name 'index'", I
> didn't say everybody agreed on the "staged area" although the vast majority
> did, and I didn't say anybody agreed on my patches, although some did.
> 
> I think I was clear.

Maybe I was not clear in my response, so let me try again. I do _not_
necessarily agree that we need to move away from the name index. I am
specifically saying that your "everyone" includes my name explicitly,
and that I do not agree with the statement you are attributing to it.

-Peff

Re: What is missing from Git v2.0

[Felipe Contreras]

Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:
> 
> > I specifically said everybody agreed to "move away from the name 'index'", I
> > didn't say everybody agreed on the "staged area" although the vast majority
> > did, and I didn't say anybody agreed on my patches, although some did.
> > 
> > I think I was clear.
> 
> Maybe I was not clear in my response, so let me try again. I do _not_
> necessarily agree that we need to move away from the name index.

So you agree that "the index" is a bad name, and you agree "staging area" is a
better name, yet you don't agree we should move away from the term "index"?

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[Jeff King]

On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:

> > Maybe I was not clear in my response, so let me try again. I do _not_
> > necessarily agree that we need to move away from the name index.
> 
> So you agree that "the index" is a bad name, and you agree "staging area" is a
> better name, yet you don't agree we should move away from the term "index"?

I don't agree that "the index" is a "bad" name, because that implies
some objective level of "bad".

I do think the name "staging area" is fine, and I think it may even be
better than "index", if we were picking a name out of the blue.

I am undecided on whether we should move away from the term "index". The
way you have phrased it seems like you are trying to create a logical
contradiction: A is bad, B is good, therefore we should move from A to
B. But that neglects the cost of moving.

Frankly, I am not that interested in discussing it with you. I _am_
interested in you not using my name to claim that I believe things I do
not.

-Peff

Re: What is missing from Git v2.0

[Felipe Contreras]

Jeff King wrote:
> On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:
> 
> > > Maybe I was not clear in my response, so let me try again. I do _not_
> > > necessarily agree that we need to move away from the name index.
> > 
> > So you agree that "the index" is a bad name, and you agree "staging area" is a
> > better name, yet you don't agree we should move away from the term "index"?
> 
> I don't agree that "the index" is a "bad" name, because that implies
> some objective level of "bad".
> 
> I do think the name "staging area" is fine, and I think it may even be
> better than "index", if we were picking a name out of the blue.

> The way you have phrased it seems like you are trying to create a logical
> contradiction: A is bad, B is good, therefore we should move from A to B.

A _is_ bad, and B _is_ good. That's what I, and many people, have argued, and
that's what the vast majority of people have agreed.

> But that neglects the cost of moving.

And you neglect the benefits of moving.

It is very clear that the costs of moving are negligible in comparison to the
benefits.

But you *always* resist any change, so of course you wouldn't agree on change.
And that's why nothing ever changes.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Kastrup]

Javier Domingo Cansino <javierdo1@gmail.com> writes:

> Felipe's
> =======
>
> = Reject non-fast-forward pulls by default =
> Not having this introduced yet allows newbie people to use git with
> just 4 commands, without bothering around with fetch and merge and so.

If you have a gun lying around your house, you should turn the safety
catch off or the children will not be able to use it without
instruction.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Jonathan Nieder]

Hi,

David Kastrup wrote:
> Javier Domingo Cansino <javierdo1@gmail.com> writes:

>> = Reject non-fast-forward pulls by default =
>> Not having this introduced yet allows newbie people to use git with
>> just 4 commands, without bothering around with fetch and merge and so.
>
> If you have a gun lying around your house, you should turn the safety
> catch off or the children will not be able to use it without
> instruction.

I probably missed a subtlety, but the above comment reminded me of
some netiquette I think this list is starting to forget.  If I have
misread it, please let me know and skip the rest of this message.

This is a comment about style, not substance.  Like coding style,
discussion style matters as a way of making life easier for
maintainers and new contributors, and different projects have subtly
different practices.

On the git list, the rule is simple.  Feel free to grumble, but make
sure there is some contribution in the same message.  For example,
after the confusing gun analogy you can say "How about this patch?"
and people reading can follow up by reviewing that patch and
potentially getting it applied.

"But what if there's already a patch doing what I want to do?" you
might ask.  No problem.  Link to the patch and say "I think this patch
should be revisited", or even better, re-send it with some notes about
how previous review comments have been addressed or remain to be
addressed.

"How do I get feedback on design of a new change without wasting a lot
of time coding something that might be a bad idea?"  Glad you asked.
Sometimes instead of a patch, a better contribution is a detailed
explanation of a design to be reviewed and adopted.  In this case, do
try to be clear about whether you'll have enough time to implement the
result or will be relying on others so people know how much time to
devote to working out the details.

"What about feature requests?  I might have an idea for improving git
that no one's had before but I don't have a detailed design in mind."
Sure, that can be a good contribution.  Just treat it as a gift ---
don't assume anyone is going to implement it for you if they're not
interested.

"What about reminders about known bugs?  There's this regression and
it would not be right to release without fixing it but I think it's
fallen through the cracks."  Yes, good contribution.

"What about jokes?"  Sure, making people laugh is productive.

"What about cryptic grumbling?"  Sorry, unless you are grumbling to
get input on how to improve git's documentation or code, it's not
enough to be worth sending an email to this list.

Hope that helps,
Jonathan

Re: What is missing from Git v2.0

[David Kastrup]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Hi,
>
> David Kastrup wrote:
>> Javier Domingo Cansino <javierdo1@gmail.com> writes:
>
>>> = Reject non-fast-forward pulls by default =
>>> Not having this introduced yet allows newbie people to use git with
>>> just 4 commands, without bothering around with fetch and merge and so.
>>
>> If you have a gun lying around your house, you should turn the safety
>> catch off or the children will not be able to use it without
>> instruction.
>
> I probably missed a subtlety, but the above comment reminded me of
> some netiquette I think this list is starting to forget.  If I have
> misread it, please let me know and skip the rest of this message.
>
> This is a comment about style, not substance.  Like coding style,
> discussion style matters as a way of making life easier for
> maintainers and new contributors, and different projects have subtly
> different practices.
>
> On the git list, the rule is simple.  Feel free to grumble, but make
> sure there is some contribution in the same message.  For example,
> after the confusing gun analogy you can say "How about this patch?"
> and people reading can follow up by reviewing that patch and
> potentially getting it applied.

Uh, Javier was commenting on a number of concrete proposals regarding
the subject line "What is missing from Git v2.0" and quoted Felipe
directly.  As you seem to have lost the context, let me requote the
respective portion:

    From: Felipe Contreras <felipe.contreras@gmail.com>
    Subject: What is missing from Git v2.0
    Newsgroups: gmane.comp.version-control.git
    To: git@vger.kernel.org
    Date: Sun, 20 Apr 2014 17:41:05 -0500 (4 days, 17 hours, 12 minutes ago)

    [...]

    = Reject non-fast-forward pulls by default =

    Many new-comers end up making merges by mistake when they pull
    because they don't understand what is a non-fast-forward and what
    they should actually be doing. Most people, even Linus Torvalds,
    agreed that by default `git pull` should fail and guide the user,
    instead of silently making a merge which might not be what the user
    wants (even though he doesn't know it), and messing up the project's
    history, which affects other people.

    The patches were sent, the issues were addressed, people agreed, and
    yet nothing happened.

    [3][4]

    [...]

    [3] http://thread.gmane.org/gmane.comp.version-control.git/240030
    [4] http://thread.gmane.org/gmane.comp.version-control.git/235981


> "How do I get feedback on design of a new change without wasting a lot
> of time coding something that might be a bad idea?"  Glad you asked.

I didn't.

> "What about reminders about known bugs?  There's this regression and
> it would not be right to release without fixing it but I think it's
> fallen through the cracks."  Yes, good contribution.
>
> "What about jokes?"  Sure, making people laugh is productive.
>
> "What about cryptic grumbling?"  Sorry, unless you are grumbling to
> get input on how to improve git's documentation or code, it's not
> enough to be worth sending an email to this list.
>
> Hope that helps,

No need to get condescending if you did not get the joke.

-- 
David Kastrup

Re: What is missing from Git v2.0

[Jonathan Nieder]

David Kastrup wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> I probably missed a subtlety, but the above comment reminded me of
>> some netiquette I think this list is starting to forget.  If I have
>> misread it, please let me know and skip the rest of this message.
[...]
>> On the git list, the rule is simple.  Feel free to grumble, but make
>> sure there is some contribution in the same message.
[...]
> Uh, Javier was commenting on a number of concrete proposals regarding
> the subject line "What is missing from Git v2.0" and quoted Felipe
> directly.  As you seem to have lost the context, let me requote the
> respective portion:

I hadn't lost the context, but thanks for a pointer.

[...]
>     = Reject non-fast-forward pulls by default =
[...]
>     The patches were sent, the issues were addressed, people agreed, and
>     yet nothing happened.
>
>     [3][4]
>
>     [...]
>
>     [3] http://thread.gmane.org/gmane.comp.version-control.git/240030
>     [4] http://thread.gmane.org/gmane.comp.version-control.git/235981

Unfortunately Felipe's summary is incomplete.

My message was meant as something that could be made into a reference
for when similar questions of netiquette come up in the future (as for
example they do all the time with Felipe).  That meant I didn't give
as good advice for your particular case than I should have.

For this particular case, my thoughts are:

If you believe those patches should be applied, please re-send them
with a summary of changes you've made (if any) and your opinion on
any unaddressed comments from the review thread.

If you believe those patches should not be applied, wouldn't it be
better to reply to that thread to help in case someone wants to pick
up the patches and fix them?

On the other hand if you just want to blow off steam, I guess that's
fine too.  Just don't expect it to result in any patches being
applied, code quality improving, etc.

Jonathan

Re: What is missing from Git v2.0

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I am not fundamentally opposed.  I just do not think it would add
> much value to new people at this point, and it will actively hurt
> if we shoved barely cooked one in 2.0.
>
> A few thinking points that are necessary to be worked out, even
> before we start imagining a plan to introduce them, off the top of
> my head, are these:
>
>  * Should we add many random aliases, or should we limit ourselves
>    only to a narrow set that everybody can agree on?
>
>  * What is the additional cognitive load do we feel comfortable
>    burdening with the new users?
>
>  * What is the exact mechanism to give these built-in aliases?
>
> Imagine that somebody says "[alias] ci = commit" and a handful of
> vocal people on this list agree that it is a good idea.  Many random
> websites start mentioning "git ci -a" in their beginner examples.
>
> Users are led to think "ci" is a command just like "commit" and does
> the same thing.... and need to learn that only the
> first kind and not the second kind cannot be used to define their
> own alias (and the users need to learn "commit" at that time as
> well).

A bit further on this point, looking into the future.

It might help if we added some "introduction" phase to the first
invocation of "git init", "git clone", etc. that is interactively
run on a machine where there is no $HOME/.gitconfig detected, and
help the user populate it with a few selected and uncontroversial
ones.  Such a session might go like this:

	$ git init
        ... We do not see $HOME/.gitconfig; using Git for the first time?
        ... Let us ask a few questions to make your Git life more pleasant.
        >> What name do you want to appear on your commits?
        Sebastian Schuberth
        >> What email address do you want to appear on your commits?
	sschuberth@gmail.com
        >> You record your commits as
        ... "Sebastian Schuberth   <sschuberth@gmail.com>".
        >> OK?
        Y
        >> Do you want us to add a few sample aliases to your configuration file?
        Y
        ... Done.  You can further tweak $HOME/.gitconfig to suit
        ... Git to your taste.

And it would end up with something like this:

	$ cat $HOME/.gitconfig
        [user]
		name = <<interactively ask and record the result>>
                email = <<ditto>>
	[alias]
        	co = checkout
		lg = log --oneline

which can serve as an example the user can then tweak, without
giving any false impression that "co" is any more special than
whatever the user adds as a custom alias.

But the need to make the set minimum and the need to carefully think
things through are still there (Ted made a very good point about "rb",
which I agree with).

Re: What is missing from Git v2.0

[Felipe Contreras]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I am not fundamentally opposed.  I just do not think it would add
> > much value to new people at this point, and it will actively hurt
> > if we shoved barely cooked one in 2.0.
> >
> > A few thinking points that are necessary to be worked out, even
> > before we start imagining a plan to introduce them, off the top of
> > my head, are these:
> >
> >  * Should we add many random aliases, or should we limit ourselves
> >    only to a narrow set that everybody can agree on?
> >
> >  * What is the additional cognitive load do we feel comfortable
> >    burdening with the new users?
> >
> >  * What is the exact mechanism to give these built-in aliases?
> >
> > Imagine that somebody says "[alias] ci = commit" and a handful of
> > vocal people on this list agree that it is a good idea.  Many random
> > websites start mentioning "git ci -a" in their beginner examples.
> >
> > Users are led to think "ci" is a command just like "commit" and does
> > the same thing.... and need to learn that only the
> > first kind and not the second kind cannot be used to define their
> > own alias (and the users need to learn "commit" at that time as
> > well).
> 
> A bit further on this point, looking into the future.
> 
> It might help if we added some "introduction" phase to the first
> invocation of "git init", "git clone", etc. that is interactively
> run on a machine where there is no $HOME/.gitconfig detected, and
> help the user populate it with a few selected and uncontroversial
> ones.  Such a session might go like this:
> 
> 	$ git init
>         ... We do not see $HOME/.gitconfig; using Git for the first time?

We shouldn't say $HOME/.gitconfig, that's not user friendly, and it might not
be accurate.

Plus, we might prefer $XDG_CONFIG_HOME/.config/git/config.

"There doesn't seem to be a Git user configuration." is enough.

>         >> Do you want us to add a few sample aliases to your configuration file?
>         Y

I don't see the point in asking this, just put them, the user can remove them
if he doesn't want.

>         ... Done.  You can further tweak $HOME/.gitconfig to suit
>         ... Git to your taste.

Aagain not friendly. `git config --global --edit`.

> And it would end up with something like this:
> 
> 	$ cat $HOME/.gitconfig
>         [user]
> 		name = <<interactively ask and record the result>>
>                 email = <<ditto>>
> 	[alias]
>         	co = checkout
> 		lg = log --oneline
> 
> which can serve as an example the user can then tweak, without
> giving any false impression that "co" is any more special than
> whatever the user adds as a custom alias.

You are assuming the user wanted to "further tweak", most likely he didn't, in
which case he wouldn't have seen those aliases.

It would be more friendly if the aliases are always there, then we can mention
them in the documentation of the relevant commands.

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:
> BTW, in my experience people tend to stick to predefined aliases instead of
> redefining them to something (completely) different. This means that having
> default aliases will very likely enable one to use the same short commands
> on one's colleague's PC (instead of you running into issues because the same
> alias was defined to a different command).
> 
> If we don't standardize this now people will come up with their own
> definitions [1] [2] (and many others if you just search GitHub) which are
> again likely to differ (slightly), hindering interoperability.

Unfortunately, that's already happened.  Some people alias ci to commit,
and some people alias it to commit -a.  There is literally no choice you
can make there that will make everyone happy.

If you provide default aliases, people will expect them to work
everywhere, and then be confused when they don't.  It's much better to
let people alias what they want on their own.  I understand the
frustration of having to work on others' machines when they don't have
your aliases, because every time I type "git pff"[0] and it fails, it
drives me crazy, but there's just no sane defaults.

[0] Aliased to git pull --ff-only.  I probably run this at least twenty
times a day.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: What is missing from Git v2.0

[Felipe Contreras]

brian m. carlson wrote:
> On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:
> > BTW, in my experience people tend to stick to predefined aliases instead of
> > redefining them to something (completely) different. This means that having
> > default aliases will very likely enable one to use the same short commands
> > on one's colleague's PC (instead of you running into issues because the same
> > alias was defined to a different command).
> > 
> > If we don't standardize this now people will come up with their own
> > definitions [1] [2] (and many others if you just search GitHub) which are
> > again likely to differ (slightly), hindering interoperability.
> 
> Unfortunately, that's already happened.  Some people alias ci to commit,
> and some people alias it to commit -a.  There is literally no choice you
> can make there that will make everyone happy.

Of course we can:
a) The people that have 'alias.co = git commit' will keep their alias
b) The people that have 'alias.co = git commit -a' will keep their alias
c) The people that haven't set alias.co, will get the default

> If you provide default aliases, people will expect them to work
> everywhere, and then be confused when they don't.

This argument was already brought up, and already proved to be false.

Mercurial allows not only to override the default alias, but to override the
core commands, so you can alias 'hg push' to 'hg push --force'. According to
your hypothesis people using Mercurial would get confused when basic commands
work on certain machines and not others. This is not the case. I challenge you
to find a single instance when people got confused because of the configured
aliases.

> It's much better to let people alias what they want on their own.  I
> understand the frustration of having to work on others' machines when they
> don't have your aliases, because every time I type "git pff"[0] and it fails,
> it drives me crazy, but there's just no sane defaults.

Yes there are sane defaults.

  co = checkout
  ci = commit
  rb = rebase
  st = status
  br = branch
  dt = difftool
  mt = mergetool

-- 
Felipe Contreras

Re: What is missing from Git v2.0

[David Aguilar]

On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
> = Reject non-fast-forward pulls by default =
> 
> Many new-comers end up making merges by mistake when they pull because
> they don't understand what is a non-fast-forward and what they should
> actually be doing. Most people, even Linus Torvalds, agreed that by
> default `git pull` should fail and guide the user, instead of silently
> making a merge which might not be what the user wants (even though he
> doesn't know it), and messing up the project's history, which affects
> other people.
> 
> The patches were sent, the issues were addressed, people agreed, and
> yet nothing happened.

We can currently set pull.ff = only to get this behavior.
I would like it if this were the default (but I am biased).

> = Use "stage" instead of "index" =

I'm probably biased about this one too, but I should probably speak up.

git-cola has used "Staged", "Modified", "Untracked", etc. since
the beginning of time.  Sorry 'bout that, but it seemed like the
simplest word to use.

I often hear users talking about "staging" files.
I'm probably in an echo chamber, but I never really had to
explain "the staging area" since the concept is pretty natural
when interacting with the GUI.

Just my $.02.

ciao,
-- 
David

Re: What is missing from Git v2.0

[Felipe Contreras]

David Aguilar wrote:
> On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:
> > = Reject non-fast-forward pulls by default =
> > 
> > Many new-comers end up making merges by mistake when they pull because
> > they don't understand what is a non-fast-forward and what they should
> > actually be doing. Most people, even Linus Torvalds, agreed that by
> > default `git pull` should fail and guide the user, instead of silently
> > making a merge which might not be what the user wants (even though he
> > doesn't know it), and messing up the project's history, which affects
> > other people.
> > 
> > The patches were sent, the issues were addressed, people agreed, and
> > yet nothing happened.
> 
> We can currently set pull.ff = only to get this behavior.

It is not the same behavior as my patch series, you get:

  fatal: Not possible to fast-forward, aborting.

With that message we certainly cannot make it the default. In my patch series you get:

  The pull was not fast-forward, please either merge or rebase.
  If unsure, run 'git pull --merge'.

> I would like it if this were the default (but I am biased).

I don't know if you followed the discussion, but virtually everyone (including
Linus) agreed this should be the default.

> > = Use "stage" instead of "index" =
> 
> I'm probably biased about this one too, but I should probably speak up.
> 
> git-cola has used "Staged", "Modified", "Untracked", etc. since
> the beginning of time.  Sorry 'bout that, but it seemed like the
> simplest word to use.
> 
> I often hear users talking about "staging" files.
> I'm probably in an echo chamber, but I never really had to
> explain "the staging area" since the concept is pretty natural
> when interacting with the GUI.

Again, virtually everyone (except Junio) agrees.

-- 
Felipe Contreras