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

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

[Nanako Shiraishi]

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>


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

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@bluebottle.com> 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

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

[Nanako Shiraishi]

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?

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@bluebottle.com> writes:

> 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.

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

[Shawn O. Pearce]

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.
...
> 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.

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

[Linus Torvalds]

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

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

[Linus Torvalds]

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

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

[Shawn O. Pearce]

Linus Torvalds <torvalds@linux-foundation.org> 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.