What's in git.git (stable)

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 <file> 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 <commit>
      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

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.

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.

Hi,

On Fri, 22 Dec 2006, Randal L. Schwartz wrote:

Maybe "git-pull origin master"?

This is just a merge, not a real pull (it leaves out the fetch part).

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

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

Hi,

On Fri, 22 Dec 2006, Randal L. Schwartz wrote:

$ git repo-config branch.xyz.remote origin $ git repo-config branch.xyz.merge refs/heads/<whateveryourfirstfetchis>

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 <whateveristhefirstfetchedhead>" 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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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.

Hi,

On Fri, 22 Dec 2006, Junio C Hamano wrote:

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

In any case, here is a patch for discussion.

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

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.

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.

How does this "set" it?

    Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

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?

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

I'm behind.  I'll pull and take a look at that commit.

    Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

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

merlyn@stonehenge.com (Randal L. Schwartz) writes:

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

<opublikowany i wysłany>

Junio C Hamano wrote:

What about marking default branch to merge explicitely using "Merge:" in remotes/<repo>, or remote.<name>.merge?

Jakub Narebski <jnareb@gmail.com> writes:

Sorry, how is that an improvement over the current branch.*.merge? and how would that help not breaking existing setups?

Junio C Hamano wrote:

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 <jnareb@gmail.com> writes:

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.

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.

Junio C Hamano wrote:

[...]

This one is not there on the 'master' branch. Quy