Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Thu, May 30, 2013 at 3:07 AM, Junio C Hamano 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Ramkumar Ramachandra 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: >> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote: >>> Felipe Contreras wrote: On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Felipe Contreras wrote: > On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote: >> Felipe Contreras wrote: >>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: >> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Felipe Contreras wrote: > On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Wed, May 29, 2013 at 3:27 PM, Ramkumar Ramachandra 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 <> ~/.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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Wed, May 29, 2013 at 3:00 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Ramkumar Ramachandra 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Felipe Contreras writes: > On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra > 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
Felipe Contreras wrote:
> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Wed, May 29, 2013 at 1:11 PM, Bráulio Bhavamitra wrote:
> -- Forwarded message --
> From: Bráulio Bhavamitra
> 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-us...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git
Bráulio Bhavamitra 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git
-- Forwarded message -- From: Bráulio Bhavamitra 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-us...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
