>>>>> TH == Tassilo Horn [2014-12-4] TH> "Davide G. M. Salvetti" <salve+ev...@linux.it> writes:
[...] >> or accept the burden of recovering from upstream rebase. TH> Out of interest: how would you do that? Say, HEAD was commit foo, you TH> added a bar commit on top, and now upstream has rebased so that foo is TH> 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. >> Therefore, I'd suggest to declare that you will rebase the branch in >> README.GIT TH> Do you really think anybody reads that except after running into TH> troubles? ;-) Yes, I positively think that developers will read it, and in any case if any trouble shows up on AUCTeX mailing lists we could at least point there. :-) TH> Well, but isn't it better in this case that I just merge master into TH> my branch as I've done now and live with the merge commits? Then TH> others can also fix bugs as they encounter them. And if want to TH> merge my changes into master at some point, I just apply the diff TH> manually or do a final rebase on my local branch and merge that. That would work, it's just that I find that the continuous merges do clutter history. However, it's your branch: of course you should follow whatever policy suits you best. -- Thanks, Davide _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel
