Linus Torvalds <[EMAIL PROTECTED]> writes:

>  - I actually prefer code and documentation to be separated. ...
>    first the actual change, then the docs updates.


>  - I'd much rather have a generic "address rewriting layer" than a "-b" 
>    flag.
>    I don't mind the shorthand at all, but I don't think it should be that
>    special. It's not "worthy" of a flag - if you have a shorthand that 
>    says "linus == rsync://", then I think it 
>    should just work, and 
>       git pull linus
>    should end up not needing a "-b" flag. It's not like there is any 
>    real ambiguity.

That makes sense.  Naturally,

        git pull linus experimental
        git pull linus tag v2.6.13

should expand to:

       git pull rsync:// experimental
       git pull rsync:// tag v2.6.13

If a user is usually interested in e100 driver work, we should

        echo rsync://

and "git pull jgarzik-e100" should expand to:

        git pull rsync:// e100

If the user says:

        git fetch jgarzik-e100 ieee80211-wifi

because the user wanted to peek his other branch just once, but
did not want to bother creating another remote reference
("jgarzik-wifi", perhaps) for this one-time use.  This should
expand to:

        git fetch rsync:// ieee80211-wifi

> And it's not necessarily just the branch handling, but more of a generic
> shorthand: I'd love to be able to mix something like
>       git pull jgarzik/misc-2.6 upstream
> and "jgarzik" would be expanded (through something like .git/branches) to 
> ""), resulting in the 
> _full_ path being expanded to
> upstream

Nice, and sounds doable without too much ambiguities.  This last
one, however, needs to be coordinated with Pasky, if we want to
use .git/branches/$name convention.  I think Cogito would barf
with your partial URL that ends with "...git/jgarzik/".

I'll code something up.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to