Service disruption: git converter currently down
imp at bsdimp.com
Wed Sep 25 19:50:11 UTC 2019
On Wed, Sep 25, 2019 at 11:56 AM Ed Maste <emaste at freebsd.org> wrote:
> On Wed, 25 Sep 2019 at 10:53, Warner Losh <imp at bsdimp.com> wrote:
> > But this really was a merge from stable/10 into master,
> I think this is just a question of semantics, not VCS details - I
> would argue that it is not a merge in the ordinary sense of the word,
> and is certainly not a merge in the git sense. You're right that this
> should be represented in history as if it were a cherry pick. Bogusly
> adding over 9000 commits to the history is definitely not the "least
> wrong" thing the conversion could do.
git log always requires added care. There's not actually 9000 commits
there. The tree looks fine topologically. Its purely an artifact of git log.
> git log --first-parent isn't really a solution here either, because
> there are cases where one legitimately does want history from both
> parents, especially working in downstream projects.
I'm pretty sure it would be fine, even in that case.
> > I'd offer the opinion that needing to know about things like git log
> --first-parent vs having to rebase every single downstream fork,
> We won't need to rebase every fork - in no case should the path
> forward be worse than uqs's suggestion of a merge from both old/new
IMHO, uqs suggestion is a complete non-starter, at least the "git diff |
git patch" one. It destroys all local history, commit messages, etc. Except
for the most trivial cases, it's not really going to fly with our users.
His other, followup ones might be workable into scripts.
I'm not sure you can merge, as there's no common ancestor that's recent
enough to give it a chance at succeeding (since the different exports would
have different hashes starting fairly early in our history). My experience
with qemu is that long-lived merge-updated branches become quite difficult
to cope with after a while. It took me three weeks to sort out that
relatively simple repo.
A rebase has a chance of working for people following a 'rebase' work flow.
I can write the scripts to do that because I basically already have them
and they just need to be modified to do a 'onto' for the easy to write, but
slightly risky case of rebasing them across the chasm to a new point on
master (as opposed to rebasing them to the same point on master). The
latter is possible, just needs a bit more scripting and wouldn't be too bad
to write and the least risky way to update across the chasm for people that
don't want to (or can't due to conflicts) jump in the easy but risky way.
However, for people like CHERIBSD who follow a 'merge from upstream' model
which never rebases (since that would be anti-social to their down
streams), I'm having trouble understanding how that could work. At work, we
basically do the merge from upstream with collapse model, which I'm having
trouble seeing how to move from old hashes to new. I'd like to know what
the plan for that would be and would happily test any solution there with a
copy of our repo. I'd even be happy to run experiments in advance of there
being something more public available to see what options do or don't work.
More information about the freebsd-git