On Fri, Feb 26, 2021 at 5:42 PM Randall S. Becker <rsbecker@xxxxxxxxxxxxx> wrote: > > On February 26, 2021 10:25 AM, : Ævar Arnfjörð Bjarmason wrote: > > To: Jean-Marie Lemetayer <jeanmarie.lemetayer@xxxxxxxxx> > > Cc: git@xxxxxxxxxxxxxxx > > Subject: Re: [RFC] new subcommand: git sync > > > > On Fri, Feb 26 2021, Jean-Marie Lemetayer wrote: > > > > > Hi folks, > > > > > > I created a new "git sync" sub-command a few months ago to deal with > > > the pull request workflow. > > > > > > Its goals are to: > > > - keep all configured branches synchronized with the remotes > > > (--set-upstream) > > > - do not touch your wip feature branches (which has diverged from > > > upstream) > > > - prune the remotes > > > > > > As I use it on a daily basis, to synchronize the remotes and then be > > > able to quickly rebase my pull requests. I think it's worth sharing. What do > > you think? > > > > > > For now it is a simple shell script available here: > > > https://github.com/jmlemetayer/one-time-setup/blob/main/git-sync > > > > > > If you think it's a good idea, I'll propose a series of patches with > > > the new sub-command, the manual page and the associated tests. > > > > Have you seen 'git branch -v' and 'git branch -v --format=*'? There seems to > > be a high amount of overlap between this wrapper you've written and it. > > > > I suspect most of what you have here could be turned into an %(if:*) > > directive where you emit the pull/push command as appropriate. > > > > If you search the internet for "git-sync" there's dozens of such command > > (and I've personally observed at least two of them being written by co- > > workers in real time, not sure if either of those is in the Google results). > > > > So I think there's probably a worthwhile problem to be solved here that > > could be turned into patches to git.git, something between "git [clone|push] > > --mirror" and "git branch -v". > > > > I don't think there's any interest in getting new shellscript built-ins in the > > future. We've been actively migrating away from those. > > > > But most of the logic in your script is just calling the ref-filter.c API behind the > > scenes. > > > > B.t.w. you can probably speed up & simplify your script a lot by making use of > > IFS="" in the shell and not calling N for-each-ref commands when it seems to > > me that one invocation would do. Just dump the N fields you need split on > > some token, and split on that token in your loop. > > 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. Thanks for the feedback ! To sum up -- if I have the time to do it -- I must do it in native C and not use a generic name like "sync". As it is a way to keep my branches up to date with the remotes, maybe create an option for the "git branch" submodule instead of a new subcommand? Maybe "git branch --synchronize" or something better ... As using "Pull request" is not the only way to use this command and also because there is a big trolling issue with the termes"Pull request" and "Merge request" I don't think using "pull-sync" is a good idea either. I know that the first golden rule of coding is "Naming", but damn, sometimes it's hard to find a good name. Best regards, Jean-Marie
