Really, I don't forsee much of a synchronization problem. People can commit to whichever branch they prefer; I'll keep an eye on the RSS feed, as might others, and if a bugfix gets pushed in one branch but not cherry-picked, we'll do it. There aren't too many commits that human error is going to matter all that much.
As for merging, 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.
I'm still not all that familiar with Git, though, and I would love to have nice history. I'm all ears for suggestions.
> 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.
