threads / discuss / 30679

Re: GIT PULL] ext4 updates for 3.5

Subject: Re: GIT PULL] ext4 updates for 3.5

## tl;dr

8 messages between Jun 1, 2012 and Jun 1, 2012.

replies: 7people: 3as markdown or json

Linus Torvalds· Jun 1, 2012, 17:56 UTC · lore

On Fri, Jun 1, 2012 at 10:43 AM, Ted Ts'o <tytso@mit.edu> wrote:

>
> So I should do "git request-pull origin git://... ext4_for_linus" next
> time, right?

Right.

> Sorry about that.  I thought it had included the reference to tag
> automatically since the text of the tag showed in the request-pull
> text.

Apparently git request-pull is too damn smart for its own good, and will find the tags even when they aren't mentioned, making you think it made it to me. Bot it doesn't - so then I have to go search for them by hand.

Added Junio and git to the cc: if git finds the tag and uses that for the request-pull message text, then it should use the tagname for the pull request line too. Or, alternatively, don't be smart at all, and force users to name the tag explicitly. The current "both smart and dumb" combination seems to be the worst of both world.

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Junio C Hamano· Jun 1, 2012, 18:55 UTC · re: Linus Torvalds · lore

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Apparently git request-pull is too damn smart for its own good, and
> will find the tags even when they aren't mentioned, making you think
> it made it to me. Bot it doesn't - so then I have to go search for
> them by hand.

Something like this, perhaps.

 git-request-pull.sh | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index e6438e2..5ca786e 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -57,9 +57,13 @@ headrev=$(git rev-parse --verify "$head"^0) || exit
 merge_base=$(git merge-base $baserev $headrev) ||
 die "fatal: No commits in common between $base and $head"
 
-# $head is the token given from the command line. If a ref with that
-# name exists at the remote and their values match, we should use it.
-# Otherwise find a ref that matches $headrev.
+# $head is the token given from the command line, and $tag_name, if
+# exists, is the tag we are going to show the commit information for.
+# If that tag exists at the remote and it points at the commit, use it.
+# Otherwise, if a branch with the same name as $head exists at the remote
+# and their values match, use that instead.
+#
+# Otherwise find a random ref that matches $headrev.
 find_matching_ref='
 	sub abbr {
 		my $ref = shift;
@@ -70,24 +74,29 @@ find_matching_ref='
 		}
 	}
 
-	my ($exact, $found);
+	my ($tagged, $branch, $found);
 	while (<STDIN>) {
 		my ($sha1, $ref, $deref) = /^(\S+)\s+(\S+?)(\^\{\})?$/;
 		next unless ($sha1 eq $ARGV[1]);
 		$found = abbr($ref);
+		if ($deref) {
+			$tagged = $found;
+			last;
+		}
 		if ($ref =~ m|/\Q$ARGV[0]\E$|) {
 			$exact = $found;
-			last;
 		}
 	}
-	if ($exact) {
+	if ($tagged) {
+		print "$tagged\n";
+	} elsif ($exact) {
 		print "$exact\n";
 	} elsif ($found) {
 		print "$found\n";
 	}
 '
 
-ref=$(git ls-remote "$url" | perl -e "$find_matching_ref" "$head" "$headrev")
+ref=$(git ls-remote "$url" | perl -e "$find_matching_ref" "$head" "$headrev" "$tag_name")
 
 url=$(git ls-remote --get-url "$url")

Junio C Hamano· Jun 1, 2012, 19:00 UTC · re: Junio C Hamano · lore

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> +# $head is the token given from the command line, and $tag_name, if
> +# exists, is the tag we are going to show the commit information for.
> +# If that tag exists at the remote and it points at the commit, use it.
> +# Otherwise, if a branch with the same name as $head exists at the remote
> +# and their values match, use that instead.
> +#
> +# Otherwise find a random ref that matches $headrev.

It may also be a good idea to add something like:

	if test -n "$tag_name" && test "tags/$tag_name" != "$ref"
        then
		echo "warning: have you really pushed the tag yet???"
	fi

somewhere near we show "cat-file tag $tag_name" information in the output.

Linus Torvalds· Jun 1, 2012, 19:02 UTC · re: Junio C Hamano · lore

On Fri, Jun 1, 2012 at 12:00 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

>
> It may also be a good idea to add something like:
>
>        if test -n "$tag_name" && test "tags/$tag_name" != "$ref"
>        then
>                echo "warning: have you really pushed the tag yet???"
>        fi
>
> somewhere near we show "cat-file tag $tag_name" information in the
> output.

Ack.

          Linus

Ted Ts'o· Jun 1, 2012, 20:38 UTC · re: Junio C Hamano · lore

One other thought. One of the reasons why I used "dev" and not "ext4_for_linus" in my git request-pull command line was because that several months ago I had created a branch called ext4_for_linus, and I hadn't gotten around to deleting it, so I figured I'd just use "dev" instead, since it was non-ambiguous.

If there is a case where there is both tag and a branch with the same name, it might be a good idea for request-pull not just to issue a warning, since the user might not notice the warning, but to just abort --- and make the user explicitly type refs/tags/ext4_for_linus or refs/heads/ext4_for_linus.

Most of the time if the user ignores the warning about the ambiguity, it's not such a big deal, but in the case of a pull-request, he or she is going to be possibly embarassing themself publically, so it might be better to explicitly list the reason why a non-qualified refname is ambiguous and force the user to pick the right one.

It's a minor point, and usually I double check the commit id in the pull request just to be sure, so it might be considered too much of coddling the user, but it might be a good safety check to add.

						- Ted

Linus Torvalds· Jun 1, 2012, 20:43 UTC · re: Ted Ts'o · lore

On Fri, Jun 1, 2012 at 1:38 PM, Ted Ts'o <tytso@mit.edu> wrote:

Show 5 quoted lines

> One other thought.  One of the reasons why I used "dev" and not
> "ext4_for_linus" in my git request-pull command line was because that
> several months ago I had created a branch called ext4_for_linus, and I
> hadn't gotten around to deleting it, so I figured I'd just use "dev"
> instead, since it was non-ambiguous.

You can always just use "tags/xyzzy" to disambiguate..

                  Linus

Ted Ts'o· Jun 1, 2012, 20:52 UTC · re: Linus Torvalds · lore

On Fri, Jun 01, 2012 at 01:43:35PM -0700, Linus Torvalds wrote:

Show 8 quoted lines

> On Fri, Jun 1, 2012 at 1:38 PM, Ted Ts'o <tytso@mit.edu> wrote:
> > One other thought.  One of the reasons why I used "dev" and not
> > "ext4_for_linus" in my git request-pull command line was because that
> > several months ago I had created a branch called ext4_for_linus, and I
> > hadn't gotten around to deleting it, so I figured I'd just use "dev"
> > instead, since it was non-ambiguous.
> 
> You can always just use "tags/xyzzy" to disambiguate..

Ah, I thought you always had to type the full "refs/tags/.." specification. I didn't realize it did substring matching. Besides, "dev" was much shorter and easier to type. :-)

One of the things which is easy for a novice to miss is the "warning: ext4_for_linus is ambiguous" message, though. And I suspect many novices don't know about the "git show-refs -a | grep ambiguous_tag" trick to figure out where the ambiguity is coming from. So if we are going to give a warning, it might be good if we actually told the user what were the other choices, and which choice git was going to choose. Most of the time it seems to choose the right thing, but trusting computer programs to choose the right answer from something ambiguous via some hueristic always scares the bejesus out of me....

    	 	   	  	     	     - Ted

Junio C Hamano· Jun 1, 2012, 20:52 UTC · re: Linus Torvalds · lore

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 8 quoted lines

> On Fri, Jun 1, 2012 at 1:38 PM, Ted Ts'o <tytso@mit.edu> wrote:
>> One other thought.  One of the reasons why I used "dev" and not
>> "ext4_for_linus" in my git request-pull command line was because that
>> several months ago I had created a branch called ext4_for_linus, and I
>> hadn't gotten around to deleting it, so I figured I'd just use "dev"
>> instead, since it was non-ambiguous.
>
> You can always just use "tags/xyzzy" to disambiguate..

Not only that, the "look at the ls-remote output and guess what you are teeling the recipient to pull" code gives tags/ext4_for_linus even if there is not ext4-for-linus branch; if I recall correctly we did this on purpose so that older git that did not DWIM "git pull ext4_for_linus" to look at targs/ext4_for_linus.