2010/9/8 Santi Béjar <santi@xxxxxxxxxxx>:
> 2010/9/8 Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>:
>> This allows users to add new @{..} alias via ref-at.* config
>> variables. The rewrite rule is printf-alike.
>>
>> My itch is I usually work on a topic and only want to see commits in
>> that topic. So I make a tag to the topic's base, then do
>>
>> git log base/my-topic..
>>
>> That is a lot of keystrokes, and my mind is small enough sometimes I
>> don't even remember the topic name, stucking at "base/ what?"
>>
>> Now I have "ref-at.base = base/%(tip)" in my gitconfig and I only need
>> to do "git log @{base}..".
>
> I like the idea, but I would like something more generic, a ref
> transformation or expression (ref-exp?). Currently you can't say
> %(tip)@{1}, neither %(tip)^, nor origin/master..origin/%(tip).
The idea is to nail down what kind of expression that should be used.
Then implement it. My first thought was to use a hook, but I thought
it was overkill for ref transformation.
Something like bash variable substitution is probably enough.
> Another issue is that it can shadow builtin @{}s, like @{upstream}.
Yes. I think @{upstream} can be put in to ref-transformation list at
startup. That way it always gets precedence.
> Why %(tip) and not %(branchname), in line with other %() modifiers.
Oh.. I picked whatever name I had in my mind. @(branchname) of @(branch)
sounds good.
> In particular I have a use case for this @{name}. I would like something like:
>
> ref-exp.last = %(tip)@{1}..%(tip)@{0}
Yeah I was tempted too after writing the patch. It's a revision range,
not a reference anymore. But from user perspective it's pretty much
the same. And transformation rule would be the same. Hmm.. tempting.
--
Duy
--
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