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 th
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
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 arbi
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
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
wh
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 fi
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
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
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 = mergeto
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
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
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
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 "
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 thos
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
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
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
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
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'
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..
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
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'
-- 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
23 matches
Mail list logo
