Re: What's in git.git (stable)

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Dec 26, 2006, 20:25 UTC
Message-ID: <418215.90592.qm@web31809.mail.mud.yahoo.com>
In-Reply-To: <7vac1fy5ae.fsf@assigned-by-dhcp.cox.net>

--- Junio C Hamano <junkio@cox.net> wrote:

> I am not quite sure about that.  An old timer would work in a
> newly cloned repository after all, and what this "newbie
> protection" is breaking is not existing repositories but
> expectation from existing users.

Hmm, "newbie protection" doesn't sound good. It sounds like "screw the old-timers and let's change well-established workflow".

The expectation is that one always pulls into origin, merges into master, and maybe checks out master to see the remote master. From then on, they decide what, where and how to merge (from) master into any local branches, and then eventually export local branches to the public.

The "^branch.\.*" options seem to be counter-intuitive to
1) git's behavor and 2) see above.

Generally "pulling" a remote master in a local branch, without the local "origin+master" being fast-forwarded/merged should be considered non-git-conformant behavior. Assuming that the local branch is a branch of master/origin, which is almost ever the case.

Show 28 quoted lines

> In any case, here is a patch for discussion.
> 
> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index f163821..b4d071b 100755
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
>  			merge_branches=$(git-repo-config \
>  			    --get-all "branch.${curr_branch}.merge")
>  		fi
> -		# If we are fetching only one branch, then first branch
> -		# is the only thing that makes sense to merge anyway,
> -		# so there is no point refusing that traditional rule.
> -		if test $# != 1 && test "z$merge_branches" = z
> +		if test "z$merge_branches" = z &&
> +			# If we are fetching only one branch, then
> +			# first branch is the only thing that makes
> +			# sense to merge anyway, so there is no point
> +			# refusing that traditional rule.
> +			test $# != 1 &&
> +
> +			# Also, old timers have been happily working
> +			# with the first branch rule without having
> +			# any branch.*.merge configuration, so if
> +			# there is none, do not bother with this
> +			# "newbie protection".  A newly cloned
> +			# repository would have branch.master.merge
> +			# set for it.

It should probably have branch.*.remote _and_ branch.*.merge set for completeness. Or we should remove the branch.* options from git-config and leave this up to porcelains.

> +			git repo-config --get-regexp \
> +				'^branch\..*\.merge$' >/dev/null

How does this "set" it?

    Luben

>  		then
>  			merge_branches=..this..would..never..match..
>  		fi