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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
