> there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
That would be a one-time headache with the first merge. After that, as long as bugfixes go into the stable branch, you won't have that problem. (Just had a quick look, it seems like it's currently a fairly trivial merge with only a few minor conflicts - I think git is doing the right thing for you here, but I don't know arc well enough to be sure).
> I would love to have nice history. I'm all ears for suggestions.
Basically, imho, splitting a tree is work and merging shouldn't be.
So by putting the commits in the right place to start with, you're avoiding work (and errors, and people checking with other people to see if that is supposed to be like that, etc).
You're essentially preserving more information as to the purpose of the fix (this is a bugfix) in a way that the tools can get hold of.
Anyway - I'm not a git expert, but that's the way I'd do it.
