Re: [PATCH] (preview) Renaming push.
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 ripping extended_sha1 out of rev-parse was actually something else. Remember I was stupidly wondering why "git log master..gitk" did not do what I wanted to? The reason I started looking at git-rev-parse was because I wanted to add "git log master...gitk" (three dots) which is equivalent to "git log $(git-merge-base master gitk)..gitk". That was what I wanted to have when I asked that stupid question. But unfortunately my GIT day this week is over, so the rest is for the weekend. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (preview) Renaming push.
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > While I have not updated the send-pack : 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: get_sha1(), get_sha1_hex(), and get_extended_sha1(). None of the users of get_sha1() really have any reason to want the limited form, so I think your patch does the right thing. 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). Of course, most people don't tend to use git-rev-list directly, so maybe that's not a biggie, and so git-rev-parse is fine. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (preview) Renaming push.
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In this format, "src" makes sense as a generic sha1_name, and _not_
> necessarily limited to a ref-name.
>
> IOW, there's really no reason to not allow
>
> git-send-pack .. dest .. :dst-ref
>
> where "" may be something else than a ref (but a ref obviously ends
> up being one such thing).
>
> For example, let's say that I've got stuff at the HEAD of my tree that I'm
> not quite ready to push out yet, but I _do_ want to push out the parent of
> the current head. I'd love to be able to just do
>
> 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 the above says.
While I have not updated the send-pack : 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.
This is a preview. I've run the standard test suite and it does
not seem to break anything, but I expect it will stay in "pu"
for a while.
[PATCH] Update get_sha1() to grok extended format.
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Makefile|3 +
rev-parse.c | 188 +-
sha1_file.c | 39 --
sha1_name.c | 222 +++
4 files changed, 229 insertions(+), 223 deletions(-)
create mode 100644 sha1_name.c
99ef7de3e234347d2af1ab2129ce99c5876b591b
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -95,7 +95,8 @@ LIB_H=cache.h object.h blob.h tree.h com
pack.h pkt-line.h refs.h
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
-refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
+refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o \
+sha1_name.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -21,8 +21,6 @@ static int output_sq = 0;
#define REVERSED 1
static int show_type = NORMAL;
-static int get_extended_sha1(char *name, unsigned char *sha1);
-
/*
* Some arguments are relevant "revision" arguments,
* others are about output format or other details.
@@ -107,182 +105,6 @@ static void show_arg(char *arg)
show_norev(arg);
}
-static int get_parent(char *name, unsigned char *result, int idx)
-{
- unsigned char sha1[20];
- int ret = get_extended_sha1(name, sha1);
- struct commit *commit;
- struct commit_list *p;
-
- if (ret)
- return ret;
- commit = lookup_commit_reference(sha1);
- if (!commit)
- return -1;
- if (parse_commit(commit))
- return -1;
- if (!idx) {
- memcpy(result, commit->object.sha1, 20);
- return 0;
- }
- p = commit->parents;
- while (p) {
- if (!--idx) {
- memcpy(result, p->item->object.sha1, 20);
- return 0;
- }
- p = p->next;
- }
- return -1;
-}
-
-static int find_short_object_filename(int len, const char *name, unsigned char
*sha1)
-{
- static char dirname[PATH_MAX];
- char hex[40];
- DIR *dir;
- int found;
-
- snprintf(dirname, sizeof(dirname), "%s/%.2s", get_object_directory(),
name);
- dir = opendir(dirname);
- sprintf(hex, "%.2s", name);
- found = 0;
- if (dir) {
- struct dirent *de;
- while ((de = readdir(dir)) != NULL) {
- if (strlen(de->d_name) != 38)
- continue;
- if (memcmp(de->d_name, name + 2, len-2))
- continue;
- memcpy(hex + 2, de->d_name, 38);
- if (++found > 1)
- break;
- }
- closedir(dir);
- }
- if (found == 1)
- return get_sha1_hex(hex, sha1) == 0;
- return 0;
-}
-
-static int match_sha(unsigned len, const unsigned char *a, const unsigned char
*b)
-{
- do {
- if (*a != *b)
- return 0;
- a++;
- b++;
- len -= 2;
- } while (len > 1);
- if (len)
- if ((*a ^ *b) & 0xf0)
- return 0;
- return 1;
-}
-
-static int find_short_packed_object(int len, const unsigned char *match,
unsigned char *sha1)
-{
- s
Re: [PATCH] (preview) Renaming push.
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] [...] - When no is specified: - with '--all', it is the same as specifying the full refs/* path for all local refs; - without '--all', it is the same as specifying the full refs/* path for refs that exist on both ends; - When one or more s are specified: - a single token (i.e. no colon) must be a pattern that tail-matches refs/* path for an existing local ref. It is an error for the pattern to match no local ref, or more than one local refs. The matching ref is pushed to the remote end under the same name. - : can have different cases. is first tried as the tail-matching pattern for refs/* path. - If more than one matches are found, it is an error. - If one match is found, must either match no remote ref and start with "refs/", or match exactly one remote ref. That remote ref is updated with the sha1 value obtained by the sha1. - If no match is found, it is given to get_extended_sha1(); it is an error if get_extended_sha1() does not find an object name. If it succeeds, must either match no remote ref and start with "refs/" or match exactly one remote ref. That remote ref is updated with the sha1 value. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (preview) Renaming push.
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > > git-send-pack parent $(git-rev-parse HEAD^):master > > When I do something like your example, I create a temporary > lightweight tag and push it. Snapshots in JIT are just a bunch > of lightweight tags so.. I like the scripting, and combining pipelines of commands kind of thing. I agree that you can just make a temporary tag, but it's a bit like in any scripting stuff - you could use a temp-file, but it's just cleaner if you can keep temporary values in local variables (or in a local cmd pipeline like the above). Whenever you script somethign that creates a new tag or ref, you suddenly have cleanup and uniqueness issues etc. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (preview) Renaming push.
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 the above says. Yes I think allowing get_sha()-able thing on the left hand side makes things, well, interesting. I need to think about it a bit. When I do something like your example, I create a temporary lightweight tag and push it. Snapshots in JIT are just a bunch of lightweight tags so.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (preview) Renaming push.
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > This allows git-send-pack to push local refs to a destination > repository under different names. Looks good, except I was almost hoping for one modification: > Here is the name mapping rules for refs. > > * If there is no ref mapping on the command line: > > - if '--all' is specified, it is equivalent to specifying > ":" for all the existing local refs on the >command line > - otherwise, it is equivalent to specifying ":" for >all the refs that exist on both sides. > > * is just a shorthand for ":" > > * ":" > > push ref that matches to ref that matches . In this format, "src" makes sense as a generic sha1_name, and _not_ necessarily limited to a ref-name. IOW, there's really no reason to not allow git-send-pack .. dest .. :dst-ref where "" may be something else than a ref (but a ref obviously ends up being one such thing). For example, let's say that I've got stuff at the HEAD of my tree that I'm not quite ready to push out yet, but I _do_ want to push out the parent of the current head. I'd love to be able to just do 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 the above says. So: > - It is an error if does not match exactly one of local > refs. I think "src" should just be seen as any random SHA1 name, and we should use "get_sha()" to convert it to a SHA1. In contrast, "dst" is obviously a real ref name, and as such: > - It is an error if matches more than one remote refs. makes sense. That makes your next rule a bit iffy, though: > - If does not match any remote refs, either > > - it has to start with "refs/"; is used as the > destination literally in this case. > > - == and the ref that matched the must not > exist in the set of remote refs; the ref matched > locally is used as the name of the destination. since "src" from a local standpoint isn't really a ref-name at all. But hey, your current patch looks fine already. It doesn't _quite_ do what I had in mind, but it gets very very close. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
