Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?

Am 9/2/2011 2:00, schrieb Jeff King:

Right now, I think of it as a local cache for whatever the remote side
has. In other words, a way of separating the network-fetching parts of
the workflow from the local parts.

This is also my interpretation. For this reason, I don't think a change is
necessary.

So I consider that a downside, because it's extra work for the user[1].
What are the upsides?

Is this about preventing workflow-related mistakes where people
accidentally merge in rebased commits, creating annoying shadow
histories?

Is it about preventing malicious rewinds from infecting downstream
repositories?

All good questions to ask.

[1] What I really don't like is that cloning git.git is no longer:

      git clone git://git.kernel.org/pub/scm/git/git.git

    which is a minimal as it can be, but becomes:

      git clone git://git.kernel.org/pub/scm/git/git.git
      cd git
      git config --add remote.origin.fetch +refs/heads/pu:refs/remotes/origin/pu

    It's not that my fingers are too tired to do all that typing, but
    rather that the first set of instructions is very easy to explain,
    and the second one is full of magic and head-scratching about why
    git isn't handling this magic itself.

Absolutely.

    It would be considerably nicer if the server had some way of saying
    "I expect this branch to be rewound". Which has been discussed off
    and on over the years, as I recall.

So, if such a feature were available, wouldn't it be nicer if the initial
clone set up the refspec like this:

  [remote "origin"]
        url = git://git.kernel.org/pub/scm/git/git.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = refs/heads/maint:refs/remotes/origin/maint
        fetch = refs/heads/master:refs/remotes/origin/master

i.e., the non-wildcard refspec are about which branches are *not* expected
to be rewound rather than the other way around.

-- Hannes