Johannes Schindelin wrote: > On Wed, 30 Apr 2014, Erik Faye-Lund wrote: > > > While it's certainly a good point, I think this is *our* fault for not > > upstreaming our changes, and the responsibility of cleaning up merges > > should lie on our shoulders. We've diverged a lot. Sure, Dscho does a > > great job making the divergence less painful, but IMO we should try to > > reduce the delta as well. > > Just for historical context: we *did* try to get our changes upstream. In > fact, that was in large part everything Steffen Prohaska did while he was > maintaining Git for Windows. The going has been tough, though, to the > point that we were losing contributors who were not *quite* willing to put > up with such a detailed vetting process as the Git mailing list requires. > > I have to admit that it is really, really hard even for someone like me, > who is used to the ways of the Git mailing list, because just a simple > thing like this curl-config issue already eats up several days of my Git > time budget. > > So while I am sympathetic to the point of view that the Git for Windows > project failed to upstream its changes, I am *equally* sympathetic to the > point of view that it is an undue burden to have to go through the process > of getting patches included by upstream Git. I, for one, simply ain't got > the time, man.
As a maintainer of another friendly fork of Git (or downstream), because of very similar reaons, I symphathize. It's something that has to be done though, otherwise the burden of maintaining the friendly fork becomse unberable. The trick is to only send the trivial patches upstream, and also to constantly keep track of what is missing from upstream. In oder to do this I've found invaluable to have an integration branch, which I constnatly regenerate with `git reintegrate`[1]. IIRC you do a similar kind of reintegration for each new release of msysgit, and it appears to me that you do it by hand, which must be tedious. I'm planning to write a blog post about the subject, but basically I have a bunch of branches that are direct descendants of an upstream version, I tell `git reintegrate` to merge them on top of certain upstream release, the result must match *exactly* what my main master branch has. The descendant branches I constanly keep rebasing, and the main master branch always mergering and cherry-picking, never rebasing. [1] https://github.com/felipec/git-reintegrate -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
