emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rewriting bzrmerge.el


From: David Engster
Subject: Re: Rewriting bzrmerge.el
Date: Sat, 22 Nov 2014 22:11:18 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux)

Eli Zaretskii writes:
> I'm going to recommend on the Wiki that people who don't consider
> themselves advanced/experienced Git users clone the repository twice,
> in which case they most probably won't have a checkout of emacs-24 in
> the clone where they work on master, and vice versa.

If there are problems with git-new-workdir, that's probably for the
best. I've never really used it, especially not on Windows.

>> If you follow admin/notes/git-workflow and create a separate
>> checkout of the emacs-24 branch, you will automatically have a local
>> tracking branch emacs-24 (also in 'trunk').
>
> Following admin/notes/git-workflow is not a requirement, it's an
> advice.  IMO, gitmerge.el should work even without that, at least
> ideally.

It will always be able to merge origin/emacs-24. I guess you could set
things up to merge from a second, separate clone (by adding it as a
remote), but I don't see the need.

>> You'll be able to do either. For git it makes no difference whether you
>> merge a local or a remote branch.
>
> I didn't mean me, I meant gitmerge.el.  If it always uses
> origin/emacs-24, it will work regardless of whether there is a
> checkout of emacs-24.  So I think this is more reliable.

At the moment, gitmerge will ask you what branch to merge with a
completing-read, where you can choose from a list of all local and
remote branches (they can optionally be filtered through a regexp). The
branch 'origin/emacs-24' is now set as INITIAL-INPUT, since this will be
the main purpose of gitmerge (for now). Are you OK with that?

-David



reply via email to

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