On Sun, 2014-08-03 at 19:38 +0000, David Woodhouse wrote:
On 08/02/2014 10:38 AM, David Woodhouse wrote:If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes.> > >Except that this correct version of history looks like this:- Implement X- Implement Y- Implement Z- Make a whole bunch of changes all at once, some of which are related to X, some to Y, some to Z, and some to more than one of them, and without any indication of which changes relate to which commit so no one in the future will ever be able to figure it out ha ha ha.Which sucks. So I'll stick with rebasing, thanks.>That is so far from the normal experience of using git as intended, that I don't quite recognise it. It sounds like you've had a bad experience of someone doing something truly bizarre and ill-advised, and it's put you off doing things *correctly* for ever more. Much like the libxml2 insanity with quantum symbol versioning seems to have put people off using *that* properly. Or indeed at all. But I wasn't necessarily expecting the "don't use git properly" policy to be changed - it's just that nobody seemed to be acknowledging the elephant in the room in this thread, which was that the whole problem being discussed is an artificial one purely caused by that policy. So I felt it appropriate to make sure it was mentioned.
I don't think the 'using git as intended' is a clear-cut thing. I guess it's reasonable to assume git was intended for Linux kernel development workflow where the linux-next is managed by Linus, who pulls the commits from lieutenants who pull the data from branches. Even in such situations IIRC the people are adviced to just rebase on feature branches to avoid the myriad of merge commits. Maintaining of Linux kernel is a bit more complicated then Gnome modules - I'd imagine that we would have corresponding situation when we would have a whole Gnome in single git repository and gtk+ development would happen in separate branch while i18n could have a separate branch. When the release of new Gnome would come a release team would pull the changes in and make a release. This is not a way which makes sense for Gnome though it makes sense for Linux as we can and are more modular. My guess would be to do it in 'Linux' way and avoid multiply merge commits would be to push the i18n to separate branch and make the maintainer, though I would imagine to be much more complicated for our purposes. ---------------------- After some digging about usage of git in Linx: LWN article http://lwn.net/Articles/328436/ - "Linus does not tell developers not to use it [rebasing]; in fact, he encourages it sometimes.", "On the other hand, private history can be rebased at will - and it probably should be.". Original Linus post http://lwn.net/Articles/328438/ - "So you can go wild on the "git rebase" thing on it", "Keep your own history readable" Best regards
Attachment:
signature.asc
Description: This is a digitally signed message part