[PATCH v2 00/13] remote-hg: general updates

[PATCH v2 00/13] remote-hg: general updates

[Felipe Contreras]

Hi,

A reroll of the previous series, only a very small bugfix, and one updated
commit message.

Dusty Phillips (2):
  remote-hg: add missing config variable in doc
  remote-hg: push to the appropriate branch

Felipe Contreras (10):
  remote-hg: trivial cleanups
  remote-hg: properly report errors on bookmark pushes
  remote-hg: make sure fake bookmarks are updated
  remote-hg: trivial test cleanups
  remote-hg: redirect buggy mercurial output
  remote-hg: split bookmark handling
  remote-hg: refactor export
  remote-hg: update remote bookmarks
  remote-hg: force remote push
  remote-hg: update tags globally

Peter van Zetten (1):
  remote-hg: fix for files with spaces

 contrib/remote-helpers/git-remote-hg     | 75 ++++++++++++++++++++++++--------
 contrib/remote-helpers/test-hg-bidi.sh   |  6 +--
 contrib/remote-helpers/test-hg-hg-git.sh |  4 +-
 3 files changed, 63 insertions(+), 22 deletions(-)

-- 
1.8.2

[PATCH v2 01/13] remote-hg: trivial cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 328c2dc..d0dfb1e 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -531,7 +531,6 @@ def parse_blob(parser):
     data = parser.get_data()
     blob_marks[mark] = data
     parser.next()
-    return
 
 def get_merge_files(repo, p1, p2, files):
     for e in repo[p1].files():
@@ -542,7 +541,7 @@ def get_merge_files(repo, p1, p2, files):
             files[e] = f
 
 def parse_commit(parser):
-    global marks, blob_marks, bmarks, parsed_refs
+    global marks, blob_marks, parsed_refs
     global mode
 
     from_mark = merge_mark = None
@@ -647,10 +646,11 @@ def parse_commit(parser):
     rev = repo[node].rev()
 
     parsed_refs[ref] = node
-
     marks.new_mark(rev, commit_mark)
 
 def parse_reset(parser):
+    global parsed_refs
+
     ref = parser[1]
     parser.next()
     # ugh
@@ -715,11 +715,11 @@ def do_export(parser):
             continue
         print "ok %s" % ref
 
-    print
-
     if peer:
         parser.repo.push(peer, force=False)
 
+    print
+
 def fix_path(alias, repo, orig_url):
     repo_url = util.url(repo.url())
     url = util.url(orig_url)
-- 
1.8.2

[PATCH v2 02/13] remote-hg: add missing config variable in doc

[Felipe Contreras]

From: Dusty Phillips <dusty@linux.ca>

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index d0dfb1e..844ec50 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -23,6 +23,10 @@ import urllib
 # If you want to switch to hg-git compatibility mode:
 # git config --global remote-hg.hg-git-compat true
 #
+# If you are not in hg-git-compat mode and want to disable the tracking of
+# named branches:
+# git config --global remote-hg.track-branches false
+#
 # git:
 # Sensible defaults for git.
 # hg bookmarks are exported as git branches, hg branches are prefixed
-- 
1.8.2

[PATCH v2 03/13] remote-hg: properly report errors on bookmark pushes

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 844ec50..19eb4db 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -710,6 +710,7 @@ def do_export(parser):
             else:
                 old = ''
             if not bookmarks.pushbookmark(parser.repo, bmark, old, node):
+                print "error %s" % ref
                 continue
         elif ref.startswith('refs/tags/'):
             tag = ref[len('refs/tags/'):]
-- 
1.8.2

[PATCH v2 04/13] remote-hg: fix for files with spaces

[Felipe Contreras]

From: Peter van Zetten <peter.van.zetten@cgi.com>

Set the maximum number of splits to make when dividing the diff stat
lines based on space characters.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 19eb4db..c6a1a47 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -578,7 +578,7 @@ def parse_commit(parser):
             mark = int(mark_ref[1:])
             f = { 'mode' : hgmode(m), 'data' : blob_marks[mark] }
         elif parser.check('D'):
-            t, path = line.split(' ')
+            t, path = line.split(' ', 1)
             f = { 'deleted' : True }
         else:
             die('Unknown file command: %s' % line)
@@ -625,7 +625,7 @@ def parse_commit(parser):
         i = data.find('\n--HG--\n')
         if i >= 0:
             tmp = data[i + len('\n--HG--\n'):].strip()
-            for k, v in [e.split(' : ') for e in tmp.split('\n')]:
+            for k, v in [e.split(' : ', 1) for e in tmp.split('\n')]:
                 if k == 'rename':
                     old, new = v.split(' => ', 1)
                     files[new]['rename'] = old
-- 
1.8.2

[PATCH v2 05/13] remote-hg: make sure fake bookmarks are updated

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg     | 7 +++++++
 contrib/remote-helpers/test-hg-bidi.sh   | 1 +
 contrib/remote-helpers/test-hg-hg-git.sh | 1 +
 3 files changed, 9 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index c6a1a47..b200e60 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -709,9 +709,16 @@ def do_export(parser):
                 old = bmarks[bmark].hex()
             else:
                 old = ''
+
+            if bmark == 'master' and 'master' not in parser.repo._bookmarks:
+                # fake bookmark
+                print "ok %s" % ref
+                continue
+
             if not bookmarks.pushbookmark(parser.repo, bmark, old, node):
                 print "error %s" % ref
                 continue
+
         elif ref.startswith('refs/tags/'):
             tag = ref[len('refs/tags/'):]
             parser.repo.tag([tag], node, None, True, None, {})
diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
index 1d61982..fe38e49 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -30,6 +30,7 @@ git_clone () {
 hg_clone () {
 	(
 	hg init $2 &&
+	hg -R $2 bookmark -i master &&
 	cd $1 &&
 	git push -q "hg::$PWD/../$2" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
 	) &&
diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
index 3f253b7..e116cb0 100755
--- a/contrib/remote-helpers/test-hg-hg-git.sh
+++ b/contrib/remote-helpers/test-hg-hg-git.sh
@@ -35,6 +35,7 @@ git_clone_git () {
 hg_clone_git () {
 	(
 	hg init $2 &&
+	hg -R $2 bookmark -i master &&
 	cd $1 &&
 	git push -q "hg::$PWD/../$2" 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
 	) &&
-- 
1.8.2

[PATCH v2 06/13] remote-hg: trivial test cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-hg-bidi.sh   | 5 ++---
 contrib/remote-helpers/test-hg-hg-git.sh | 3 +--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
index fe38e49..a3c88f6 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -22,7 +22,6 @@ fi
 
 # clone to a git repo
 git_clone () {
-	hg -R $1 bookmark -f -r tip master &&
 	git clone -q "hg::$PWD/$1" $2
 }
 
@@ -201,8 +200,8 @@ test_expect_success 'hg branch' '
 	hg_push hgrepo gitrepo &&
 	hg_clone gitrepo hgrepo2 &&
 
-	: TODO, avoid "master" bookmark &&
-	(cd hgrepo2 && hg checkout gamma) &&
+	: Back to the common revision &&
+	(cd hgrepo && hg checkout default) &&
 
 	hg_log hgrepo > expected &&
 	hg_log hgrepo2 > actual &&
diff --git a/contrib/remote-helpers/test-hg-hg-git.sh b/contrib/remote-helpers/test-hg-hg-git.sh
index e116cb0..73ae18d 100755
--- a/contrib/remote-helpers/test-hg-hg-git.sh
+++ b/contrib/remote-helpers/test-hg-hg-git.sh
@@ -27,7 +27,6 @@ fi
 
 # clone to a git repo with git
 git_clone_git () {
-	hg -R $1 bookmark -f -r tip master &&
 	git clone -q "hg::$PWD/$1" $2
 }
 
@@ -48,7 +47,7 @@ git_clone_hg () {
 	(
 	git init -q $2 &&
 	cd $1 &&
-	hg bookmark -f -r tip master &&
+	hg bookmark -i -f -r tip master &&
 	hg -q push -r master ../$2 || true
 	)
 }
-- 
1.8.2

[PATCH v2 07/13] remote-hg: redirect buggy mercurial output

[Felipe Contreras]

Mercurial emits messages like "searching for changes", "no changes
found", etc. meant for the use of its own UI layer, which break the pipe
between transport helper and remote helper.

Since there's no way to silence Mercurial, let's redirect to standard
error.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index b200e60..874ccd4 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -271,6 +271,7 @@ def get_repo(url, alias):
 
     myui = ui.ui()
     myui.setconfig('ui', 'interactive', 'off')
+    myui.fout = sys.stderr
 
     if hg.islocal(url):
         repo = hg.repository(myui, url)
-- 
1.8.2

[PATCH v2 08/13] remote-hg: split bookmark handling

[Felipe Contreras]

Will be useful for remote bookmarks.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 39 +++++++++++++++++++++++-------------
 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 874ccd4..6901689 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -685,6 +685,8 @@ def parse_tag(parser):
 def do_export(parser):
     global parsed_refs, bmarks, peer
 
+    p_bmarks = []
+
     parser.next()
 
     for line in parser.each_block('done'):
@@ -706,20 +708,9 @@ def do_export(parser):
             pass
         elif ref.startswith('refs/heads/'):
             bmark = ref[len('refs/heads/'):]
-            if bmark in bmarks:
-                old = bmarks[bmark].hex()
-            else:
-                old = ''
-
-            if bmark == 'master' and 'master' not in parser.repo._bookmarks:
-                # fake bookmark
-                print "ok %s" % ref
-                continue
-
-            if not bookmarks.pushbookmark(parser.repo, bmark, old, node):
-                print "error %s" % ref
-                continue
-
+            p_bmarks.append((bmark, node))
+            # handle below
+            continue
         elif ref.startswith('refs/tags/'):
             tag = ref[len('refs/tags/'):]
             parser.repo.tag([tag], node, None, True, None, {})
@@ -731,6 +722,26 @@ def do_export(parser):
     if peer:
         parser.repo.push(peer, force=False)
 
+    # handle bookmarks
+    for bmark, node in p_bmarks:
+        ref = 'refs/heads' + bmark
+
+        if bmark in bmarks:
+            old = bmarks[bmark].hex()
+        else:
+            old = ''
+
+        if bmark == 'master' and 'master' not in parser.repo._bookmarks:
+            # fake bookmark
+            print "ok %s" % ref
+            continue
+
+        if not bookmarks.pushbookmark(parser.repo, bmark, old, node):
+            print "error %s" % ref
+            continue
+
+        print "ok %s" % ref
+
     print
 
 def fix_path(alias, repo, orig_url):
-- 
1.8.2

[PATCH v2 09/13] remote-hg: refactor export

[Felipe Contreras]

No functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 6901689..c741f13 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -9,7 +9,7 @@
 # Then you can clone with:
 # git clone hg::/path/to/mercurial/repo/
 
-from mercurial import hg, ui, bookmarks, context, util, encoding
+from mercurial import hg, ui, bookmarks, context, util, encoding, node
 
 import re
 import sys
@@ -60,6 +60,9 @@ def hgmode(mode):
     m = { '100755': 'x', '120000': 'l' }
     return m.get(mode, '')
 
+def hghex(node):
+    return hg.node.hex(node)
+
 def get_config(config):
     cmd = ['git', 'config', '--get', config]
     process = subprocess.Popen(cmd, stdout=subprocess.PIPE)
@@ -705,19 +708,18 @@ def do_export(parser):
 
     for ref, node in parsed_refs.iteritems():
         if ref.startswith('refs/heads/branches'):
-            pass
+            print "ok %s" % ref
         elif ref.startswith('refs/heads/'):
             bmark = ref[len('refs/heads/'):]
             p_bmarks.append((bmark, node))
-            # handle below
             continue
         elif ref.startswith('refs/tags/'):
             tag = ref[len('refs/tags/'):]
             parser.repo.tag([tag], node, None, True, None, {})
+            print "ok %s" % ref
         else:
             # transport-helper/fast-export bugs
             continue
-        print "ok %s" % ref
 
     if peer:
         parser.repo.push(peer, force=False)
@@ -725,6 +727,7 @@ def do_export(parser):
     # handle bookmarks
     for bmark, node in p_bmarks:
         ref = 'refs/heads' + bmark
+        new = hghex(node)
 
         if bmark in bmarks:
             old = bmarks[bmark].hex()
@@ -733,10 +736,11 @@ def do_export(parser):
 
         if bmark == 'master' and 'master' not in parser.repo._bookmarks:
             # fake bookmark
-            print "ok %s" % ref
-            continue
-
-        if not bookmarks.pushbookmark(parser.repo, bmark, old, node):
+            pass
+        elif bookmarks.pushbookmark(parser.repo, bmark, old, new):
+            # updated locally
+            pass
+        else:
             print "error %s" % ref
             continue
 
-- 
1.8.2

[PATCH v2 10/13] remote-hg: update remote bookmarks

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index c741f13..b54de1e 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -744,6 +744,11 @@ def do_export(parser):
             print "error %s" % ref
             continue
 
+        if peer:
+            if not peer.pushkey('bookmarks', bmark, old, new):
+                print "error %s" % ref
+                continue
+
         print "ok %s" % ref
 
     print
-- 
1.8.2

[PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

Ideally we shouldn't do this, as it's not recommended in mercurial
documentation, but there's no other way to push multiple bookmarks (on
the same branch), which would be the behavior most similar to git.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index b54de1e..b784c54 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -722,7 +722,7 @@ def do_export(parser):
             continue
 
     if peer:
-        parser.repo.push(peer, force=False)
+        parser.repo.push(peer, force=True)
 
     # handle bookmarks
     for bmark, node in p_bmarks:
-- 
1.8.2

[PATCH v2 12/13] remote-hg: update tags globally

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index b784c54..56b3641 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -715,7 +715,11 @@ def do_export(parser):
             continue
         elif ref.startswith('refs/tags/'):
             tag = ref[len('refs/tags/'):]
-            parser.repo.tag([tag], node, None, True, None, {})
+            if mode == 'git':
+                msg = 'Added tag %s for changeset %s' % (tag, hghex(node[:6]));
+                parser.repo.tag([tag], node, msg, False, None, {})
+            else:
+                parser.repo.tag([tag], node, None, True, None, {})
             print "ok %s" % ref
         else:
             # transport-helper/fast-export bugs
-- 
1.8.2

[PATCH v2 13/13] remote-hg: push to the appropriate branch

[Felipe Contreras]

From: Dusty Phillips <dusty@linux.ca>

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 56b3641..d82eb2d 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -625,6 +625,10 @@ def parse_commit(parser):
     if merge_mark:
         get_merge_files(repo, p1, p2, files)
 
+    # Check if the ref is supposed to be a named branch
+    if ref.startswith('refs/heads/branches/'):
+        extra['branch'] = ref.rpartition('/')[2]
+
     if mode == 'hg':
         i = data.find('\n--HG--\n')
         if i >= 0:
-- 
1.8.2

Re: [PATCH v2 07/13] remote-hg: redirect buggy mercurial output

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Mercurial emits messages like "searching for changes", "no changes
> found", etc. meant for the use of its own UI layer, which break the pipe
> between transport helper and remote helper.
>
> Since there's no way to silence Mercurial, let's redirect to standard
> error.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---

Thanks.

Let me suggest retitling it with s/buggy/unwanted/, because it is
not a "bug" to have these output from Hg's point of view.  It is
just that this reading process does not want it.

>  contrib/remote-helpers/git-remote-hg | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index b200e60..874ccd4 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -271,6 +271,7 @@ def get_repo(url, alias):
>  
>      myui = ui.ui()
>      myui.setconfig('ui', 'interactive', 'off')
> +    myui.fout = sys.stderr
>  
>      if hg.islocal(url):
>          repo = hg.repository(myui, url)

Re: [PATCH v2 11/13] remote-hg: force remote push

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Ideally we shouldn't do this, as it's not recommended in mercurial
> documentation, but there's no other way to push multiple bookmarks (on
> the same branch), which would be the behavior most similar to git.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---

In the previous round you wanted me to exclude this one to force
split head at the remote, and I saw you and Max Horn discussing
(rather, shouting at each other ;-) why it is needed/desirable.

Have you changed your mind and you want this as part of the series,
or is it just you forgot to exclude it?

>  contrib/remote-helpers/git-remote-hg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index b54de1e..b784c54 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -722,7 +722,7 @@ def do_export(parser):
>              continue
>  
>      if peer:
> -        parser.repo.push(peer, force=False)
> +        parser.repo.push(peer, force=True)
>  
>      # handle bookmarks
>      for bmark, node in p_bmarks:

Re: [PATCH v2 13/13] remote-hg: push to the appropriate branch

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> From: Dusty Phillips <dusty@linux.ca>
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  contrib/remote-helpers/git-remote-hg | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index 56b3641..d82eb2d 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -625,6 +625,10 @@ def parse_commit(parser):
>      if merge_mark:
>          get_merge_files(repo, p1, p2, files)
>  
> +    # Check if the ref is supposed to be a named branch
> +    if ref.startswith('refs/heads/branches/'):
> +        extra['branch'] = ref.rpartition('/')[2]
> +

Is this meant to cut everything after "refs/heads/branches/", or cut
at the last slash?  I know rpartition does the latter, but I was
wondering if we see "refs/heads/branches/foo/bar" as its input here.

>      if mode == 'hg':
>          i = data.find('\n--HG--\n')
>          if i >= 0:

Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Felipe Contreras <felipe.contreras@gmail.com> writes:
> Ideally we shouldn't do this, as it's not recommended in mercurial
> documentation, but there's no other way to push multiple bookmarks (on
> the same branch), which would be the behavior most similar to git.

The problem is that you're interacting with a Mercurial upstream, not a
Git upstream.  When you're in their playground, you have to play by
their rules.  Creating new heads is disruptive and not likely to be
appreciated.

Re: [PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>
> In the previous round you wanted me to exclude this one to force
> split head at the remote, and I saw you and Max Horn discussing
> (rather, shouting at each other ;-) why it is needed/desirable.

No, that was "don't update bookmarks unnecessarily", and it seems you
skipped it appropriately.

> Have you changed your mind and you want this as part of the series,
> or is it just you forgot to exclude it?

Nope, I still see no reason not to push this.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Ideally we shouldn't do this, as it's not recommended in mercurial
>>> documentation, but there's no other way to push multiple bookmarks (on
>>> the same branch), which would be the behavior most similar to git.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>
>> In the previous round you wanted me to exclude this one to force
>> split head at the remote, and I saw you and Max Horn discussing
>> (rather, shouting at each other ;-) why it is needed/desirable.
>
> No, that was "don't update bookmarks unnecessarily", and it seems you
> skipped it appropriately.

OK.

Re: [PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

On Thu, Apr 4, 2013 at 12:17 PM, Jed Brown <jed@59a2.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
>
> The problem is that you're interacting with a Mercurial upstream, not a
> Git upstream.  When you're in their playground, you have to play by
> their rules.  Creating new heads is disruptive and not likely to be
> appreciated.

If that's the case, they should disable in the server, just like some
people disable non-fast-forward pushes in git.

The problem is Mercurial, purely and simple, without forcing the push,
how do you expect this to work?

% git clone hg::whatever
% git checkout -b feature-a master
# do stuff
% git push -u origin feature-a

If somebody made a single commit to master (default), you can't push
any more, you have to merge master to feature-a, and if you push
further changes to feature-a and somebody is blocked by that, they
need to merge feature-a to master. It's a completely nonsensical
workflow, and there's nothing _we_ can do about it.

However, it's easy to work around; simply create a 'bookmarks' branch
were people can push unlimited amounts of heads, problem solved. The
people working with traditional permanent branches won't be blocked by
other people pushing bookmarks in a git-like workflow.

Why punish the sane people?

However we can have a configuration to turn this on and off, I would
all it remote-hg.stop-me-from-doing-what-i-just-told-you-to-do. I
don't see the hurry though, specially if (according to you), remote-hg
can't even clone.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> If that's the case, they should disable in the server, just like some
> people disable non-fast-forward pushes in git.

I don't know how to make Hg allow new branches and bookmarks, but not
new anonymous heads.  Vanishly few Hg projects use a workflow anything
like topic branches so it's normally not a common thing to be creating
new heads.  If someone is using remote-hg, we can be pretty sure they
are not the primary maintainer, so if they are pushing, they'll be aware
of upstream policy and will need to play by those rules.

> The problem is Mercurial, purely and simple, without forcing the push,
> how do you expect this to work?
>
> % git clone hg::whatever
> % git checkout -b feature-a master
> # do stuff
> % git push -u origin feature-a

There is a difference between pushing a new branch (see 'hg push
--new-branch -b branch-name') and creating arbitrary new heads.  In a
very common case where multiple people are pushing to the same
branch/bookmark, force push creates new anonymous heads that share the
same branch.  (For less familiar readers, hg branches can have multiple
heads, though most commands will behave as though the latest head to
appear in the repository is the unique head associated with a given
branch.  Yes, it's insane.)

Normal workflow in case of new commits upstream is to 'hg pull --rebase' or
to pull and merge (yucky for first-parent, but most Hg users are far
from caring about such things).  Silently creating new anonymous heads
is a bad default.

Note: I don't know of any way to avoid the race condition when pushing
a bookmark that creates a new head since there is no 'hg push --new-bookmark'.

Re: [PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

On Thu, Apr 4, 2013 at 2:14 PM, Jed Brown <jed@59a2.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> If that's the case, they should disable in the server, just like some
>> people disable non-fast-forward pushes in git.
>
> I don't know how to make Hg allow new branches and bookmarks, but not
> new anonymous heads.

It's not possible to push new bookmarks without pushing new heads
(unless they are all reusing the same commits), and all the drawbacks
of doing that, Merucrial's UI make sure of that.

> Vanishly few Hg projects use a workflow anything
> like topic branches so it's normally not a common thing to be creating
> new heads.  If someone is using remote-hg, we can be pretty sure they
> are not the primary maintainer, so if they are pushing, they'll be aware
> of upstream policy and

> will need to play by those rules.

No, we don't. The fact that you say so doesn't make it so.

I create a branch felipec-bookmarks, and I push as many heads as I
wish. Who will get affected? Nobody. I already explained that, and you
conveniently avoided that paragraph in the reply.

>> The problem is Mercurial, purely and simple, without forcing the push,
>> how do you expect this to work?
>>
>> % git clone hg::whatever
>> % git checkout -b feature-a master
>> # do stuff
>> % git push -u origin feature-a
>
> There is a difference between pushing a new branch (see 'hg push
> --new-branch -b branch-name') and creating arbitrary new heads.

feature-a is not a branch, it's a bookmark, and bookmarks cannot be
pushed without creating new heads (essentially).

> Normal workflow in case of new commits upstream

And who says we are committing upstream?

> Note: I don't know of any way to avoid the race condition when pushing
> a bookmark that creates a new head since there is no 'hg push --new-bookmark'.

This is not about the race condition, and the race condition cannot be
fixed with the current design.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Felipe Contreras <felipe.contreras@gmail.com> writes:


[...]

>> will need to play by those rules.
>
> No, we don't. The fact that you say so doesn't make it so.

Then perhaps we have different goals [1].  I don't know any Git User that
would prefer to have an Hg upstream accessed through remote-hg.  We have
to assume that every Git (remote-hg) User is dealing with Hg Team that
is setting the rules, since otherwise Git User would just change the
whole damn project to Git and be done with it.  In that sense, it is
inappropriate to do things that are likely to make Hg Team yell at Git
User.

> I create a branch felipec-bookmarks, and I push as many heads as I
> wish. Who will get affected? Nobody.

Every Hg user will see those heads by default every time they run 'hg
log' or 'hg heads'.

> And who says we are committing upstream?

The discussion is moot if you don't want to push your commits upstream.


[1] As I mentioned earlier, I don't need either tool any more.

Re: [PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@59a2.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>
> [...]
>
>>> will need to play by those rules.
>>
>> No, we don't. The fact that you say so doesn't make it so.
>
> Then perhaps we have different goals [1].  I don't know any Git User that
> would prefer to have an Hg upstream accessed through remote-hg.

Who cares? If you don't know somebody, does that mean such person doesn't exist?

> We have
> to assume that every Git (remote-hg) User is dealing with Hg Team

No, we don't.

> that
> is setting the rules, since otherwise Git User would just change the
> whole damn project to Git and be done with it.  In that sense, it is
> inappropriate to do things that are likely to make Hg Team yell at Git
> User.

If you are always going to do Mercurial workflows, then what's the
point of using Git?

>> I create a branch felipec-bookmarks, and I push as many heads as I
>> wish. Who will get affected? Nobody.
>
> Every Hg user will see those heads by default every time they run 'hg
> log' or 'hg heads'.

Wow, catastrophic. BTW. Any commit pushed will show in 'hg log' either
way. And who will run 'hg heads' if, according to you, the project has
stated that new heads should not be pushed? If no new heads are
pushed, 'hg heads' will never show anything interesting.

Is that the *HUGE* problem? Too many heads will show in the arcane 'hg heads'?

>> And who says we are committing upstream?
>
> The discussion is moot if you don't want to push your commits upstream.

There are so many workflows and use cases you are completely ignoring.

Anyway, I'm not going to discuss with you any more, a configuration
option would work perfectly, and curiously you didn't comment on that.
It's quite clear that you are arguing for the sake of arguing, or at
least not looking for a solution.

Bye.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@59a2.org> wrote:
>>
>> Then perhaps we have different goals [1].  I don't know any Git User that
>> would prefer to have an Hg upstream accessed through remote-hg.
>
> Who cares? If you don't know somebody, does that mean such person
> doesn't exist?

Maybe I wasn't explicit enough:

    I don't know any Git User that would prefer to have an Hg upstream
    accessed through remote-hg *than to have a Git upstream accessed
    through native Git.*

>> We have
>> to assume that every Git (remote-hg) User is dealing with Hg Team
>
> No, we don't.

Really?  If there is no Hg Team, why bother with an Hg upstream?

> If you are always going to do Mercurial workflows, then what's the
> point of using Git?

Using Git workflow locally while being able to interact with the Hg Team
via whatever conventions they have established.  Sane branching, merge
strategies, rerere, and a host of other Git features are plenty useful,
even when contained within your personal repo.

> Wow, catastrophic. BTW. Any commit pushed will show in 'hg log' either
> way. And who will run 'hg heads' if, according to you, the project has
> stated that new heads should not be pushed? If no new heads are
> pushed, 'hg heads' will never show anything interesting.
>
> Is that the *HUGE* problem? Too many heads will show in the arcane 'hg
> heads'?

Hg displays warnings about multiple heads, suggests that you merge them
any time they are anonymous, and doesn't have remote namespaces so that
names can collide.  Remember that the most common reason people give for
using Hg in the first place is that it's "simpler" (yeah, I don't agree
either, but that's their story).  So don the hat of a Git (remote-hg)
User: You're interacting with people that don't understand version
control very well and only know the basic Hg command set.  Do you really
think it's okay to silently put them in a state where Hg will print
confusing messages about multiple heads, disrupt their workflow ('hg
log'), and suggest that they do things that are likely to be disruptive
(like merge those heads)?

I've spent the last five years as an active contributor to an Hg-based
project and throughout that time, newer contributors would constantly
get flustered over things like this and I would get the emails asking
what happened and how to fix it.  Over that five year period, several
other Hg projects that I was involved in switched to Git.  My statements
about what is likely to be acceptable to an Hg upstream is based on my
experience with these projects and with a couple remaining Hg holdouts
(scientific applications that I support through libraries).  In none of
those projects would a force push have been acceptable.

>>> And who says we are committing upstream?
>>
>> The discussion is moot if you don't want to push your commits upstream.
>
> There are so many workflows and use cases you are completely ignoring.

Examples?  I'm just summarizing the workflows that I encounter and that
other contributors to gitifyhg encounter.  You have said yourself that
you don't actually use remote-hg [1], so why are you so confident that
you know what workflows are desirable to remote-hg users?

> Anyway, I'm not going to discuss with you any more, a configuration
> option would work perfectly, and curiously you didn't comment on that.

Sorry, defaults matter and project philosophy matters.  The fact that we
are arguing about such basic things has convinced me that I can't
recommend remote-hg because I have no confidence that the behavior will
be remotely acceptable to a Git user working with an Hg Team.



My primary project switched to Git three weeks ago and there is already
less confusion, despite having adopted a master/next/topic branch
workflow that only two of us were familiar with prior to the switch.
For this reason, I no longer have a vested interest in remote helpers so
I don't intend to debate this issue further.

But please try to make tools for actual users rather than hypothetical
users, or at least don't act so incredulous when people are less than
thrilled about using or contributing to your project.


[1] http://article.gmane.org/gmane.comp.version-control.git/219988

Re: [PATCH v2 11/13] remote-hg: force remote push

[Felipe Contreras]

On Thu, Apr 4, 2013 at 4:27 PM, Jed Brown <jed@59a2.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@59a2.org> wrote:
>>>
>>> Then perhaps we have different goals [1].  I don't know any Git User that
>>> would prefer to have an Hg upstream accessed through remote-hg.
>>
>> Who cares? If you don't know somebody, does that mean such person
>> doesn't exist?
>
> Maybe I wasn't explicit enough:
>
>     I don't know any Git User that would prefer to have an Hg upstream
>     accessed through remote-hg *than to have a Git upstream accessed
>     through native Git.*

Yes, Git users prefer Git, how are such obvious statements advancing any point?

>>> We have
>>> to assume that every Git (remote-hg) User is dealing with Hg Team
>>
>> No, we don't.
>
> Really?  If there is no Hg Team, why bother with an Hg upstream?

Say, I push my stuff to Bitbucket, and tell my team to pull from
there. Bitbucket also has support for pull requests, so I push to
Bitbucket tons of branches, and then issue pull requests through the
web interface.

Making assumptions about how people's workflows only segregates users.
There is always a way to make it work for *everybody*.

>> Wow, catastrophic. BTW. Any commit pushed will show in 'hg log' either
>> way. And who will run 'hg heads' if, according to you, the project has
>> stated that new heads should not be pushed? If no new heads are
>> pushed, 'hg heads' will never show anything interesting.
>>
>> Is that the *HUGE* problem? Too many heads will show in the arcane 'hg
>> heads'?
>
> Hg displays warnings about multiple heads, suggests that you merge them
> any time they are anonymous, and doesn't have remote namespaces so that
> names can collide.  Remember that the most common reason people give for
> using Hg in the first place is that it's "simpler" (yeah, I don't agree
> either, but that's their story).  So don the hat of a Git (remote-hg)
> User: You're interacting with people that don't understand version
> control very well and only know the basic Hg command set.  Do you really
> think it's okay to silently put them in a state where Hg will print
> confusing messages about multiple heads, disrupt their workflow ('hg
> log'), and suggest that they do things that are likely to be disruptive
> (like merge those heads)?

They have to merge those heads *anyway*. The only question is who and when.

And of course this is a total red-herring, you are not answering the
question at all. Newbies don't run 'hg heads', and they don't have to,
there's no problem with a branch specific for bookmarks. None
whatsoever.

>>>> And who says we are committing upstream?
>>>
>>> The discussion is moot if you don't want to push your commits upstream.
>>
>> There are so many workflows and use cases you are completely ignoring.
>
> Examples?  I'm just summarizing the workflows that I encounter and that
> other contributors to gitifyhg encounter.  You have said yourself that
> you don't actually use remote-hg [1], so why are you so confident that
> you know what workflows are desirable to remote-hg users?

Because I've used them in the past, and because I see Bitbucket, and
because I have eyes.

>> Anyway, I'm not going to discuss with you any more, a configuration
>> option would work perfectly, and curiously you didn't comment on that.
>
> Sorry, defaults matter and project philosophy matters.  The fact that we
> are arguing about such basic things has convinced me that I can't
> recommend remote-hg because I have no confidence that the behavior will
> be remotely acceptable to a Git user working with an Hg Team.

Yes defaults matter, and forcing the push is the only sane default,
there is no other way to push bookmarks in Mercurial. Period.

If your team has a problem with it, you turn it off, problem solved.

And ultimately it doesn't matter what I say, we are in a public
mailing list where Junio can pick anybody's patches, even if I object.
But you have to prove your point, and you haven't. And be honest, you
not recommending remote-hg has nothing to do with the quality of it,
or the "philosophy" of it, it's simply because you made a different
choice, and you are emotionally attached to it.

> But please try to make tools for actual users rather than hypothetical
> users, or at least don't act so incredulous when people are less than
> thrilled about using or contributing to your project.

By people you mean you. Nobody else has complained.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Joachim Schmitz]

Jed Brown wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@59a2.org> wrote:
...
>>> We have
>>> to assume that every Git (remote-hg) User is dealing with Hg Team
>>
>> No, we don't.
>
> Really?  If there is no Hg Team, why bother with an Hg upstream?

Huh? the counterpart of "every user" wpuld be "some users" and not "no user" 
or "no HG team", isn't it? 

Re: [PATCH v2 13/13] remote-hg: push to the appropriate branch

[Felipe Contreras]

On Thu, Apr 4, 2013 at 10:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> From: Dusty Phillips <dusty@linux.ca>
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  contrib/remote-helpers/git-remote-hg | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
>> index 56b3641..d82eb2d 100755
>> --- a/contrib/remote-helpers/git-remote-hg
>> +++ b/contrib/remote-helpers/git-remote-hg
>> @@ -625,6 +625,10 @@ def parse_commit(parser):
>>      if merge_mark:
>>          get_merge_files(repo, p1, p2, files)
>>
>> +    # Check if the ref is supposed to be a named branch
>> +    if ref.startswith('refs/heads/branches/'):
>> +        extra['branch'] = ref.rpartition('/')[2]
>> +
>
> Is this meant to cut everything after "refs/heads/branches/", or cut
> at the last slash?  I know rpartition does the latter, but I was
> wondering if we see "refs/heads/branches/foo/bar" as its input here.

Good catch, it should be the former.

-- 
Felipe Contreras

Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown]

Joachim Schmitz <jojo@schmitz-digital.de> writes:

> Jed Brown wrote:
>>
>> Really?  If there is no Hg Team, why bother with an Hg upstream?
>
> Huh? the counterpart of "every user" wpuld be "some users" and not "no user" 
> or "no HG team", isn't it? 

I'm not sure what you're getting at here, but the whole premise of a
two-way git-remote-X is that the users of git-remote-X have less
influence in the project than the users of X have in the project.
Usually this means that the project workflow is whatever the X users
find comfortable rather than whatever git-remote-X users prefer.

If you are the sole publisher to a remote repository, sending pull
requests to upstream, and if they are comfortable with pulling bookmarks
(much more likely if they use a pull-request model rather than a shared
repo), then force-pushing by default is more reasonable.  An imperfect
analogy is Git's push.default=simple, which is more friendly to
beginners and to those sharing a remote.