[PATCH v3] build: add default aliases

[PATCH v3] build: add default aliases

[Felipe Contreras]

For now simply add a few common aliases.

  co = checkout
  ci = commit
  rb = rebase
  st = status

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---

I still think we should ship a default /etc/gitconfig, but the project needs to
agree it's a good change, and nobody every agrees changes are good. So this is
the minimal change that achieves the desired result.

 Documentation/git-checkout.txt |  5 +++++
 Documentation/git-commit.txt   |  5 +++++
 Documentation/git-rebase.txt   |  5 +++++
 Documentation/git-status.txt   |  5 +++++
 alias.c                        | 17 +++++++++++++++++
 5 files changed, 37 insertions(+)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ca118ac..7597813 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -14,6 +14,11 @@ SYNOPSIS
 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
 
+ALIAS
+-----
+
+git co
+
 DESCRIPTION
 -----------
 Updates files in the working tree to match the version in the index
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..8705abc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -15,6 +15,11 @@ SYNOPSIS
 	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
 	   [-i | -o] [-S[<keyid>]] [--] [<file>...]
 
+ALIAS
+-----
+
+git ci
+
 DESCRIPTION
 -----------
 Stores the current contents of the index in a new commit along
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 6b2e1c8..bb18fea 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -14,6 +14,11 @@ SYNOPSIS
 	--root [<branch>]
 'git rebase' --continue | --skip | --abort | --edit-todo
 
+ALIAS
+-----
+
+git rb
+
 DESCRIPTION
 -----------
 If <branch> is specified, 'git rebase' will perform an automatic
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 9046df9..30ecd25 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -11,6 +11,11 @@ SYNOPSIS
 [verse]
 'git status' [<options>...] [--] [<pathspec>...]
 
+ALIAS
+-----
+
+git st
+
 DESCRIPTION
 -----------
 Displays paths that have differences between the index file and the
diff --git a/alias.c b/alias.c
index eb9f08b..d6bad69 100644
--- a/alias.c
+++ b/alias.c
@@ -14,11 +14,28 @@ static int alias_lookup_cb(const char *k, const char *v, void *cb)
 	return 0;
 }
 
+static struct {
+	const char *key;
+	const char *val;
+} default_aliases[] = {
+	{ "co", "checkout" },
+	{ "ci", "checkout" },
+	{ "rb", "rebase" },
+	{ "st", "status" },
+};
+
 char *alias_lookup(const char *alias)
 {
+	int i;
 	alias_key = alias;
 	alias_val = NULL;
 	git_config(alias_lookup_cb, NULL);
+	if (alias_val)
+		return alias_val;
+	for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {
+		if (!strcmp(alias, default_aliases[i].key))
+			return xstrdup(default_aliases[i].val);
+	}
 	return alias_val;
 }
 
-- 
1.8.4-fc

Re: [PATCH v3] build: add default aliases

[Jeff King]

On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:

> For now simply add a few common aliases.
> 
>   co = checkout
>   ci = commit
>   rb = rebase
>   st = status

Are these the best definitions of those shortcuts? It seems[1] that some
people define "ci" as "commit -a", and some people define "st" as
"status -s" or even "status -sb".

You are making things more consistent for people who already define
those aliases in the same way (they are available everywhere, even if
they have not moved their config to a new installation), but less so for
people who define them differently. Rather than get an obvious:

  git: 'co' is not a git command. See 'git --help'.

the result will be subtly different (especially so in the case of
"commit" versus "commit -a").

-Peff

[1] https://github.com/search?q=%22ci+%3D+commit+-a%22+path%3A.gitconfig&type=Code

    https://github.com/search?q=%22st+%3D+status+-s%22&type=Code

    https://github.com/search?q=%22st+%3D+status+-sb%22&type=Code

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Mon, Sep 23, 2013 at 11:53 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>
>> For now simply add a few common aliases.
>>
>>   co = checkout
>>   ci = commit
>>   rb = rebase
>>   st = status
>
> Are these the best definitions of those shortcuts? It seems[1] that some
> people define "ci" as "commit -a", and some people define "st" as
> "status -s" or even "status -sb".
>
> You are making things more consistent for people who already define
> those aliases in the same way (they are available everywhere, even if
> they have not moved their config to a new installation), but less so for
> people who define them differently. Rather than get an obvious:
>
>   git: 'co' is not a git command. See 'git --help'.
>
> the result will be subtly different (especially so in the case of
> "commit" versus "commit -a").

Before:

# machine A: git ci
git: 'ca' is not a git command. See 'git --help'.

# machine B: git ci
commits

After:

# machine A: git ci
no changes added to commit (use "git add" and/or "git commit -a")

# machine B: git ci
commits

The "after" part is much more consistent, at least several commands
have a higher chance of doing what the user actually wants, at worst
they would do something close to what the user wants.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Jeff King]

On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:

> > You are making things more consistent for people who already define
> > those aliases in the same way (they are available everywhere, even if
> > they have not moved their config to a new installation), but less so for
> > people who define them differently. Rather than get an obvious:
> >
> >   git: 'co' is not a git command. See 'git --help'.
> >
> > the result will be subtly different (especially so in the case of
> > "commit" versus "commit -a").
> 
> Before:
> 
> # machine A: git ci
> git: 'ca' is not a git command. See 'git --help'.
> 
> # machine B: git ci
> commits
> 
> After:
> 
> # machine A: git ci
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> # machine B: git ci
> commits

That is the output if there are no files to commit. What about while
resolving a merge, or after using "git add" on a path? In that case we
create a commit, but it is subtly different than what the user intended.

I think for the merge case, it is probably OK, as the "surprise" should
always go in the safe direction (user expects "commit -a", gets
"commit", and commit balks). But the other omits intended files from the
commit.

-Peff

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 12:37 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:
>
>> > You are making things more consistent for people who already define
>> > those aliases in the same way (they are available everywhere, even if
>> > they have not moved their config to a new installation), but less so for
>> > people who define them differently. Rather than get an obvious:
>> >
>> >   git: 'co' is not a git command. See 'git --help'.
>> >
>> > the result will be subtly different (especially so in the case of
>> > "commit" versus "commit -a").
>>
>> Before:
>>
>> # machine A: git ci
>> git: 'ca' is not a git command. See 'git --help'.
>>
>> # machine B: git ci
>> commits
>>
>> After:
>>
>> # machine A: git ci
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> # machine B: git ci
>> commits
>
> That is the output if there are no files to commit. What about while
> resolving a merge, or after using "git add" on a path? In that case we
> create a commit, but it is subtly different than what the user intended.

It might be different, but it might not.

Anyway, if you are so worried about this hypothetical user not
noticing that 'git ci' didn't commit all the files, we could ma ci to
'git commit -v' so we are being straightforward to the user as to what
is being committed.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Jeff King]

On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:

> Anyway, if you are so worried about this hypothetical user not
> noticing that 'git ci' didn't commit all the files, we could ma ci to
> 'git commit -v' so we are being straightforward to the user as to what
> is being committed.

I do not think that is a useful suggestion, as the output of "commit -v"
is typically too long for unsuspecting people to check carefully, and is
redundant with the filename summary we already put in the commit
template. And neither is shown with "-m", anyway.  I agree it's a
minority of cases where somebody will make a bogus commit because of it,
though.

But let's take a step back for a moment. What was the goal of the patch?
Who are we trying to help? People who already have identical aliases are
not helped on existing boxes; they already have them. They might be
helped on new boxes, where they will not have to copy over their custom
aliases (but they would probably end up wanting to copy the rest of
their config and aliases anyway).  People who have different aliases for
the same terms are unaffected on existing boxes, but slightly hindered
on new boxes as the aliases do something else.

People with no matching aliases now get these aliases. What do they
expect them to do? Do they expect "commit" or "commit -a"? Do they
expect "status" or "status -s" or "status -sb"? Are we trying for
consistency across git installations, or consistency with similar
aliases in systems like cvs (in which case, would that argue for "commit
-a")? Do people who have not bothered to configure the aliases even
care?

My original question was: are these the best definitions of those
shortcuts? I have not seen any answer to that.

-Peff

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 1:18 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:
>
>> Anyway, if you are so worried about this hypothetical user not
>> noticing that 'git ci' didn't commit all the files, we could ma ci to
>> 'git commit -v' so we are being straightforward to the user as to what
>> is being committed.
>
> I do not think that is a useful suggestion, as the output of "commit -v"
> is typically too long for unsuspecting people to check carefully, and is
> redundant with the filename summary we already put in the commit
> template. And neither is shown with "-m", anyway.  I agree it's a
> minority of cases where somebody will make a bogus commit because of it,
> though.
>
> But let's take a step back for a moment. What was the goal of the patch?
> Who are we trying to help? People who already have identical aliases are
> not helped on existing boxes; they already have them. They might be
> helped on new boxes, where they will not have to copy over their custom
> aliases (but they would probably end up wanting to copy the rest of
> their config and aliases anyway).

They probably will want that, but they won't be forced to by typing
failing commands, they could do it later at their pleasure.

> People who have different aliases for
> the same terms are unaffected on existing boxes, but slightly hindered
> on new boxes as the aliases do something else.

Less hindered than in the current situation.

> People with no matching aliases now get these aliases. What do they
> expect them to do? Do they expect "commit" or "commit -a"? Do they
> expect "status" or "status -s" or "status -sb"? Are we trying for
> consistency across git installations, or consistency with similar
> aliases in systems like cvs (in which case, would that argue for "commit
> -a")? Do people who have not bothered to configure the aliases even
> care?

cvs ci = cvs commit
cvs co = cvs checkout

svn ci = svn commit
svn co = svn checkout

hg ci = hg commit
hg co = hg checkout

And somehow you think this is not natural and sensible?

git ci = git commit
git co = git checkout

I think it's as clear as day.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Jeff King]

On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote:

> > People who have different aliases for
> > the same terms are unaffected on existing boxes, but slightly hindered
> > on new boxes as the aliases do something else.
> 
> Less hindered than in the current situation.

I do not agree, but I've already explained my reasoning.  I think we
must agree to disagree on this.

> cvs ci = cvs commit
> cvs co = cvs checkout
> 
> svn ci = svn commit
> svn co = svn checkout
> 
> hg ci = hg commit
> hg co = hg checkout
> 
> And somehow you think this is not natural and sensible?
> 
> git ci = git commit
> git co = git checkout
> 
> I think it's as clear as day.

If it is natural, sensible, and as clear as day, then why do people
alias the commands to something besides what you show?

-Peff

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 1:46 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote:
>
>> > People who have different aliases for
>> > the same terms are unaffected on existing boxes, but slightly hindered
>> > on new boxes as the aliases do something else.
>>
>> Less hindered than in the current situation.
>
> I do not agree, but I've already explained my reasoning.  I think we
> must agree to disagree on this.
>
>> cvs ci = cvs commit
>> cvs co = cvs checkout
>>
>> svn ci = svn commit
>> svn co = svn checkout
>>
>> hg ci = hg commit
>> hg co = hg checkout
>>
>> And somehow you think this is not natural and sensible?
>>
>> git ci = git commit
>> git co = git checkout
>>
>> I think it's as clear as day.
>
> If it is natural, sensible, and as clear as day, then why do people
> alias the commands to something besides what you show?

For the same reason people would do alias.commit='commit -a' if it was possible.

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

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Jonathan Nieder]

Jeff King wrote:
> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:

>> For now simply add a few common aliases.
>>
>>   co = checkout
>>   ci = commit
>>   rb = rebase
>>   st = status
>
> Are these the best definitions of those shortcuts? It seems[1] that some
> people define "ci" as "commit -a", and some people define "st" as
> "status -s" or even "status -sb".

I feel bad about having waited for 4 rounds of this patch to say this,
but the basic change (providing "co", "ci", etc. as aliases by
default) does not look well thought through.

It would be a different story if this were a patch to update
documentation to suggest adding such aliases at the same time as
telling Git what your name is.  The user manual doesn't explain how to
set up aliases at all yet, and that should be fixed.

But making 'ci' a synonym of another command by default while still
keeping its definition configurable would be doing people a
disservice, I fear.  As long as 'ci' works out of the box, it will
start showing up in examples and used in suggestions over IRC, etc,
which is great.  Unfortunately that means that anyone who has 'ci'
defined to mean something different can no longer use those examples,
that advice from IRC, and so on.  So in the world where 'ci' is a
synonym for 'commit' by default, while people still *can* redefine
'ci' to include whatever options they like (e.g., "-a"), actually
carrying out such a personal customization is asking for trouble.

Incidentally, that is also the reason git already doesn't allow
aliases to override built-in commands such as "git commit", even
though it would be convenient to some to not have to remember to add
"-a" each time.  As consolation we have been able to say "But you can
take the even shorter-and-sweeter 'git ci' and make it mean whatever
you want".  Now we should take that avenue away for people?

Bad idea.

Hope that helps,
Jonathan

Re: [PATCH v3] build: add default aliases

[John Szakmeister]

On Tue, Sep 24, 2013 at 2:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jeff King wrote:
>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>
>>> For now simply add a few common aliases.
>>>
>>>   co = checkout
>>>   ci = commit
>>>   rb = rebase
>>>   st = status
>>
>> Are these the best definitions of those shortcuts? It seems[1] that some
>> people define "ci" as "commit -a", and some people define "st" as
>> "status -s" or even "status -sb".
>
> I feel bad about having waited for 4 rounds of this patch to say this,
> but the basic change (providing "co", "ci", etc. as aliases by
> default) does not look well thought through.
>
> It would be a different story if this were a patch to update
> documentation to suggest adding such aliases at the same time as
> telling Git what your name is.  The user manual doesn't explain how to
> set up aliases at all yet, and that should be fixed.

Yes, better documentation around aliases would be a good idea.

> But making 'ci' a synonym of another command by default while still
> keeping its definition configurable would be doing people a
> disservice, I fear.  As long as 'ci' works out of the box, it will
> start showing up in examples and used in suggestions over IRC, etc,
> which is great.  Unfortunately that means that anyone who has 'ci'
> defined to mean something different can no longer use those examples,
> that advice from IRC, and so on.  So in the world where 'ci' is a
> synonym for 'commit' by default, while people still *can* redefine
> 'ci' to include whatever options they like (e.g., "-a"), actually
> carrying out such a personal customization is asking for trouble.

I'm not sure I agree.  Yes, if someone has configured their shortcut
differently, they may not be able to use the example exactly.  OTOH,
shells have aliases, and while there are sometimes problems, I think
most people overcome them.  I don't see the situation being very
different here.

FWIW, I'm not overly convinced one way or another.  What I can say is,
in the circles I run in, I can only think of one person has gone
without setting up aliases to commit (ci), status (st), and checkout
(co).  The full names are simply to long for day-to-day usage.

-John

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jeff King wrote:
>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>
>>> For now simply add a few common aliases.
>>>
>>>   co = checkout
>>>   ci = commit
>>>   rb = rebase
>>>   st = status
>>
>> Are these the best definitions of those shortcuts? It seems[1] that some
>> people define "ci" as "commit -a", and some people define "st" as
>> "status -s" or even "status -sb".
>
> I feel bad about having waited for 4 rounds of this patch to say this,
> but the basic change (providing "co", "ci", etc. as aliases by
> default) does not look well thought through.

To you.

> It would be a different story if this were a patch to update
> documentation to suggest adding such aliases at the same time as
> telling Git what your name is.  The user manual doesn't explain how to
> set up aliases at all yet, and that should be fixed.

That's a completely different subject.

> But making 'ci' a synonym of another command by default while still
> keeping its definition configurable would be doing people a
> disservice, I fear.

And I and many (most) users disagree.

> As long as 'ci' works out of the box, it will
> start showing up in examples and used in suggestions over IRC, etc,
> which is great.

It might, or...

> Unfortunately that means that anyone who has 'ci'
> defined to mean something different can no longer use those examples,
> that advice from IRC, and so on.  So in the world where 'ci' is a
> synonym for 'commit' by default, while people still *can* redefine
> 'ci' to include whatever options they like (e.g., "-a"), actually
> carrying out such a personal customization is asking for trouble.

Precisely for this reason it might not. If people know aliases can be
different in different machines, they would avoid them in
documentation which is meant for all machines.

If you truly want to be pedantic, you could add a warning if the
default alias is not used, and this warning gets silenced if the user
configures the alias manually.

> Incidentally, that is also the reason git already doesn't allow
> aliases to override built-in commands such as "git commit", even
> though it would be convenient to some to not have to remember to add
> "-a" each time.  As consolation we have been able to say "But you can
> take the even shorter-and-sweeter 'git ci' and make it mean whatever
> you want".  Now we should take that avenue away for people?

Who is taking away that avenue? Certainly not this patch.

> Bad idea.

Only if you assume your hypothesis is a fact, which is not, and even
if you do, it's still not.

> Hope that helps,

The project? No, it doesn't. Virtually every VCS out there has default aliases,
and Git somehow cannot manage to get them done.

And BTW, look what I can do in mercurial:

.hgrc
---
[alias]
status = status --all
---

OMG! The world is going to end! No, it's not, it's no problem. What you think
is so clearly a bad idea, seems to be doing just fine in Mercurial.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Michael Haggerty]

On 09/29/2013 12:41 AM, Felipe Contreras wrote:
> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>>>> For now simply add a few common aliases.
>>>>
>>>>   co = checkout
>>>>   ci = commit
>>>>   rb = rebase
>>>>   st = status
>>>
>>> [...]
> 
>> But making 'ci' a synonym of another command by default while still
>> keeping its definition configurable would be doing people a
>> disservice, I fear.
> 
> And I and many (most) users disagree.
> 
>> As long as 'ci' works out of the box, it will
>> start showing up in examples and used in suggestions over IRC, etc,
>> which is great.

...and in scripts.

> It might, or...
> 
>> Unfortunately that means that anyone who has 'ci'
>> defined to mean something different can no longer use those examples,
>> that advice from IRC, and so on.  So in the world where 'ci' is a
>> synonym for 'commit' by default, while people still *can* redefine
>> 'ci' to include whatever options they like (e.g., "-a"), actually
>> carrying out such a personal customization is asking for trouble.
> 
> Precisely for this reason it might not. If people know aliases can be
> different in different machines, they would avoid them in
> documentation which is meant for all machines.

My experience contradicts your prediction.  I have 'ci'/'co' aliases in
my own configuration.  But even though I am aware of the fact that other
people might not have the same aliases, I have on multiple occasions
used them in documentation and/or scripts meant for other people.  The
muscle memory is just too strong.

My error was discovered by other people who didn't have those aliases.
If *most* people had the same aliases as I did, and others had defined
their own slightly different ones, then the scripts would have subtly
malfunctioned for the latter set of users and I would have had trouble
reproducing the errors.

That being said, independent of aliases, there are many other config
settings that can affect commands that might be used in documentation or
scripts, and which also could be the source of errors for the non-vigilent.

So, even though I think such aliases are a great convenience factor, I
am -0 on including pre-defined but overrideable aliases and -1 on
including pre-defined and non-overrideable aliases.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Sat, Sep 28, 2013 at 10:18 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 09/29/2013 12:41 AM, Felipe Contreras wrote:
>> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>>>>> For now simply add a few common aliases.
>>>>>
>>>>>   co = checkout
>>>>>   ci = commit
>>>>>   rb = rebase
>>>>>   st = status
>>>>
>>>> [...]
>>
>>> But making 'ci' a synonym of another command by default while still
>>> keeping its definition configurable would be doing people a
>>> disservice, I fear.
>>
>> And I and many (most) users disagree.
>>
>>> As long as 'ci' works out of the box, it will
>>> start showing up in examples and used in suggestions over IRC, etc,
>>> which is great.
>
> ...and in scripts.
>
>> It might, or...
>>
>>> Unfortunately that means that anyone who has 'ci'
>>> defined to mean something different can no longer use those examples,
>>> that advice from IRC, and so on.  So in the world where 'ci' is a
>>> synonym for 'commit' by default, while people still *can* redefine
>>> 'ci' to include whatever options they like (e.g., "-a"), actually
>>> carrying out such a personal customization is asking for trouble.
>>
>> Precisely for this reason it might not. If people know aliases can be
>> different in different machines, they would avoid them in
>> documentation which is meant for all machines.
>
> My experience contradicts your prediction.  I have 'ci'/'co' aliases in
> my own configuration.  But even though I am aware of the fact that other
> people might not have the same aliases, I have on multiple occasions
> used them in documentation and/or scripts meant for other people.  The
> muscle memory is just too strong.

If you are already making that error, then this patch wouldn't make it
any worst. In fact, it would make the situation better.

If previously you had 10 persons complaining about the "ci" command
not working, now 9 of them wouldn't complain because "git ci" does
actually work, even if you have aliased it to something slightly
different, like "commit -v". Instead, you would have 1 person
complaining, because he has a different alias, which makes the command
fail somehow. In reality, that 1 person might not even exist.

The solution before and after my patch is the same; avoid the 'ci'/'co' aliases.

> My error was discovered by other people who didn't have those aliases.

And after this patch it still will.

> If *most* people had the same aliases as I did, and others had defined
> their own slightly different ones, then the scripts would have subtly
> malfunctioned for the latter set of users and I would have had trouble
> reproducing the errors.

Doubtful. But a warning that a default alias is being used, or simply
showing the actual command in the standard output would fix the
problem.

It certainly looks like you are not even looking for solutions for the
hypothetical problems you put forward.

> So, even though I think such aliases are a great convenience factor, I
> am -0 on including pre-defined but overrideable aliases and -1 on
> including pre-defined and non-overrideable aliases.

And still, somehow every other VCS out there manages default aliases
just fine, and Mercurial even allows overriding commands. How do you
explain that the world hasn't ended for them?

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Jonathan Nieder]

Michael Haggerty wrote:

> That being said, independent of aliases, there are many other config
> settings that can affect commands that might be used in documentation or
> scripts, and which also could be the source of errors for the non-vigilent.

Yep, this is a problem, too (I'm looking at you, "git push").  We try
to avoid this problem or balance it against convenience by being
careful when adding new configuration, but sometimes we slip up.

Thanks for your thoughtfulness.

Sincerely,
Jonathan

Re: [PATCH v3] build: add default aliases

[Duy Nguyen]

On Tue, Oct 1, 2013 at 2:33 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Michael Haggerty wrote:
>
>> That being said, independent of aliases, there are many other config
>> settings that can affect commands that might be used in documentation or
>> scripts, and which also could be the source of errors for the non-vigilent.
>
> Yep, this is a problem, too (I'm looking at you, "git push").  We try
> to avoid this problem or balance it against convenience by being
> careful when adding new configuration, but sometimes we slip up.

I think the problem is we start pushing too much on the porcelain
front and forget about plumbing. "git push" is for human, but I don't
think there's an equivalent for scripts. "git branch --list" vs "git
for-each-ref" is a good example.
-- 
Duy

Re: [PATCH v3] build: add default aliases

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> It seems[1] that some
> people define "ci" as "commit -a", and some people define "st" as
> "status -s" or even "status -sb".

These option variants aside.

Just like thinking that committing must be the same as publishing,
it is a cvs/svn induced braindamage to think that "checking in" must
be the same as "committing".  The former is a sign of not
understanding the "distributed", the latter "the index".

In a world with both check-in and commit as two words usable to
denote possibly different concepts, it may make sense to say "you
check-in the current status of the working tree files into the
index, in order to make commits out of it later".

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > It seems[1] that some
> > people define "ci" as "commit -a", and some people define "st" as
> > "status -s" or even "status -sb".
> 
> These option variants aside.
> 
> Just like thinking that committing must be the same as publishing,
> it is a cvs/svn induced braindamage to think that "checking in" must
> be the same as "committing".  The former is a sign of not
> understanding the "distributed", the latter "the index".
> 
> In a world with both check-in and commit as two words usable to
> denote possibly different concepts, it may make sense to say "you
> check-in the current status of the working tree files into the
> index, in order to make commits out of it later".

Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are
just wrong. So you are saying they are just ignorant.

Personally I don't care if it's 'ci', or 'co', or 'cm', or 'ct'. I just
want/need a shortcut, then I can train my fingers to type that.

If you have a better alias than 'ci', then by all means, throw away your
suggestion.

Now, if you are commenting on the aliases, that would mean you are not against
the idea of aliaes per se, but more about values of those aliases. So if we
agreed on the right values, you would welcome this patch.

Is that correct?

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>> > It seems[1] that some
>> > people define "ci" as "commit -a", and some people define "st" as
>> > "status -s" or even "status -sb".
>> 
>> These option variants aside.
>> 
>> Just like thinking that committing must be the same as publishing,
>> it is a cvs/svn induced braindamage to think that "checking in" must
>> be the same as "committing".  The former is a sign of not
>> understanding the "distributed", the latter "the index".
>> 
>> In a world with both check-in and commit as two words usable to
>> denote possibly different concepts, it may make sense to say "you
>> check-in the current status of the working tree files into the
>> index, in order to make commits out of it later".
>
> Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are
> just wrong. So you are saying they are just ignorant.

I am sick of seeing my word twisted, especially when they were not
even addressed to you (see the message's primary recipients list).
Those who want to type "git ci" due to their familiarity with "svn
ci" are not wrong; they can do so if they choose.

Let's try again (see below).

> Now, if you are commenting on the aliases, that would mean you are not against
> the idea of aliaes per se, but more about values of those aliases. So if we
> agreed on the right values, you would welcome this patch.
>
> Is that correct?

No.

I agree with the issue the message I was replying to raised. The
alias mechanism is a way to help users to define their own
convenient short-cut. If you want to say "git ci" to mean "git
commit" (and not "git commit -a" or something else), define it for
your own use, and stop there, without getting in the way of other
people. That is why I see an attempt to add hard-coded set of
aliases as a move in the wrong direction.

A set of hard-coded alias that _officially_ declares that "checkin"
is an equivalent to "commit" has another issue.  It will close the
door for us to later add "git checkin" that may mean something
different from "git commit", and that is another reason why I do not
agree with the patch under discussion in this thread. A "checkin"
that is an operation that checks-in the current contents to the
index is one example of an action other than committing that the
word may make sense for, because "git checkout README.txt" is about
checking out of the index, its logical opposite "checkin" could be
about checking into the index.

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> Jeff King <peff@peff.net> writes:
> >> 
> >> > It seems[1] that some
> >> > people define "ci" as "commit -a", and some people define "st" as
> >> > "status -s" or even "status -sb".
> >> 
> >> These option variants aside.
> >> 
> >> Just like thinking that committing must be the same as publishing,
> >> it is a cvs/svn induced braindamage to think that "checking in" must
> >> be the same as "committing".  The former is a sign of not
> >> understanding the "distributed", the latter "the index".
> >> 
> >> In a world with both check-in and commit as two words usable to
> >> denote possibly different concepts, it may make sense to say "you
> >> check-in the current status of the working tree files into the
> >> index, in order to make commits out of it later".
> >
> > Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are
> > just wrong. So you are saying they are just ignorant.
> 
> I am sick of seeing my word twisted, especially when they were not
> even addressed to you (see the message's primary recipients list).

When you send messages to a public mailing list, even if not addressed to that
mailing list, is with the expectation that other people in that mailing list
will reply.

When you say something is a sign of not understanding, that means ignorance,
and there's nothing bad about that, we are all ignorant about many things.

> Those who want to type "git ci" due to their familiarity with "svn
> ci" are not wrong; they can do so if they choose.

I never suggested they were wrong, you suggested they were ignorant.

And this is being used by you as reason *not* to use ci as an alias for commit
by default.

> > Now, if you are commenting on the aliases, that would mean you are not against
> > the idea of aliaes per se, but more about values of those aliases. So if we
> > agreed on the right values, you would welcome this patch.
> >
> > Is that correct?
> 
> No.
> 
> I agree with the issue the message I was replying to raised. The
> alias mechanism is a way to help users to define their own
> convenient short-cut. If you want to say "git ci" to mean "git
> commit" (and not "git commit -a" or something else), define it for
> your own use, and stop there, without getting in the way of other
> people.

A set of default aliases doesn't get in the way of other people either.

That's why all VCS tools have them, and none of them have a problem.

> That is why I see an attempt to add hard-coded set of aliases as a move in
> the wrong direction.

They are not hard-coded, they are configurable.

> A set of hard-coded alias that _officially_ declares that "checkin"
> is an equivalent to "commit" has another issue.

No. Nobody said anything about check-in, it's ci, which could be CommIt. And
you are conveniently ignoring all the other possible aliases for commit.

> It will close the door for us to later add "git checkin" that may mean
> something different from "git commit", and that is another reason why I do
> not agree with the patch under discussion in this thread. A "checkin" that is
> an operation that checks-in the current contents to the index is one example
> of an action other than committing that the word may make sense for, because
> "git checkout README.txt" is about checking out of the index, its logical
> opposite "checkin" could be about checking into the index.

Nobody said anything about a check-in. This is a red herring.

Absolultely nothing you have said in this second half has anything to do with
the question I asked. I asked specifically about the idea of aliases,
independently of their actual values, and all you have done is argue against
the value of a single alias: ci.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[John Szakmeister]

On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> For now simply add a few common aliases.
>
>   co = checkout
>   ci = commit
>   rb = rebase
>   st = status
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>
> I still think we should ship a default /etc/gitconfig, but the project needs to
> agree it's a good change, and nobody every agrees changes are good. So this is
> the minimal change that achieves the desired result.

I wish you would stop attacking the project every time you send a
patch--it's simply not productive and it's certainly not getting you
any closer to a resolution.

That said, I think the idea of having some default aliases is good,
and these match what several other version control systems have
already.

FWIW, I alias st to "status -sb", but I'm not convinced it's a good
default.  I think the safe thing to do is to just alias it to
status--like you did here--and let folks override it, if they want
something more.

-John

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:
> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> For now simply add a few common aliases.
>>
>>   co = checkout
>>   ci = commit
>>   rb = rebase
>>   st = status
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>
>> I still think we should ship a default /etc/gitconfig, but the project needs to
>> agree it's a good change, and nobody every agrees changes are good. So this is
>> the minimal change that achieves the desired result.
>
> I wish you would stop attacking the project every time you send a
> patch--it's simply not productive and it's certainly not getting you
> any closer to a resolution.

I'm not attacking the project, I'm making an objective claim, and I
can back it up with several instances of evidence where 99% of the
users would benefit from a change, yet it does not move forward.

If you don't agree my comment is accurate, that's one thing, but
labeling it as an attack is another.

I would admit I was wrong if an /etc/gitconfig is indeed shipped by
default, and agree that the Git project is indeed welcome to change,
but that's not going to happen.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[John Szakmeister]

On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:
>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> For now simply add a few common aliases.
>>>
>>>   co = checkout
>>>   ci = commit
>>>   rb = rebase
>>>   st = status
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>>
>>> I still think we should ship a default /etc/gitconfig, but the project needs to
>>> agree it's a good change, and nobody every agrees changes are good. So this is
>>> the minimal change that achieves the desired result.
>>
>> I wish you would stop attacking the project every time you send a
>> patch--it's simply not productive and it's certainly not getting you
>> any closer to a resolution.
>
> I'm not attacking the project, I'm making an objective claim, and I
> can back it up with several instances of evidence where 99% of the
> users would benefit from a change, yet it does not move forward.

There's nothing objective about "Nobody every (sic) agrees changes are
good".  If it were true, no changes would get in.

Also, you don't know that any of those changes would benefit "99% of
all users".  It's a guess or an estimate but it's not based on
anything concrete.  It might be a good guess--and in this case, I
think it is--but it's not a concrete fact.  Don't make it sound like
it is.

> If you don't agree my comment is accurate, that's one thing, but
> labeling it as an attack is another.

Don't turn it around.  A number of your patches and emails poke at the
community of the Git project and you know it.  It's simply not helping
the situation.

Your clearly a bright and motivated individual--which makes it all the
more frustrating that you don't approach this differently.  I even
agree with your motivations for Git: I'd like to see less shell and
perl involved and to see Git run faster on Windows.  But I wish you'd
stop with the jabs.

> I would admit I was wrong if an /etc/gitconfig is indeed shipped by
> default, and agree that the Git project is indeed welcome to change,
> but that's not going to happen.

And there it is again.  Predicting the future now?  Objectively and
accurately?  Please stop.

-John

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:
> On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:
>>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>> For now simply add a few common aliases.
>>>>
>>>>   co = checkout
>>>>   ci = commit
>>>>   rb = rebase
>>>>   st = status
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>>
>>>> I still think we should ship a default /etc/gitconfig, but the project needs to
>>>> agree it's a good change, and nobody every agrees changes are good. So this is
>>>> the minimal change that achieves the desired result.
>>>
>>> I wish you would stop attacking the project every time you send a
>>> patch--it's simply not productive and it's certainly not getting you
>>> any closer to a resolution.
>>
>> I'm not attacking the project, I'm making an objective claim, and I
>> can back it up with several instances of evidence where 99% of the
>> users would benefit from a change, yet it does not move forward.
>
> There's nothing objective about "Nobody every (sic) agrees changes are
> good".  If it were true, no changes would get in.

It is true, where by "changes" I mean "changes from common user's
point of view", actually, a tiny amount of then do sneak in, so let me
be precise: "Virtually nobody ever agrees important changes from the
common user's point of view are good".

So now that I'm being clear, do tell, name one important change in Git
from the user's point of view that happened in the last two years.

> Also, you don't know that any of those changes would benefit "99% of
> all users".  It's a guess or an estimate but it's not based on
> anything concrete.  It might be a good guess--and in this case, I
> think it is--but it's not a concrete fact.  Don't make it sound like
> it is.

Sure, it's not a concrete fact, but the actual probability most likely
follows a beta distribution with alpha=15 and beta=1. Is that more
precise for you?

>> If you don't agree my comment is accurate, that's one thing, but
>> labeling it as an attack is another.
>
> Don't turn it around.  A number of your patches and emails poke at the
> community of the Git project and you know it.  It's simply not helping
> the situation.

Show me a patch that "pokes" at the community. All my patches have
technical descriptions, and help improve Git.

> Your clearly a bright and motivated individual--which makes it all the
> more frustrating that you don't approach this differently.  I even
> agree with your motivations for Git: I'd like to see less shell and
> perl involved and to see Git run faster on Windows.  But I wish you'd
> stop with the jabs.

Don't worry, I'll stop the "jabs" (which are really objective
observations which are not particularly flattering for the project,
but true, and serious problems that need to be fixed) as soon when I
leave the project, which I'll do once it's clear my patches are going
nowhere without any valid justification, and we are right on track for
that.

>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by
>> default, and agree that the Git project is indeed welcome to change,
>> but that's not going to happen.
>
> And there it is again.  Predicting the future now?  Objectively and
> accurately?  Please stop.

Yes I am. Feel free to go back to this mail and tell me I was wrong
when they do what I said they won't.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[John Szakmeister]

On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:
[snip]
>> There's nothing objective about "Nobody every (sic) agrees changes are
>> good".  If it were true, no changes would get in.
>
> It is true, where by "changes" I mean "changes from common user's
> point of view", actually, a tiny amount of then do sneak in, so let me
> be precise: "Virtually nobody ever agrees important changes from the
> common user's point of view are good".
>
> So now that I'm being clear, do tell, name one important change in Git
> from the user's point of view that happened in the last two years.

Credential helpers.

>> Also, you don't know that any of those changes would benefit "99% of
>> all users".  It's a guess or an estimate but it's not based on
>> anything concrete.  It might be a good guess--and in this case, I
>> think it is--but it's not a concrete fact.  Don't make it sound like
>> it is.
>
> Sure, it's not a concrete fact, but the actual probability most likely
> follows a beta distribution with alpha=15 and beta=1. Is that more
> precise for you?

It's not about precision, it's that you don't have any actual facts to
stand on but you speak like you do.  Then when someone questions it,
you accuse them of being against fixes for the user.  I wish you'd
stop it and do something more constructive to help move things along.

>>> If you don't agree my comment is accurate, that's one thing, but
>>> labeling it as an attack is another.
>>
>> Don't turn it around.  A number of your patches and emails poke at the
>> community of the Git project and you know it.  It's simply not helping
>> the situation.
>
> Show me a patch that "pokes" at the community. All my patches have
> technical descriptions, and help improve Git.

You're filtering what I said again.  Take a look at the first message
is this thread.

I'll agree the patches themselves have been free of this, but the
cover letters--which I consider to be part of the patch--and ensuing
conversation has not.  If you need another example, look at the cover
letter for your transport helper patches.

None of this is news to you.

[snip]
>>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by
>>> default, and agree that the Git project is indeed welcome to change,
>>> but that's not going to happen.
>>
>> And there it is again.  Predicting the future now?  Objectively and
>> accurately?  Please stop.
>
> Yes I am. Feel free to go back to this mail and tell me I was wrong
> when they do what I said they won't.

I have no need for that, and I'm done talking to you about any of this.

-John

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

n

On Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister <john@szakmeister.net> wrote:
> On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:
> [snip]
>>> There's nothing objective about "Nobody every (sic) agrees changes are
>>> good".  If it were true, no changes would get in.
>>
>> It is true, where by "changes" I mean "changes from common user's
>> point of view", actually, a tiny amount of then do sneak in, so let me
>> be precise: "Virtually nobody ever agrees important changes from the
>> common user's point of view are good".
>>
>> So now that I'm being clear, do tell, name one important change in Git
>> from the user's point of view that happened in the last two years.
>
> Credential helpers.

That's not a change, that's a new feature, and it could hardly be
called important.

By change I mean something that was one way before, and it's a
different way now.

But let me help you; you can't mention one, because there isn't any.

>>> Also, you don't know that any of those changes would benefit "99% of
>>> all users".  It's a guess or an estimate but it's not based on
>>> anything concrete.  It might be a good guess--and in this case, I
>>> think it is--but it's not a concrete fact.  Don't make it sound like
>>> it is.
>>
>> Sure, it's not a concrete fact, but the actual probability most likely
>> follows a beta distribution with alpha=15 and beta=1. Is that more
>> precise for you?
>
> It's not about precision, it's that you don't have any actual facts to
> stand on but you speak like you do.  Then when someone questions it,
> you accuse them of being against fixes for the user.  I wish you'd
> stop it and do something more constructive to help move things along.

I have as many facts as you or anybody does.

If I cannot use the claim that 99% (or any overwhelming number) of
users would benefit, then nobody can make the claim that X amount of
users would be affected negatively, because the actual number can be
close to or equal to 0. But one claim is more likely than the other.

As for doing something more constructive to help move things along,
what you don't get is that there is nothing to do to move things
along. I send the patches, the patches are good, the patches should be
applied. That's what any decently run project would do, concentrate on
the technical side.

Do you think if I hold hands with the people involved and we all sing
Kumbaya things would move along? Well it shouldn't, if the patches are
good the patches are good. What should move things along is the
technical merits of the patch.

>>>> If you don't agree my comment is accurate, that's one thing, but
>>>> labeling it as an attack is another.
>>>
>>> Don't turn it around.  A number of your patches and emails poke at the
>>> community of the Git project and you know it.  It's simply not helping
>>> the situation.
>>
>> Show me a patch that "pokes" at the community. All my patches have
>> technical descriptions, and help improve Git.
>
> You're filtering what I said again.  Take a look at the first message
> is this thread.
>
> I'll agree the patches themselves have been free of this, but the
> cover letters--which I consider to be part of the patch--and ensuing
> conversation has not.  If you need another example, look at the cover
> letter for your transport helper patches.

I don't consider the cover letter part of the patch. And the
conversation is irrelevant, all the users care about is the code.

Not introducing a good feature for users because a developer said a
nasty word (which I haven't) in the cover letter of the patch series
is ridiculous.

>>>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by
>>>> default, and agree that the Git project is indeed welcome to change,
>>>> but that's not going to happen.
>>>
>>> And there it is again.  Predicting the future now?  Objectively and
>>> accurately?  Please stop.
>>
>> Yes I am. Feel free to go back to this mail and tell me I was wrong
>> when they do what I said they won't.
>
> I have no need for that, and I'm done talking to you about any of this.

Doesn't matter, because it's not going to happen.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Matthieu Moy]

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

> But let me help you; you can't mention one, because there isn't any.

Or because you didn't really look. Read the release notes of every Git
release these days, there's a big section about ongoing backward
incompatible changes.

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

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> But let me help you; you can't mention one, because there isn't any.
>
> Or because you didn't really look. Read the release notes of every Git
> release these days, there's a big section about ongoing backward
> incompatible changes.

I said *important* changes from the common user's point of view.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Matthieu Moy]

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

> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> But let me help you; you can't mention one, because there isn't any.
>>
>> Or because you didn't really look. Read the release notes of every Git
>> release these days, there's a big section about ongoing backward
>> incompatible changes.
>
> I said *important* changes from the common user's point of view.

Call me fool, but I do consider the default behavior of "git push" as
something important, indeed.

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

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> But let me help you; you can't mention one, because there isn't any.
>>>
>>> Or because you didn't really look. Read the release notes of every Git
>>> release these days, there's a big section about ongoing backward
>>> incompatible changes.
>>
>> I said *important* changes from the common user's point of view.
>
> Call me fool, but I do consider the default behavior of "git push" as
> something important, indeed.

Last time I checked nothing has changed, the default remains
push.default=matching.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[Matthieu Moy]

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

> Last time I checked nothing has changed, the default remains
> push.default=matching.

LOL.

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

Re: [PATCH v3] build: add default aliases

[Felipe Contreras]

On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Last time I checked nothing has changed, the default remains
>> push.default=matching.
>
> LOL.

I'd take that as an admission that you don't have any examples of
important changes in the past two years, at least.

-- 
Felipe Contreras

Re: [PATCH v3] build: add default aliases

[SZEDER Gábor]

The subject line needs to be updated.

On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
> For now simply add a few common aliases.
> 
>   co = checkout
>   ci = commit
>   rb = rebase
>   st = status
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---

[...]

> diff --git a/alias.c b/alias.c
> index eb9f08b..d6bad69 100644
> --- a/alias.c
> +++ b/alias.c
> @@ -14,11 +14,28 @@ static int alias_lookup_cb(const char *k, const char *v, void *cb)
>  	return 0;
>  }
>  
> +static struct {
> +	const char *key;
> +	const char *val;
> +} default_aliases[] = {
> +	{ "co", "checkout" },
> +	{ "ci", "checkout" },
> +	{ "rb", "rebase" },
> +	{ "st", "status" },
> +};
> +
>  char *alias_lookup(const char *alias)
>  {
> +	int i;
>  	alias_key = alias;
>  	alias_val = NULL;
>  	git_config(alias_lookup_cb, NULL);
> +	if (alias_val)
> +		return alias_val;
> +	for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {
> +		if (!strcmp(alias, default_aliases[i].key))
> +			return xstrdup(default_aliases[i].val);
> +	}
>  	return alias_val;
>  }

Aliases implemented this way don't work the same way as "normal"
aliases do:

  $ # which aliases do I have?
  $ ./bin-wrappers/git config --get-regexp "alias\..*"
  $ # no aliases at all
  $ # does completion work?
  $ ./bin-wrappers/git co ma<TAB>
  mailmap.c      mailmap.h      mailmap.o      match-trees.c  match-trees.o
  $ # no refs completion
  $ # let's see a real alias
  $ git config alias.co checkout
  $ ./bin-wrappers/git config --get-regexp "alias\..*"
  alias.co checkout
  $ ./bin-wrappers/git co ma<TAB>
  maint    master
  $ # as expected


Best,
Gábor

[PATCH v4] build: add default aliases

[Felipe Contreras]

For now simply add a few common aliases.

  co = checkout
  ci = commit
  rb = rebase
  st = status

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-checkout.txt | 5 +++++
 Documentation/git-commit.txt   | 5 +++++
 Documentation/git-rebase.txt   | 5 +++++
 Documentation/git-status.txt   | 5 +++++
 config.c                       | 5 +++++
 5 files changed, 25 insertions(+)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ca118ac..7597813 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -14,6 +14,11 @@ SYNOPSIS
 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
 
+ALIAS
+-----
+
+git co
+
 DESCRIPTION
 -----------
 Updates files in the working tree to match the version in the index
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..8705abc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -15,6 +15,11 @@ SYNOPSIS
 	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
 	   [-i | -o] [-S[<keyid>]] [--] [<file>...]
 
+ALIAS
+-----
+
+git ci
+
 DESCRIPTION
 -----------
 Stores the current contents of the index in a new commit along
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 6b2e1c8..bb18fea 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -14,6 +14,11 @@ SYNOPSIS
 	--root [<branch>]
 'git rebase' --continue | --skip | --abort | --edit-todo
 
+ALIAS
+-----
+
+git rb
+
 DESCRIPTION
 -----------
 If <branch> is specified, 'git rebase' will perform an automatic
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 9046df9..30ecd25 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -11,6 +11,11 @@ SYNOPSIS
 [verse]
 'git status' [<options>...] [--] [<pathspec>...]
 
+ALIAS
+-----
+
+git st
+
 DESCRIPTION
 -----------
 Displays paths that have differences between the index file and the
diff --git a/config.c b/config.c
index e13a7b6..be724b2 100644
--- a/config.c
+++ b/config.c
@@ -1082,6 +1082,11 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)
 
 	home_config_paths(&user_config, &xdg_config, "config");
 
+	ret += fn("alias.ci", "commit", data);
+	ret += fn("alias.co", "checkout", data);
+	ret += fn("alias.rb", "rebase", data);
+	ret += fn("alias.st", "status", data);
+
 	if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, 0)) {
 		ret += git_config_from_file(fn, git_etc_gitconfig(),
 					    data);
-- 
1.8.4-fc