"Davide G. M. Salvetti" <[email protected]> writes: Hi Davide,
>>> or accept the burden of recovering from upstream rebase. > > TH> Out of interest: how would you do that? Say, HEAD was commit foo, > TH> you added a bar commit on top, and now upstream has rebased so > TH> that foo is gone and the new upstream HEAD is quux. > > I would follow what is documented in git-rebase(1), section "RECOVERING > FROM UPSTREAM REBASE", paragraph "The hard case". Basically, one need > to identify the parent commit where his own branch starts and use > : git rebase --onto rebased-upstream-branch \ > : old-upstream-branch-parent-commit \ > : my-own-branch > The only tricky (not really that tricky) bit is finding > old-upstream-branch-parent-commit, but I guess one can rely on git-log > if nothing else. Thanks. > TH> Well, but isn't it better in this case that I just merge master > TH> into my branch as I've done now and live with the merge commits? > TH> Then others can also fix bugs as they encounter them. And if want > TH> to merge my changes into master at some point, I just apply the > TH> diff manually or do a final rebase on my local branch and merge > TH> that. > > That would work, it's just that I find that the continuous merges do > clutter history. But the cluttered history is only in that single branch which would get removed after its changes have been merged (manually or with a rebase) into master. > However, it's your branch: of course you should follow whatever policy > suits you best. I'll keep things as they are for the simplify-TeX-parse-error branch, but I'll consider changing the procedure next time. Bye, Tassilo _______________________________________________ auctex-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/auctex-devel
