{"thread":{"id":"33790","subject":"Cannot push anything via export transport helper after push fails.","startedAt":"2013-05-11T12:29:36Z","lastAt":"2014-04-12T21:24:14Z","messageCount":9,"participants":["Andrey Borzenkov","John Keeping","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"216994","messageId":"20130511162936.0354e5d7@opensuse.site","threadId":"33790","inReplyTo":null,"subject":"Cannot push anything via export transport helper after push fails.","fromName":"Andrey Borzenkov","fromEmail":"arvidjaar@gmail.com","sentAt":"2013-05-11T12:29:36Z","receivedAt":"2013-05-11T12:29:36Z","isPatch":false,"sender":{"key":"arvidjaar@gmail.com","avatar":null},"body":"I noticed that using git-remote-bzr, but as far as I can tell this is\ngeneric for all transport helpers using fast-export.\n\n\n\nWhat happened was \"git push\" failed due to merge conflict. So far so\ngood - but from now on git assumes everything is up to date.\n\nbor@opensuse:/tmp/test/git> git push origin master\nTo bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n ! [rejected]        master -> master (non-fast-forward)\nerror: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\nhint: before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details.\nbor@opensuse:/tmp/test/git> git push origin master\nEverything up-to-date\nbor@opensuse:/tmp/test/git> \n\nThe problem seems to be that git fast-export updates marks\nunconditionally, whether export actually applied or not. So next time\nit assumes everything is already exported and does nothing.\n\nIs it expected behavior?\n\nTIA\n\n-andrey\n"},{"id":"216995","messageId":"20130511123626.GD2299@serenity.lan","threadId":"33790","inReplyTo":"20130511162936.0354e5d7@opensuse.site","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-11T12:36:26Z","receivedAt":"2013-05-11T12:36:26Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:\n> I noticed that using git-remote-bzr, but as far as I can tell this is\n> generic for all transport helpers using fast-export.\n> \n> \n> \n> What happened was \"git push\" failed due to merge conflict. So far so\n> good - but from now on git assumes everything is up to date.\n> \n> bor@opensuse:/tmp/test/git> git push origin master\n> To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n>  ! [rejected]        master -> master (non-fast-forward)\n> error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> hint: Updates were rejected because the tip of your current branch is behind\n> hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> hint: before pushing again.\n> hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> bor@opensuse:/tmp/test/git> git push origin master\n> Everything up-to-date\n> bor@opensuse:/tmp/test/git> \n> \n> The problem seems to be that git fast-export updates marks\n> unconditionally, whether export actually applied or not. So next time\n> it assumes everything is already exported and does nothing.\n> \n> Is it expected behavior?\n\nWhat version of Git are you using?\n\nThis sounds similar to the regression fixed by commit 126aac5\n(transport-helper: fix remote helper namespace regression, 2013-05-10)\nbut that was only introduced in commit 664059f (transport-helper: update\nremote helper namespace, 2013-04-17) which isn't in any released\nversions of Git.\n"},{"id":"217003","messageId":"20130511174447.094cc76d@opensuse.site","threadId":"33790","inReplyTo":"20130511123626.GD2299@serenity.lan","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Andrey Borzenkov","fromEmail":"arvidjaar@gmail.com","sentAt":"2013-05-11T13:44:47Z","receivedAt":"2013-05-11T13:44:47Z","isPatch":false,"sender":{"key":"arvidjaar@gmail.com","avatar":null},"body":"В Sat, 11 May 2013 13:36:26 +0100\nJohn Keeping <john@keeping.me.uk> пишет:\n\n> On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:\n> > I noticed that using git-remote-bzr, but as far as I can tell this is\n> > generic for all transport helpers using fast-export.\n> > \n> > \n> > \n> > What happened was \"git push\" failed due to merge conflict. So far so\n> > good - but from now on git assumes everything is up to date.\n> > \n> > bor@opensuse:/tmp/test/git> git push origin master\n> > To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n> >  ! [rejected]        master -> master (non-fast-forward)\n> > error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> > hint: Updates were rejected because the tip of your current branch is behind\n> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> > hint: before pushing again.\n> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> > bor@opensuse:/tmp/test/git> git push origin master\n> > Everything up-to-date\n> > bor@opensuse:/tmp/test/git> \n> > \n> > The problem seems to be that git fast-export updates marks\n> > unconditionally, whether export actually applied or not. So next time\n> > it assumes everything is already exported and does nothing.\n> > \n> > Is it expected behavior?\n> \n> What version of Git are you using?\n> \n\nbor@opensuse:~/src/git> rpm -q git\ngit-1.8.1.4-1.1.1.x86_64\n\n> This sounds similar to the regression fixed by commit 126aac5\n> (transport-helper: fix remote helper namespace regression, 2013-05-10)\n> but that was only introduced in commit 664059f (transport-helper: update\n> remote helper namespace, 2013-04-17) which isn't in any released\n> versions of Git.\n\nYes, it sounds similar, but likely the different issue. This can be\ndemonstrated without any transport-helper involved.\n\nbor@opensuse:/tmp/test/git> cat .git/bzr/origin/marks-git \n:4 7ee7c98504aa12cb82a18978ebef37900b3a5dfb\n:2 91fc7db33a662ae294699945631239365eb12880\nbor@opensuse:/tmp/test/git> git rev-list HEAD\n7ee7c98504aa12cb82a18978ebef37900b3a5dfb\n91fc7db33a662ae294699945631239365eb12880\nbor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git HEAD\nbor@opensuse:/tmp/test/git> git rev-list master...origin/master\n7ee7c98504aa12cb82a18978ebef37900b3a5dfb\nbor@opensuse:/tmp/test/git> git rev-list master...bzr/origin/heads/master\n7ee7c98504aa12cb82a18978ebef37900b3a5dfb\nbor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git HEAD...bzr/origin/heads/master\nbor@opensuse:/tmp/test/git> git fast-export --import-marks=.git/bzr/origin/marks-git master...bzr/origin/heads/master\nbor@opensuse:/tmp/test/git> \n\nSo in this particular case the problem is in git-fast-export. Actually\nthis behavior seems to documented:\n\n           Any commits that have already been marked will not be exported\n           again.\n\nMay be the right thing would be to write only those marks that had\nbeen confirmed by remote helper. But that as far as I understand\nrequires some interaction between remote helper and git-fast-export. \n"},{"id":"217004","messageId":"CAMP44s1YhQR0o-0CLc2PG-EJTZdN4tha-4BVEUy-K_Av81D=GQ@mail.gmail.com","threadId":"33790","inReplyTo":"20130511162936.0354e5d7@opensuse.site","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-11T13:57:14Z","receivedAt":"2013-05-11T13:57:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:\n> I noticed that using git-remote-bzr, but as far as I can tell this is\n> generic for all transport helpers using fast-export.\n>\n>\n>\n> What happened was \"git push\" failed due to merge conflict. So far so\n> good - but from now on git assumes everything is up to date.\n>\n> bor@opensuse:/tmp/test/git> git push origin master\n> To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n>  ! [rejected]        master -> master (non-fast-forward)\n> error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> hint: Updates were rejected because the tip of your current branch is behind\n> hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> hint: before pushing again.\n> hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> bor@opensuse:/tmp/test/git> git push origin master\n> Everything up-to-date\n> bor@opensuse:/tmp/test/git>\n>\n> The problem seems to be that git fast-export updates marks\n> unconditionally, whether export actually applied or not. So next time\n> it assumes everything is already exported and does nothing.\n>\n> Is it expected behavior?\n\nIndeed, this is the way it currently works, and it's not easy to fix.\nWe would need some way to make fast-export wait until we know the exit\nstatus of the remote helper, and then tell it when it failed, so the\nmarks are not updated.\n\nHowever, the way remote-bzr/hg work is that the commits are still\nthere anyway. So if you merge the next time you push those commits are\nalready converted, so it's not a problem if fast-export is not\nexporting them again.\n\nSo even though it's not ideal, it should work.\n\nThe problem is when the remote-helper crashes and the marks of\nfast-export and the remote-helper are out of sync, and then the user\nis really screwed.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"217031","messageId":"20130511224837.39a1c551@opensuse.site","threadId":"33790","inReplyTo":"CAMP44s1YhQR0o-0CLc2PG-EJTZdN4tha-4BVEUy-K_Av81D=GQ@mail.gmail.com","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Andrey Borzenkov","fromEmail":"arvidjaar@gmail.com","sentAt":"2013-05-11T18:48:37Z","receivedAt":"2013-05-11T18:48:37Z","isPatch":false,"sender":{"key":"arvidjaar@gmail.com","avatar":null},"body":"В Sat, 11 May 2013 08:57:14 -0500\nFelipe Contreras <felipe.contreras@gmail.com> пишет:\n\n> >\n> > The problem seems to be that git fast-export updates marks\n> > unconditionally, whether export actually applied or not. So next time\n> > it assumes everything is already exported and does nothing.\n> >\n> > Is it expected behavior?\n> \n> Indeed, this is the way it currently works, and it's not easy to fix.\n> We would need some way to make fast-export wait until we know the exit\n> status of the remote helper, and then tell it when it failed, so the\n> marks are not updated.\n> \n\nOne possibility would be to omit *export-marks and manage GIT marks in\nremote helper as well. Helper would then update synchronously both GIT\nand BZR marks if no errors were detected. Or even better, it could\nupdate just those commits that had been successful.\n\n> However, the way remote-bzr/hg work is that the commits are still\n> there anyway. So if you merge the next time you push those commits are\n> already converted, so it's not a problem if fast-export is not\n> exporting them again.\n> \n\nAs I understand bzr commit ID is stable. What happens if we try to\ncommit the same ID second time?\n\n> So even though it's not ideal, it should work.\n> \n\nI'm more concerned about transport errors. Any network glitch during\npush renders you repository unusable (at least, without much efforts).\n\n> The problem is when the remote-helper crashes and the marks of\n> fast-export and the remote-helper are out of sync, and then the user\n> is really screwed.\n> \n\nThis case would benefit from moving processing of GIT marks into remote\nhelper as well.\n"},{"id":"217044","messageId":"CAMP44s2XGcJT3SXFGVbKWdQMn8QuCCJ9MVob-CsZSM8O8aUy8A@mail.gmail.com","threadId":"33790","inReplyTo":"20130511224837.39a1c551@opensuse.site","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-11T21:17:37Z","receivedAt":"2013-05-11T21:17:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 11, 2013 at 1:48 PM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:\n> В Sat, 11 May 2013 08:57:14 -0500\n> Felipe Contreras <felipe.contreras@gmail.com> пишет:\n>\n>> >\n>> > The problem seems to be that git fast-export updates marks\n>> > unconditionally, whether export actually applied or not. So next time\n>> > it assumes everything is already exported and does nothing.\n>> >\n>> > Is it expected behavior?\n>>\n>> Indeed, this is the way it currently works, and it's not easy to fix.\n>> We would need some way to make fast-export wait until we know the exit\n>> status of the remote helper, and then tell it when it failed, so the\n>> marks are not updated.\n>>\n>\n> One possibility would be to omit *export-marks and manage GIT marks in\n> remote helper as well. Helper would then update synchronously both GIT\n> and BZR marks if no errors were detected. Or even better, it could\n> update just those commits that had been successful.\n\nThat would need to change the whole architecture, because right now\nthe remote helpers are agnostic of Git SHA-1s.\n\n>> However, the way remote-bzr/hg work is that the commits are still\n>> there anyway. So if you merge the next time you push those commits are\n>> already converted, so it's not a problem if fast-export is not\n>> exporting them again.\n>>\n>\n> As I understand bzr commit ID is stable. What happens if we try to\n> commit the same ID second time?\n\nIt's skipped, because it's already converted.\n\n>> So even though it's not ideal, it should work.\n>>\n>\n> I'm more concerned about transport errors. Any network glitch during\n> push renders you repository unusable (at least, without much efforts).\n\nNo, it doesn't. If the remote-helper fails gracefully, the bzr\nrevisions are converted and stored in the bzr repo, even if they were\nnot pushed to the remote. So it's OK if fast-export never exports them\nagain; we already have them.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"217629","messageId":"20130516213856.2deba50d@opensuse.site","threadId":"33790","inReplyTo":"CAMP44s1YhQR0o-0CLc2PG-EJTZdN4tha-4BVEUy-K_Av81D=GQ@mail.gmail.com","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Andrey Borzenkov","fromEmail":"arvidjaar@gmail.com","sentAt":"2013-05-16T17:38:56Z","receivedAt":"2013-05-16T17:38:56Z","isPatch":false,"sender":{"key":"arvidjaar@gmail.com","avatar":null},"body":"В Sat, 11 May 2013 08:57:14 -0500\nFelipe Contreras <felipe.contreras@gmail.com> пишет:\n\n> On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:\n> > I noticed that using git-remote-bzr, but as far as I can tell this is\n> > generic for all transport helpers using fast-export.\n> >\n> >\n> >\n> > What happened was \"git push\" failed due to merge conflict. So far so\n> > good - but from now on git assumes everything is up to date.\n> >\n> > bor@opensuse:/tmp/test/git> git push origin master\n> > To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n> >  ! [rejected]        master -> master (non-fast-forward)\n> > error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> > hint: Updates were rejected because the tip of your current branch is behind\n> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> > hint: before pushing again.\n> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> > bor@opensuse:/tmp/test/git> git push origin master\n> > Everything up-to-date\n> > bor@opensuse:/tmp/test/git>\n> >\n> > The problem seems to be that git fast-export updates marks\n> > unconditionally, whether export actually applied or not. So next time\n> > it assumes everything is already exported and does nothing.\n> >\n> > Is it expected behavior?\n> \n> Indeed, this is the way it currently works, and it's not easy to fix.\n> We would need some way to make fast-export wait until we know the exit\n> status of the remote helper, and then tell it when it failed, so the\n> marks are not updated.\n> \n\nHmm ... actually as far as I understand transport-helper keeps track of\nwhich revisions to push in \"remote helper ref\" (for the lack of better\nword). This makes use of marks as tracking means rather redundant.\n\nWhat about the idea below? This relies on transport helper to provide\ncorrect revisions and uses marks exclusively as cross-reference between\nGIT and remote SCM. It is on top of next branch.\n\n\n---\n builtin/fast-export.c                 | 15 ++++++++++-----\n contrib/remote-helpers/git-remote-bzr | 11 ++++++++---\n transport-helper.c                    |  7 ++++++-\n 3 files changed, 24 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/fast-export.c b/builtin/fast-export.c\nindex d60d675..5bc4b3c 100644\n--- a/builtin/fast-export.c\n+++ b/builtin/fast-export.c\n@@ -29,6 +29,7 @@ static enum { ERROR, DROP, REWRITE } tag_of_filtered_mode = ERROR;\n static int fake_missing_tagger;\n static int use_done_feature;\n static int no_data;\n+static int do_not_skip_marked_commits;\n static int full_tree;\n \n static int parse_opt_signed_tag_mode(const struct option *opt,\n@@ -95,7 +96,8 @@ static inline void mark_object(struct object *object, uint32_t mark)\n \n static inline void mark_next_object(struct object *object)\n {\n-\tmark_object(object, ++last_idnum);\n+\tif (!(do_not_skip_marked_commits && lookup_decoration(&idnums, object)))\n+\t\tmark_object(object, ++last_idnum);\n }\n \n static int get_object_mark(struct object *object)\n@@ -144,7 +146,7 @@ static void export_blob(const unsigned char *sha1)\n \n \tmark_next_object(object);\n \n-\tprintf(\"blob\\nmark :%\"PRIu32\"\\ndata %lu\\n\", last_idnum, size);\n+\tprintf(\"blob\\nmark :%\"PRIu32\"\\ndata %lu\\n\", get_object_mark(object), size);\n \tif (size && fwrite(buf, size, 1, stdout) != 1)\n \t\tdie_errno (\"Could not write blob '%s'\", sha1_to_hex(sha1));\n \tprintf(\"\\n\");\n@@ -326,7 +328,7 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)\n \tif (!commit->parents)\n \t\tprintf(\"reset %s\\n\", (const char*)commit->util);\n \tprintf(\"commit %s\\nmark :%\"PRIu32\"\\n%.*s\\n%.*s\\ndata %u\\n%s\",\n-\t       (const char *)commit->util, last_idnum,\n+\t       (const char *)commit->util, get_object_mark(&commit->object),\n \t       (int)(author_end - author), author,\n \t       (int)(committer_end - committer), committer,\n \t       (unsigned)(reencoded\n@@ -631,7 +633,7 @@ static void import_marks(char *input_file)\n \t\tif (!object)\n \t\t\tcontinue;\n \n-\t\tif (object->flags & SHOWN)\n+\t\tif (get_object_mark(object))\n \t\t\terror(\"Object %s already has a mark\", sha1_to_hex(sha1));\n \n \t\tif (object->type != OBJ_COMMIT)\n@@ -640,7 +642,8 @@ static void import_marks(char *input_file)\n \n \t\tmark_object(object, mark);\n \n-\t\tobject->flags |= SHOWN;\n+\t\tif (!do_not_skip_marked_commits)\n+\t\t\tobject->flags |= SHOWN;\n \t}\n \tfclose(f);\n }\n@@ -673,6 +676,8 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN(0, \"use-done-feature\", &use_done_feature,\n \t\t\t     N_(\"Use the done feature to terminate the stream\")),\n \t\tOPT_BOOL(0, \"no-data\", &no_data, N_(\"Skip output of blob data\")),\n+\t\tOPT_BOOL(0, \"do-not-skip-marked-commits\", &do_not_skip_marked_commits,\n+\t\t\t     N_(\"Do not skip marked commits\")),\n \t\tOPT_END()\n \t};\n \ndiff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr\nindex 3e452af..24a9a99 100755\n--- a/contrib/remote-helpers/git-remote-bzr\n+++ b/contrib/remote-helpers/git-remote-bzr\n@@ -629,7 +629,12 @@ def parse_commit(parser):\n \n     committer, date, tz = committer\n     parents = [mark_to_rev(p) for p in parents]\n-    revid = bzrlib.generate_ids.gen_revision_id(committer, date)\n+    try:\n+        revid = mark_to_rev(commit_mark)\n+    except KeyError:\n+        revid = bzrlib.generate_ids.gen_revision_id(committer, date)\n+        marks.new_mark(revid, commit_mark)\n+\n     props = {}\n     props['branch-nick'] = branch.nick\n \n@@ -650,7 +655,6 @@ def parse_commit(parser):\n         branch.unlock()\n \n     parsed_refs[ref] = revid\n-    marks.new_mark(revid, commit_mark)\n \n def parse_reset(parser):\n     global parsed_refs\n@@ -692,12 +696,12 @@ def do_export(parser):\n         if ref.startswith('refs/heads/'):\n             name = ref[len('refs/heads/'):]\n             branch = bzrlib.branch.Branch.open(branches[name])\n-            branch.generate_revision_history(revid, marks.get_tip(name))\n \n             if name in peers:\n                 peer = bzrlib.branch.Branch.open(peers[name])\n                 try:\n                     peer.bzrdir.push_branch(branch, revision_id=revid)\n+                    branch.generate_revision_history(revid, marks.get_tip(name))\n                 except bzrlib.errors.DivergedBranches:\n                     print \"error %s non-fast forward\" % ref\n                     continue\n@@ -732,6 +736,7 @@ def do_capabilities(parser):\n     if os.path.exists(path):\n         print \"*import-marks %s\" % path\n     print \"*export-marks %s\" % path\n+    print \"*full-marks\"\n \n     print\n \ndiff --git a/transport-helper.c b/transport-helper.c\nindex 2f5ac3f..3f1f2d7 100644\n--- a/transport-helper.c\n+++ b/transport-helper.c\n@@ -27,6 +27,7 @@ struct helper_data {\n \t\tpush : 1,\n \t\tconnect : 1,\n \t\tsigned_tags : 1,\n+\t\tfull_marks : 1,\n \t\tno_disconnect_req : 1;\n \tchar *export_marks;\n \tchar *import_marks;\n@@ -195,6 +196,8 @@ static struct child_process *get_helper(struct transport *transport)\n \t\t\tdata->connect = 1;\n \t\t} else if (!strcmp(capname, \"signed-tags\")) {\n \t\t\tdata->signed_tags = 1;\n+\t\t} else if (!strcmp(capname, \"full-marks\")) {\n+\t\t\tdata->full_marks = 1;\n \t\t} else if (!prefixcmp(capname, \"export-marks \")) {\n \t\t\tstruct strbuf arg = STRBUF_INIT;\n \t\t\tstrbuf_addstr(&arg, \"--export-marks=\");\n@@ -415,11 +418,13 @@ static int get_exporter(struct transport *transport,\n \t/* we need to duplicate helper->in because we want to use it after\n \t * fastexport is done with it. */\n \tfastexport->out = dup(helper->in);\n-\tfastexport->argv = xcalloc(6 + revlist_args->nr, sizeof(*fastexport->argv));\n+\tfastexport->argv = xcalloc(7 + revlist_args->nr, sizeof(*fastexport->argv));\n \tfastexport->argv[argc++] = \"fast-export\";\n \tfastexport->argv[argc++] = \"--use-done-feature\";\n \tfastexport->argv[argc++] = data->signed_tags ?\n \t\t\"--signed-tags=verbatim\" : \"--signed-tags=warn-strip\";\n+\tif (data->full_marks)\n+\t\tfastexport->argv[argc++] = \"--do-not-skip-marked-commits\";\n \tif (data->export_marks)\n \t\tfastexport->argv[argc++] = data->export_marks;\n \tif (data->import_marks)\n-- \ntg: (2a9af4b..) t/marks-shown (depends on: next)\n"},{"id":"238795","messageId":"5349ae827ef03_285f9032ecd1@nysa.notmuch","threadId":"33790","inReplyTo":"CAMP44s1YhQR0o-0CLc2PG-EJTZdN4tha-4BVEUy-K_Av81D=GQ@mail.gmail.com","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-12T21:22:10Z","receivedAt":"2014-04-12T21:22:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:\n> > I noticed that using git-remote-bzr, but as far as I can tell this is\n> > generic for all transport helpers using fast-export.\n> >\n> >\n> >\n> > What happened was \"git push\" failed due to merge conflict. So far so\n> > good - but from now on git assumes everything is up to date.\n> >\n> > bor@opensuse:/tmp/test/git> git push origin master\n> > To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n> >  ! [rejected]        master -> master (non-fast-forward)\n> > error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> > hint: Updates were rejected because the tip of your current branch is behind\n> > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> > hint: before pushing again.\n> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> > bor@opensuse:/tmp/test/git> git push origin master\n> > Everything up-to-date\n> > bor@opensuse:/tmp/test/git>\n> >\n> > The problem seems to be that git fast-export updates marks\n> > unconditionally, whether export actually applied or not. So next time\n> > it assumes everything is already exported and does nothing.\n> >\n> > Is it expected behavior?\n> \n> Indeed, this is the way it currently works, and it's not easy to fix.\n> We would need some way to make fast-export wait until we know the exit\n> status of the remote helper, and then tell it when it failed, so the\n> marks are not updated.\n> \n> However, the way remote-bzr/hg work is that the commits are still\n> there anyway. So if you merge the next time you push those commits are\n> already converted, so it's not a problem if fast-export is not\n> exporting them again.\n> \n> So even though it's not ideal, it should work.\n> \n> The problem is when the remote-helper crashes and the marks of\n> fast-export and the remote-helper are out of sync, and then the user\n> is really screwed.\n\nI sent patches that should fix this problem:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/246187\n\n-- \nFelipe Contreras\n"},{"id":"238796","messageId":"5349aefe85652_285f9032ec14@nysa.notmuch","threadId":"33790","inReplyTo":"20130516213856.2deba50d@opensuse.site","subject":"Re: Cannot push anything via export transport helper after push fails.","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-12T21:24:14Z","receivedAt":"2014-04-12T21:24:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andrey Borzenkov wrote:\n> В Sat, 11 May 2013 08:57:14 -0500\n> Felipe Contreras <felipe.contreras@gmail.com> пишет:\n> \n> > On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:\n> > > I noticed that using git-remote-bzr, but as far as I can tell this is\n> > > generic for all transport helpers using fast-export.\n> > >\n> > >\n> > >\n> > > What happened was \"git push\" failed due to merge conflict. So far so\n> > > good - but from now on git assumes everything is up to date.\n> > >\n> > > bor@opensuse:/tmp/test/git> git push origin master\n> > > To bzr::bzr+ssh://bor@localhost/tmp/test/bzr\n> > >  ! [rejected]        master -> master (non-fast-forward)\n> > > error: failed to push some refs to 'bzr::bzr+ssh://bor@localhost/tmp/test/bzr'\n> > > hint: Updates were rejected because the tip of your current branch is behind\n> > > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')\n> > > hint: before pushing again.\n> > > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> > > bor@opensuse:/tmp/test/git> git push origin master\n> > > Everything up-to-date\n> > > bor@opensuse:/tmp/test/git>\n> > >\n> > > The problem seems to be that git fast-export updates marks\n> > > unconditionally, whether export actually applied or not. So next time\n> > > it assumes everything is already exported and does nothing.\n> > >\n> > > Is it expected behavior?\n> > \n> > Indeed, this is the way it currently works, and it's not easy to fix.\n> > We would need some way to make fast-export wait until we know the exit\n> > status of the remote helper, and then tell it when it failed, so the\n> > marks are not updated.\n> > \n> \n> Hmm ... actually as far as I understand transport-helper keeps track of\n> which revisions to push in \"remote helper ref\" (for the lack of better\n> word). This makes use of marks as tracking means rather redundant.\n> \n> What about the idea below? This relies on transport helper to provide\n> correct revisions and uses marks exclusively as cross-reference between\n> GIT and remote SCM. It is on top of next branch.\n\nThis is one way of using it, but not ideal, and I think the patch series I sent\nshould work for all remote helpers.\n\n-- \nFelipe Contreras"}]}