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' 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: 1) 'fetch' did not retrieve any revisions from remote; the last local commit is the head of the branch. The workspace is up to date (it may need to be comitted). 2) 'fetch' retrieved revisions, and there were no local commits since the previous fetch. The last fetch is the head of the branch; if not equal to HEAD, the workspace needs to be updated (via 'merge'). 3) fetch retrieved revisions, and there were local commits since the previous fetch. There are two heads for the branch (the two described above), they need to be merged, then the workspace updated. I'm not sure how 'git fetch' handles case 3); I have not tested that case yet. The question I have is: What git queries can I run to determine which of the three states the current workspace is in? 'rev-parse HEAD' gives the last workspace commit. 'rev-parse refs/remotes/<remote>/<branch>' gives the head of the branch in the remote repository as of the most recent fetch. But to distinguish among the cases, I need to determine if one of these two revs is a child of the other or not. I don't see a git query to determine that directly. I could try parsing a 'log' output; I have not investigated that. This is easy in monotone; there is a command 'mtn heads' that gives this result directly (it returns either one or two revs), and another command 'mtn automate toposort' that orders revs topologically (by parent/child relationships). -- -- Stephe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html