threads / patch / 8620

patchCloning from a repo without "current branch"

Subject: [PATCH] Cloning from a repo without "current branch"

## tl;dr

8 messages between Jun 16, 2007 and Jun 22, 2007. Diffs are folded; open one to read it.

replies: 7people: 4as markdown or json

Nanako Shiraishi· Jun 16, 2007, 22:26 UTC · lore

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 <nanako3@bluebottle.com>
Show changes to git-clone.sh +13 −7
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· Jun 17, 2007, 03:41 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Cloning from a repo without "current branch"

Nanako Shiraishi <nanako3@bluebottle.com> writes:
Show 19 quoted lines
> 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?
Show 21 quoted lines
> @@ -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...?
Show 10 quoted lines
> +	'')
> +		# 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· Jun 20, 2007, 21:50 UTC · re: Junio C Hamano · lore

Re: [PATCH] Cloning from a repo without "current branch"

Quoting Junio C Hamano <gitster@pobox.com>:
Show 13 quoted lines
> Nanako Shiraishi <nanako3@bluebottle.com> 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· Jun 20, 2007, 22:29 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Cloning from a repo without "current branch"

Nanako Shiraishi <nanako3@bluebottle.com> writes:
Show 18 quoted lines
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Nanako Shiraishi <nanako3@bluebottle.com> 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· Jun 21, 2007, 05:01 UTC · lore

Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"

Junio C Hamano <gitster@pobox.com> 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.
...
Show 14 quoted lines
> 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· Jun 21, 2007, 19:39 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"

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· Jun 21, 2007, 19:47 UTC · re: Linus Torvalds · lore

Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"

On Thu, 21 Jun 2007, Linus Torvalds wrote:
Show 9 quoted lines
> 
> 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· Jun 22, 2007, 03:34 UTC · re: Linus Torvalds · lore

Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 17 quoted lines
> 
> 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.

← back to recent threads