(+cc: Martin, who also requested something like this long ago[1] iirc)
Hi,
The following is only about motivation; I'm ignoring the mechanics for
now.
Junio C Hamano wrote:
> What's the point of being able to do this in the first place?
>
> The _only_ reason "git pull $there $branch" into an unborn branch exists
> is because it feels like
>
> $ git clone $there $directory
>
> could be broken down as this command sequence:
>
> $ mkdir $directory
> $ cd $directory
> $ git init
> $ git remote add origin $there
> $ git fetch
> $ git pull $there ;# or "git merge origin/master"
I'm to blame for the suggestion, I'm afraid.
I haven't wanted to be able to "git init && git remote add origin
$there && git fetch && git merge origin/topic-1 origin/topic-2" for a
long time, but there was a time (around 3 years ago, I think) I wanted
it a lot.
In fact I can't remember the details of why. The facts I remember:
- /etc was kept in a git repository managed by etckeeper;
- history was not precious --- it was just a way of understanding the
final result;
- the user wasn't sure how to manage topic branches yet. The usual
workflow involved
(1) cherry-picking each automatic commit to an appropriate topic
branch and writing a sensible description
(2) bundling the topic branches together with an octopus merge
(3) diff-ing against the automatically committed latest state to
see if anything was missing
(4) force a push.
So I suspect my use case was "start with a bundle of these branches".
I could have (and did) used "git checkout -b" to grab the first one
and merged the rest, but somehow a merge into nothingness seemed more
intuitive. Remember, this is before the days of checkout --orphan
and rebase -i --everything.
That said.
I doubt the above is a very compelling use case, to justify the
maintenance cost and easily explain in documentation. I would find
something like the following more compelling:
Currently git merge has a special case to "pull into
emptiness", to support the following sequence of commands:
git init repo
cd repo
git remote add origin $url
git fetch origin
git merge origin/master
But it is very much a special case. It does not support
octopus merges, --squash, --stat, alternate strategies,
or any of the rest of merge machinery.
It would be more intuitive if the above features _did_ work
where they make sense, and if this essentially worked as
though performing an ordinary merge with merge base being an
empty tree that is ancestor of everything.
Here is a first step --- support for octopus merges. It
also makes it easier to support the others, by [...].
> It very much feels like
> "because I can make things more complex", not "because this is an often
> desired missing feature that is a major pain point".
Therefore a good goal would be to make this make the code more simple
at the same time as making the semantics so.
(But also: Tim, please don't feel attached to this topic if you're not
interested in it; there are many more out there.)
Thanks for some useful feedback.
Jonathan
[1] http://bugs.debian.org/432558
--
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