Re: [PATCH] (preview) Renaming push.

2005-08-04 Thread Junio C Hamano
Linus Torvalds [EMAIL PROTECTED] writes: Now, for extra bonus points, maybe you should make git-rev-list also understand the rev..rev format (which you can't do with just the get_sha1() interface, since it expands into more). Hmph. That makes sense. What I set out to do when I started

Re: [PATCH] (preview) Renaming push.

2005-08-03 Thread Junio C Hamano
Linus Torvalds [EMAIL PROTECTED] writes: git-send-pack parent $(git-rev-parse HEAD^):master and there's no real reason why that syntax shouldn't just work: it's entirely logical to say I want to push out the parent of my HEAD as 'master' on the other end, and that's _exactly_ what

Re: [PATCH] (preview) Renaming push.

2005-08-03 Thread Junio C Hamano
Well, I pushed it out, although I do agree that we should be able to give anything get_sha()-able on the source side of the push. Probably a revised version should have the following semantics: $ git-send-pack [--all] remote [ref...] - When no ref is specified: - with '--all', it is

Re: [PATCH] (preview) Renaming push.

2005-08-03 Thread Linus Torvalds
On Wed, 3 Aug 2005, Junio C Hamano wrote: While I have not updated the send-pack src:dst syntax, I added a horrible hack that some people may love to see. This removes the need to use git-rev-parse from many commands. Yes, I think this makes sense. We had three different sha1 parsers: