Han Seoul-Oh

Thanks for your interest! Are the repos you refer to publicly available anywhere to test? `git-subhistory` as currently implemented definitely performs atrociously, even worse than `git-subtree`. The _strategy_ I believe...

So basically there's 2 fundamental data model problems with `git-subhistory`: - Mapping commit messages (minor, but easier to explain): many projects have a convention of prefixing commit messages with the...

@Darthholi: gosh, thanks for actually reading that huge tome I wrote! I kind of spit it all out without spending that much time editing it down (though I originally wrote...

> Iam a bash noob (look at my branch), but if You would come up with really clever thingies (sed on commit messages is cool) for subhistory (or, hell, even...

> I do not understand in "what do we do if A and B have conflicting changes outside the subproject?" the part about conflicting changes outside of subproject. I need...

> They are not two separate subrepositories, it is just that these two folders do contain the code for one library actually. Unfortunately a git commit history has to have...

I'm still grokking your PR but I was thinking about the idea of caching a separate map between Main commits and Sub commits, and I was thinking about how `git...

Thanks! Still making my way through, but do you think you could describe for me at a high level specifically what you're trying to do and your approach?

Another point against the clean merge requirement: just because `ASSIMILATE_HEAD` is a clean merge into `HEAD` now doesn't mean it will be in the future, even into commits that are...

Right now, after going through all this, what I'm thinking going forward is (assuming I don't kill `git-subhistory` entirely): - definitely improve path 2 in the straightforward way described above...