Hi Adam, please reply-to-all on this list. On Fri, 27 May 2016, Adam Spiers wrote: > My feeling is that rebase -i provides something tremendously > important, which the vast majority of users use on a regular basis, > but that git is currently missing a convenient way to > *non-interactively* perform the same magic which rebase -i > facilitates. Would it not make sense to enhance `rebase -i`, then? I, for one, plan to port my Git garden shears (at least partially) once I managed to get my rebase--helper work in. The shears script is kind of a "--preseve-merges done right": https://github.com/git-for-windows/build-extra/blob/master/shears.sh It allows you to (re-)create a branch structure like this: bud pick cafebabe XYZ pick 01234567 Another patch mark the-first-branch bud pick 98765432 This patch was unrelated mark the-second-branch bud merge the-first-branch merge the-second-branch Of course, this is interactive. But quite frankly, you want to be able to perform quite complicated stuff, and I think the command-line offers only an inadequate interface for this. > I suspect the most popular use-case in the short term would be the > infamous "oops, I only just noticed that I put that commit on the > wrong branch, and now there's already a whole bunch of other commits > on top of it". I have two workflows for that. The simpler one: git checkout other-branch git commit git checkout @{-1} Sometimes I need to call `git stash -p` before, and `git stash apply` after those calls. The more complicated one comes in handy when a complete rebuild takes a long time, and branch switching would trigger a rebuild: # Here, I stash what I *want* on the other branch git stash -p git worktree add throwaway other-branch cd throwaway git stash apply git commit I did use the approach you proposed a couple of times: just commit in the middle, and sort things out later. The problem: I frequently forgot, and if I did not, reordering the commits resulted in stupid and avoidable merge conflicts. > > > In the longer term however, I'd like to write two more subcommands: > > > > > > - git-transplant(1) which wraps around git-splice(1) and enables > > > easy non-interactive transplanting of a range of commits from > > > one branch to another. This should be pretty straightforward > > > to implement. > > > > This is just cherry-pick with a range... > > No it's not: > > - git-transplant would be able to splice commits from one branch > *into* (i.e. inside, *not* onto) another branch. Okay, but in case of merge conflicts, you still have to switch to the other branch, right? > - git-transplant would also take care of removing the commits from > the source branch, but not before they were safely inside the > destination branch. That assumes a workflow where you develop on one big messy branch and later sort it out into the appropriate, separate branches, right? I admit that I used to do that, too, but ever since worktrees arrived, I do not do that anymore: it resulted in too much clean-up work. Better to put the commits into the correct branch right away. Of course, that is just *my* preference. > - git-transplant would orchestrate the whole workflow with a single > command, complete with --abort and --continue. cherry-pick also sports --abort and --continue. > > > - git-explode(1) which wraps around git-transplant(1) and > > > git-deps(1), and automatically breaks a linear sequence of commits > > > into multiple smaller sequences, forming a commit graph where > > > ancestry mirrors commit dependency, as mentioned above. I expect > > > this to be more difficult, and would probably write it in Python. > > > > You mean something like Darcs on top of Git. Essentially, you want to end > > up with an octopus merge of branches whose commits would conflict if > > exchanged. > > Something like that, yes, but it's not as simple as a single octopus > merge. It would support arbitrarily deep DAGs of topic branches. Yes, of course. Because A - B - C - D might need to resolve into A - M1 - C - M3 X / B - M2 - D > > I implemented the logic for this in a shell script somewhere, so it is not > > *all* that hard (Python not required). But I ended up never quite using it > > because it turns out that in practice, the commit "dependency" (as defined > > by the commit diffs) does not really reflect the true dependency. > > > > For example, > > [snipped examples] > > Sure - I already covered this concern in footnote [0] of my previous > mail; maybe you missed that? I think it deserves more prominent a place than a footnote. > > So I think that this is a nice exercise, but in practice it will > > require a human to determine which commits really depend on each > > other. > > Of course - this is exactly why I wrote "or at least > semi-automatically" in the first mail of this thread. But even though > git-deps / git-explode can never automatically handle *all* > dependencies, they can handle enough dependencies to be significantly > useful. I have concrete real-world experience of that. I'd love to see those examples where it worked, because it sure did not work for me (I wasted two weeks to implement that script that I never used successfully). > I have made a large bunch of small commits to a single text file > (design document). Some are possibly contentious; some aren't. Ah. Well, as I said, I changed my workflow to use multiple worktrees with multiple branches. The contentious changes would go into at least one branch, more likely multiple. The uncontentious changes would go into another. And most likely at least some of those branches would cause merge conflicts. However, they would do so only once, not multiple times during the cleaning-up phase. I did actually track the time at some stage to determine what is faster. Sorting things into multiple branches won hands down (in my hands). And no: I did not believe it would. > So I need to split them out into a series of smaller independent patch > series which I can submit to gerrit for review, thereby making life > easier for the reviewers and minimizing any bottlenecks where reviews > for one change are blocked because another change hasn't been reviewed > yet. And in this case, because the changes are all applying to a single > file containing only natural language, git-deps correctly determines > *all* dependencies, not just textual ones. I do not buy that. When you introduce a section way down in the document for which you have to introduce a new definition in one of the first sections, logically those two changes belong to the same topic branch. Yet git-deps would have no chance to determine that. > > You would render me *really* impressed if you could come up with an > > automated way to determine logical dependencies between patches. > > Hey, I would *really* impress myself if I could do that, too; after > all, that would be a pretty sophisticated form of artificial > intelligence :-) Yep, I will definitely follow your progress! Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html