On Wed, May 29, 2013 at 3:00 PM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
>> <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html