# [PATCH] Cloning from a repo without "current branch" 8 messages from 2007-06-16 to 2007-06-22. Participants: Nanako Shiraishi, Junio C Hamano, Shawn O. Pearce, Linus Torvalds. Thread: https://gitlist.dev/t/8620 ## Nanako Shiraishi, 2007-06-16 22:26 Subject: [PATCH] Cloning from a repo without "current branch" Message-ID: <200706162226.l5GMQBss004492@mi0.bluebottle.com> URL: https://gitlist.dev/e/200706162226.l5GMQBss004492%40mi0.bluebottle.com ``` If the remote repository does not have a "current branch", git-clone was confused and did not set up the resulting new repository correctly. It did not reset HEAD from the default 'master', and did not write the SHA1 to the master branch. Signed-off-by: Nanako Shiraishi diff --git a/git-clone.sh b/git-clone.sh index 3a41062..bd44ce1 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -377,6 +377,13 @@ then ) ) + # Upstream URL + git-config remote."$origin".url "$repo" && + + # Set up the mappings to track the remote branches. + git-config remote."$origin".fetch \ + "+refs/heads/*:$remote_top/*" '^$' && + # Write out remote.$origin config, and update our "$head_points_at". case "$head_points_at" in ?*) @@ -384,21 +391,20 @@ then git-symbolic-ref HEAD "refs/heads/$head_points_at" && # Tracking branch for the primary branch at the remote. - origin_track="$remote_top/$head_points_at" && git-update-ref HEAD "$head_sha1" && - # Upstream URL - git-config remote."$origin".url "$repo" && - - # Set up the mappings to track the remote branches. - git-config remote."$origin".fetch \ - "+refs/heads/*:$remote_top/*" '^$' && rm -f "refs/remotes/$origin/HEAD" git-symbolic-ref "refs/remotes/$origin/HEAD" \ "refs/remotes/$origin/$head_points_at" && git-config branch."$head_points_at".remote "$origin" && git-config branch."$head_points_at".merge "refs/heads/$head_points_at" + ;; + '') + # Source had detached HEAD pointing nowhere + git-update-ref --no-deref HEAD "$head_sha1" && + rm -f "refs/remotes/$origin/HEAD" + ;; esac case "$no_checkout" in -- 1.5.2 ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com ``` ## Junio C Hamano, 2007-06-17 03:41 Subject: Re: [PATCH] Cloning from a repo without "current branch" Message-ID: <7vbqff1c3w.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7vbqff1c3w.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <200706162226.l5GMQBss004492@mi0.bluebottle.com> ``` Nanako Shiraishi writes: > diff --git a/git-clone.sh b/git-clone.sh > index 3a41062..bd44ce1 100755 > --- a/git-clone.sh > +++ b/git-clone.sh > @@ -377,6 +377,13 @@ then > ) > ) > > + # Upstream URL > + git-config remote."$origin".url "$repo" && > + > + # Set up the mappings to track the remote branches. > + git-config remote."$origin".fetch \ > + "+refs/heads/*:$remote_top/*" '^$' && > + > # Write out remote.$origin config, and update our > "$head_points_at". > case "$head_points_at" in > ?*) Whitespace breakage? > @@ -384,21 +391,20 @@ then > git-symbolic-ref HEAD "refs/heads/$head_points_at" && > > # Tracking branch for the primary branch at the remote. > - origin_track="$remote_top/$head_points_at" && > git-update-ref HEAD "$head_sha1" && > > - # Upstream URL > - git-config remote."$origin".url "$repo" && > - > - # Set up the mappings to track the remote branches. > - git-config remote."$origin".fetch \ > - "+refs/heads/*:$remote_top/*" '^$' && > rm -f "refs/remotes/$origin/HEAD" > git-symbolic-ref "refs/remotes/$origin/HEAD" \ > "refs/remotes/$origin/$head_points_at" && > > git-config branch."$head_points_at".remote "$origin" && > git-config branch."$head_points_at".merge > "refs/heads/$head_points_at" > + ;; Again...? > + '') > + # Source had detached HEAD pointing nowhere > + git-update-ref --no-deref HEAD "$head_sha1" && > + rm -f "refs/remotes/$origin/HEAD" > + ;; > esac > > case "$no_checkout" in > -- > 1.5.2 ``` ## Nanako Shiraishi, 2007-06-20 21:50 Subject: Re: [PATCH] Cloning from a repo without "current branch" Message-ID: <200706202150.l5KLoHkE002843@mi0.bluebottle.com> URL: https://gitlist.dev/e/200706202150.l5KLoHkE002843%40mi0.bluebottle.com In-Reply-To: <7vbqff1c3w.fsf@assigned-by-dhcp.pobox.com> ``` Quoting Junio C Hamano : > Nanako Shiraishi writes: > > > diff --git a/git-clone.sh b/git-clone.sh > > ?*) > > Whitespace breakage? > > > @@ -384,21 +391,20 @@ then > > git-config branch."$head_points_at".merge > > "refs/heads/$head_points_at" > > + ;; > > Again...? Sorry, I'll re-send from a different mail addr. Is it alright to send attachments? ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com ``` ## Junio C Hamano, 2007-06-20 22:29 Subject: Re: [PATCH] Cloning from a repo without "current branch" Message-ID: <7vwsxy5kfg.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7vwsxy5kfg.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <200706202150.l5KLoHkE002843@mi0.bluebottle.com> ``` Nanako Shiraishi writes: > Quoting Junio C Hamano : > >> Nanako Shiraishi writes: >> >> > diff --git a/git-clone.sh b/git-clone.sh >> > ?*) >> >> Whitespace breakage? >> >> > @@ -384,21 +391,20 @@ then >> > git-config branch."$head_points_at".merge >> > "refs/heads/$head_points_at" >> > + ;; >> >> Again...? > > Sorry, I'll re-send from a different mail addr. > Is it alright to send attachments? Well, the breakage was trivial enough to fix at my end; no need to resend. Thanks for your patch; it is a real fix (well, at least one of the necessary ones) to a breakage we discussed on the list recently. ``` ## Shawn O. Pearce, 2007-06-21 05:01 Subject: Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?" Message-ID: <20070621050117.GF8477@spearce.org> URL: https://gitlist.dev/e/20070621050117.GF8477%40spearce.org In-Reply-To: <7vk5tx5333.fsf@assigned-by-dhcp.pobox.com> ``` Junio C Hamano wrote: > The blame window shows "who wrote the piece originally" and "who > moved it there" in two columns. In order to identify the former > more correctly, it helps to use the new -w option. ... > diff --git a/lib/blame.tcl b/lib/blame.tcl > index 139171d..a412a8c 100644 > --- a/lib/blame.tcl > +++ b/lib/blame.tcl > @@ -672,7 +672,7 @@ method _read_blame {fd cur_w cur_d cur_s} { > close $fd > if {$cur_w eq $w_asim} { > _exec_blame $this $w_amov @amov_data \ > - [list -M -C -C] \ > + [list -w -C -C] \ > { original location} > } else { > set current_fd {} > I've wanted to do this since you introduced `git blame -w`. But I can't use it, because I cannot trust that -w is there. For example it is not in maint, but the new blame viewer from git-gui is. Apply my --list-features patch to core Git and I'll activate -w in git-gui when --list-features claims the 'blame-ignore-whitespace' feature is available. ;-) -- Shawn. ``` ## Linus Torvalds, 2007-06-21 19:39 Subject: Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?" Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0706211237220.3593%40woody.linux-foundation.org In-Reply-To: <20070621050117.GF8477@spearce.org> ``` On Thu, 21 Jun 2007, Shawn O. Pearce wrote: > > I've wanted to do this since you introduced `git blame -w`. But I > can't use it, because I cannot trust that -w is there. For example > it is not in maint, but the new blame viewer from git-gui is. Actually, I think there's a different fundamental problem, namely that git-gui doesn't seem to accept parameters. I'd personally rather *not* have git-gui make the -w/-M/-C choice for me. Why don't you just allow the user to say? Sometimes I might want to see who introduced broken whitespace. Let me say git gui blame -w filename.c please? Instead of making that choice for me, and then blaming git for something that wasn't git's problem. Linus ``` ## Linus Torvalds, 2007-06-21 19:47 Subject: Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?" Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0706211243400.3593%40woody.linux-foundation.org In-Reply-To: ``` On Thu, 21 Jun 2007, Linus Torvalds wrote: > > I'd personally rather *not* have git-gui make the -w/-M/-C choice for me. > Why don't you just allow the user to say? Sometimes I might want to see > who introduced broken whitespace. Let me say > > git gui blame -w filename.c > > please? Instead of making that choice for me, and then blaming git for > something that wasn't git's problem. Side note - this ended up being one reason why "gitk" is so good. It just passed down the arguments to "git-rev-list", and it allowed me to improve on the original gitk without gitk ever even _realizing_ it was improved upon. All the pathname filtering etc was done without gitk ever learning about it - it "just worked". Linus ``` ## Shawn O. Pearce, 2007-06-22 03:34 Subject: Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?" Message-ID: <20070622033456.GB17393@spearce.org> URL: https://gitlist.dev/e/20070622033456.GB17393%40spearce.org In-Reply-To: ``` Linus Torvalds wrote: > > On Thu, 21 Jun 2007, Linus Torvalds wrote: > > > > I'd personally rather *not* have git-gui make the -w/-M/-C choice for me. > > Why don't you just allow the user to say? Sometimes I might want to see > > who introduced broken whitespace. Let me say > > > > git gui blame -w filename.c > > > > please? Instead of making that choice for me, and then blaming git for > > something that wasn't git's problem. > > Side note - this ended up being one reason why "gitk" is so good. It just > passed down the arguments to "git-rev-list", and it allowed me to improve > on the original gitk without gitk ever even _realizing_ it was improved > upon. All the pathname filtering etc was done without gitk ever learning > about it - it "just worked". Hmm. Good point about gitk. We all know you would rather not hack Tcl to enhance tools, because you would prefer to work directly in C. A lot of the stuff rev-list does in pure C does translate directly into gitk, and its one of the features that I also love most about gitk. Except --reverse; gitk doesn't really like to do `gitk --reverse --all`. But it can be extremely amusing to run if you are bored and have time to waste. However. The new blame viewer supports two columns, and runs two blame passes to obtain the information for them. I like that, because it offers up a lot of information in a single compact view. Which column do I send the option(s) to? Do I let the user specify which column to apply the options onto? git gui blame --left='-C -C' --right= filename.c ;# default git gui blame --left=-w --right=-M filename.c ;# not default ? Or do I only show one column if the user supplies command line options? Doesn't that limit the tool? -- Shawn. ```