Re: Highlevel (but simple to implement) commands provided by default for git

Re: Highlevel (but simple to implement) commands provided by default for git

[Bráulio Bhavamitra]

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

On Wed, May 29, 2013 at 8:23 AM, Bráulio Bhavamitra <brauliobo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:

> Hello all,
>
> One of the things I note about git is that is provides mostly low-level
> and strictly necessary commands.
> Many highlevel commands are then implemented as alias by users, after a
> deep search on the internet.
>
> Adding highlevel commands, even though it could be implemented by a simple
> alias, would put git in another level
> of user experience and create a new standard for newbie users.
> What git developers think about this?
>
> I have, as many other users, an enormous .gitconfig. I paste here some
> highlevel commands of it, according to my judgement.
> Mercurial provides many of these highlevel commands.
>
>   root = rev-parse --show-toplevel
>
>  upstream = !git for-each-ref --format='%(upstream:short)' $(git symbolic-ref -q HEAD)
>  upstream-remote = !git upstream | sed -e 's/\\/.*$//g'
>
>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD
>  in = pull --dry-run
>
>
>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>  untracked = ls-files --other --exclude-standard
>  staged = ls-files --staged
>  modified = ls-files --modified
>  deleted = ls-files --deleted
>
>
>   head = !git l -1
>   current = rev-parse --abbrev-ref HEAD
>
> Source:
> https://github.com/brauliobo/gitconfig/blob/master/configs/.gitconfig
>
> regards,
> bráulio
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.



[-- Attachment #2: Type: text/html, Size: 6933 bytes --]

Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Bráulio Bhavamitra]

---------- Forwarded message ----------
From: Bráulio Bhavamitra <brauliobo@gmail.com>
Date: Wed, May 29, 2013 at 8:23 AM
Subject: [git-users] Highlevel (but simple to implement) commands
provided by default for git
To: git-users@googlegroups.com


Hello all,

One of the things I note about git is that is provides mostly
low-level and strictly necessary commands.
Many highlevel commands are then implemented as alias by users, after
a deep search on the internet.

Adding highlevel commands, even though it could be implemented by a
simple alias, would put git in another level
of user experience and create a new standard for newbie users.
What git developers think about this?

I have, as many other users, an enormous .gitconfig. I paste here some
highlevel commands of it, according to my judgement.
Mercurial provides many of these highlevel commands.

  root = rev-parse --show-toplevel

 upstream = !git for-each-ref --format='%(upstream:short)' $(git
symbolic-ref -q HEAD)
 upstream-remote = !git upstream | sed -e 's/\\/.*$//g'

 out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD
 in = pull --dry-run


 unmerged = !git ls-files --unmerged | cut -f2 | uniq
 untracked = ls-files --other --exclude-standard
 staged = ls-files --staged
 modified = ls-files --modified
 deleted = ls-files --deleted


  head = !git l -1
 current = rev-parse --abbrev-ref HEAD

Source: https://github.com/brauliobo/gitconfig/blob/master/configs/.gitconfig

regards,
bráulio

--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to git-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Bráulio Bhavamitra wrote:
>   root = rev-parse --show-toplevel

What is your usecase for this?

>  upstream = !git for-each-ref --format='%(upstream:short)' $(git
> symbolic-ref -q HEAD)

Again, what is the usecase?  What doesn't @{u} do?

>  upstream-remote = !git upstream | sed -e 's/\\/.*$//g'

Windows back-slashes?

>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD

I didn't understand this at all.  What are you doing?

>  in = pull --dry-run

Why?

>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>  untracked = ls-files --other --exclude-standard
>  staged = ls-files --staged
>  modified = ls-files --modified
>  deleted = ls-files --deleted

What is wrong with git status showing a unified output?

>   head = !git l -1

What is git l again?

>  current = rev-parse --abbrev-ref HEAD

Why don't you use a prompt?  Use the one in contrib/completion/git-prompt.sh.

Re: Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Junio C Hamano]

Bráulio Bhavamitra <brauliobo@gmail.com> writes:

>   root = rev-parse --show-toplevel

Hmm, part of my "cdup" shell function looks something like

     cdup () {
	... error detection etc...
	d=$(git rev-parse --show-toplevel)
        cd "$d"
    }

so I can quickly go up to the top-level.  With "root", I could
replace that rev-parse call with "git root", but I'd keep typing

	$ cdup

after doing so anyway.  I am not sure how much value it adds.

You would need to handle error cases like "you are not in a working
tree", you cannot expect to be able to say

	$ cd "$(git root)"

anyway.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Wed, May 29, 2013 at 1:11 PM, Bráulio Bhavamitra <brauliobo@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Bráulio Bhavamitra <brauliobo@gmail.com>
> Date: Wed, May 29, 2013 at 8:23 AM
> Subject: [git-users] Highlevel (but simple to implement) commands
> provided by default for git
> To: git-users@googlegroups.com

> One of the things I note about git is that is provides mostly
> low-level and strictly necessary commands.
> Many highlevel commands are then implemented as alias by users, after
> a deep search on the internet.
>
> Adding highlevel commands, even though it could be implemented by a
> simple alias, would put git in another level
> of user experience and create a new standard for newbie users.
> What git developers think about this?

Completely agree.

>   root = rev-parse --show-toplevel
>
>  upstream = !git for-each-ref --format='%(upstream:short)' $(git
> symbolic-ref -q HEAD)

git rev-parse --abbrev-ref @{u}

>  upstream-remote = !git upstream | sed -e 's/\\/.*$//g'

git config branch.$(git rev-parse --abbrev-ref HEAD).remote

>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD

'git fetch' without arguments is the same as git fetch `git upstream-remote`

Junio: See? It's not the expected behavior for most of our user-base.

'git log @{u}..HEAD' does the same as 'git log `git upstream`..HEAD'

>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>  untracked = ls-files --other --exclude-standard
>  staged = ls-files --staged
>  modified = ls-files --modified
>  deleted = ls-files --deleted

I think we should have a user-friendly 'git ls' command.

>   head = !git l -1

Or 'git show --quiet'.

>  current = rev-parse --abbrev-ref HEAD

We should probably also add typical shortucts:

d = diff
l = log
f = fetch
p = push
r = reset
ci = commit
rb = rebase
co = checkout
st = status
pi = cherry-pick
mt = mergetool

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Bráulio Bhavamitra wrote:
>>   root = rev-parse --show-toplevel
>
> What is your usecase for this?

Some Git commands expect to be in the top level directory (e.g. git blame).

>>  upstream-remote = !git upstream | sed -e 's/\\/.*$//g'
>
> Windows back-slashes?

Maybe git config quoting.

>>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD
>
> I didn't understand this at all.  What are you doing?

Finding out what changes haven't been pushed out yet?

>>  in = pull --dry-run
>
> Why?

Because it's very easy to mess things up with 'git pull'. This
probably wouldn't be needed if we change the default of 'git pull' to
barf when the changes are not a fast-forward, and print a message
suggesting to either merge or rebase, as it has been suggested.

>>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>>  untracked = ls-files --other --exclude-standard
>>  staged = ls-files --staged
>>  modified = ls-files --modified
>>  deleted = ls-files --deleted
>
> What is wrong with git status showing a unified output?

It's not easy to be used in "scripts", say, 'gvim -p $(git unmerged)'.

>>   head = !git l -1
>
> What is git l again?

'git log', of course.

>>  current = rev-parse --abbrev-ref HEAD
>
> Why don't you use a prompt?  Use the one in contrib/completion/git-prompt.sh.

While this is probably a good idea, not everybody has a prompt
configured. Imagine ssh'ing to a machine you haven't touched before,
or shouldn't configure. Sure, right now you need to configure it
anyway, but the whole proposal is to make these default aliases.

In Mercurial 'hg branch' shows only the current branch, and I think
that's more appropriate.

Before I configured my prompt, 'git branch' was by far the command I
used the most.

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> Bráulio Bhavamitra wrote:
>>>   root = rev-parse --show-toplevel
>>
>> What is your usecase for this?
>
> Some Git commands expect to be in the top level directory (e.g. git blame).

Um, git blame revert.c when in builtin/ works for me: what am I missing?

>>>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD
>>
>> I didn't understand this at all.  What are you doing?
>
> Finding out what changes haven't been pushed out yet?

... but why would I want to club a slow network operation with
something like log?  Yeah, I use git log @{u}.. all the time.

>>>  in = pull --dry-run
>>
>> Why?
>
> Because it's very easy to mess things up with 'git pull'. This
> probably wouldn't be needed if we change the default of 'git pull' to
> barf when the changes are not a fast-forward, and print a message
> suggesting to either merge or rebase, as it has been suggested.

Yeah, I saw that thread and I think shipping "sane" defaults is a lost
cause.  I really want to make pull more useable, but by making it more
configurable.

>>>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>>>  untracked = ls-files --other --exclude-standard
>>>  staged = ls-files --staged
>>>  modified = ls-files --modified
>>>  deleted = ls-files --deleted
>>
>> What is wrong with git status showing a unified output?
>
> It's not easy to be used in "scripts", say, 'gvim -p $(git unmerged)'.

RIght, but we shouldn't ship anything "pretty" for scripts, otherwise
it'll become hard to understand them.

>>>   head = !git l -1
>>
>> What is git l again?
>
> 'git log', of course.

I use 'git show' all the time.

>>>  current = rev-parse --abbrev-ref HEAD
>>
>> Why don't you use a prompt?  Use the one in contrib/completion/git-prompt.sh.
>
> While this is probably a good idea, not everybody has a prompt
> configured. Imagine ssh'ing to a machine you haven't touched before,
> or shouldn't configure. Sure, right now you need to configure it
> anyway, but the whole proposal is to make these default aliases.

Like I said earlier, I'm really not interested in sane defaults: I
don't think all of us can agree on one thing.

> In Mercurial 'hg branch' shows only the current branch, and I think
> that's more appropriate.
>
> Before I configured my prompt, 'git branch' was by far the command I
> used the most.

Yeah, we're fixing 'git branch' (by making it more configurable): the
topic is in progress.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Junio C Hamano]

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

> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> Bráulio Bhavamitra wrote:
>>>   root = rev-parse --show-toplevel
>>
>> What is your usecase for this?
>
> Some Git commands expect to be in the top level directory (e.g. git blame).

"Git" things we can fix [*1*], but more importantly, build structure
of many project may require you to go up to the top to build the
whole thing, so being able to get a relative path to the top when
you are deep inside is a necessity.


[Footnote]

*1* "blame" is an oddball (and I suspect the recent log -Ln,m:path
    may share the same) in that it really wants a concret path, not
    a pathspec, so you cannot even say

	cd Documentation; git blame :/Makefile

    I think the right fix is to teach it that the argument it has
    been taking as a pathname is actually a pathspec, match the
    pathspec with appropriate place (either in the working tree, or
    in the commit we start digging from), and use the path that the
    pathspec matches to a single one (otherwise barf).

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Junio C Hamano wrote:
>> Some Git commands expect to be in the top level directory (e.g. git blame).
>
> "Git" things we can fix [*1*], but more importantly, build structure
> of many project may require you to go up to the top to build the
> whole thing, so being able to get a relative path to the top when
> you are deep inside is a necessity.

How is the project built?  When I type `make` inside Documentation/, I
want documentation to be built.  When I want a toplevel-build, I use a
custom git-make function (which does a cd before calling make).

> [Footnote]
>
> *1* "blame" is an oddball (and I suspect the recent log -Ln,m:path
>     may share the same) in that it really wants a concret path, not
>     a pathspec, so you cannot even say
>
>         cd Documentation; git blame :/Makefile

*scratches head*

  cd Documentation; git blame ../Makefile

Isn't this how pathspecs are specified everywhere?

  cd Documentation; git log ../Makefile
  cd Documentation; git log -L0,10:../Makefile

What is the difference between "concrete path" and "pathspec"?

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> We should probably also add typical shortucts:
>
> d = diff
> l = log
> f = fetch
> p = push
> r = reset
> ci = commit
> rb = rebase
> co = checkout
> st = status
> pi = cherry-pick
> mt = mergetool

Terrible idea.  We'll be eating up more subcommands that the user
cannot override.  I'm already unhappy with am not having been called
apply-mailbox, because I want am to mean am -3 -c (too lazy to write
those configuration variables).

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>>         cd Documentation; git blame :/Makefile
>
> *scratches head*

You lean new things every day ;-).

>   cd Documentation; git blame ../Makefile
>
> Isn't this how pathspecs are specified everywhere?

The whole point of show-cdup is that people (especially those in
java land) bury themselves in a hierarchy so deep that it is not
feasible to tell "Go count the hierarchy and prefix that many ../
yourself" to them.

The answer to "we cannot count ../" issue is ":(top)" aka ":/" magic
pathspec modifier.

"git blame" takes a single pathname, not "a set of patterns to match
against to select concrete paths", which is what a pathspec is.  

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> The whole point of show-cdup is that people (especially those in
> java land) bury themselves in a hierarchy so deep that it is not
> feasible to tell "Go count the hierarchy and prefix that many ../
> yourself" to them.

Ah.

> The answer to "we cannot count ../" issue is ":(top)" aka ":/" magic
> pathspec modifier.

I thought :/ was a revspec, which is why I was scratching my head so
hard.  Did we introduce this ambiguity intentionally?

This errors out:

  git log :/Makefile

So, I have to do either of these:

  git log :/Makefile --
  git log -- :/Makefile

depending on what I want.

> "git blame" takes a single pathname, not "a set of patterns to match
> against to select concrete paths", which is what a pathspec is.

So the problem is that I can't do:

  git blame -- :/Makefile

So blame has to be converted to use pathspec semantics, and should
error out when the pathspec doesn't match the concrete path of a file.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Bráulio Bhavamitra wrote:
> Agree, these aliased should work as a fallback or as an automatic short
> version

Making builtins override'able is also a terrible idea.  It opens doors
to potential bugs we don't want to deal with.  Simple example:

   am = log -1
   log = am -3

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Jonathan Nieder]

Ramkumar Ramachandra wrote:
> Bráulio Bhavamitra wrote:

>> Agree, these aliased should work as a fallback or as an automatic short
>> version
>
> Making builtins override'able is also a terrible idea.  It opens doors
> to potential bugs we don't want to deal with.  Simple example:
>
>    am = log -1
>    log = am -3

That's detectable and could be made to error out, so it's not too bad.

A bigger problem (in my opinion) with allowing arbitrary changes to
the meaning of existing commands is that scripts, whether placed in
.sh files or given as commands to run over IRC, stop working
altogether.  It's nice to have commands like "git log" and "git am"
mean the same thing no matter what machine I am on.

Hope that helps,
Jonathan

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Wed, May 29, 2013 at 3:00 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>>> Bráulio Bhavamitra wrote:
>>>>   root = rev-parse --show-toplevel
>>>
>>> What is your usecase for this?
>>
>> Some Git commands expect to be in the top level directory (e.g. git blame).
>
> Um, git blame revert.c when in builtin/ works for me: what am I missing?

I meant 'git bisect', but 'git blame' has a similar issue if it's
receiving it's arguments from other git commands.

>>>>  out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD
>>>
>>> I didn't understand this at all.  What are you doing?
>>
>> Finding out what changes haven't been pushed out yet?
>
> ... but why would I want to club a slow network operation with
> something like log?  Yeah, I use git log @{u}.. all the time.

Then we would be out-of-date all the time.

>>>>  in = pull --dry-run
>>>
>>> Why?
>>
>> Because it's very easy to mess things up with 'git pull'. This
>> probably wouldn't be needed if we change the default of 'git pull' to
>> barf when the changes are not a fast-forward, and print a message
>> suggesting to either merge or rebase, as it has been suggested.
>
> Yeah, I saw that thread and I think shipping "sane" defaults is a lost
> cause.  I really want to make pull more useable, but by making it more
> configurable.

Sane defaults still make sense, and still will happen, sooner or later.

In the meantime 'pull --dry-run' makes sense.

>>>>  unmerged = !git ls-files --unmerged | cut -f2 | uniq
>>>>  untracked = ls-files --other --exclude-standard
>>>>  staged = ls-files --staged
>>>>  modified = ls-files --modified
>>>>  deleted = ls-files --deleted
>>>
>>> What is wrong with git status showing a unified output?
>>
>> It's not easy to be used in "scripts", say, 'gvim -p $(git unmerged)'.
>
> RIght, but we shouldn't ship anything "pretty" for scripts, otherwise
> it'll become hard to understand them.

Not at all. The user is specifically asking for unmerged files, a
straight-forward list is easier to understand that a list with a bunch
of other stuff the user is not interested in, where the user has to
manually browse with his eyes until he finds the section he is
interested in.

Your argument is akin to saying that 'ls foo' doesn't make sense,
because the user can see 'foo' when he does 'ls'. That defeats the
whole notion of letting the user query what he is looking for.

>>>>   head = !git l -1
>>>
>>> What is git l again?
>>
>> 'git log', of course.
>
> I use 'git show' all the time.

Even more characters to type.

>>>>  current = rev-parse --abbrev-ref HEAD
>>>
>>> Why don't you use a prompt?  Use the one in contrib/completion/git-prompt.sh.
>>
>> While this is probably a good idea, not everybody has a prompt
>> configured. Imagine ssh'ing to a machine you haven't touched before,
>> or shouldn't configure. Sure, right now you need to configure it
>> anyway, but the whole proposal is to make these default aliases.
>
> Like I said earlier, I'm really not interested in sane defaults: I
> don't think all of us can agree on one thing.

This is not a matter of "us" (developers) agreeing, it's a matter of
the vast majority of *users* suffering.

If you are not interested in them, then don't distract us that do.

>> In Mercurial 'hg branch' shows only the current branch, and I think
>> that's more appropriate.
>>
>> Before I configured my prompt, 'git branch' was by far the command I
>> used the most.
>
> Yeah, we're fixing 'git branch' (by making it more configurable): the
> topic is in progress.

This is about the default. 'git branch' doesn't do what it should *by
default*, so 'git current' makes sense in the meantime.

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Wed, May 29, 2013 at 3:27 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> We should probably also add typical shortucts:
>>
>> d = diff
>> l = log
>> f = fetch
>> p = push
>> r = reset
>> ci = commit
>> rb = rebase
>> co = checkout
>> st = status
>> pi = cherry-pick
>> mt = mergetool
>
> Terrible idea.

A "terrible idea" that somehow each and every other SCM tool in the planet does.

I don't see Mercurial users demanding that they take their useful
shortcuts away, I see the opposite; they demand useful shortcuts for
Git.

I say it's a terrible idea **not** to do that.

> We'll be eating up more subcommands that the user
> cannot override.

We won't. We can easily implement these as special aliases that the
moment the user specifies something else.

But actually, we don't have to do anything because the current
implementation already does that.

If the user has 'alias.ci=commit -v', and then we specify a default
'alias.ci=commit', the user's configuration takes precedence.

> I'm already unhappy with am not having been called
> apply-mailbox, because I want am to mean am -3 -c (too lazy to write
> those configuration variables).

cat > ~/bin/git-am <<EOF
#!/bin/sh
git am -3 -c "$@"
EOF
chmod +x ~/bin/git-am
echo export GIT_EXEC_PATH=$HOME/bin:$(git --exec-path) >> ~/.profile

Done.

And I don't see what that has to do with default *aliases* the user
can override. This is a red herring.

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ramkumar Ramachandra wrote:
>> Bráulio Bhavamitra wrote:
>
>>> Agree, these aliased should work as a fallback or as an automatic short
>>> version
>>
>> Making builtins override'able is also a terrible idea.  It opens doors
>> to potential bugs we don't want to deal with.  Simple example:
>>
>>    am = log -1
>>    log = am -3
>
> That's detectable and could be made to error out, so it's not too bad.
>
> A bigger problem (in my opinion) with allowing arbitrary changes to
> the meaning of existing commands is that scripts, whether placed in
> .sh files or given as commands to run over IRC, stop working
> altogether.  It's nice to have commands like "git log" and "git am"
> mean the same thing no matter what machine I am on.

Except that's not true:

% git config --global format.pretty oneline

Either way, this is a red herring, I don't see anybody pushing for
overriding builtins.

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Jonathan Nieder]

Felipe Contreras wrote:
> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Ramkumar Ramachandra wrote:

>>> Making builtins override'able is also a terrible idea.  It opens doors
>>> to potential bugs we don't want to deal with.  Simple example:
>>>
>>>    am = log -1
>>>    log = am -3
>>
>> That's detectable and could be made to error out, so it's not too bad.
>>
>> A bigger problem (in my opinion) with allowing arbitrary changes to
>> the meaning of existing commands is that scripts, whether placed in
>> .sh files or given as commands to run over IRC, stop working
>> altogether.  It's nice to have commands like "git log" and "git am"
>> mean the same thing no matter what machine I am on.
>
> Except that's not true:

It's not true that my opinion is that a bigger problem than the
non-problem Ram mentioned with allowing arbitrary changes to the
meaning of existing commands is that scripts stop working reliably?

This combative style of communication is toxic.  It kills the chance
of a calm, pleasant discussion, even with patient people who don't
even fundamentally disagree.  Please stop it.

Perhaps you meant "Commands like 'git log' and 'git am' actually don't
mean the same thing on all machines.  The default format of 'git log'
is configurable.  But that is neither here nor there", which would
have been a pleasant (if irrelevant) response instead of an obnoxious
one.

Regards,
Jonathan

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>>> A bigger problem (in my opinion) with allowing arbitrary changes to
>>> the meaning of existing commands is that scripts, whether placed in
>>> .sh files or given as commands to run over IRC, stop working
>>> altogether.  It's nice to have commands like "git log" and "git am"
>>> mean the same thing no matter what machine I am on.
>>
>> Except that's not true:
>
> It's not true that my opinion is that a bigger problem than the
> non-problem Ram mentioned with allowing arbitrary changes to the
> meaning of existing commands is that scripts stop working reliably?

It's not true what you said:

commands like "git log" and "git am" mean the same thing no matter
what machine I am on.

> This combative style of communication is toxic.  It kills the chance
> of a calm, pleasant discussion, even with patient people who don't
> even fundamentally disagree.  Please stop it.

Stop assuming bad faith[1].

[1] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> That's detectable and could be made to error out, so it's not too bad.

Sure it's possible, but I'm arguing about whether it's worth the
effort.  There can be loops like a -> b -> c -> d -> e -> a.  Given
that nobody has even bothered to get git to print an error message
when a builtin command is overridden, do you think anyone will be
interested in this?

> A bigger problem (in my opinion) with allowing arbitrary changes to
> the meaning of existing commands is that scripts, whether placed in
> .sh files or given as commands to run over IRC, stop working
> altogether.  It's nice to have commands like "git log" and "git am"
> mean the same thing no matter what machine I am on.

Yeah, I agree with this to a large extent.  It's nice to have a
minimal set of unambiguous commands for the purposes of communicating,
and I'm quite happy with the present state of things.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Jonathan Nieder]

Felipe Contreras wrote:
> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Felipe Contreras wrote:
>>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>>>> A bigger problem (in my opinion) with allowing arbitrary changes to
>>>> the meaning of existing commands is that scripts, whether placed in
>>>> .sh files or given as commands to run over IRC, stop working
>>>> altogether.  It's nice to have commands like "git log" and "git am"
>>>> mean the same thing no matter what machine I am on.
>>>
>>> Except that's not true:
>>
>> It's not true that my opinion is that a bigger problem than the
>> non-problem Ram mentioned with allowing arbitrary changes to the
>> meaning of existing commands is that scripts stop working reliably?
>
> It's not true what you said:
>
> commands like "git log" and "git am" mean the same thing no matter
> what machine I am on.

It's not true that it's nice when they do?

>> This combative style of communication is toxic.  It kills the chance
>> of a calm, pleasant discussion, even with patient people who don't
>> even fundamentally disagree.  Please stop it.
>
> Stop assuming bad faith[1].

Perhaps you mean "I'm trying, but I'm human  --- please bear with me
while I work on improving.  Know that my intentions are good."

Unfortunately, good intentions are not enough.  Communicating in a way
that clearly conveys what you mean instead of something else that
derails the conversation is a real skill and, as I said, it's an
important one that is basic to being able to have a productive
conversation.  If you are working on it and are not there yet, my best
advice would be to lurk more and speak less, to learn from the example
of others, and to start by working on how to receive criticism and to
clear up misunderstandings, which can at least mitigate the damage
when things go wrong.

You have accused others of assuming bad faith in the past, which only
escalates things.  It's not a good way to move forward.  It's possible
that the best way to move forward involves some way (e.g., mail client
configuration that holds messages in "drafts" for a little while
before sending them out) of being able to cool down when discussions
get hot.

Sincerely,
Jonathan

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Felipe Contreras]

On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Felipe Contreras wrote:
>>>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>>>> A bigger problem (in my opinion) with allowing arbitrary changes to
>>>>> the meaning of existing commands is that scripts, whether placed in
>>>>> .sh files or given as commands to run over IRC, stop working
>>>>> altogether.  It's nice to have commands like "git log" and "git am"
>>>>> mean the same thing no matter what machine I am on.
>>>>
>>>> Except that's not true:
>>>
>>> It's not true that my opinion is that a bigger problem than the
>>> non-problem Ram mentioned with allowing arbitrary changes to the
>>> meaning of existing commands is that scripts stop working reliably?
>>
>> It's not true what you said:
>>
>> commands like "git log" and "git am" mean the same thing no matter
>> what machine I am on.
>
> It's not true that it's nice when they do?

Yeah, it's nice that the sun is purple. Never-mind the fact that it's not true.

The consistency you experience across machines has absolutely nothing
to do with Git, since Git can be configured in a way you don't
consider nice.

So this argument is invalid. Any proposed change to make Git more
configurable is not affected by this argument, because Git can
*already* be configured in a way that would break your experience, yet
it doesn't happen.

In other words; it's the policy or your machine users you have to
thank for, not Git's code, and changing Git's code is not going to
change that policy.

Either way this is a straw man, again, nobody is pushing to allow
builtins to be overridable.

The topic is default *aliases*.

-- 
Felipe Contreras

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> So the problem is that I can't do:
>
>   git blame -- :/Makefile
>
> So blame has to be converted to use pathspec semantics, and should
> error out when the pathspec doesn't match the concrete path of a file.

Correct, that is what I wrote in two messages ago in the footnote
you were responding to.

Re: [git-users] Highlevel (but simple to implement) commands provided by default for git

[Duy Nguyen]

On Thu, May 30, 2013 at 3:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> *1* "blame" is an oddball (and I suspect the recent log -Ln,m:path
>     may share the same) in that it really wants a concret path, not
>     a pathspec, so you cannot even say
>
>         cd Documentation; git blame :/Makefile
>
>     I think the right fix is to teach it that the argument it has
>     been taking as a pathname is actually a pathspec, match the
>     pathspec with appropriate place (either in the working tree, or
>     in the commit we start digging from), and use the path that the
>     pathspec matches to a single one (otherwise barf).

You should have CCed me when it's about pathspec :) At least we can
safely turn on :/ trick for git-blame and reject other features (like
globbing) that blame can't handle. I'll look into how easy/hard to
make git-blame support pathspec.
--
Duy