* Script to rebase branches @ 2017-05-06 10:23 Lars Schneider 2017-05-06 17:14 ` Dennis Kaarsemaker 2017-05-09 4:09 ` Jeff King 0 siblings, 2 replies; 9+ messages in thread From: Lars Schneider @ 2017-05-06 10:23 UTC (permalink / raw) To: git@vger.kernel.org Hi, I am about to write a bash/sh script that helps me to rebase a bunch of branches (e.g. select branches based on prefix, conflict resolution/ rerere support, ...). I wonder if anyone has such a script already and is willing to share it. Thanks, Lars ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-06 10:23 Script to rebase branches Lars Schneider @ 2017-05-06 17:14 ` Dennis Kaarsemaker 2017-05-09 4:09 ` Jeff King 1 sibling, 0 replies; 9+ messages in thread From: Dennis Kaarsemaker @ 2017-05-06 17:14 UTC (permalink / raw) To: Lars Schneider, git@vger.kernel.org On Sat, 2017-05-06 at 12:23 +0200, Lars Schneider wrote: > Hi, > > I am about to write a bash/sh script that helps me to rebase a bunch of > branches (e.g. select branches based on prefix, conflict resolution/ > rerere support, ...). > > I wonder if anyone has such a script already and is willing to share it. Dscho's git garden shears perhaps? https://github.com/git-for-windows/build-extra/blob/master/shears.sh D. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-06 10:23 Script to rebase branches Lars Schneider 2017-05-06 17:14 ` Dennis Kaarsemaker @ 2017-05-09 4:09 ` Jeff King 2017-05-09 10:50 ` Johannes Schindelin 1 sibling, 1 reply; 9+ messages in thread From: Jeff King @ 2017-05-09 4:09 UTC (permalink / raw) To: Lars Schneider; +Cc: git@vger.kernel.org On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider wrote: > I am about to write a bash/sh script that helps me to rebase a bunch of > branches (e.g. select branches based on prefix, conflict resolution/ > rerere support, ...). > > I wonder if anyone has such a script already and is willing to share it. This is what I use: https://github.com/peff/git/blob/meta/rebase There's no documentation in the script, but the commit message in its history should give a good sense of what each part does. -Peff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 4:09 ` Jeff King @ 2017-05-09 10:50 ` Johannes Schindelin 2017-05-09 11:02 ` Jeff King 0 siblings, 1 reply; 9+ messages in thread From: Johannes Schindelin @ 2017-05-09 10:50 UTC (permalink / raw) To: Jeff King; +Cc: Lars Schneider, git@vger.kernel.org Hi Peff, On Tue, 9 May 2017, Jeff King wrote: > On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider wrote: > > > I am about to write a bash/sh script that helps me to rebase a bunch of > > branches (e.g. select branches based on prefix, conflict resolution/ > > rerere support, ...). > > > > I wonder if anyone has such a script already and is willing to share it. > > This is what I use: > > https://github.com/peff/git/blob/meta/rebase > > There's no documentation in the script, but the commit message in its > history should give a good sense of what each part does. That requires Meta/ to be checked out and up-to-date. I'd bet there are exactly two people who fall into that category. Also, I see that you do not use worktrees. Otherwise your script would fail. When I still hoped to be able to get the rebase--helper related topic branches in by August last year, I had grandiose plans to teach the sequencer not only to perform the Git garden shears' trick (i.e. recreate merges), but also to optionally update local branches corresponding to the merge commits, including updates to the worktrees that checked them out (if any). Maybe I'll still get around to do this, some time this year. And it'll probably hit git.git by mid next year ;-) Ciao, Dscho ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 10:50 ` Johannes Schindelin @ 2017-05-09 11:02 ` Jeff King 2017-05-09 12:32 ` Johannes Schindelin 2017-05-09 22:47 ` Junio C Hamano 0 siblings, 2 replies; 9+ messages in thread From: Jeff King @ 2017-05-09 11:02 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Lars Schneider, git@vger.kernel.org On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote: > > This is what I use: > > > > https://github.com/peff/git/blob/meta/rebase > > > > There's no documentation in the script, but the commit message in its > > history should give a good sense of what each part does. > > That requires Meta/ to be checked out and up-to-date. I'd bet there are > exactly two people who fall into that category. Actually, it is not Junio's Meta that needs checked out, but rather the "meta" branch where you will find that "rebase" script. If other people find them useful, the set of scripts could perhaps be transitioned to a namespace that is appropriate to go into people's $PATH. I didn't really expect anybody to use it verbatim, though. I was providing it more for inspiration. > Also, I see that you do not use worktrees. Otherwise your script would > fail. Yes, the script predates the invention of worktrees by several years. I have occasionally played with worktrees, but don't use them extensively (I'd usually use them for a one-off change, and then remove the worktree). > When I still hoped to be able to get the rebase--helper related topic > branches in by August last year, I had grandiose plans to teach the > sequencer not only to perform the Git garden shears' trick (i.e. recreate > merges), but also to optionally update local branches corresponding to the > merge commits, including updates to the worktrees that checked them out > (if any). I don't think I need anything that fancy. But simply checking "is this checked out in a worktree" for each branch and then doing "cd /path/to/worktree && git rebase" instead of just "git rebase $branch" would be enough, I think. (I'm assuming the problem you see is just that the directory running Meta/rebase cannot check out a branch that is checked out in another worktree). -Peff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 11:02 ` Jeff King @ 2017-05-09 12:32 ` Johannes Schindelin 2017-05-10 4:46 ` Jeff King 2017-05-09 22:47 ` Junio C Hamano 1 sibling, 1 reply; 9+ messages in thread From: Johannes Schindelin @ 2017-05-09 12:32 UTC (permalink / raw) To: Jeff King; +Cc: Lars Schneider, git@vger.kernel.org Hi Peff, On Tue, 9 May 2017, Jeff King wrote: > On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote: > > > > This is what I use: > > > > > > https://github.com/peff/git/blob/meta/rebase > > > > > > There's no documentation in the script, but the commit message in its > > > history should give a good sense of what each part does. > > > > That requires Meta/ to be checked out and up-to-date. I'd bet there are > > exactly two people who fall into that category. > > Actually, it is not Junio's Meta that needs checked out, but rather the > "meta" branch where you will find that "rebase" script. Oh, okay, I misunderstood that part, indeed. > If other people find them useful, the set of scripts could perhaps be > transitioned to a namespace that is appropriate to go into people's > $PATH. > > I didn't really expect anybody to use it verbatim, though. I was > providing it more for inspiration. I deem it part of Git's mission is to avoid forcing everybody to write scripts so specific to their own needs that they cannot be shared easily. There are lots of parts in the interactive rebase, for example, that I do not want to use myself. But enough users do to make it worthwhile to support in Git proper. Likewise, I assume that most developers work on one topic branch at a time, until it is submitted as a Pull Request, and then move to the next topic branch after the previous has been merged. But there are enough users, I'd wager, including both you and me, who need to work on multiple topics in parallel (for a plethora of reasons). Certainly there will be more developers with the need to rebase multiple branches at once than there are developers needing to send patches via mail (and we support the latter operation with several top-level Git commands). And that makes me believe that there is enough need for multi-branch operations that we should consider supporting them out of the box. > > Also, I see that you do not use worktrees. Otherwise your script would > > fail. > > Yes, the script predates the invention of worktrees by several years. I > have occasionally played with worktrees, but don't use them extensively > (I'd usually use them for a one-off change, and then remove the > worktree). I assumed as much, and I did not mean to criticise you for it. I was just pointing out, implicitly, that the script has room for improvement to make it applicable to a broader audience. Personally, I am a heavy user of worktrees, and once the vexing bug that corrupts them by gc'ing in-use objects away. I kind of use them not only for developing the topic branches (as you know, my patch series frequently see many iterations and many weeks going by before they hit home), but also as kind of a Pensive, where I keep things I want to work on but do not have time right now. Some of my worktrees are both: they are topic branches in flight, and also remind me that a certain topic was not yet accepted. > > When I still hoped to be able to get the rebase--helper related topic > > branches in by August last year, I had grandiose plans to teach the > > sequencer not only to perform the Git garden shears' trick (i.e. > > recreate merges), but also to optionally update local branches > > corresponding to the merge commits, including updates to the worktrees > > that checked them out (if any). > > I don't think I need anything that fancy. But simply checking "is this > checked out in a worktree" for each branch and then doing "cd > /path/to/worktree && git rebase" instead of just "git rebase $branch" > would be enough, I think. > > (I'm assuming the problem you see is just that the directory running > Meta/rebase cannot check out a branch that is checked out in another > worktree). I understand that you do not need anything that fancy. And you probably understand that I was not talking about your needs only, nor mine. I was talking about a broader audience of power users with the need to work on multiple branches in parallel, to automate things in order to make work more fun. Kinda like Git, you know? Ciao, Dscho ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 12:32 ` Johannes Schindelin @ 2017-05-10 4:46 ` Jeff King 0 siblings, 0 replies; 9+ messages in thread From: Jeff King @ 2017-05-10 4:46 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Lars Schneider, git@vger.kernel.org On Tue, May 09, 2017 at 02:32:37PM +0200, Johannes Schindelin wrote: > > I didn't really expect anybody to use it verbatim, though. I was > > providing it more for inspiration. > > I deem it part of Git's mission is to avoid forcing everybody to write > scripts so specific to their own needs that they cannot be shared easily. Sure. I'd be happy if somebody used it as inspiration to make a tool for everybody, too. The two main reasons I don't polish and try to share the bits in my Meta/ more widely are: 1. Most of them are as much policy as they are implementation logic. So either you buy in completely to the worldview that I've assumed in my tools, or you end up fighting the tool (and by the time you make the tool configurable enough to handle all world-views, you haven't really helped anybody). I think the best thing to do with those logic bits is to add them as much as possible to Git itself (e.g., as command-line options). That keeps any personal scripts as thin wrappers that specify the policy. 2. Some of the features are really powerful but also really dangerous. For example, my "rebase" script (which rebases all my topics) and my "private" script (which builds my daily "private" version of Git to run) both write a shell snippet into $GIT_DIR/continue. And then I have a git-continue alias that looks like this: #!/bin/sh SUBDIRECTORY_OK=Yes . git-sh-setup cd_to_toplevel if test -f "$GIT_DIR/continue"; then eval "$(cat "$GIT_DIR/continue")" elif test -d "$GIT_DIR/rebase-merge"; then git rebase --continue elif test -d "$GIT_DIR/rebase-apply"; then if test -f "$GIT_DIR/rebase-apply/applying"; then git am --continue else git rebase --continue fi elif test -f "$GIT_DIR/CHERRY_PICK_HEAD"; then git cherry-pick --continue else echo >&2 "nothing to continue" exit 1 fi So when I run "git continue" it magically tries to pick up the operation in progress keep going. When it works, it works beautifully. But when it doesn't...well, you can dig yourself into a pretty confusing situation. It's worth it for me, because I can dig myself out. But I'm not sure it's something I'd encourage other people to use. -Peff ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 11:02 ` Jeff King 2017-05-09 12:32 ` Johannes Schindelin @ 2017-05-09 22:47 ` Junio C Hamano 2017-05-10 4:36 ` Jeff King 1 sibling, 1 reply; 9+ messages in thread From: Junio C Hamano @ 2017-05-09 22:47 UTC (permalink / raw) To: Jeff King; +Cc: Johannes Schindelin, Lars Schneider, git@vger.kernel.org Jeff King <peff@peff.net> writes: >> That requires Meta/ to be checked out and up-to-date. I'd bet there are >> exactly two people who fall into that category. > > Actually, it is not Junio's Meta that needs checked out, but rather the > "meta" branch where you will find that "rebase" script. If other people > find them useful, the set of scripts could perhaps be transitioned to a > namespace that is appropriate to go into people's $PATH. > > I didn't really expect anybody to use it verbatim, though. I was > providing it more for inspiration. > >> Also, I see that you do not use worktrees. Otherwise your script would >> fail. > > Yes, the script predates the invention of worktrees by several years. I > have occasionally played with worktrees, but don't use them extensively > (I'd usually use them for a one-off change, and then remove the > worktree). I check out a different Meta/ at the top-level of my working tree when working on Git, but I do use an equivalent of "worktree" to have separate build areas for four integration branches. It is trivial to check out Meta/ just once to the primary working tree and symlink it to others ;-) One thing that struck me odd about your "rebase" script was that it didn't seem to have a special provision to handle a topic that builds on another topic. I saw toposort, but is that sufficient? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Script to rebase branches 2017-05-09 22:47 ` Junio C Hamano @ 2017-05-10 4:36 ` Jeff King 0 siblings, 0 replies; 9+ messages in thread From: Jeff King @ 2017-05-10 4:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, Lars Schneider, git@vger.kernel.org On Wed, May 10, 2017 at 07:47:26AM +0900, Junio C Hamano wrote: > > Yes, the script predates the invention of worktrees by several years. I > > have occasionally played with worktrees, but don't use them extensively > > (I'd usually use them for a one-off change, and then remove the > > worktree). > > I check out a different Meta/ at the top-level of my working tree > when working on Git, but I do use an equivalent of "worktree" to > have separate build areas for four integration branches. It is > trivial to check out Meta/ just once to the primary working tree and > symlink it to others ;-) Yeah, I guess I'd need to do that, too, if I used worktrees extensively. I think the specific problem with the rebase script is just that it expects to be able to checkout all the branches. > One thing that struck me odd about your "rebase" script was that it > didn't seem to have a special provision to handle a topic that > builds on another topic. I saw toposort, but is that sufficient? It topo-sorts so that a single run rebases everything (otherwise you may need to run N times, where N is the deepest dependency chain). But it also uses reflogs to try to find the fork point when the upstream topic has been rebased. The logic is in find_base(). Once upon a time it used "git pull --rebase", but there were some complications. These days I think it could probably use "rebase --fork-point", but I just never got around to testing it. -Peff ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-05-10 4:46 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-06 10:23 Script to rebase branches Lars Schneider 2017-05-06 17:14 ` Dennis Kaarsemaker 2017-05-09 4:09 ` Jeff King 2017-05-09 10:50 ` Johannes Schindelin 2017-05-09 11:02 ` Jeff King 2017-05-09 12:32 ` Johannes Schindelin 2017-05-10 4:46 ` Jeff King 2017-05-09 22:47 ` Junio C Hamano 2017-05-10 4:36 ` Jeff King
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).