# What's in git.git (stable) 20 messages from 2006-12-22 to 2006-12-27. Participants: Junio C Hamano, Randal L. Schwartz, Johannes Schindelin, Jakub Narebski, Quy Tonthat, Luben Tuikov. Thread: https://gitlist.dev/t/6075 ## Junio C Hamano, 2006-12-22 09:25 Subject: What's in git.git (stable) Message-ID: <7vodpw46zj.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vodpw46zj.fsf%40assigned-by-dhcp.cox.net ``` I guess I'll need to push another maintenance release out soon, if only to fix the manual pages. On the 'master' front there are a handful more topics pushed out from 'next'. I still need to apply the __FREEBSD__ fix yet, but otherwise we should be able to start calming things down. * The 'maint' branch has these fixes since the last announcement. Johannes Schindelin (1): diff --check: fix off by one error Junio C Hamano (1): spurious .sp in manpages * The 'master' branch has these since the last announcement. Eric Wong (3): git-svn: convert to using Git.pm git-svn: remove support for the svn command-line client git-svn: rename 'commit' command to 'set-tree' Johannes Schindelin (5): Introduce GIT_TEMPLATE_DIR diff --check: fix off by one error Use git-merge-file in git-merge-one-file, too git-tag: support -F option git-reset --hard: tell the user what the HEAD was reset to Josef Weidendorfer (1): Move "no merge candidate" warning into git-pull Junio C Hamano (22): git-clone: use wildcard specification for tracking branches git-pull: refuse default merge without branch.*.merge git-clone: lose the artificial "first" fetch refspec git-clone: lose the traditional 'no-separate-remote' layout rev-list --left-right Teach all of log family --left-right output. Make left-right automatic. fix testsuite: make sure they use templates freshly built from the source Teach git-branch to delete tracking branches with -r -d blame: -b (blame.blankboundary) and --root (blame.showroot) Revert "fix testsuite: make sure they use templates freshly built from the source" Do not create $GIT_DIR/remotes/ directory anymore. Use preprocessor constants for environment variable names. Revert "Make left-right automatic." git-add: error out when given no arguments. spurious .sp in manpages compat/inet_ntop: do not use u_int diff documentation: mostly talk about Revert "git-pull: refuse default merge without branch.*.merge" parse-remote: mark all refs not for merge only when fetching more than one _XOPEN_SOURCE problem also exists on FreeBSD commit-tree: do not overflow MAXPARENT Quy Tonthat (2): git-branch -d: do not stop at the first failure. Documentation/git-branch: new -r to delete remote-tracking branches. Shawn Pearce (3): Suggest 'add' in am/revert/cherry-pick. Rename imap-send's internal info/warn functions. Introduce a global level warn() function. Terje Sten Bjerkseth (1): Fix system header problems on Mac OS X ``` ## Randal L. Schwartz, 2006-12-22 17:15 Subject: Re: What's in git.git (stable) Message-ID: <86k60jsvh8.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86k60jsvh8.fsf%40blue.stonehenge.com In-Reply-To: <7vodpw46zj.fsf@assigned-by-dhcp.cox.net> ``` >>>>> "Junio" == Junio C Hamano writes: Junio> git-pull: refuse default merge without branch.*.merge Argh. How do I get back the old behavior? "git-pull origin" doesn't seem to be enough. You just broke a bunch of automated scripts for me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ``` ## Randal L. Schwartz, 2006-12-22 17:19 Subject: Re: What's in git.git (stable) Message-ID: <86fyb7sv9f.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86fyb7sv9f.fsf%40blue.stonehenge.com In-Reply-To: <86k60jsvh8.fsf@blue.stonehenge.com> ``` >>>>> "Randal" == Randal L Schwartz writes: >>>>> "Junio" == Junio C Hamano writes: Junio> git-pull: refuse default merge without branch.*.merge Randal> Argh. How do I get back the old behavior? Randal> "git-pull origin" doesn't seem to be enough. Randal> You just broke a bunch of automated scripts for me. Ahh, it's "git-pull . origin". Maybe a bit more warning for non-upward-compatible changes though, please. Or maybe we should presume everything is non-upward compatible? I didn't think a naked "git-pull" was that out of the ordinary. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ``` ## Johannes Schindelin, 2006-12-22 18:09 Subject: Re: What's in git.git (stable) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612221902490.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <86fyb7sv9f.fsf@blue.stonehenge.com> ``` Hi, On Fri, 22 Dec 2006, Randal L. Schwartz wrote: > >>>>> "Randal" == Randal L Schwartz writes: > > >>>>> "Junio" == Junio C Hamano writes: > Junio> git-pull: refuse default merge without branch.*.merge > > Randal> Argh. How do I get back the old behavior? > Randal> "git-pull origin" doesn't seem to be enough. Maybe "git-pull origin master"? > Randal> You just broke a bunch of automated scripts for me. > > Ahh, it's "git-pull . origin". This is just a merge, not a real pull (it leaves out the fetch part). > Maybe a bit more warning for non-upward-compatible changes though, > please. It is unfortunate that this change broke your scripts. But I really think that the new behaviour is much saner: If you have different branches, you probably do not want to pull the _same_ remote branch into _all_ of them. So, for each branch (e.g. "xyz") for which you have a preferred upstream (e.g. remote "linus" with branch "master"), say $ git repo-config branch.xyz.remote linus $ git repo-config branch.xyz.merge refs/heads/master Then, $ git pull pulls your preferred upstream. But when you pull from another remote, or into another branch, without specifying which remote branch you want to pull, git now refuses to blindly pull branch "master". This should prevent quite some pilot errors. Ciao, Dscho ``` ## Randal L. Schwartz, 2006-12-22 18:12 Subject: Re: What's in git.git (stable) Message-ID: <861wmrsstc.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/861wmrsstc.fsf%40blue.stonehenge.com In-Reply-To: ``` >>>>> "Johannes" == Johannes Schindelin writes: >> Ahh, it's "git-pull . origin". Johannes> This is just a merge, not a real pull (it leaves out the fetch part). OK, so what does what a naked "git-pull" used to do before, which was "fetch origin, then pull it into the current branch"? Johannes> So, for each branch (e.g. "xyz") for which you have a preferred upstream Johannes> (e.g. remote "linus" with branch "master"), say Johannes> $ git repo-config branch.xyz.remote linus Johannes> $ git repo-config branch.xyz.merge refs/heads/master But that's not upward compatible. The default should be the old behavior, or we need a better way to notify people that this breaks things. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ``` ## Randal L. Schwartz, 2006-12-22 18:21 Subject: Re: What's in git.git (stable) Message-ID: <86wt4jrdu6.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86wt4jrdu6.fsf%40blue.stonehenge.com In-Reply-To: <861wmrsstc.fsf@blue.stonehenge.com> ``` >>>>> "Randal" == Randal L Schwartz writes: Randal> But that's not upward compatible. The default should be the old behavior, Randal> or we need a better way to notify people that this breaks things. Not to mention that the manpage still says: git pull, git pull origin Fetch the default head from the repository you cloned from and merge it into your current branch. So even if I was *looking* for a change in behavior, it wasn't documented. Nothing changed in that area in recent history. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ``` ## Junio C Hamano, 2006-12-22 18:58 Subject: Re: What's in git.git (stable) Message-ID: <7vwt4jzrjb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwt4jzrjb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <86fyb7sv9f.fsf@blue.stonehenge.com> ``` merlyn@stonehenge.com (Randal L. Schwartz) writes: >>>>>> "Randal" == Randal L Schwartz writes: >>>>>> "Junio" == Junio C Hamano writes: > Junio> git-pull: refuse default merge without branch.*.merge > > Randal> Argh. How do I get back the old behavior? > Randal> "git-pull origin" doesn't seem to be enough. > > Randal> You just broke a bunch of automated scripts for me. > > Ahh, it's "git-pull . origin". > > Maybe a bit more warning for non-upward-compatible changes though, please. > > Or maybe we should presume everything is non-upward compatible? I didn't > think a naked "git-pull" was that out of the ordinary. Things are supposed to be upward compatible, but this round until v1.5.0 some things may not be when it is justifiably an improvement. For example, we've already made 'separate remote' not only the default but the only layout 'git clone' produces. I cannot think of others offhand, but I am reasonably certain there are others. We need a "incompatible changes" list. The tradtional "pull always merges the first set of branches" rule, although I was actually very much in favor of it, was something that was hated by everybody. It was said that people had lot of trouble after doing "git pull origin" without any refspecs ("git pull" without any argument defaults to 'origin' which is backward compatible, if you do not have branch.*.remote, so that form has the same issues), when on a branch other than the 'master' branch. "merges the same first set of branches no matter which branch you are on" was the rule, but people did not want to merge the ones they usually merge to their 'master' but wanted some other branch merged. "branch.*.merge" can be used to specify this, but if you do not have need for this "merge different branches depending on which branch I am on", you do not have to use it. Without "branch.*.merge" for the current branch, we are still backward compatible and follow the "first set of branches" rule. The real trouble is that some people further argued that pulling without 'branch.*.merge' when you might not want to follow the "first set of branches" rule might be a newbie mistake and should be warned and forbidden. The commit that broke you was an attempt for that behaviour. I think that newbie protection intent is good, but the execution was obviously not. What I have on 'master' has a little fixup to use 'first set of branches' rule when the fetch gets only one branch without complaining. I am still not happy with that either, and at this point I am not sure if there is a good compromise that does not break existing setup while offering the newbie protection. Possibilities: (1) Forget about that "protection" business. If you do not want mistakes, use 'branch.*.merge' but otherwise we will continue to follow the good old "first set of branches" rule. (2) A slight variant of the above; do the "protection" only when 'branch.*.merge' is defined for _any_ of the branches, not just the current branch. (3) A further variant; do not do the above "protection" if the current branch is 'master' (this further makes 'master' special, which some people may hate). ``` ## Johannes Schindelin, 2006-12-22 19:21 Subject: Re: What's in git.git (stable) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612221949490.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <861wmrsstc.fsf@blue.stonehenge.com> ``` Hi, On Fri, 22 Dec 2006, Randal L. Schwartz wrote: > >>>>> "Johannes" == Johannes Schindelin > >>>>> writes: > > >> Ahh, it's "git-pull . origin". > > Johannes> This is just a merge, not a real pull (it leaves out the fetch > Johannes> part). > > OK, so what does what a naked "git-pull" used to do before, which was > "fetch origin, then pull it into the current branch"? $ git repo-config branch.xyz.remote origin $ git repo-config branch.xyz.merge refs/heads/ > Johannes> So, for each branch (e.g. "xyz") for which you have a > Johannes> preferred upstream (e.g. remote "linus" with branch > Johannes> "master"), say > > Johannes> $ git repo-config branch.xyz.remote linus > Johannes> $ git repo-config branch.xyz.merge refs/heads/master > > But that's not upward compatible. The default should be the old > behavior, or we need a better way to notify people that this breaks > things. AFAIK it is not in maint. Not even in 1.4.4.3. So, you got it with master. So, TFA should have been in a message "What's in git (stable)". Alas, the commit a71fb0a1: "git-pull: refuse default merge without branch.*.merge" was merged _after_ the latest announcement. HOWEVER, it has been in "What's cooking in git (topics)". Having said that, we could (at least for some time) print a big red warning for the specific case of "git pull" meaning "git pull origin " that this will GO AWAY SOON. Of course, you would not see it. Only your script. BTW I would _never_ allow a script to rely on such a DWIM feature. Ciao, Dscho ``` ## Jakub Narebski, 2006-12-22 20:04 Subject: Re: What's in git.git (stable) Message-ID: URL: https://gitlist.dev/e/emhdir%24he9%241%40sea.gmane.org In-Reply-To: <7vwt4jzrjb.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Possibilities: > >  (1) Forget about that "protection" business.  If you do not >      want mistakes, use 'branch.*.merge' but otherwise we will >      continue to follow the good old "first set of branches" >      rule. What about marking default branch to merge explicitely using "Merge:" in remotes/, or remote..merge? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Junio C Hamano, 2006-12-22 20:13 Subject: Re: What's in git.git (stable) Message-ID: <7virg3zo1k.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7virg3zo1k.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > HOWEVER, it has been in "What's cooking in git (topics)". > > Having said that, we could (at least for some time) print a big red > warning for the specific case of "git pull" meaning "git pull origin > " that this will GO AWAY SOON. > > Of course, you would not see it. Only your script. > > BTW I would _never_ allow a script to rely on such a DWIM feature. That's too strong a statement. It is not DWIM but has been a longstanding rule to use "the first set of branches" for the merge. We've merged the first set of branches since day one, and even after branch.*.merge we've done so unless you do not have such configuration. The complaint (or "newbie protection") was a backward incompatible change, and it was executed poorly. So my apologies go to Merlyn. While many "new features" can be done in backward compatible way, any "newbie protection" can break existing practices -- because the whole point of "protection" is to forbid what once was allowed only because we did not use to check. And when we have something that we check now that we did not check before, that by definition will not be backward compatible. Some backward incompatibilities are more justfiable than others. For example, we recently changed "git add" without argument not to do anything. It used to have the same effect as "git add .", but (1) adding all files in a working tree is a rare event, (2) just a single dot is not hard to type, (3) without argument you will get a response "not doing anything". On the other hand, doing "git add" without argument by mistake and ending up with the index with many unwanted files is more painful and more likely to hapen -- it is more valuable to protect users against it than saving the two keysrokes. That's why I think that change is a justified improvement. I do not think this "merge complaint", at least in the form that lived on 'master', is justifiable. The first one that was merged from the topic made it a requirement to have the branch.*.merge configuration when you do not give explicit refspecs on the command line, which was just outright WRONG. The one currently on the public repository says if the fetch ended up getting only one branch then not having branch.*.merge is Ok, which arguably is an improvement, but I do not think is good enough. I mentioned other possibilities in my earlier message. I also personally think that it is not as clear cut as the "git add" case that "the first set of branches" rule is wrong, but the trouble I caused to Merlyn and Luben primarily comes from the check to trigger "newbie protection", not from what the protection is trying to do. ``` ## Junio C Hamano, 2006-12-22 20:16 Subject: Re: What's in git.git (stable) Message-ID: <7vejqrznwo.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vejqrznwo.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Jakub Narebski writes: > > > Junio C Hamano wrote: > >> Possibilities: >> >>  (1) Forget about that "protection" business.  If you do not >>      want mistakes, use 'branch.*.merge' but otherwise we will >>      continue to follow the good old "first set of branches" >>      rule. > > What about marking default branch to merge explicitely using > "Merge:" in remotes/, or remote..merge? Sorry, how is that an improvement over the current branch.*.merge? and how would that help not breaking existing setups? ``` ## Quy Tonthat, 2006-12-22 20:21 Subject: Re: What's in git.git (stable) Message-ID: <458C3E65.4090807@gmail.com> URL: https://gitlist.dev/e/458C3E65.4090807%40gmail.com In-Reply-To: <7vodpw46zj.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > * The 'master' branch has these since the last announcement. [...] > > Quy Tonthat (2): > ... > Documentation/git-branch: new -r to delete remote-tracking branches. > This one is not there on the 'master' branch. Quy ``` ## Johannes Schindelin, 2006-12-22 20:44 Subject: Re: What's in git.git (stable) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612222141060.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7virg3zo1k.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Fri, 22 Dec 2006, Junio C Hamano wrote: > Johannes Schindelin writes: > > > HOWEVER, it has been in "What's cooking in git (topics)". > > > > Having said that, we could (at least for some time) print a big red > > warning for the specific case of "git pull" meaning "git pull origin > > " that this will GO AWAY SOON. > > > > Of course, you would not see it. Only your script. > > > > BTW I would _never_ allow a script to rely on such a DWIM feature. > > That's too strong a statement. It is not DWIM but has been a > longstanding rule to use "the first set of branches" for the > merge. We've merged the first set of branches since day one, > and even after branch.*.merge we've done so unless you do not > have such configuration. Okay, I have been wrong. My sincere apologies. So, if I understand your option (2) correctly, it complains _only_ if there is at least one branch.*.merge in the config, but not for the current branch? I think that would safeguard the existing repositories _and_ the new ones, because git-clone sets them up with such an entry to begin with. If that behaviour was meant by (2), I am all for it. Ciao, Dscho ``` ## Jakub Narebski, 2006-12-22 20:56 Subject: Re: What's in git.git (stable) Message-ID: <200612222156.21215.jnareb@gmail.com> URL: https://gitlist.dev/e/200612222156.21215.jnareb%40gmail.com In-Reply-To: <7vejqrznwo.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Jakub Narebski writes: > >> >> >> Junio C Hamano wrote: >> >>> Possibilities: >>> >>>  (1) Forget about that "protection" business.  If you do not >>>      want mistakes, use 'branch.*.merge' but otherwise we will >>>      continue to follow the good old "first set of branches" >>>      rule. >> >> What about marking default branch to merge explicitely using >> "Merge:" in remotes/, or remote..merge? > > Sorry, how is that an improvement over the current branch.*.merge? > and how would that help not breaking existing setups? I meant that in addition to forgetting about "protection" business. This would be intermediate improvement over old behavior, marking clearly which is default branch to merge (with first branch still being default, and perhaps error out if there is _only_ wildcard Pull:/fetch line/variable; the branches marked with + are ineligible as candidate for merge with "first branch being default branch to merge" default). Perhaps make "protection" business optional, default to on for new users? -- Jakub Narebski Poland ``` ## Junio C Hamano, 2006-12-22 21:44 Subject: Re: What's in git.git (stable) Message-ID: <7vac1fy5ae.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vac1fy5ae.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > So, if I understand your option (2) correctly, it complains _only_ if > there is at least one branch.*.merge in the config, but not for the > current branch? > > I think that would safeguard the existing repositories _and_ the new ones, > because git-clone sets them up with such an entry to begin with. > > If that behaviour was meant by (2), I am all for it. 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. 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. + git repo-config --get-regexp \ + '^branch\..*\.merge$' >/dev/null then merge_branches=..this..would..never..match.. fi ``` ## Junio C Hamano, 2006-12-22 21:49 Subject: Re: What's in git.git (stable) Message-ID: <7v3b77y52j.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3b77y52j.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200612222156.21215.jnareb@gmail.com> ``` Jakub Narebski writes: > Junio C Hamano wrote: > ... >>>> Possibilities: >>>> >>>>  (1) Forget about that "protection" business.  If you do not >>>>      want mistakes, use 'branch.*.merge' but otherwise we will >>>>      continue to follow the good old "first set of branches" >>>>      rule. >>> >>> What about marking default branch to merge explicitely using >>> "Merge:" in remotes/, or remote..merge? >> >> Sorry, how is that an improvement over the current branch.*.merge? >> and how would that help not breaking existing setups? > > I meant that in addition to forgetting about "protection" business. > This would be intermediate improvement over old behavior. I do not think so. It does not talk about "when on my local branch X do this", and applies to all pulls from the named remote. Then longstanding rule of merging the first set of branches is just fine and as expressive. You see them the first in the list, and you already know they somehow matter more. On the other hand, I think Santi's branch.*.merge (done in commit 5372806a) _was_ a real improvement. > Perhaps make "protection" business optional, default to on for > new users? Now the question is how you would tell "new users". The possibility (2) is not even good enough, because even old timers work in a newly cloned repositories. ``` ## Luben Tuikov, 2006-12-26 20:25 Subject: Re: What's in git.git (stable) Message-ID: <418215.90592.qm@web31809.mail.mud.yahoo.com> URL: https://gitlist.dev/e/418215.90592.qm%40web31809.mail.mud.yahoo.com In-Reply-To: <7vac1fy5ae.fsf@assigned-by-dhcp.cox.net> ``` --- Junio C Hamano 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 ``` ## Junio C Hamano, 2006-12-26 23:54 Subject: Re: What's in git.git (stable) Message-ID: <7vd566ciwq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd566ciwq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <418215.90592.qm@web31809.mail.mud.yahoo.com> ``` Luben Tuikov writes: >> 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". As far as I am concerned, this is a topic already closed four days ago with commit fb8696d9. Are you way too behind, are you rubbing it in, or am I hallucinating and fb8696d9 did not actually fix it? ``` ## Luben Tuikov, 2006-12-27 01:19 Subject: Re: What's in git.git (stable) Message-ID: <368927.59162.qm@web31804.mail.mud.yahoo.com> URL: https://gitlist.dev/e/368927.59162.qm%40web31804.mail.mud.yahoo.com In-Reply-To: <7vd566ciwq.fsf@assigned-by-dhcp.cox.net> ``` --- Junio C Hamano wrote: > Luben Tuikov writes: > > >> 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". > > As far as I am concerned, this is a topic already closed four > days ago with commit fb8696d9. > > Are you way too behind, are you rubbing it in, or am I > hallucinating and fb8696d9 did not actually fix it? I'm behind. I'll pull and take a look at that commit. Luben ``` ## Junio C Hamano, 2006-12-27 02:14 Subject: Re: What's in git.git (stable) Message-ID: <7vslf2axvj.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vslf2axvj.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <368927.59162.qm@web31804.mail.mud.yahoo.com> ``` Luben Tuikov writes: > --- Junio C Hamano wrote: >> Luben Tuikov writes: >> >> >> 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". >> >> As far as I am concerned, this is a topic already closed four >> days ago with commit fb8696d9. >> >> Are you way too behind, are you rubbing it in, or am I >> hallucinating and fb8696d9 did not actually fix it? > > I'm behind. I'll pull and take a look at that commit. Thanks. And sorry that I sounded harsher than necessary. Between the two paragraphs, I meant to say "... with commit fb8696d9. It was a mistake, I broke existing workflows, I apologized, and the commit should have fixed it". ```