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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Junio C Hamano <junkio@xxxxxxx> 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.

> 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


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]