Hi,
Thank you very much for myrepos, it is really a great tool which I have integrated in my daily workflow and which improved my productivity a lot!
I am successfully using it for ~100 repos (both personal and community-based) and one thing that I am trying to achieve is better reporting of the overall status of an action. For instance, I do an mr rebase at the root of my account and it will rebase all my personal branches against their main ones. This sometimes fails though and myreports mr rebase: finished (115 ok, 3 failed)
The problem is that I now have to scroll up through the long output to find which repos failed w/ their rebase. I would like myrepos to report the directory/repo paths into which there was a problem but I have not found a way to do that. Each rebase action runs in its own shell and I don't have an easy way to transfer the state (failed or not) into a global variable that myrepos could check. The closest I can think of is to put those failed paths into an exported shell variable that a wrapper script running myrepos would check at the end.
Looking into the myrepos source, I don't see an easy way here (the showstats() routine uses counters for ok/failed/skipped, but does not appear to store repo paths there).
Is there a way to achieve what I want here?
Thanks much for your help!
Vincent
Hi Vincent, glad you like myrepos
Personally, I think the right way to deal with your situation is for each failing rebase to spawn a shell for each failure, unless you use -j, but if you do use -j you could spawn an xterm instead of a shell. Right now I am using a git-rebase-all script I wrote for this purpose, you could adapt it to your situation.
BTW, if you have long-running branches that often have rebase failures, I suggest using git-imerge and or mergeify. They make rebasing much easier by bisecting your rebase failures and then letting you rebase over the exact commit causing the rebase failure, splitting the rebase up into several much smaller rebases that you can incrementally solve. I've only used git-imerge, it has a bit of a learning curve, but once you get used to it, it becomes invaluable for this use-case.
Without using git-rebase-all and without any changes to the myrepos code, there are two possible ways you can do what you asked for:
Use the "offline" mode, which records what commands failed so you can run them again when online. First you turn on "offline" mode, then run the rebase command, (optionally) inspect the log of failed commands and then re-run only the failed commands. The offline mode is mainly meant for
mr fetchbut it works for any situation where you want to log failed commands.Use the --cache option and then inspect the cache after myrepos has run. The cache contains separate files for both the command exit code and the text output of each repository. So you can run the rebase in cache mode and then inspect the cache of the rebase command return codes. Something like this should print the list of dirs (relative to your $HOME dir) where the rebase failed:
Hi Paul,
Thanks for your answer and for all the good suggestions esp. on the tooling side for
git-imergeandmergify. Your suggestion to start a shell (I am not using-j) is indeed an excellent one, as I will need to fix the rebase in one way or the other (so doing it right as the repos are processed is a good idea).On the rebase side, your
git-rebase-allscript is also a good suggestion. I am looking into ways to do automated rebases on different branches: say that I am working onsandbox/vrubiolo/develwhich is branched offorigin/devel(but has a remote onorigin/sandbox/vrubiolo/develso that I can push daily to backup my work), I want to rebasesandbox/vrubiolo/develevery morning on the new state oforigin/devel. Right now, I need to store theorigin/develpointer in an array to know which branch I should rebase against. Is there a better way in your case?Thanks again for your prompt replies!
@{u},@{upstream},HEAD{u},HEAD{upstream},sandbox/vrubiolo/devel{u},sandbox/vrubiolo/devel{upstream}, see the gitrevisions(7) manual page for details. The git-rebase-all script mentioned above uses the@{u}shortcut in order to avoid having to look up the upstream branch.The --stats option adds an output at the end like:
The name of this option could be better, the mnemonic for it is that it expands the normal stats output with more detail.