[Top][All Lists]

[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>

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.


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]