Re: [AUCTeX-devel] [PATCH v3]: Merge /preview/ into top-level

[Davide G. M. Salvetti]

>>>>>  TH == Tassilo Horn [2014-12-4]

TH> "Davide G. M. Salvetti" <address@hidden> 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