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
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
