Our great sponsors
-
Somewhat (or possibly greatly) related:
Are tools like git-absorb safe/reliable?
"Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run `hg absorb` and the uncommitted modifications are automagically folded ("absorbed") into the appropriate draft ancestor changesets. This is essentially doing `hg histedit` + "roll" actions without having to make a commit or manually make history modification rules."
I haven't wrapped my head around the algorithm. I get that an algorithm can "recollate" a series of commits in a way that yields no commit conflicts, but that's not the same as rearranging and combining commits into a sequence of semantically coherent atomic commits.
---
-
Somewhat (or possibly greatly) related:
Are tools like git-absorb safe/reliable?
"Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run `hg absorb` and the uncommitted modifications are automagically folded ("absorbed") into the appropriate draft ancestor changesets. This is essentially doing `hg histedit` + "roll" actions without having to make a commit or manually make history modification rules."
I haven't wrapped my head around the algorithm. I get that an algorithm can "recollate" a series of commits in a way that yields no commit conflicts, but that's not the same as rearranging and combining commits into a sequence of semantically coherent atomic commits.
---
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
@jpgrayson (since I see you lurking around here) Thanks for maintaining stgit! I've been a recent convert and it's a great workflow improvement. I used to be a big `git rebase -i` user and stgit works so much more fluidly and fits great with my mental model of how I want git to behave. Thanks!
I'd love to add functionality that mimics `git rebase -i`. That is, you would open an editor and be able to select which patches you want on your stack as well as possibly designate patches as 'squash' or 'fix' from your editor. Think of it as `stg sink`, but able to operate on multiple patches at once.
Prior art: this script[1] already performs a re-ordering of commits but in a pretty hacky way. I'd like to productize it!
I'd love to have this new `stg rebase --interactive` be part of the main repo to enjoy the benefits of the existing test suite. My question for you is around how to include the new command with the rest of the tools. Would you want it to integrate with the existing rebase command (`stg rebase --interactive`) or is it something more appropriate for `contrib` (so a new independent command like `stg-rebase-interactive`)?
[1] https://github.com/da-x/misc-gitology/blob/master/stg-rebase...
-
Ah ha, someone did use `stg publish`!
I removed it because it was challenging to test and maintain, its semantics are somewhat complex, and it wasn't clear that it provided value to anyone.
If you wouldn't mind making your case on the issue tracker [1], I will reconsider the fate of `stg publish`.
