# Re: (unknown) 14 messages from 2006-10-25 to 2006-10-26. Participants: Junio C Hamano, Jakub Narebski, Josef Weidendorfer, Andy Parkins, andyparkins@gmail.com, Karl Hasselström, Linus Torvalds, Shawn Pearce. Thread: https://gitlist.dev/t/43245 ## andyparkins@gmail.com, 2006-10-25 14:47 Subject: (unknown) Message-ID: URL: https://gitlist.dev/e/E1Gck2K-0003H4-00%40dvr.360vision.com ``` From cd4366ed4e3f765c00310c35c0eabeccf433acdb Mon Sep 17 00:00:00 2001 From: Andy Parkins Date: Wed, 25 Oct 2006 15:47:19 +0100 Subject: [PATCH] Use "up/" prefix for all the upstream branches To: git@vger.kernel.org X-TUID: aba1ff8a0c61615e X-UID: 126 X-Length: 1359 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610251547.19208.andyparkins@gmail.com> To easily differentiate the read-only upstream branches, from normal branches, default to cloning them with the prefix "up/" added to their branch names. This also abandons the idea of an "origin" branch which is now simply "up/master" and hence removes the special treatment that master was getting. (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit) Signed-off-by: Andy Parkins --- I'm sure this will be an unwanted patch. However, I really do think it's important to highlight these upstream branches in some way. I realise renaming "origin" is probably not going to fly, but perhaps it would be okay to have at least the non-origin branches prefixed? git-clone.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index 3f006d1..ebd93da 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -185,7 +185,7 @@ fi if test -z "$origin" then - origin=origin + origin=up/master fi # Turn the source into an absolute path if @@ -389,7 +389,7 @@ Pull: refs/heads/$head_points_at:$origin then continue fi - echo "Pull: refs/heads/${name}:$remote_top/${name}" + echo "Pull: refs/heads/${name}:$remote_top/up/${name}" done >>"$GIT_DIR/remotes/$origin" && case "$use_separate_remote" in t) -- 1.4.2.3 ``` ## Jakub Narebski, 2006-10-25 14:53 Subject: Re: (unknown) Message-ID: URL: https://gitlist.dev/e/ehntnv%24b1k%241%40sea.gmane.org In-Reply-To: ``` andyparkins@gmail.com wrote: > To easily differentiate the read-only upstream branches, from normal branches, > default to cloning them with the prefix "up/" added to their branch names. > This also abandons the idea of an "origin" branch which is now simply > "up/master" and hence removes the special treatment that master was getting. > (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit) > Signed-off-by: Andy Parkins > --- > I'm sure this will be an unwanted patch.  However, I really do think it's > important to highlight these upstream branches in some way.  I realise > renaming "origin" is probably not going to fly, but perhaps it would be okay > to have at least the non-origin branches prefixed? Check if "git clone --use-separate-remote" isn't what you want. And please correct mail sending. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Andy Parkins, 2006-10-25 15:10 Subject: Re: (unknown) Message-ID: <200610251610.02446.andyparkins@gmail.com> URL: https://gitlist.dev/e/200610251610.02446.andyparkins%40gmail.com In-Reply-To: ``` On Wednesday 2006 October 25 15:53, Jakub Narebski wrote: > Check if "git clone --use-separate-remote" isn't what you want. I did try that, but then the branches don't appear in git branch. I still like that they exist. > And please correct mail sending. AHHHH!!! I thought I had. Dagnamit; I think an upgrade in Debian overwrote my manual git-imap-send compile. The git-imap-send bug was fixed in e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it into debian yet. I'm getting so sick of looking like an idiot. My apologies to everyone for the constant noise I keep dumping on the list. I promise I'm trying really hard to be good. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com ``` ## Karl Hasselström, 2006-10-25 15:31 Subject: Re: (unknown) Message-ID: <20061025153121.GA29291@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20061025153121.GA29291%40diana.vm.bytemark.co.uk In-Reply-To: <200610251610.02446.andyparkins@gmail.com> ``` On 2006-10-25 16:10:02 +0100, Andy Parkins wrote: > My apologies to everyone for the constant noise I keep dumping on > the list. I promise I'm trying really hard to be good. I always try sending the patch to myself first, since something almost always goes wrong on the first try. This helps against most problems, but certainly not all. :-) -- Karl Hasselström, kha@treskal.com ``` ## Junio C Hamano, 2006-10-25 18:38 Subject: Re: (unknown) Message-ID: <7vods0b5rk.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vods0b5rk.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200610251610.02446.andyparkins@gmail.com> ``` Andy Parkins writes: > On Wednesday 2006 October 25 15:53, Jakub Narebski wrote: > >> Check if "git clone --use-separate-remote" isn't what you want. > > I did try that, but then the branches don't appear in git branch. I still > like that they exist. "git branch -r" perhaps. ``` ## Andy Parkins, 2006-10-25 22:03 Subject: Re: (unknown) Message-ID: <200610252303.07900.andyparkins@gmail.com> URL: https://gitlist.dev/e/200610252303.07900.andyparkins%40gmail.com In-Reply-To: <7vods0b5rk.fsf@assigned-by-dhcp.cox.net> ``` On Wednesday 2006, October 25 19:38, Junio C Hamano wrote: > > I did try that, but then the branches don't appear in git branch. I > > still like that they exist. > > "git branch -r" perhaps. That's pretty good. It makes things like git-log remotes/origin/master..master A bit long winded, but it's certainly what I asked for. You guys really have thought of everything. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE ``` ## Junio C Hamano, 2006-10-25 22:16 Subject: Re: (unknown) Message-ID: <7v1wowm46j.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wowm46j.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200610252303.07900.andyparkins@gmail.com> ``` Andy Parkins writes: > On Wednesday 2006, October 25 19:38, Junio C Hamano wrote: > >> > I did try that, but then the branches don't appear in git branch. I >> > still like that they exist. >> >> "git branch -r" perhaps. > > That's pretty good. It makes things like > > git-log remotes/origin/master..master > > A bit long winded, but it's certainly what I asked for. "git log remotes/origin..master" perhaps? The point being, remotes/origin when origin is a directory that has HEAD that points at something, it stands for remotes/origin/HEAD. ``` ## Shawn Pearce, 2006-10-25 22:16 Subject: Re: (unknown) Message-ID: <20061025221659.GC10140@spearce.org> URL: https://gitlist.dev/e/20061025221659.GC10140%40spearce.org In-Reply-To: <200610252303.07900.andyparkins@gmail.com> ``` Andy Parkins wrote: > On Wednesday 2006, October 25 19:38, Junio C Hamano wrote: > > > > I did try that, but then the branches don't appear in git branch. I > > > still like that they exist. > > > > "git branch -r" perhaps. > > That's pretty good. It makes things like > > git-log remotes/origin/master..master > > A bit long winded, but it's certainly what I asked for. > > You guys really have thought of everything. Try the bash completion support in contrib/completion. If you are using the bash shell it does branch name completions for most commands, including both sides of the '..' in log there. At this point I can't use Git without it. -- ``` ## Junio C Hamano, 2006-10-25 22:20 Subject: Re: (unknown) Message-ID: <7vwt6okpgr.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwt6okpgr.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v1wowm46j.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Andy Parkins writes: > >> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote: >> >>> > I did try that, but then the branches don't appear in git branch. I >>> > still like that they exist. >>> >>> "git branch -r" perhaps. >> >> That's pretty good. It makes things like >> >> git-log remotes/origin/master..master >> >> A bit long winded, but it's certainly what I asked for. > > "git log remotes/origin..master" perhaps? > > The point being, remotes/origin when origin is a directory that > has HEAD that points at something, it stands for > remotes/origin/HEAD. Heh, I spoke too fast. "git log origin..master" If you do not have none of .git/origin, .git/refs/origin, .git/refs/tags/origin, .git/refs/heads/origin, nor .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is what "origin" means (see get_sha1_basic() in sha1_name.c). ``` ## Andy Parkins, 2006-10-26 07:14 Subject: Re: (unknown) Message-ID: <200610260814.05957.andyparkins@gmail.com> URL: https://gitlist.dev/e/200610260814.05957.andyparkins%40gmail.com In-Reply-To: <7vwt6okpgr.fsf@assigned-by-dhcp.cox.net> ``` > > "git log remotes/origin..master" perhaps? > > > > The point being, remotes/origin when origin is a directory that > > has HEAD that points at something, it stands for > > remotes/origin/HEAD. > > Heh, I spoke too fast. > > "git log origin..master" > > If you do not have none of .git/origin, .git/refs/origin, > .git/refs/tags/origin, .git/refs/heads/origin, nor > .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is > what "origin" means (see get_sha1_basic() in sha1_name.c). Again: you guys have thought of everything. I believe then, that my problem is that I didn't find this written anywhere - would it be useful if I were to write a Documentation/ file about commit-ish/tree-ish that covered these issues? Have I overlooked the existence of such a file already? Andy -- Dr Andy Parkins, M Eng (hons), MIEE ``` ## Junio C Hamano, 2006-10-26 08:17 Subject: [PATCH] Documentation: clarify refname disambiguation rules. Message-ID: <7vhcxrqynx.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhcxrqynx.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <200610260814.05957.andyparkins@gmail.com> ``` Nobody should create ambiguous refs (i.e. have tag "foobar" and branch "foobar" at the same time) that need to be disambiguated with these rules to keep sanity, but the rules are there so document them. Signed-off-by: Junio C Hamano --- >> Heh, I spoke too fast. >> >> "git log origin..master" >> >> If you do not have none of .git/origin, .git/refs/origin, >> .git/refs/tags/origin, .git/refs/heads/origin, nor >> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is >> what "origin" means (see get_sha1_basic() in sha1_name.c). Something like this. Documentation/git-rev-parse.txt | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 5d42570..ed938aa 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -122,14 +122,30 @@ blobs contained in a commit. your repository whose object name starts with dae86e. * An output from `git-describe`; i.e. a closest tag, followed by a - dash, a 'g', and an abbreviated object name. + dash, a `g`, and an abbreviated object name. * A symbolic ref name. E.g. 'master' typically means the commit object referenced by $GIT_DIR/refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say 'heads/master' to tell git which one you mean. + When ambiguous, a `` is disambiguated by taking the + first match in the following rules: -* A suffix '@' followed by a date specification enclosed in a brace + . if `$GIT_DIR/` exists, that is what you mean (this is usually + useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`); + + . otherwise, `$GIT_DIR/refs/` if exists; + + . otherwise, `$GIT_DIR/refs/tags/` if exists; + + . otherwise, `$GIT_DIR/refs/heads/` if exists; + + . otherwise, `$GIT_DIR/refs/remotes/` if exists; + + . otherwise, `$GIT_DIR/refs/remotes//HEAD` if exists. + +* A ref followed by the suffix '@' with a date specification + enclosed in a brace pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1 second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value of the ref at a prior point in time. This suffix may only be @@ -146,8 +162,9 @@ blobs contained in a commit. * A suffix '{tilde}' to a revision parameter means the commit object that is the th generation grand-parent of the named commit object, following only the first parent. I.e. rev~3 is - equivalent to rev{caret}{caret}{caret} which is equivalent to\ - rev{caret}1{caret}1{caret}1. + equivalent to rev{caret}{caret}{caret} which is equivalent to + rev{caret}1{caret}1{caret}1. See below for a illustration of + the usage of this form. * A suffix '{caret}' followed by an object type name enclosed in brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object -- 1.4.3.3.g43f1 ``` ## Jakub Narebski, 2006-10-26 08:40 Subject: Re: [PATCH] Documentation: clarify refname disambiguation rules. Message-ID: URL: https://gitlist.dev/e/ehps96%245b2%241%40sea.gmane.org In-Reply-To: <7vhcxrqynx.fsf_-_@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > -* A suffix '@' followed by a date specification enclosed in a brace [...] > +* A ref followed by the suffix '@' with a date specification > +  enclosed in a brace >    pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1 This introduces strange line breaking. Is it only in source? Here diff didn't produce optimal for review patch, separating changed from part and changed to part with large block of added code. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Josef Weidendorfer, 2006-10-26 13:22 Subject: Re: (unknown) Message-ID: <200610261522.44433.Josef.Weidendorfer@gmx.de> URL: https://gitlist.dev/e/200610261522.44433.Josef.Weidendorfer%40gmx.de In-Reply-To: <7vwt6okpgr.fsf@assigned-by-dhcp.cox.net> ``` On Thursday 26 October 2006 00:20, Junio C Hamano wrote: > Heh, I spoke too fast. > > "git log origin..master" > > If you do not have none of .git/origin Really? I thought refs are always looked up in ".git/refs" only? > , .git/refs/origin, > .git/refs/tags/origin, .git/refs/heads/origin, nor > .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is > what "origin" means (see get_sha1_basic() in sha1_name.c). Yes. However, IMHO it really should be a alias to "remotes/origin/", depending on current "" you are on. AFAI can remember, when implementing it, HEAD was choosen as sha1_name.c should not cope with porcelain issues (e.g. getting current branch name). It was the intention to change remotes/origin/HEAD in the porcelain command before actual use. Is this still sensible? ``` ## Linus Torvalds, 2006-10-26 15:35 Subject: Re: (unknown) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0610260825040.3962%40g5.osdl.org In-Reply-To: <200610261522.44433.Josef.Weidendorfer@gmx.de> ``` On Thu, 26 Oct 2006, Josef Weidendorfer wrote: > On Thursday 26 October 2006 00:20, Junio C Hamano wrote: > > Heh, I spoke too fast. > > > > "git log origin..master" > > > > If you do not have none of .git/origin > > Really? I thought refs are always looked up in ".git/refs" only? Yes and no. The "iterate over all refs" code only ever looks in the "refs" subdirectory, so when you _list_ refs, they won't ever be shown unless they are there. That affects a lot of programs (like "git ls-remote"). Also, a symlink-ref has to point into "refs/" or it is considered invalid. But, there are two extra rules: - ".git/HEAD" is obviously special, and will show up separately even for things like "git ls-remote", so even processes that _list_ things will show it. - when you do a named lookup, stuff directly in ".git" will take precedence over EVERYTHING, even if it is never listed. So for example, if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't matter. Your ".git/HEAD" will still be looked up first. Similarly, other "special heads", like ORIG_HEAD or MERGE_HEAD will be looked up in .git, even though they will never be listed by anything. So the "refs/" requirement is a real requirement for a "true ref", but it is still overruled by the rule that we have special refs in $GIT_DIR that always take precedence. This also means, for example, that you can always give the "full" refname for lookup, ie git-rev-parse refs/heads/master works, because that's the "full path" from the ".git" subdirectory. If we only ever looked things up inside "refs", you'd have to use "heads/master". ```