search

schacon / hg-git

mercurial to git bridge, pushed to directly from the hg-git plugin in Hg
GNU General Public License v2.0
620 stars 71 forks source link

pull does update - and fails if crossing branches #84

Closed kiilerix closed 14 years ago

kiilerix commented 14 years ago

The following behaviour (some kind of update from within pull) seems confusing and wrong. Just like ordinary pull it should pull to a subtree as child of the right parent node, without updating working directory. If it has to update the working directory it should say so up front - especially if it can't update.

[mk@localhost freerdp]$ hg pull -u pulling from git://freerdp.git.sourceforge.net/gitroot/freerdp/freerdp importing Hg objects into Git Counting objects: 13, done. Compressing objects: 100% (13/13), done. Total 13 (delta 0), reused 0 (delta 0) importing Git objects into Hg abort: crosses branches (use 'hg merge' or use 'hg update -c') [mk@localhost freerdp]$ hg qpop -a popping ... [mk@localhost freerdp]$ hg pull -u pulling from git://freerdp.git.sourceforge.net/gitroot/freerdp/freerdp importing Hg objects into Git Counting objects: 13, done. Compressing objects: 100% (13/13), done. Total 13 (delta 0), reused 0 (delta 0) importing Git objects into Hg 7 files updated, 0 files merged, 1 files removed, 0 files unresolved [mk@localhost freerdp]$

abderrahim commented 14 years ago

The only difference to vanilla hg is heads reporting : not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge)

it shouldn't be very difficult to fix but it isn't a big problem.

kiilerix commented 14 years ago

abderrahim, sorry, I don't understand that comment.

At a first glance it is IMHO a big problem that pull fails. But if the right workaround is to update to the old git tip before pulling then it is no problem ... if the user finds out.

abderrahim commented 14 years ago

sorry, what I meant is that the pull didn't fail, just the update, which isn't very different from hg behaviour (where you get a nice explanation instead of an abort). And even if the pull really failed (it didn't in my test), the workaround would be to pull then update/rebase/whetever.

kiilerix commented 14 years ago

You say that the pull actually succeeded first time? I never understood the object counts and I have seen it behave in ways I didn't understand, but I assumed that when the working pull counted the same number of objects as the first failing one then it meant that the first pull didn't succeed at all. But ok - perhaps this is just a usability problem where the user in this case don't understand what goes on ;-)

abderrahim commented 14 years ago

You're right about the object count, but the pull still succeeded :-)

The problem with object count is that commits that haven't been merged to any branch (to be more accurate, changesets that aren't ancestors of tagged/bookmarked changesets) are downloaded again. This is generally not a problem since people will most of the time merge just after pulling.

anyway, I think it shouldn't be too difficult to fix.

kiilerix commented 14 years ago

Confirmed - it works as expected if I close my eyes and ignore the message ;-)