Re: [Pan-users] Pan 0.99999999999999

[Duncan]

SciFi posted on Thu, 16 Jun 2011 16:56:25 +0000 as excerpted:

> On Thu, 16 Jun 2011 16:19:22 +0200, Rhialto wrote:
>> 
>> Speaking of git, did the repository at
>> git://github.com/lostcoder/pan2.git change history subtly at some
>> point?
> 
> I don't know myself of this particular problem.
> But I _do_ remember in the past that lostcoder has been known to
> completely re-build his trees that would cause such errors.
> He would usually say to just build a new clone on your system (which
> you've already done).
> 
> I also think this might happen when a tree-owner is trying to sync with
> other trees (such as imhotep82's new file-uploading code).
> 
> Or GitHub has some bugs itself.
> 
> Perhaps.
> Perhaps not.
> I dunno.
> 
> But this does kinda ruin the purpose of using any SCM.
> 
> ;)

FWIW, git has a "rebase" command that rebases (forward-ports local 
commits to the updated upstream head) a branch against another branch, 
local or remote.

This is very convenient for primarily users following an upstream 
primary, who may have one or more local commits that haven't been pushed 
upstream yet.

For instance, I'm a regular Linux kernel tester that normally runs very 
close to the upstream Linus kernel, but some versions ago a commit to the 
radeon drm tree totally broke things for my still AGP based Radeon hd4650 
(r7xx series chips), and after bisecting the problem to a specific commit 
(which updated the whole r7xx series to fix a problem certain PCI-E users 
were having), which I reported upstream, I created a local commit 
reverting that upstream commit.

But it took the kernel radeon drm maintainer quite some time (a kernel 
version and a half, probably about three months) to, with my cooperation, 
figure out that the fix applied to PCI-E cards actually broke AGP users, 
and commit a fix for /that/, thereby allowing me to revert to the un-
patched upstream kernel once again.  In the mean time, I was carrying 
forward my local commit against upstream, so I could continue to test and 
ultimately run newer stable kernels with the one commit that broke things 
for me reverted by my reversing commit.

At first, pull and merge the conflicts manually, but that got to be a 
pain real fast, especially since each time I did, it added a commit 
reflecting my manual merge, even tho I'd changed nothing and in reality 
it was still just one single (reversing) commit away from upstream.

Then I discovered git rebase, which allowed me to simply rebase my single 
commit on top of the latest pull from upstream each time.  It required 
less work on my part (the "conflicts" weren't really conflicts after all, 
and the rebase continued to go smoothly) and the new status now reflected 
that of the pull from upstream plus that single commit, instead of adding 
one for the merge each time.

But, rebasing a more public branch that others pull and base their own 
work on is very explicitly discouraged.  From the git-rebase manpage:

   RECOVERING FROM UPSTREAM REBASE
      Rebasing (or any other form of rewriting) a branch that others
      have based work on is a bad idea:  anyone downstream of it is
      forced to manually fix their history. This section explains how
      to do the fix from the downstream’s point of view. The real fix,
      however, would be to avoid rebasing the upstream in the first
      place.


There follows an explanation complete with ASCII diagrams of the 
duplicated history such rebases can cause in branches based on them and 
later merged back into mainline, along with the fix (rebase your own work 
on the sub-branch that did the rebase, the problem being that this can 
ultimately cause quite a ripple effect of rebasing, and if more than one 
subsystem is doing it at a time, good luck trying to manage the ripple 
interference without some serious manual history hacking!).

And if you are a kernel developer with others pulling from you and rebase, 
at least without a very public announcement/warning and explanation, you 
get to sit in the very public doghouse for some time, for screwing up 
everybody else.

It follows that Linus himself *NEVER* rebases his public branch.  
Everything he does gets done in local branches, and only when he's 
satisfied with them does he merge them to his public branch.  (And as 
he's stated before, real men don't need backups as the net itself 
provides them.  If he DOES screw up, there's plenty of git mirrors he can 
clone his own public branch from as of the last public commit! =:^)  And 
he expects all his kernel subsystem lieutenants to work the same way, and 
in turn enforce the same rules on those under them.

My guess is that as many non-kernel devs, khaley/lostcoder is to some 
extent learning git on-the-fly.  It's thus somewhat likely that learning 
how disruptive rebases on the public tree can be was a process.  
Meanwhile, it's not as if the lostcoder tree is as massively 
cooperatively developed as is the kernel tree by a LONG stretch, so the 
ripple effect in any case dissipates within only a couple iterations from 
his mainstream, and it's not the big deal it most *DEFINITELY* would be 
if Linus or one of his major lieutenants rebased their public tree.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman