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

Re: dpkg with triggers support (again)

On Tue, 11 Mar 2008, John Goerzen wrote:
> On Tuesday 11 March 2008 4:41:57 pm Ian Jackson wrote:
> > He is polishing revision logs by rebasing changes, reorganising
> > commits into a different order, moving code between files,
> > gratuitously reformatting[2], etc.
> What is it that people don't get from git-rebase(1)?
>        When you rebase a branch, you are changing its history in a way that
>        will cause problems for anyone who already has a copy of the branch in
>        their repository and tries to pull updates from you. You should
>        understand the implications of using git rebase on a repository that
>        you share.
> In short, never rebase something that is already public.

Rebasing *published* commits in the *mainline/master* branch is utterly

Note that I do think you should clean up the hell out of the history and
commit logs right before a merge, use topic branches, and rebase the fuckers
right before merges to ease everyone else's lives when looking at the
history and doing bissect hunts.  I have made this clear to anyone reading
my posts.

But even I agree that one MUST NEVER rebase published commits in the main
branch.  There is no excuse to mess with the mainline history other than to
defang some commit that is SO dangerous, it can't be risked someone would
hit it on a bissect.  I have *never* heard of something like this happening.

Now, there comes the IMPORTANT question: was the rebase done on the main
branch?  Or was it a clean up operation on some topic branch before merging
it?  I'd appreciate quite a LOT if such extremely important information is
also disclosed.

> > [2] His most recent commit is 402 diff lines of stuff like this:
> >   -static void usage(void) {
> >   +void
> >   +usage(void)
> >   +{
> Ugh.  I laughed when I first read this, but now I feel more revulsion.
> Ugh.

Double ugh with an argh on top.  It is icky (I *hate* that way of writing C
source).  And to really rub it in, it makes something that was static,
non-static (i.e. it DOES change code in important ways).

You NEVER mix pure fluff changes with real changes in the same commit, it is
Bad Taste with a capital B.   It is right there in the list of "DON'Ts", in
the same slot for "moving AND changing large chunks of code in one single
commit, instead of moving it unmodified in the first commit, and changing it
in a second commit".

Not to mention that this is a bad time to go fixing fluff in dpkg when there
is such a lot of outstanding code to be merged...

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: