{"thread":{"id":"55219","subject":"[RFC] new subcommand: git sync","startedAt":"2021-02-26T09:09:51Z","lastAt":"2021-03-01T13:56:39Z","messageCount":7,"participants":["Jean-Marie Lemetayer","Ævar Arnfjörð Bjarmason","Randall S. Becker","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"417886","messageId":"CAAdc0hwmR7BF53_66LNaceLrkFPDphU-y2sLEGB_1YoR5ErQsg@mail.gmail.com","threadId":"55219","inReplyTo":null,"subject":"[RFC] new subcommand: git sync","fromName":"Jean-Marie Lemetayer","fromEmail":"jeanmarie.lemetayer@gmail.com","sentAt":"2021-02-26T09:08:24Z","receivedAt":"2021-02-26T09:09:51Z","isPatch":false,"sender":{"key":"jeanmarie.lemetayer@gmail.com","avatar":null},"body":"Hi folks,\n\nI created a new \"git sync\" sub-command a few months ago to deal with the pull\nrequest workflow.\n\nIts goals are to:\n - keep all configured branches synchronized with the remotes (--set-upstream)\n - do not touch your wip feature branches (which has diverged from upstream)\n - prune the remotes\n\nAs I use it on a daily basis, to synchronize the remotes and then be able to\nquickly rebase my pull requests. I think it's worth sharing. What do you think?\n\nFor now it is a simple shell script available here:\nhttps://github.com/jmlemetayer/one-time-setup/blob/main/git-sync\n\nIf you think it's a good idea, I'll propose a series of patches with the new\nsub-command, the manual page and the associated tests.\n\nBest regards,\nJean-Marie Lemetayer\n"},{"id":"417894","messageId":"87tupy7sx6.fsf@evledraar.gmail.com","threadId":"55219","inReplyTo":"CAAdc0hwmR7BF53_66LNaceLrkFPDphU-y2sLEGB_1YoR5ErQsg@mail.gmail.com","subject":"Re: [RFC] new subcommand: git sync","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-02-26T15:25:09Z","receivedAt":"2021-02-26T15:25:58Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Feb 26 2021, Jean-Marie Lemetayer wrote:\n\n> Hi folks,\n>\n> I created a new \"git sync\" sub-command a few months ago to deal with the pull\n> request workflow.\n>\n> Its goals are to:\n> - keep all configured branches synchronized with the remotes (--set-upstream)\n> - do not touch your wip feature branches (which has diverged from upstream)\n> - prune the remotes\n>\n> As I use it on a daily basis, to synchronize the remotes and then be able to\n> quickly rebase my pull requests. I think it's worth sharing. What do you think?\n>\n> For now it is a simple shell script available here:\n> https://github.com/jmlemetayer/one-time-setup/blob/main/git-sync\n>\n> If you think it's a good idea, I'll propose a series of patches with the new\n> sub-command, the manual page and the associated tests.\n\nHave you seen 'git branch -v' and 'git branch -v --format=*'? There\nseems to be a high amount of overlap between this wrapper you've written\nand it.\n\nI suspect most of what you have here could be turned into an %(if:*)\ndirective where you emit the pull/push command as appropriate.\n\nIf you search the internet for \"git-sync\" there's dozens of such command\n(and I've personally observed at least two of them being written by\nco-workers in real time, not sure if either of those is in the Google\nresults).\n\nSo I think there's probably a worthwhile problem to be solved here that\ncould be turned into patches to git.git, something between \"git\n[clone|push] --mirror\" and \"git branch -v\".\n\nI don't think there's any interest in getting new shellscript built-ins\nin the future. We've been actively migrating away from those.\n\nBut most of the logic in your script is just calling the ref-filter.c\nAPI behind the scenes.\n\nB.t.w. you can probably speed up & simplify your script a lot by making\nuse of IFS=\"\" in the shell and not calling N for-each-ref commands when\nit seems to me that one invocation would do. Just dump the N fields you\nneed split on some token, and split on that token in your loop.\n"},{"id":"417903","messageId":"042b01d70c5e$593f0380$0bbd0a80$@nexbridge.com","threadId":"55219","inReplyTo":"87tupy7sx6.fsf@evledraar.gmail.com","subject":"RE: [RFC] new subcommand: git sync","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-02-26T16:42:13Z","receivedAt":"2021-02-26T17:16:27Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On February 26, 2021 10:25 AM, : Ævar Arnfjörð Bjarmason wrote:\n> To: Jean-Marie Lemetayer \n> Cc: git@vger.kernel.org\n> Subject: Re: [RFC] new subcommand: git sync\n> \n> On Fri, Feb 26 2021, Jean-Marie Lemetayer wrote:\n> \n> > Hi folks,\n> >\n> > I created a new \"git sync\" sub-command a few months ago to deal with\n> > the pull request workflow.\n> >\n> > Its goals are to:\n> > - keep all configured branches synchronized with the remotes\n> > (--set-upstream)\n> > - do not touch your wip feature branches (which has diverged from\n> > upstream)\n> > - prune the remotes\n> >\n> > As I use it on a daily basis, to synchronize the remotes and then be\n> > able to quickly rebase my pull requests. I think it's worth sharing. What do\n> you think?\n> >\n> > For now it is a simple shell script available here:\n> > https://github.com/jmlemetayer/one-time-setup/blob/main/git-sync\n> >\n> > If you think it's a good idea, I'll propose a series of patches with\n> > the new sub-command, the manual page and the associated tests.\n> \n> Have you seen 'git branch -v' and 'git branch -v --format=*'? There seems to\n> be a high amount of overlap between this wrapper you've written and it.\n> \n> I suspect most of what you have here could be turned into an %(if:*)\n> directive where you emit the pull/push command as appropriate.\n> \n> If you search the internet for \"git-sync\" there's dozens of such command\n> (and I've personally observed at least two of them being written by co-\n> workers in real time, not sure if either of those is in the Google results).\n> \n> So I think there's probably a worthwhile problem to be solved here that\n> could be turned into patches to git.git, something between \"git [clone|push]\n> --mirror\" and \"git branch -v\".\n> \n> I don't think there's any interest in getting new shellscript built-ins in the\n> future. We've been actively migrating away from those.\n> \n> But most of the logic in your script is just calling the ref-filter.c API behind the\n> scenes.\n> \n> B.t.w. you can probably speed up & simplify your script a lot by making use of\n> IFS=\"\" in the shell and not calling N for-each-ref commands when it seems to\n> me that one invocation would do. Just dump the N fields you need split on\n> some token, and split on that token in your loop.\n\nYeah, I'm one of those that has made extensive use of the name \"sync\" when using git to synchronize between (POSIX) OSS/USS and (Non-POSIX) NonStop/MVS respectively. If you're going somewhere with it, could I suggest something like \"reconcile\" or of it is specific to the pull workflow, maybe \"pull-sync\"? I agree that scripts are not desirable long-term.\n\nMy $0.02.\nRandall\n\n-- Brief whoami:\n NonStop developer since approximately 211288444200000000\n UNIX developer since approximately 421664400\n MVS developer a long time ago in a galaxy far far away\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"417917","messageId":"xmqq35xisbp3.fsf@gitster.g","threadId":"55219","inReplyTo":"87tupy7sx6.fsf@evledraar.gmail.com","subject":"Re: [RFC] new subcommand: git sync","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-02-26T22:31:36Z","receivedAt":"2021-02-26T22:32:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> B.t.w. you can probably speed up & simplify your script a lot by making\n> use of IFS=\"\" in the shell and not calling N for-each-ref commands when\n> it seems to me that one invocation would do. Just dump the N fields you\n> need split on some token, and split on that token in your loop.\n\nA hidden gem in for-each-ref is its ability to quote the placeholder\nvalues in a language specific way, and that is to allow the --format\nto generate a script that can be eval'ed. E.g.\n\n $ git for-each-ref --shell \\\n --format='doit %(authorname) %(subject)' refs/heads/ab/\\* |\n head -n 3\n doit 'Ævar Arnfjörð Bjarmason' 'branch: show \"HEAD detached\" first ...'\n doit 'Ævar Arnfjörð Bjarmason' 'CoC: update to version 2.0 + local ...'\n doit 'Ævar Arnfjörð Bjarmason' 'config.mak.uname: remove unused NEE...'\n\nso that you can prepare\n\n\tdoit () {\n\t\tperson=$1 subject=$2\n\t\t... do things on the branch data ...\n\t}\n\nbeforehand and then eval the output from the script you wrote with\n\"git for-each-ref\".\n\n\n"},{"id":"417920","messageId":"xmqqlfbaquv1.fsf@gitster.g","threadId":"55219","inReplyTo":"xmqq35xisbp3.fsf@gitster.g","subject":"Re: [RFC] new subcommand: git sync","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-02-26T23:20:34Z","receivedAt":"2021-02-26T23:21:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> so that you can prepare\n> ...\n> beforehand and then eval the output from the script you wrote with\n> \"git for-each-ref\".\n\nEhhh, not \"eval the output from the script\", but \"eval the script\".\nIn essense, you use \"for-each-ref --format\" as a tool to write a\nscript, and then execute it.\n"},{"id":"418022","messageId":"CAAdc0hw5O8aUQUdFnbUsiigdkhp_Sd6Djef3Hz9oA8XqN7Mhjg@mail.gmail.com","threadId":"55219","inReplyTo":"042b01d70c5e$593f0380$0bbd0a80$@nexbridge.com","subject":"Re: [RFC] new subcommand: git sync","fromName":"Jean-Marie Lemetayer","fromEmail":"jeanmarie.lemetayer@gmail.com","sentAt":"2021-03-01T09:48:04Z","receivedAt":"2021-03-01T09:53:33Z","isPatch":false,"sender":{"key":"jeanmarie.lemetayer@gmail.com","avatar":null},"body":"On Fri, Feb 26, 2021 at 5:42 PM Randall S. Becker\n wrote:\n>\n> On February 26, 2021 10:25 AM, : Ævar Arnfjörð Bjarmason wrote:\n> > To: Jean-Marie Lemetayer \n> > Cc: git@vger.kernel.org\n> > Subject: Re: [RFC] new subcommand: git sync\n> >\n> > On Fri, Feb 26 2021, Jean-Marie Lemetayer wrote:\n> >\n> > > Hi folks,\n> > >\n> > > I created a new \"git sync\" sub-command a few months ago to deal with\n> > > the pull request workflow.\n> > >\n> > > Its goals are to:\n> > > - keep all configured branches synchronized with the remotes\n> > > (--set-upstream)\n> > > - do not touch your wip feature branches (which has diverged from\n> > > upstream)\n> > > - prune the remotes\n> > >\n> > > As I use it on a daily basis, to synchronize the remotes and then be\n> > > able to quickly rebase my pull requests. I think it's worth sharing. What do\n> > you think?\n> > >\n> > > For now it is a simple shell script available here:\n> > > https://github.com/jmlemetayer/one-time-setup/blob/main/git-sync\n> > >\n> > > If you think it's a good idea, I'll propose a series of patches with\n> > > the new sub-command, the manual page and the associated tests.\n> >\n> > Have you seen 'git branch -v' and 'git branch -v --format=*'? There seems to\n> > be a high amount of overlap between this wrapper you've written and it.\n> >\n> > I suspect most of what you have here could be turned into an %(if:*)\n> > directive where you emit the pull/push command as appropriate.\n> >\n> > If you search the internet for \"git-sync\" there's dozens of such command\n> > (and I've personally observed at least two of them being written by co-\n> > workers in real time, not sure if either of those is in the Google results).\n> >\n> > So I think there's probably a worthwhile problem to be solved here that\n> > could be turned into patches to git.git, something between \"git [clone|push]\n> > --mirror\" and \"git branch -v\".\n> >\n> > I don't think there's any interest in getting new shellscript built-ins in the\n> > future. We've been actively migrating away from those.\n> >\n> > But most of the logic in your script is just calling the ref-filter.c API behind the\n> > scenes.\n> >\n> > B.t.w. you can probably speed up & simplify your script a lot by making use of\n> > IFS=\"\" in the shell and not calling N for-each-ref commands when it seems to\n> > me that one invocation would do. Just dump the N fields you need split on\n> > some token, and split on that token in your loop.\n>\n> Yeah, I'm one of those that has made extensive use of the name \"sync\" when using git to synchronize between (POSIX) OSS/USS and (Non-POSIX) NonStop/MVS respectively. If you're going somewhere with it, could I suggest something like \"reconcile\" or of it is specific to the pull workflow, maybe \"pull-sync\"? I agree that scripts are not desirable long-term.\n\nThanks for the feedback !\n\nTo sum up -- if I have the time to do it -- I must do it in native C\nand not use a generic name like \"sync\".\n\nAs it is a way to keep my branches up to date with the remotes, maybe\ncreate an option for the \"git branch\" submodule instead of a new\nsubcommand? Maybe \"git branch --synchronize\" or something better ...\n\nAs using \"Pull request\" is not the only way to use this command and\nalso because there is a big trolling issue with the termes\"Pull\nrequest\" and \"Merge request\" I don't think using \"pull-sync\" is a good\nidea either.\n\nI know that the first golden rule of coding is \"Naming\", but damn,\nsometimes it's hard to find a good name.\n\nBest regards,\nJean-Marie\n"},{"id":"418036","messageId":"008d01d70ea2$90f0f400$b2d2dc00$@nexbridge.com","threadId":"55219","inReplyTo":"CAAdc0hw5O8aUQUdFnbUsiigdkhp_Sd6Djef3Hz9oA8XqN7Mhjg@mail.gmail.com","subject":"RE: [RFC] new subcommand: git sync","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-03-01T13:55:35Z","receivedAt":"2021-03-01T13:56:39Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 1, 2021 4:48 AM, Jean-Marie Lemetayer wrote:\n> To: Randall S. Becker \n> Cc: Ævar Arnfjörð Bjarmason ; git@vger.kernel.org\n> Subject: Re: [RFC] new subcommand: git sync\n> \n> On Fri, Feb 26, 2021 at 5:42 PM Randall S. Becker \n> wrote:\n> >\n> > On February 26, 2021 10:25 AM, : Ævar Arnfjörð Bjarmason wrote:\n> > > To: Jean-Marie Lemetayer \n> > > Cc: git@vger.kernel.org\n> > > Subject: Re: [RFC] new subcommand: git sync\n> > >\n> > > On Fri, Feb 26 2021, Jean-Marie Lemetayer wrote:\n> > >\n> > > > Hi folks,\n> > > >\n> > > > I created a new \"git sync\" sub-command a few months ago to deal\n> > > > with the pull request workflow.\n> > > >\n> > > > Its goals are to:\n> > > > - keep all configured branches synchronized with the remotes\n> > > > (--set-upstream)\n> > > > - do not touch your wip feature branches (which has diverged from\n> > > > upstream)\n> > > > - prune the remotes\n> > > >\n> > > > As I use it on a daily basis, to synchronize the remotes and then\n> > > > be able to quickly rebase my pull requests. I think it's worth\n> > > > sharing. What do\n> > > you think?\n> > > >\n> > > > For now it is a simple shell script available here:\n> > > > https://github.com/jmlemetayer/one-time-setup/blob/main/git-sync\n> > > >\n> > > > If you think it's a good idea, I'll propose a series of patches\n> > > > with the new sub-command, the manual page and the associated tests.\n> > >\n> > > Have you seen 'git branch -v' and 'git branch -v --format=*'? There\n> > > seems to be a high amount of overlap between this wrapper you've\n> written and it.\n> > >\n> > > I suspect most of what you have here could be turned into an %(if:*)\n> > > directive where you emit the pull/push command as appropriate.\n> > >\n> > > If you search the internet for \"git-sync\" there's dozens of such\n> > > command (and I've personally observed at least two of them being\n> > > written by co- workers in real time, not sure if either of those is in the\n> Google results).\n> > >\n> > > So I think there's probably a worthwhile problem to be solved here\n> > > that could be turned into patches to git.git, something between \"git\n> > > [clone|push] --mirror\" and \"git branch -v\".\n> > >\n> > > I don't think there's any interest in getting new shellscript\n> > > built-ins in the future. We've been actively migrating away from those.\n> > >\n> > > But most of the logic in your script is just calling the\n> > > ref-filter.c API behind the scenes.\n> > >\n> > > B.t.w. you can probably speed up & simplify your script a lot by\n> > > making use of IFS=\"\" in the shell and not calling N for-each-ref\n> > > commands when it seems to me that one invocation would do. Just\n> dump\n> > > the N fields you need split on some token, and split on that token in your\n> loop.\n> >\n> > Yeah, I'm one of those that has made extensive use of the name \"sync\"\n> when using git to synchronize between (POSIX) OSS/USS and (Non-POSIX)\n> NonStop/MVS respectively. If you're going somewhere with it, could I\n> suggest something like \"reconcile\" or of it is specific to the pull workflow,\n> maybe \"pull-sync\"? I agree that scripts are not desirable long-term.\n> \n> Thanks for the feedback !\n> \n> To sum up -- if I have the time to do it -- I must do it in native C and not use a\n> generic name like \"sync\".\n> \n> As it is a way to keep my branches up to date with the remotes, maybe\n> create an option for the \"git branch\" submodule instead of a new\n> subcommand? Maybe \"git branch --synchronize\" or something better ...\n> \n> As using \"Pull request\" is not the only way to use this command and also\n> because there is a big trolling issue with the termes\"Pull request\" and\n> \"Merge request\" I don't think using \"pull-sync\" is a good idea either.\n> \n> I know that the first golden rule of coding is \"Naming\", but damn, sometimes\n> it's hard to find a good name.\n\nIt's almost feels like you are thinking along the lines of a variant of a mirror rather than pulls and merges. I wonder whether that analogy would hold up? I would love to have a stable mechanism of mirroring repositories when doing development on 2-3 platforms at the same time. Yes, pull/merge can be a bit heavy handed in this situation. I have considered something like rsync to do the job (which it can), but within a git context it sounds more like a mirror - although it would be nice to mirror work in progress. So perhaps this should go through the stash mechanism.\n\n"}]}