Re: Translation commits pushed when rolling a tarball

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 
 work is preserved. Someone later trying to work out what 
happened has
 actually got a correct version of history to refer back to, and 
 problem can be correctly tracked down to the *merge* of the 
 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 
     them, and without any indication of which changes relate to 
     commit so no one in the future will ever be able to figure it 
     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 
someone doing something truly bizarre and ill-advised, and it's put 
off doing things *correctly* for ever more.

Much like the libxml2 insanity with quantum symbol versioning seems 
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 
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 


After some digging about usage of git in Linx:
LWN article - "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 - "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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]