[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AUCTeX-devel] [PATCH v3]: Merge /preview/ into top-level
From: |
Tassilo Horn |
Subject: |
Re: [AUCTeX-devel] [PATCH v3]: Merge /preview/ into top-level |
Date: |
Mon, 08 Dec 2014 15:54:52 +0100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
"Davide G. M. Salvetti" <address@hidden>
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