[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AUCTeX-devel] [PATCH v3]: Merge /preview/ into top-level
From: |
Davide G. M. Salvetti |
Subject: |
Re: [AUCTeX-devel] [PATCH v3]: Merge /preview/ into top-level |
Date: |
Sun, 07 Dec 2014 19:12:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
>>>>> 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