Re: [Pan-users] Pan 0.99999999999999

[K. Haley]

On 06/16/2011 02:23 PM, Duncan wrote:
> 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).
Yep, my testing branch has never been considered to have a stable
history.  I'm fairly certain that I mentioned it would be re-built
occasionally back when I started using github.
> 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.
git pull --rebase
> 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 is a touch of irony here since I'm somewhat following the git
model.  My testing branch is equivalent to their pu branch.  It gets
re-based / re-built as needed.

signature.asc
Description: OpenPGP digital signature