absorb command

[valpackett]

git-absorb, inspired by hg absorb, is pretty useful (when it works). This kind of thing might be a desirable feature here.

Considering the whole "working copy as a commit" thing it would be more like a "smart squash" or something.

[martinvonz]

it would be more like a "smart squash" or something

Yes, that's actually how hg absorb works. I didn't know about git-absorb until now.

The tricky bit is presenting the changes to the user. I think that's pretty important for a "magical" command like absorb. git-absorb addresses that by creating fixup! commits that the user can then review before they run git rebase -i --autosquash. hg absorb instead (optionally) prints the hunks and which commit they're going to go into and then lets the user confirm or abort. Since we have generic undo functionality, that becomes less needed, and another option is to give the user a way of telling what changed after it's done (and then they can undo if they don't like it). Issue #23 would help with that, but it's probably better to have the command display the changes it made.

[arxanas]

The tricky bit is presenting the changes to the user. I think that's pretty important for a "magical" command like absorb. git-absorb addresses that by creating fixup! commits that the user can then review before they run git rebase -i --autosquash. hg absorb instead (optionally) prints the hunks and which commit they're going to go into and then lets the user confirm or abort.

Not to say that we shouldn't have a preview, but an anecdote: I had a coworker who remarked to me that, in principle, hg absorb shows you a preview of the changes it's going to make, but in practice, they just trusted it to magically do the right thing and didn't look at the output anymore 😂. (Although maybe that's possible only because it uses a weave approach and not a commuting-hunk approach.)

[martinvonz]

I mostly do the same :) But I do inspect it when I know that the changes in the working copy touch areas of the code that I've also touched in more than one recent commit.

[martinvonz]

I created issue #170 for this.

[arxanas]

Which topics do you want in this discussion thread vs. in the issue itself?

[martinvonz]

Good question :) I created an issue from this because something made me think about the command so I went to look for the issue for it and couldn't find it. I think I prefer all feature requests as issues. It's more like "would it make sense to have this feature?", then I think I'd prefer it as a discussion. I don't mind if users start it as a discussion like here, though; I can just create an issue for it if I think it's a feature we should have.

[martinvonz]

Sorry, I realized now that you were asking about this topic in particular. I think if it's relevant to the person eventually implementing it, then it's best to have it in the issue so it's less likely to be missed.