On Tue, Jan 16, 2007 at 12:39:58AM +0100, Yann Dirson wrote:
> > >I would be of the opinion to stop calling "git pull" entirely, and use
> > >"git fetch and the git.move_branch show above. Unless I hear about
> > >better ideas, my next patch set will be along those lines.
> >
> > Or replace the 'git pull' in the config file with 'git fetch && git
> > reset --hard MERGE_HEAD'? I might be wrong though as I almost never
> > use git directly :-).
>
> Hm. Probably rather FETCH_HEAD. Will have to look at that - but see
> above.
[...]
> Note that I did not think of using FETCH_HEAD, I was rather thinking
> of using information about the parent branch (which I had worked on
> recently), with the idea that this info probably belongs to
> branch.<name>.merge - which would complement Pavel's 87c69539 about
> branch.<name>.remote.
Unfortunately, using "reset('FETCH_HEAD')" or similar would not work.
Eg, in the case we have cloned an stgit branch as "origin", and the
revspec does not have a "+", git-fetch after a patch refresh in the
remote repo still updates FETCH_HEAD even if it notices it cannot then
fast-forward. With this we would end up with the "origin" branch not
being changed, and our stack still being rebased as if we had a "+"
refspec, which would be quite inconsistent.
Best regards,
--
Yann.
-
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