Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, 26 Feb 2008, Ian Jackson wrote: > But, is it really worth the effort to go back and edit revision logs > now ? And if I do so, will I disrupt merging any less than if I > rebase ? As soon as you edit commits, they'll get a new id, and thus you'll disrupt merging. The thing that you doesn't seem to understand is that if you don't do it, Guillem will do it for you and you'll have to fix up your other branches (flex-based parser, ...) anyway and you won't be able to use plain merge for that (or rather you can but it will be highly inefficient compared to a "git-rebase -i" where you skip the irrelevant commits that have been merged with other id). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, Feb 26, 2008 at 07:09:46PM +, Ian Jackson wrote: > I will then merge mainline into my branch, do any conflict resolution > necessary, and give it a quick test to make sure nothing seems to have > been broken in the meantime. Then merging my branch back into > mainline is, as you say, just a fast forward - so I will simply do > that, and push the result. I've no idea if anyone involved would consider it acceptable but might merging the triggers branch into the mainline with --squash be a suitable comprimise? This would give a single commit discarding the branch history which isn't ideal but would avoid having the history from your branch in the main history. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On 25/02/2008, Pierre Habouzit wrote: > What you want him to do is using: > > git rebase -i Probably with -p. -- Cyril Brulebois, who tried, w/o prior knowledge of the code. pgpoAOtx3byAG.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Luk Claes writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)"):
> What's the intention of discussing dpkg package team's internals on the
> debian-devel list?
I have a disagreement about the management of the team. I thought
that a wider perspective from the rest of the project would help.
It's certainly the case that bunches of people have contributed to
this `git bikeshedding' subthread who probably wouldn't have done
otherwise. And that question is nothing to do with dpkg specifically,
really.
And of course the project at large might have a view on whether they
would like to be able to deploy triggers in lenny - with a reasonable
time before the freeze to do so.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)"):
> Well, what you want him to do then is not rebasing onto master,
> because that won't change that a single bit. And indeed I agree this
> history is a complete mess, and an SCM abuse.
>
> What you want him to do is using:
> git rebase -i
If I do that, it will surely break the revision history of my derived
branches just as badly ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Henrique de Moraes Holschuh writes ("Re: git bikeshedding (Re: triggers in
dpkg, and dpkg maintenance)"):
> Given that many of us work on the kernel, some of us are both upstream and
> downstream in git, and therefore know *both* sides of the troubles and
> advantages of git rebase quite well... I can see why you'd have a tough
> time convincing anyone to change his mind about it. We will have lived it
> ourselves and made up our minds about it a long time ago, already...
dpkg is not the Linux kernel.
Linux dpkg
Number of different people
regularly contributinghundreds or three or
significant changes thousandsfour
Size of source (.tar.gz) 59 Mby 6.3 Mby
Current gatekeepersOriginal author Developers who
and hand-picked happened along
lieutenants at the right time
Organisational relationshipNone / Members of original
between main contributors commercial project, under
competition unified governance
Linux has some very severe management problems to solve: its large
size, its position right at the centre, and so forth. To deal with
these problems, very heavyweight processes have evolved to ensure that
the load on the small number of central gatekeepers is absolutely
minimised. An underlying assumption is that in order to save a minute
of work for Linus, it is worthwhile to impose tens of minutes, or even
hours, of work on submitters.
The gatekeepers in Linux can only delegate with extreme care because
the code is too big for effective ongoing review, and because many
contributors' motives are often specifically aligned with a desire to
get a patch accepted - often with substantial financial implications.
If you try to apply the same processes to dpkg, or to even smaller and
less important projects, you're introducing a very cumbersome burden
for very little good effect.
It is very unfortunate for git that most of its advocates want to
adopt these almost unmanageable development practices along with the
revision control software.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Raphael Hertzog writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)"):
> It starts with two very big commits touching almost all files
> and is followed by many small commits which have ubuntu changelog entries
> as commit log (and thus the "summary line" is useless).
> It also contains invalid email address in some "Author" fields.
Well, I'm sorry that not all of my early commit entries are ideal.
Note that the wrong email address was due to a bug in Debian's git.
But, is it really worth the effort to go back and edit revision logs
now ? And if I do so, will I disrupt merging any less than if I
rebase ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)"):
> Raphael is wrong to ask you to rebase, he's _really_ wrong about that,
> but *you* also are wrong to ask him to pull (aka fetch + merge). The
> usual way is that _you_ merge the current state of dpkg in your work so
> that _you_ solve the conflicts and issues, and _then_ mainline can see
> how it looks and look at the cleansed diff.
I definitely agree that I should be the one to do the merge. So at
least twice already I have merged mainline into my tree and published
the result.
Ie, I agree with you. That's exactly what I want to happen.
I'm very happy to do that merge again, if I have some assurance that
it's not just wasted work.
In fact, at this stage I don't even want any effort from Raphael and
Guillem. All I want is permission. They have already granted me
physical commit access but they have made it clear that they don't
want me to merge my branch, or to commit freely, and that they will
consider it abusive if I simply push a merged triggers branch.
All I want is for Raphael or Guillem to say `oh all right then'.
I will then merge mainline into my branch, do any conflict resolution
necessary, and give it a quick test to make sure nothing seems to have
been broken in the meantime. Then merging my branch back into
mainline is, as you say, just a fast forward - so I will simply do
that, and push the result.
And really I would like Raphael and/or Guillem to simply confirm that
I'm a full member of the team.
> IOW, you have to merge master, preferably in a new branch than your
> trigger-new one, like a master-pu-triggers or whatever, and if mainline
> is pleased or can read that patch (that I'm sure isn't _that_ big) they
> _then_ will be able to merge that branch that would just be a
> fast-forward.
The resulting patch is still big (3-4kloc of diff) because triggers is
a big feature. The size will not change much depending on what
precise revision it's based on.
> Note that they may ask you to rework this merge if they had done some
> further commits, but if you mkdir .git/rr-cache then git is able to use
> recorded images of already solved conflicts so that merging the same
> conflicts again and again doesn't costs you any time.
IME I can just merge from mainline into my branch, and it all works
completely fine and I never need to do any rework. This is, after
all, what a distributed vcs is for.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
