* Re: [RFC] Using gitrevisions :/search style with other operators @ 2010-11-09 7:30 Yann Dirson 2010-11-09 8:06 ` Kevin Ballard 2010-11-09 16:10 ` Jeff King 0 siblings, 2 replies; 27+ messages in thread From: Yann Dirson @ 2010-11-09 7:30 UTC (permalink / raw) To: git list, Jeff King, kevin Jeff wrote: > It seems to me the natural way to do that would be to use our existing > generic "start at this ref and follow some chain" syntax, which is > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}. We may want to keep the "/" mnemonic (which seems no to conflict withcurrent use either), rather than the ":" part, with something like origin/pu^{/Merge 'kb/blame-author-email'}, and keep ":" for future use. > We also have ref@{upstream}. The analogue here would be > origin/pu@{:Merge 'kb/blame-author-email'}. That's somewhat different, it looks like the foo@{...} only applies to references with name "foo", and not to arbitrary revisions. Allowing a search to start from any commit seems more useful here. Kevin wrote: > Junio wrote: > > $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' [...] > > Interesting idea. It certainly solves the problem of being able to > embed it within other operations (though you do then have to worry > about escaping any embedded close-parens in the search), though it > does mean my suggestion for being able to select the 2nd (or nth) > match won't work. Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be somewhat consistent with the commit^2 case, and would seem unambiguous as well - a bit weird, though. -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 7:30 [RFC] Using gitrevisions :/search style with other operators Yann Dirson @ 2010-11-09 8:06 ` Kevin Ballard 2010-11-09 9:24 ` Yann Dirson 2010-11-09 16:10 ` Jeff King 1 sibling, 1 reply; 27+ messages in thread From: Kevin Ballard @ 2010-11-09 8:06 UTC (permalink / raw) To: Yann Dirson; +Cc: git list, Jeff King On Nov 8, 2010, at 11:30 PM, Yann Dirson wrote: > Kevin wrote: >> Junio wrote: >>> $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' > [...] >> >> Interesting idea. It certainly solves the problem of being able to >> embed it within other operations (though you do then have to worry >> about escaping any embedded close-parens in the search), though it >> does mean my suggestion for being able to select the 2nd (or nth) >> match won't work. > > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be > somewhat consistent with the commit^2 case, and would seem unambiguous > as well - a bit weird, though. This violates the idea that once you reach the end of a ^{} structure, it resolves to a commit that can then be modified by subsequent operations. -Kevin Ballard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 8:06 ` Kevin Ballard @ 2010-11-09 9:24 ` Yann Dirson 2010-11-10 0:18 ` Junio C Hamano 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-11-09 9:24 UTC (permalink / raw) To: Kevin Ballard; +Cc: git list, Jeff King On Tue, 09 Nov 2010 00:06:47 -0800 Kevin Ballard <kevin@sb.org> wrote: > On Nov 8, 2010, at 11:30 PM, Yann Dirson wrote: > > > Kevin wrote: > >> Junio wrote: > >>> $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' > > [...] > >> > >> Interesting idea. It certainly solves the problem of being able to > >> embed it within other operations (though you do then have to worry > >> about escaping any embedded close-parens in the search), though it > >> does mean my suggestion for being able to select the 2nd (or nth) > >> match won't work. > > > > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be > > somewhat consistent with the commit^2 case, and would seem > > unambiguous as well - a bit weird, though. > > This violates the idea that once you reach the end of a ^{} structure, > it resolves to a commit that can then be modified by subsequent > operations. OK, that's kinda related to the "looks weird" issue. Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'} Since the foo^{objecttype} syntax would not care for a count, it is not a problem, and it keeps provision for using a count with future operators. OTOH, it could be a problem if we extend foo^{bar} to accept "bar" for other things than object types. -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 9:24 ` Yann Dirson @ 2010-11-10 0:18 ` Junio C Hamano 2010-11-10 0:33 ` Kevin Ballard 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-11-10 0:18 UTC (permalink / raw) To: Yann Dirson; +Cc: Kevin Ballard, git list, Jeff King Yann Dirson <dirson@bertin.fr> writes: >> > Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be > ... > Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'} What are these "2"s? You need to question how you figured out the commit you want is the second one reachable (in whatever traversal order) from something in the first place. Didn't you use "git log --oneline" or something to find that out? At that point, you have the object name already, so I doubt such a "counting" feature is of much practical use. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 0:18 ` Junio C Hamano @ 2010-11-10 0:33 ` Kevin Ballard 2010-11-10 7:32 ` Yann Dirson 0 siblings, 1 reply; 27+ messages in thread From: Kevin Ballard @ 2010-11-10 0:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Yann Dirson, git list, Jeff King On Nov 9, 2010, at 4:18 PM, Junio C Hamano wrote: > Yann Dirson <dirson@bertin.fr> writes: > >>>> Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be >> ... >> Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'} > > What are these "2"s? > > You need to question how you figured out the commit you want is the second > one reachable (in whatever traversal order) from something in the first > place. Didn't you use "git log --oneline" or something to find that out? > At that point, you have the object name already, so I doubt such a > "counting" feature is of much practical use. The particular case that prompted this for me was I knew I had created two commits called "WIP", scheduled for renaming later, and I wanted to quickly look at the contents of the first one. I would have loved to be able to type something like `git show :/WIP/2`. I suppose this situation may be rare enough not to bother supporting it in the new syntax. With the new syntax it will be possible to do something like `git show HEAD^{:/WIP}^^{:/WIP}`, but that looks awfully awkward. Another thing to consider - the current :/foo syntax searches for the newest commit reachable from any ref. Using the ^{} syntax will require specifying a ref first. I'm not sure this is a problem though, as I'm not really sure why :/foo searches from all refs to begin with. -Kevin Ballard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 0:33 ` Kevin Ballard @ 2010-11-10 7:32 ` Yann Dirson 2010-11-10 7:46 ` Kevin Ballard 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-11-10 7:32 UTC (permalink / raw) To: Kevin Ballard; +Cc: Junio C Hamano, git list, Jeff King On Tue, 09 Nov 2010 16:33:31 -0800 Kevin Ballard <kevin@sb.org> wrote: > On Nov 9, 2010, at 4:18 PM, Junio C Hamano wrote: > > > Yann Dirson <dirson@bertin.fr> writes: > > > >>>> Syntax like origin/pu^{/Merge 'kb/blame-author-email'}2 would be > >> ... > >> Another idea: origin/pu^{:2/Merge 'kb/blame-author-email'} > > > > What are these "2"s? > > > > You need to question how you figured out the commit you want is the > > second one reachable (in whatever traversal order) from something > > in the first place. Didn't you use "git log --oneline" or > > something to find that out? At that point, you have the object name > > already, so I doubt such a "counting" feature is of much practical > > use. I usually always have a gitk displaying history. Whereas it shows the commit summary, it does not show the sha1 for each commit - and even if it did, my brain is still more comfortable dealing with words than hashes (though that may arguably be an effect of aging ;) > The particular case that prompted this for me was I knew I had > created two commits called "WIP", scheduled for renaming later, and I > wanted to quickly look at the contents of the first one. I would have > loved to be able to type something like `git show :/WIP/2`. I suppose > this situation may be rare enough not to bother supporting it in the > new syntax. With the new syntax it will be possible to do something > like `git show HEAD^{:/WIP}^^{:/WIP}`, but that looks awfully awkward. Another use for counting would be for reflog, to lookup things like "2nd to last of yesterday's commits" - that could be spelled like "master^{:2:yesterday}" or similar. Not sure it's worth it (I hardly use the @{anything vague} syntax myself, especially because it is so vague), but that looked similar enough to be mentionned here. > Another thing to consider - the current :/foo syntax searches for the > newest commit reachable from any ref. Using the ^{} syntax will > require specifying a ref first. I'm not sure this is a problem > though, as I'm not really sure why :/foo searches from all refs to > begin with. The syntax could be extended so that ^{whatever} starts looking at current commit (ie. HEAD), somewhat like @{whatever} looks at reflog for current branch. -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 7:32 ` Yann Dirson @ 2010-11-10 7:46 ` Kevin Ballard 2010-11-10 7:46 ` Yann Dirson 0 siblings, 1 reply; 27+ messages in thread From: Kevin Ballard @ 2010-11-10 7:46 UTC (permalink / raw) To: Yann Dirson; +Cc: Junio C Hamano, git list, Jeff King On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote: >> Another thing to consider - the current :/foo syntax searches for the >> newest commit reachable from any ref. Using the ^{} syntax will >> require specifying a ref first. I'm not sure this is a problem >> though, as I'm not really sure why :/foo searches from all refs to >> begin with. > > The syntax could be extended so that ^{whatever} starts looking at > current commit (ie. HEAD), somewhat like @{whatever} looks at reflog for > current branch. :/foo doesn't start from the current commit - it searches all refs. However, making ^{} search all refs if not given one doesn't make sense for any operator except :/foo, so I don't think it's worth doing -Kevin Ballard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 7:46 ` Kevin Ballard @ 2010-11-10 7:46 ` Yann Dirson 2010-11-10 15:26 ` Jakub Narebski 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-11-10 7:46 UTC (permalink / raw) To: Kevin Ballard; +Cc: Junio C Hamano, git list, Jeff King On Tue, 09 Nov 2010 23:46:59 -0800 Kevin Ballard <kevin@sb.org> wrote: > On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote: > > >> Another thing to consider - the current :/foo syntax searches for > >> the newest commit reachable from any ref. Using the ^{} syntax will > >> require specifying a ref first. I'm not sure this is a problem > >> though, as I'm not really sure why :/foo searches from all refs to > >> begin with. > > > > The syntax could be extended so that ^{whatever} starts looking at > > current commit (ie. HEAD), somewhat like @{whatever} looks at > > reflog for current branch. > > :/foo doesn't start from the current commit - it searches all refs. > However, making ^{} search all refs if not given one doesn't make > sense for any operator except :/foo, so I don't think it's worth doing Yes, that's why I suggested to make it search from HEAD, not from all refs. -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 7:46 ` Yann Dirson @ 2010-11-10 15:26 ` Jakub Narebski 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy 2010-11-10 17:23 ` [RFC] Using gitrevisions :/search style with other operators Junio C Hamano 0 siblings, 2 replies; 27+ messages in thread From: Jakub Narebski @ 2010-11-10 15:26 UTC (permalink / raw) To: Yann Dirson; +Cc: Kevin Ballard, Junio C Hamano, git list, Jeff King Yann Dirson <dirson@bertin.fr> writes: > On Tue, 09 Nov 2010 23:46:59 -0800 > Kevin Ballard <kevin@sb.org> wrote: >> On Nov 9, 2010, at 11:32 PM, Yann Dirson wrote: >> >>>> Another thing to consider - the current :/foo syntax searches for >>>> the newest commit reachable from any ref. Using the ^{} syntax will >>>> require specifying a ref first. I'm not sure this is a problem >>>> though, as I'm not really sure why :/foo searches from all refs to >>>> begin with. >>> >>> The syntax could be extended so that ^{whatever} starts looking at >>> current commit (ie. HEAD), somewhat like @{whatever} looks at >>> reflog for current branch. The <ref>@<sth> is about reflogs: <ref>@{<n>}, <ref>@{<aproxidate>}, @{-<n>}, <ref>@{upstream} / <ref>@{u}. Because HEAD has separate reflog, then @{<sth>} is about current branch reflog (@{-<n>} uses HEAD reflog, though). <ref> must be something that has reflog. The <obj>^<sth> is about dereferencing: <tag>^{<objtype>} and <tag>^{}, which includes following parents <commit>^ and <commit>^<n>. Then there are odd <commit-ish>^! (returning range) and <commit-ish>^@ (all parents) but which nevertheless follow this rule. The <obj>:<sth> is (with single exception of ':/<regexp>') about selecting subitem (path): <tree-ish>:<path>, [:<stage>]:<path> >> >> :/foo doesn't start from the current commit - it searches all refs. >> However, making ^{} search all refs if not given one doesn't make >> sense for any operator except :/foo, so I don't think it's worth doing > > Yes, that's why I suggested to make it search from HEAD, not from all > refs. Perhaps '--all^{/foo}'? Just kidding... I think ;-) About n-th match: I think that ^{<n>/foo} or ^{:<n>/foo}... or ^{:nth(<n>)/foo} as generic form of e.g. ^{3rd/foo} a la Perl 6 :-) Or perhaps even full form ^{m:nth(<n>)/foo}... well, perhaps not. -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 15:26 ` Jakub Narebski @ 2010-11-10 16:37 ` Nguyễn Thái Ngọc Duy 2010-11-10 17:17 ` Matthieu Moy ` (3 more replies) 2010-11-10 17:23 ` [RFC] Using gitrevisions :/search style with other operators Junio C Hamano 1 sibling, 4 replies; 27+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2010-11-10 16:37 UTC (permalink / raw) To: git, jnareb Cc: dirson, kevin, gitster, peff, Nguyễn Thái Ngọc Duy Currently :path and ref:path can be used to refer to a specific object in index or ref respectively. "path" component is absolute path. This patch allows "path" to be written as "./path" or "../path", which is relative to user's original cwd. This does not work in commands that startup_info is NULL (i.e. non-builtin ones). --- On Wed, Nov 10, 2010 at 07:26:20AM -0800, Jakub Narebski wrote: > The <obj>:<sth> is (with single exception of ':/<regexp>') about > selecting subitem (path): <tree-ish>:<path>, [:<stage>]:<path> I feel the urge of keeping ':./path' and ':../path' out of this competition. The idea is old although I don't remember if anybody has made any attempt to realize it: use './' and '../' to specify the given path is relative, not absolute. I don't remember either if the idea was rejected or nobody bothered to implement it. Anyway, here it is (for demostration only because it needs two minor patches to work). Comments? -- Duy sha1_name.c | 30 +++++++++++++++++++++++++++--- 1 files changed, 27 insertions(+), 3 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index 484081d..791608d 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -1060,25 +1060,35 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, if (!ret) return ret; /* sha1:path --> object name of path in ent sha1 - * :path -> object name of path in index + * :path -> object name of absolute path in index + * :./path -> object name of path relative to cwd in index * :[0-3]:path -> object name of path in index at stage * :/foo -> recent commit matching foo */ if (name[0] == ':') { int stage = 0; struct cache_entry *ce; + char *new_path = NULL; int pos; if (namelen > 2 && name[1] == '/') return get_sha1_oneline(name + 2, sha1); if (namelen < 3 || name[2] != ':' || - name[1] < '0' || '3' < name[1]) + name[1] < '0' || '3' < name[1]) { cp = name + 1; + if (startup_info && cp[0] == '.' && + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) { + new_path = prefix_path(startup_info->prefix, + strlen(startup_info->prefix), + cp); + cp = new_path; + } + } else { stage = name[1] - '0'; cp = name + 3; } - namelen = namelen - (cp - name); + namelen = strlen(cp); strncpy(oc->path, cp, sizeof(oc->path)); @@ -1096,12 +1106,14 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, break; if (ce_stage(ce) == stage) { hashcpy(sha1, ce->sha1); + free(new_path); return 0; } pos++; } if (!gently) diagnose_invalid_index_path(stage, prefix, cp); + free(new_path); return -1; } for (cp = name, bracket_depth = 0; *cp; cp++) { @@ -1122,6 +1134,17 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, } if (!get_sha1_1(name, cp-name, tree_sha1)) { const char *filename = cp+1; + char *new_filename = NULL; + + if (startup_info && + filename[0] == '.' && + (filename[1] == '/' || + (filename[1] == '.' && filename[2] == '/'))) { + new_filename = prefix_path(startup_info->prefix, + strlen(startup_info->prefix), + filename); + filename = new_filename; + } ret = get_tree_entry(tree_sha1, filename, sha1, &oc->mode); if (!gently) { diagnose_invalid_sha1_path(prefix, filename, @@ -1133,6 +1156,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, sizeof(oc->path)); oc->path[sizeof(oc->path)-1] = '\0'; + free(new_filename); return ret; } else { if (!gently) -- 1.7.3.2.210.g045198 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy @ 2010-11-10 17:17 ` Matthieu Moy 2010-11-10 17:47 ` Jonathan Nieder ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Matthieu Moy @ 2010-11-10 17:17 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy Cc: git, jnareb, dirson, kevin, gitster, peff Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > Currently :path and ref:path can be used to refer to a specific object > in index or ref respectively. "path" component is absolute path. This > patch allows "path" to be written as "./path" or "../path", which is > relative to user's original cwd. > > This does not work in commands that startup_info is NULL Grammar: shouldn't it be "commands for which startup_info is NULL"? > (i.e. non-builtin ones). Does that include "git show"? That's probably the most common use-case for the <object>:<path> syntax, perhaps worth mentionning here. Also, what happens when it doesn't work? I guess it falls back to the previous behavior, which tries to do a detailed diagnosis and provides a general error message. But probably the error messages should be reworded to include "syntax not supported by this command" or so, 'cause it's really weird for a user to be able to say HEAD:./foo in some places and not in others. > The idea is old although I don't remember if anybody has made any > attempt to realize it: use './' and '../' to specify the given path > is relative, not absolute. I gave it a try, but I was not aware of the startup_info thing, and tried passing more arguments to get_sha1*, and you can guess I quickly gave up ;-). > + if (startup_info && cp[0] == '.' && > + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) { Nothing performance-critical here, so I'd rather have something more readable, like startup_info && (!prefixcmp(cp, "./") || !prefixcmp(cp, "../")) > + new_path = prefix_path(startup_info->prefix, > + strlen(startup_info->prefix), > + cp); free(cp); here? > + cp = new_path; > + } > + } > @@ -1122,6 +1134,17 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, > } > if (!get_sha1_1(name, cp-name, tree_sha1)) { > const char *filename = cp+1; > + char *new_filename = NULL; > + > + if (startup_info && > + filename[0] == '.' && > + (filename[1] == '/' || > + (filename[1] == '.' && filename[2] == '/'))) { > + new_filename = prefix_path(startup_info->prefix, > + strlen(startup_info->prefix), > + filename); Same 2 questions as above. Also, that would be nice is this came with a testcase :-) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy 2010-11-10 17:17 ` Matthieu Moy @ 2010-11-10 17:47 ` Jonathan Nieder 2010-11-11 13:18 ` Nguyen Thai Ngoc Duy 2010-11-10 19:34 ` Junio C Hamano 2010-12-09 21:10 ` Junio C Hamano 3 siblings, 1 reply; 27+ messages in thread From: Jonathan Nieder @ 2010-11-10 17:47 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy Cc: git, jnareb, dirson, kevin, gitster, peff Nguyễn Thái Ngọc Duy wrote: > This does not work in commands that startup_info is NULL > (i.e. non-builtin ones). That is easily fixable, no? The non-builtins are: fast-import imap-send shell daemon show-index upload-pack http-backend http-fetch http-push Of those, only fast-import might have a possible reason need to know about this new syntax. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Assuming your patch builds on acf4823a (setup: save prefix (original cwd relative to toplevel) in startup_info, 2010-10-24). Untested. diff --git a/fast-import.c b/fast-import.c index 77549eb..3b597e8 100644 --- a/fast-import.c +++ b/fast-import.c @@ -2923,8 +2923,11 @@ static void parse_argv(void) int main(int argc, const char **argv) { + static struct startup_info git_startup_info; unsigned int i; + startup_info = &git_startup_info; + git_extract_argv0_path(argv[0]); if (argc == 2 && !strcmp(argv[1], "-h")) ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 17:47 ` Jonathan Nieder @ 2010-11-11 13:18 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 27+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-11 13:18 UTC (permalink / raw) To: Jonathan Nieder; +Cc: git, jnareb, dirson, kevin, gitster, peff 2010/11/11 Jonathan Nieder <jrnieder@gmail.com>: > Nguyễn Thái Ngọc Duy wrote: > >> This does not work in commands that startup_info is NULL >> (i.e. non-builtin ones). > > That is easily fixable, no? Laziness is a big factor to me (or maybe I'm just tired after work). In the meantime I'll take your analysis and fix fast-import. Thanks. -- Duy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy 2010-11-10 17:17 ` Matthieu Moy 2010-11-10 17:47 ` Jonathan Nieder @ 2010-11-10 19:34 ` Junio C Hamano 2010-11-11 1:30 ` Nguyen Thai Ngoc Duy 2010-12-09 21:10 ` Junio C Hamano 3 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-11-10 19:34 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy; +Cc: git, jnareb, dirson, kevin, peff Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > if (namelen < 3 || > name[2] != ':' || > - name[1] < '0' || '3' < name[1]) > + name[1] < '0' || '3' < name[1]) { > cp = name + 1; > + if (startup_info && cp[0] == '.' && > + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) { > + new_path = prefix_path(startup_info->prefix, > + strlen(startup_info->prefix), > + cp); > + cp = new_path; > + } > + } What does this new codepath do when we know where the working tree is and we are outside of the working tree (e.g. we are looking at the index or a commit in a submodule from above the superproject)? What should it do? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 19:34 ` Junio C Hamano @ 2010-11-11 1:30 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 27+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-11 1:30 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, jnareb, dirson, kevin, peff 2010/11/11 Junio C Hamano <gitster@pobox.com>: > Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > >> if (namelen < 3 || >> name[2] != ':' || >> - name[1] < '0' || '3' < name[1]) >> + name[1] < '0' || '3' < name[1]) { >> cp = name + 1; >> + if (startup_info && cp[0] == '.' && >> + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) { >> + new_path = prefix_path(startup_info->prefix, >> + strlen(startup_info->prefix), >> + cp); >> + cp = new_path; >> + } >> + } > > What does this new codepath do when we know where the working tree is and > we are outside of the working tree (e.g. we are looking at the index or a > commit in a submodule from above the superproject)? > > What should it do? Prefix is NULL in that case. So no prefixing, git will complain the given path does not exist (although it should say "./" syntax is not usable without a worktree). prefix_path() dies if the resolved path is outside repo. So no, users can't look up files in superproject from a subproject. I think we need to define the superproject/subproject relation first. I have $HOME/.git, but I don't think it's a superproject to any repos inside my $HOME. -- Duy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy ` (2 preceding siblings ...) 2010-11-10 19:34 ` Junio C Hamano @ 2010-12-09 21:10 ` Junio C Hamano 2010-12-09 21:37 ` Junio C Hamano 3 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-12-09 21:10 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy; +Cc: git, jnareb, dirson, kevin, peff Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > Currently :path and ref:path can be used to refer to a specific object > in index or ref respectively. "path" component is absolute path. This > patch allows "path" to be written as "./path" or "../path", which is > relative to user's original cwd. > > This does not work in commands that startup_info is NULL > (i.e. non-builtin ones). > --- > On Wed, Nov 10, 2010 at 07:26:20AM -0800, Jakub Narebski wrote: > > The <obj>:<sth> is (with single exception of ':/<regexp>') about > > selecting subitem (path): <tree-ish>:<path>, [:<stage>]:<path> > > I feel the urge of keeping ':./path' and ':../path' out of this > competition. > > The idea is old although I don't remember if anybody has made any > attempt to realize it: use './' and '../' to specify the given path > is relative, not absolute. I've had this queued for some time, with help from Jonathan, and am happy about it in general, but after taking another look at it, noticed one minor thing. > diff --git a/sha1_name.c b/sha1_name.c > index 484081d..791608d 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -1060,25 +1060,35 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, > if (!ret) > return ret; > /* sha1:path --> object name of path in ent sha1 > - * :path -> object name of path in index > + * :path -> object name of absolute path in index > + * :./path -> object name of path relative to cwd in index > * :[0-3]:path -> object name of path in index at stage > * :/foo -> recent commit matching foo > */ > if (name[0] == ':') { > int stage = 0; > struct cache_entry *ce; > + char *new_path = NULL; > int pos; > if (namelen > 2 && name[1] == '/') > return get_sha1_oneline(name + 2, sha1); > if (namelen < 3 || > name[2] != ':' || > - name[1] < '0' || '3' < name[1]) > + name[1] < '0' || '3' < name[1]) { > cp = name + 1; > + if (startup_info && cp[0] == '.' && > + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) { > + new_path = prefix_path(startup_info->prefix, > + strlen(startup_info->prefix), > + cp); > + cp = new_path; > + } > + } This deals with ":$foo" (path $foo in the index), which is a shorthand for ":0:$foo" (the path $foo at stage #0 in the index). However... > else { > stage = name[1] - '0'; > cp = name + 3; ... this side does not do anything about it, so: $ cd Documentation ... working for a while ... $ git merge another_branch ... oops, got conflicts at ../Makefile $ git show :2:../Makefile won't work. Besides, it is a bad idea to make ":../Makefile" work while leaving its longhand ":0:../Makefile" not. I think it is just the matter of moving "if (startup-info)..." logic outside the "is the :$path lacking an explicit stage number" block and having it after that if/else, no? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-12-09 21:10 ` Junio C Hamano @ 2010-12-09 21:37 ` Junio C Hamano 2010-12-10 1:35 ` Nguyen Thai Ngoc Duy 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-12-09 21:37 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy; +Cc: git, jnareb, dirson, kevin, peff Junio C Hamano <gitster@pobox.com> writes: > I think it is just the matter of moving "if (startup-info)..." logic > outside the "is the :$path lacking an explicit stage number" block and > having it after that if/else, no? Like this, perhaps? -- >8 -- Subject: get_sha1: teach ":$n:<path>" the same relative path logic Earlier we taught the object name parser ":<path>" syntax that uses a path relative to the current working directory. Given that ":<path>" is just a short-hand for ":0:<path>" (i.e. "take stage #0 of that path"), we should allow ":$n:<path>" to use relative path the same way. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- sha1_name.c | 14 ++++++++------ t/t1506-rev-parse-diagnosis.sh | 24 ++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 6 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index f918faf..2074056 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -1091,17 +1091,19 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1, return get_sha1_oneline(name + 2, sha1); if (namelen < 3 || name[2] != ':' || - name[1] < '0' || '3' < name[1]) { + name[1] < '0' || '3' < name[1]) cp = name + 1; - new_path = resolve_relative_path(cp); - if (new_path) - cp = new_path; - } else { stage = name[1] - '0'; cp = name + 3; } - namelen = strlen(cp); + new_path = resolve_relative_path(cp); + if (!new_path) { + namelen = namelen - (cp - name); + } else { + cp = new_path; + namelen = strlen(cp); + } strncpy(oc->path, cp, sizeof(oc->path)); diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh index 1866470..9f8adb1 100755 --- a/t/t1506-rev-parse-diagnosis.sh +++ b/t/t1506-rev-parse-diagnosis.sh @@ -34,6 +34,8 @@ test_expect_success 'correct file objects' ' test_expect_success 'correct relative file objects (0)' ' git rev-parse :file.txt >expected && git rev-parse :./file.txt >result && + test_cmp expected result && + git rev-parse :0:./file.txt >result && test_cmp expected result ' @@ -68,6 +70,28 @@ test_expect_success 'correct relative file objects (4)' ' ) ' +test_expect_success 'correct relative file objects (5)' ' + git rev-parse :subdir/file.txt >expected && + ( + cd subdir && + git rev-parse :./file.txt >result && + test_cmp ../expected result && + git rev-parse :0:./file.txt >result && + test_cmp ../expected result + ) +' + +test_expect_success 'correct relative file objects (6)' ' + git rev-parse :file.txt >expected && + ( + cd subdir && + git rev-parse :../file.txt >result && + test_cmp ../expected result && + git rev-parse :0:../file.txt >result && + test_cmp ../expected result + ) +' + test_expect_success 'incorrect revision id' ' test_must_fail git rev-parse foobar:file.txt 2>error && grep "Invalid object name '"'"'foobar'"'"'." error && ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax 2010-12-09 21:37 ` Junio C Hamano @ 2010-12-10 1:35 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 27+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-12-10 1:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, jnareb, dirson, kevin, peff 2010/12/10 Junio C Hamano <gitster@pobox.com>: > Junio C Hamano <gitster@pobox.com> writes: > >> I think it is just the matter of moving "if (startup-info)..." logic >> outside the "is the :$path lacking an explicit stage number" block and >> having it after that if/else, no? > > Like this, perhaps? Yeah, looks good. Sorry I missed that else block. -- Duy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 15:26 ` Jakub Narebski 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy @ 2010-11-10 17:23 ` Junio C Hamano 2010-11-10 18:19 ` Jakub Narebski 1 sibling, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-11-10 17:23 UTC (permalink / raw) To: Jakub Narebski Cc: Yann Dirson, Kevin Ballard, Junio C Hamano, git list, Jeff King Jakub Narebski <jnareb@gmail.com> writes: > The <ref>@<sth> is about reflogs Wrong. "@" in the olden days were limited about reflogs but not these days. <ref>@<something> is about refs; <objectname>^<operation> is about objects (most often commits). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-10 17:23 ` [RFC] Using gitrevisions :/search style with other operators Junio C Hamano @ 2010-11-10 18:19 ` Jakub Narebski 0 siblings, 0 replies; 27+ messages in thread From: Jakub Narebski @ 2010-11-10 18:19 UTC (permalink / raw) To: Junio C Hamano; +Cc: Yann Dirson, Kevin Ballard, git list, Jeff King On Wed, 10 Nov 2010, Junio C Hamano wrote: > Jakub Narebski <jnareb@gmail.com> writes: > > > The <ref>@<sth> is about reflogs > > Wrong. "@" in the olden days were limited about reflogs but not these > days. <ref>@<something> is about refs; <objectname>^<operation> is about > objects (most often commits). Fact. I even provided example, and didn't notice it: [<ref>]@{upstream} does not use reflogs, but config. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 7:30 [RFC] Using gitrevisions :/search style with other operators Yann Dirson 2010-11-09 8:06 ` Kevin Ballard @ 2010-11-09 16:10 ` Jeff King 1 sibling, 0 replies; 27+ messages in thread From: Jeff King @ 2010-11-09 16:10 UTC (permalink / raw) To: Yann Dirson; +Cc: git list, kevin On Tue, Nov 09, 2010 at 08:30:23AM +0100, Yann Dirson wrote: > Jeff wrote: > > It seems to me the natural way to do that would be to use our existing > > generic "start at this ref and follow some chain" syntax, which is > > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}. > > We may want to keep the "/" mnemonic (which seems no to conflict > withcurrent use either), rather than the ":" part, with something like > origin/pu^{/Merge 'kb/blame-author-email'}, and keep ":" for future use. Yeah, sorry, the ':' thing was just a think-o on my part. It should definitely be "/". > > We also have ref@{upstream}. The analogue here would be > > origin/pu@{:Merge 'kb/blame-author-email'}. > > That's somewhat different, it looks like the foo@{...} only applies to > references with name "foo", and not to arbitrary revisions. Allowing a > search to start from any commit seems more useful here. Yeah, agreed. -Peff ^ permalink raw reply [flat|nested] 27+ messages in thread
* [RFC] Using gitrevisions :/search style with other operators @ 2010-11-05 22:38 Kevin Ballard 2010-11-08 19:09 ` Junio C Hamano 0 siblings, 1 reply; 27+ messages in thread From: Kevin Ballard @ 2010-11-05 22:38 UTC (permalink / raw) To: Git mailing list Most of the ways to refer to a git revision can be combined, e.g. I can type something silly like HEAD~2^^2^2~4^{tree} and this will work as expected. There is one operator that doesn't allow this at all, and that's the commit message search (e.g. :/foo). Every character after the :/ is taken to be part of the regular expression. This is rather unfortunate as it prevents me from doing something like :/foo^ to refer to the parent of the matching commit. Does anybody have any opinions on changing this operator? My suggestion would be to treat a second / as a termination of the pattern and allow operators (such as ^ or ~<n>) to occur at that point. This would look like :/Merge branch 'foo'/^ If you need a / in your message then you can just escape it with a backslash. A second change to consider is a syntax to specify that you want the 2nd (or nth) match rather than the first. This could be done like :/foo/2 unless someone has a better idea. And finally, I'd love to be able to specify the ref to search from. The current behavior is to find the earliest matching commit on any ref, but it seems I should be able to type something like git merge 'origin/pu:/jh\/notes-merge/^2' in order to grab the jh/notes-merge topic branch from origin/pu and merge it into HEAD. Currently trying to type something like master:/test will treat /test as a file path on master, which is something that will never resolve to a real file due to the leading slash. Comments/suggestions/critiques are welcome. -Kevin Ballard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-05 22:38 Kevin Ballard @ 2010-11-08 19:09 ` Junio C Hamano 2010-11-08 22:11 ` Kevin Ballard 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-11-08 19:09 UTC (permalink / raw) To: Kevin Ballard; +Cc: Git mailing list Kevin Ballard <kevin@sb.org> writes: > There is one operator that doesn't allow this at all, and that's the commit > message search (e.g. :/foo). Every character after the :/ is taken to be > part of the regular expression. This is rather unfortunate as it prevents me > from doing something like :/foo^ to refer to the parent of the matching commit. > > Does anybody have any opinions on changing this operator? If you mean to change what ":/Merge branch 'kb/blame-author-email'" means, and make my scripts suddenly start breaking, I would be moderately unhappy. It is fine if we can enhance the extended SHA-1 vocabulary by introducing a syntax that used to be illegal, hence there is no chance somebody was using it for other purposes. I wonder if we can introduce something like ':( ... )' to group things. E.g. $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' I haven't visited the particular codepath for some time, so I don't know offhand how involved the change would be, though. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-08 19:09 ` Junio C Hamano @ 2010-11-08 22:11 ` Kevin Ballard 2010-11-09 5:16 ` Jeff King 0 siblings, 1 reply; 27+ messages in thread From: Kevin Ballard @ 2010-11-08 22:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git mailing list On Nov 8, 2010, at 11:09 AM, Junio C Hamano wrote: > Kevin Ballard <kevin@sb.org> writes: > >> There is one operator that doesn't allow this at all, and that's the commit >> message search (e.g. :/foo). Every character after the :/ is taken to be >> part of the regular expression. This is rather unfortunate as it prevents me >> from doing something like :/foo^ to refer to the parent of the matching commit. >> >> Does anybody have any opinions on changing this operator? > > If you mean to change what ":/Merge branch 'kb/blame-author-email'" means, > and make my scripts suddenly start breaking, I would be moderately unhappy. Ah yes, I suppose you do have a common case it would break. > It is fine if we can enhance the extended SHA-1 vocabulary by introducing > a syntax that used to be illegal, hence there is no chance somebody was > using it for other purposes. > > I wonder if we can introduce something like ':( ... )' to group things. > E.g. > > $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' > > I haven't visited the particular codepath for some time, so I don't know > offhand how involved the change would be, though. Interesting idea. It certainly solves the problem of being able to embed it within other operations (though you do then have to worry about escaping any embedded close-parens in the search), though it does mean my suggestion for being able to select the 2nd (or nth) match won't work. When I have the time I'll start taking a look at the code. Any comments on my suggestion to specify the ref to search from, e.g. origin/pu:/"Merge 'kb/blame-author-email'"? As I stated before, I believe this syntax is currently-unused (as it is interpreted as a file lookup, but file paths starting with / will never resolve to anything in testing), but I want to make sure I'm not overlooking something. -Kevin Ballard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-08 22:11 ` Kevin Ballard @ 2010-11-09 5:16 ` Jeff King 2010-11-09 15:59 ` Junio C Hamano 0 siblings, 1 reply; 27+ messages in thread From: Jeff King @ 2010-11-09 5:16 UTC (permalink / raw) To: Kevin Ballard; +Cc: Junio C Hamano, Git mailing list On Mon, Nov 08, 2010 at 02:11:54PM -0800, Kevin Ballard wrote: > > $ git log 'HEAD..:( :/Merge branch 'kb/blame-author-email' )^2' > > > > I haven't visited the particular codepath for some time, so I don't know > > offhand how involved the change would be, though. > > Interesting idea. It certainly solves the problem of being able to embed it > within other operations (though you do then have to worry about escaping any > embedded close-parens in the search), though it does mean my suggestion for > being able to select the 2nd (or nth) match won't work. When I have the time > I'll start taking a look at the code. > > Any comments on my suggestion to specify the ref to search from, e.g. > origin/pu:/"Merge 'kb/blame-author-email'"? As I stated before, I believe It seems to me the natural way to do that would be to use our existing generic "start at this ref and follow some chain" syntax, which is ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}. We already use it for "follow tree link" and "peel tag objects", and it is syntactically similar to the usual "follow the ancestry chain" syntax ("ref^"). And I believe it should be unambiguous, as nothing that could go in ^{} could start with ":". And presumably one would have to backslash-escape embedded closing curly braces. We also have ref@{upstream}. The analogue here would be origin/pu@{:Merge 'kb/blame-author-email'}. I don't recall whether we put any conscious thought into ref@{upstream} versus ref^{upstream}. Certainly the former implies to me finding a particular starting point (as we do for reflogs), and the latter implies walking object graph (either by parent ancestry links, or through dereferencing tag and commit pointers). But I may just be rationalizing after the fact. :) Certainly this particular case seems to me to be more like "^" or "~"; you are walking the ancestry tree not a specific number of steps, but until you see a particular subject. -Peff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 5:16 ` Jeff King @ 2010-11-09 15:59 ` Junio C Hamano 2010-11-09 16:08 ` Jeff King 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-11-09 15:59 UTC (permalink / raw) To: Jeff King; +Cc: Kevin Ballard, Git mailing list Jeff King <peff@peff.net> writes: >> Any comments on my suggestion to specify the ref to search from, e.g. >> origin/pu:/"Merge 'kb/blame-author-email'"? As I stated before, I believe > > It seems to me the natural way to do that would be to use our existing > generic "start at this ref and follow some chain" syntax, which is > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}. > > We already use it for "follow tree link" and "peel tag objects", and it > is syntactically similar to the usual "follow the ancestry chain" syntax > ("ref^"). And I believe it should be unambiguous, as nothing that could > go in ^{} could start with ":". And presumably one would have to > backslash-escape embedded closing curly braces. Yeah, that may make more sense but I think the operation specifier should be '/', not ':', no? We chose ':' as a "funky SHA-1 expression introducer" that can be followed by other letters to specify what kind of funkiness is being summoned (in the case of ':/string', you are asking for "search" funkiness), so that we can extend it with different kind of funkiness later. That is where my earlier ':(...)' came from. > We also have ref@{upstream}. The analogue here would be > origin/pu@{:Merge 'kb/blame-author-email'}. > > I don't recall whether we put any conscious thought into ref@{upstream} > versus ref^{upstream}. I think that is because it is nonsensical to say sha1@{u} for an arbitrary SHA-1 expression (i.e. the operator only makes sense for a branch ref we can find branch.*.merge for). So from that perspective, you are right that "Start from this commit and find an ancestor whose log message contains this string" goes well with "sha1^{/some string}" ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Using gitrevisions :/search style with other operators 2010-11-09 15:59 ` Junio C Hamano @ 2010-11-09 16:08 ` Jeff King 0 siblings, 0 replies; 27+ messages in thread From: Jeff King @ 2010-11-09 16:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: Kevin Ballard, Git mailing list On Tue, Nov 09, 2010 at 07:59:03AM -0800, Junio C Hamano wrote: > > It seems to me the natural way to do that would be to use our existing > > generic "start at this ref and follow some chain" syntax, which is > > ref^{foo}. For example: origin/pu^{:Merge 'kb/blame-author-email'}. > > Yeah, that may make more sense but I think the operation specifier should > be '/', not ':', no? Yeah, I don't know what I was thinking when I wrote the text above. It should definitely be origin/pu^{/Merge...}. -Peff ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2010-12-10 1:35 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-09 7:30 [RFC] Using gitrevisions :/search style with other operators Yann Dirson 2010-11-09 8:06 ` Kevin Ballard 2010-11-09 9:24 ` Yann Dirson 2010-11-10 0:18 ` Junio C Hamano 2010-11-10 0:33 ` Kevin Ballard 2010-11-10 7:32 ` Yann Dirson 2010-11-10 7:46 ` Kevin Ballard 2010-11-10 7:46 ` Yann Dirson 2010-11-10 15:26 ` Jakub Narebski 2010-11-10 16:37 ` [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax Nguyễn Thái Ngọc Duy 2010-11-10 17:17 ` Matthieu Moy 2010-11-10 17:47 ` Jonathan Nieder 2010-11-11 13:18 ` Nguyen Thai Ngoc Duy 2010-11-10 19:34 ` Junio C Hamano 2010-11-11 1:30 ` Nguyen Thai Ngoc Duy 2010-12-09 21:10 ` Junio C Hamano 2010-12-09 21:37 ` Junio C Hamano 2010-12-10 1:35 ` Nguyen Thai Ngoc Duy 2010-11-10 17:23 ` [RFC] Using gitrevisions :/search style with other operators Junio C Hamano 2010-11-10 18:19 ` Jakub Narebski 2010-11-09 16:10 ` Jeff King -- strict thread matches above, loose matches on Subject: below -- 2010-11-05 22:38 Kevin Ballard 2010-11-08 19:09 ` Junio C Hamano 2010-11-08 22:11 ` Kevin Ballard 2010-11-09 5:16 ` Jeff King 2010-11-09 15:59 ` Junio C Hamano 2010-11-09 16:08 ` Jeff King
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).