Replies: 2 comments 2 replies
-
I wanted something similar as well. I think a (much) simpler variant could still be very useful. What about having the possibility to categorize (mark / tag) hunks (in the work tree and/or in the index). So then the usual commands (stage/commit/...) could target the given categories. The work tree and the index can be seen as two categories of "coming changes". And the applicable commands (stage/commit...) are restricted in each category. It would be great to extend this idea and allow the creation of any number of categories, ideally with user defined names (but this is not essential). And allow all(?) commands to apply to any category. E.g. I have 10 hunks in the work tree. When I check them, currently I can stage any of them and then e.g. commit or stash the selected ones, i.e. the ones, that are "moved" into the index (or kept in the work tree). This is a possibility to split bigger changes into smaller commits, but it is a tedious task when there are many hunks and I want to organize them into several commits. The idea is to mark the hunks; in other words: to assign them to categories X or Y or Z or ... Then, having commands like "stash the hunks in category X" or "commit the hunks in category Y" or "create a new branch named Z and commit the changes in category Z in that new branch"... As I understand, "virtual branches" may provide one more feature on top of these: they can be used to separate the changes in time, so if I move a hunk into a virtual branch (into a category), and then change the corresponding code again (but still before committing the original changes), these subsequent changes can easily be separated (into different "virtual branches"). With "normal git" (and thus: with the simple hunk-categorization feature sketched above), this separation is supported only in the two predefined categories, index and work tree, but e.g. separating three subsequent changes of the same code is not possible (without stashing or committing... meanwhile). In my view this extra functionality of "virtual branches" is a nice add on, but its implementation may be complicated. I hope that the implementation of the hunk categorization feature sketched above, would not be difficult in magit. |
Beta Was this translation helpful? Give feedback.
-
This is a nice feature, but I expect it would be very hard to implement properly. An initial poc may turn out to be not that hard, but if I remember correctly, the video only shows the happy path, leaving out what happens if there are conflicts between the things being committed to different branches. Getting it to work properly in all cases and to provide adequate support when things don't just work and the user has to get involved, would definitely be hard, and would require making improvements over the next few years. I simply do not have the time for that. Sorry. I don't want to implement a 80% version, because I know that I would then be on the hook to do the other 80%. I do not need another time sink. This is their killer feature, and they have a team working on it. I cannot do that also, on top over everything else. What I have been using instead is separate commits, which may, in a second, separate step be split across different branches. Changes can be assigned to different buckets using "instant fixup". Magit also provides useful tools for splitting, such as Maybe that's just because that's what I am used to, but I think this might actually be superior. I think there is value in separating the steps of "assigning" changes to "buckets" (either commits or branches), and performing the final separation in a separate step. (Or to even do several rounds of it.) I don't know what you would want to use this feature for. I could see myself using it when I work on some feature and spot an issue nearby. A trivial example would be a typo in nearby function that won't also be touched by the changes I am actually working on. In that case one can just create a new commit, (optionally) rebase it toward the beginning of the feature branch (to move it "out of sight"), and later extract it onto another branch, using the harvest command. A much less trivial case is, when you realize that, what you have in the working tree, is not just a new feature, but also a refactoring of the existing code on top of which the new feature is being implemented. This happens to me a lot and in many cases it is simply impossible to separate the refactored part from the new parts, using just I do it anyway, by committing the combined result, doing a rebase that stops at the commit before that "combined" commit, and then recreating the refactoring parts by themselves (potentially spit across multiple commits). (Some parts I might be able to apply from the "next"/"combined" commit, but some manual editing is involved, in the hard cases at least). Then I continue the rebase, which results in a conflict, at which point I can just pick "their" side. The diff after that is done has to be inspected carefully. It is possible that one included too little or too much in the (now) "earlier" commit. This isn't trivial, but I think there is value in doing it even in the cases that require "re-editing". The multiple-branches approach wouldn't magically make the hard cases trivial. I have a feeling that it would make those harder or even impossible. The value of the rebase approach is in having to rethink the steps separately, again, or if the work-process was a bit muddy, actually for the first time. It does definitely happen that in this process, I don't just come up with cleaner steps toward the end result, but actually a cleaner result, including a cleaner new feature and/or a cleaner base abstraction. I guess one could say I think about this "in time" (series of commits, some of which involves time travel), while you think about it "in space" (branches that co-exist). The solution in space is probably more intuitive, but it only works in the trivial cases. In my experience, the non-trivial cases are actually quite common. Making the trivial cases even easier to handle, doesn't seem like a good investment for me. Furthermore, using the time-traveling approach works here too, and using that for the trivial cases, has the advantage that one gets the practice, to later deal with the non-trivial cases with confidence. I don't think the non-trivial cases can be done in space alone. |
Beta Was this translation helpful? Give feedback.
-
I just discovered GitButler, and it looks like a very promising solution to the problem of dealing with multiple concurrent threads of work:
https://docs.gitbutler.com/features/virtual-branches
I recommend watching the short YouTube demo on the above page.
I wrote some ugly shell hacks for this years ago which work OK for me, but I've longed for a better solution to these higher-order workflows. It would be amazing if at some magical point in the future, magit could achieve the same kind of thing.
Beta Was this translation helpful? Give feedback.
All reactions