Re: Determining update/merge/current state of a workspace

2014-02-02 Thread brian m. carlson
On Sun, Feb 02, 2014 at 03:04:59PM -0800, David Aguilar wrote: > I think you're looking for "git merge-base". > > If you do `git merge-base HEAD origin/master` > and its result is equal to `git rev-parse HEAD` > then you know that master is an ancestor of origin/master > and can be trivially fast-

Re: Determining update/merge/current state of a workspace

2014-02-02 Thread David Aguilar
On Sun, Feb 02, 2014 at 04:15:09PM -0600, Stephen Leake wrote: > I'm working on the DVC Emacs front-end for git > (http://www.emacswiki.org/emacs/DistributedVersionControl), adding > features similar to the ones I added for monotone > (http://www.monotone.ca). I'm used to monotone and new to git, s

Re: Determining update/merge/current state of a workspace

2014-02-02 Thread Jeff King
On Sun, Feb 02, 2014 at 04:15:09PM -0600, Stephen Leake wrote: > I always do 'fetch' and 'merge' separately, never 'pull'. So after a > 'fetch', the DVC Emacs front end must determine what needs to happen > next. I think there are three cases: Doing the two steps separately is common in git, too.

Determining update/merge/current state of a workspace

2014-02-02 Thread Stephen Leake
I'm working on the DVC Emacs front-end for git (http://www.emacswiki.org/emacs/DistributedVersionControl), adding features similar to the ones I added for monotone (http://www.monotone.ca). I'm used to monotone and new to git, so this may seem like an odd workflow. I always do 'fetch' and 'merge'