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'

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.

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, so

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