Fossil Forum

Commiting only a subset of actual changes (similar to "git add -p")
Login

Commiting only a subset of actual changes (similar to "git add -p")

Commiting only a subset of actual changes (similar to "git add -p")

(1) By anonymous on 2019-11-12 12:39:02 [link] [source]

Was googling this thing for two days and only found this:

https://fossil-users.fossil-scm.narkive.com/kbUad5iy/interactive-patching

There is a description of how to achieve the "git add -p" workflow in fossil.

(TLDR of the link above) It boils down to just doing `fossil diff > changes.diff && fossil revert` and then you split the diff to small chunks and apply them step by step, doing `fossil commit` in between (or use some smart tool that can extract parts of the diff and apply them, but that's just implementation detail).

Is there some tool that can help me to apply diff partially, with equal level of convenience to `git add -p`?

Is there any other way of splitting your work to smaller parts before commiting?

If anyone adopted such a workflow and came up with some automation, please share.

(2) By kak (kkugler) on 2019-11-12 14:26:36 in reply to 1 [link] [source]

I'm not familiar with 'git add -p' but I just wanted to point out that you can selectively commit files in fossil. If your changeset has 20 file changes and you only want to commit 2 of those files then you can just specify those files as part of fossil commit.

If you're talking about several changes to a single file that you want to break into several smaller commits then the approach you linked above seems worthwhile, but I would scrutinize the need to do that.

(3) By anonymous on 2019-11-12 16:51:28 in reply to 1 [link] [source]

It boils down to just doing fossil diff > changes.diff && fossil revert and then you split the diff to small chunks and apply them step by step, doing fossil commit in between

You should be able to do something like this with 'fossil stash'

fossil stash save
fossil stash gdiff
fossil ci
fossil stash gdiff
fossil ci
# repeat as needed

'fossil stash' will save your changes to the local check out's stash and then revert your working files.

Configure fossil to run an interactive diff/merge tool, then 'fossil gdiff' will run that so you can apply just the changes you want for each commit.

(8) By Ashish SHUKLA (ashish) on 2022-03-27 11:10:52 in reply to 3 [link] [source]

I just tried it in conjunction with Emacs' ediff-files, and it's pretty good workflow.

Thanks for sharing it.

(9) By Daniel Dumitriu (danield) on 2022-03-28 23:18:45 in reply to 3 [link] [source]

I can confirm this works with vimdiff, Meld, and WinMerge.

(10) By anonymous on 2022-03-29 06:29:56 in reply to 9 [source]

I never understood the need of staging.

I understand that one want to commit a clean patch, using GIT, one can use the command line options to do that.

But there is a more generic way to do that, applicable to most of the SCMs. The developer basically work in 2 modes with different mindsets:

  • one mode is development, developer is basically implementing some features
  • the second mode is publishing, the developer wants to publish some code

So let's create 2 directories with their own repositories:

  • mysoft-dev
  • mysoft-release

The developer commit at anytime in mysoft-dev, this is dirty and convenient. When the feature is working and need to be published with several 'clean' patches, simply start a 2-way merge tool (WinDiff, Meld, you name it) and merge the wanted lines from mysoft-dev into mysoft-release. When it's done just commit and synchronize your mysoft-release.

This workflow is simple and don't need specific tooling.

(11) By Daniel Dumitriu (danield) on 2022-03-29 10:13:53 in reply to 10 [link] [source]

I don't like the staging area, either, and find it a misfeature. And the code should indeed be tested before committing. But on the other hand, there are a) objectively: some specific types of changes (typos for once) that do not need deep testing, and b) subjectively: many imperfect developers that forget to commit timely. Which brought us the stash.

As Warren mentioned it, using stash solves this real philosophical problem. Adding stash gdiff and the merge tool to the mix only adds the optional benefit of working on hunk level, should anyone need it. As for the risks, grown-ups should be able to ponder when/whether to use the hedge clippers. The same applies to programmers.

(4) By Richard Hipp (drh) on 2019-11-12 17:12:43 in reply to 1 [link] [source]

FWIW, Fossil frowns upon doing partial commits, because doing so normally means that you are committing something that you have not tested.

(5) By kak (kkugler) on 2019-11-12 17:49:18 in reply to 4 [link] [source]

That's a valid point, but I think partial commits serve a purpose.

I use partial commits when I have made multiple orthogonal changes, and I do it so that each commit has a concise message about the change and the diff is easy to digest. The partial commits are almost always done in short succession, with a few seconds between each commit. Also, I'm the only person working on the particular branch I make the partial commits on.

Yes I realize I wouldn't have to do this if I just worked on one change at a time, but for one reason or another my brain just doesn't work that way.

(6) By anonymous on 2019-11-14 06:22:28 in reply to 4 [link] [source]

Then Fossil should remove https://www.fossil-scm.org/home/tktview?name=ac8dcd394c from the tickets instead of keeping it for 9 years with "Important" severity :D

I can understand that it might not be important to some people, and I guess it's mainly true about ones who apply all the best practices of development... And I mean those who rarely end up in a chaotic state where they change half of the files in the tree while working on a rather small and specific problem... https://www.youtube.com/watch?v=8fnfeuoh4s8

Now, back to your comment again:

something that you have not tested

That does not have to be the case. Fossil could make it so that after you commit some part of your changes, the current working copy of your code is the same state as your history. So you can test it (or deliberately avoid testing if you're a rock star) and then run some command to commit next part of your changes...

(7) By anonymous on 2019-11-14 17:30:26 in reply to 6 [link] [source]

Then Fossil should remove https://www.fossil-scm.org/home/tktview?name=ac8dcd394c from the tickets

I think that's been there like that because the Fossil project stopped using tickets due to spamming problems.

I see that the ticket has been closed, now.

Fossil could make it so that after you commit some part of your changes, the current working copy of your code is the same state as your history.

After a "normal" commit, this is the case. After a partial commit, I don't see how even git could do that.

On the other hand, both git and Fossil have a stash feature.

After a "stash save", your changes are in the stash and your working copy has been reverted. Then you can diff between the stash and your working copy to selectively incorporate your changes. Then you can build, test and commit from your working copy. Repeat until all changes have been tested and committed.

Whether you are using git or Fossil, I think this is a better way to do partial commits.

(12) By KIT.james (kjames3411) on 2022-03-30 02:04:17 in reply to 4 [link] [source]

Aren't there many kinds of commits that do not need tests or that can be tested by other ways? Or that live in "not yet tested" branches?

Especially for things other than source code. (If Fossil is not optimized for knowledge data or other kinds of non-executable data any time soon, then I guess partial commits & staging make less sense)

(13) By Alfred M. Szmidt (ams) on 2022-03-31 12:45:13 in reply to 1 [link] [source]

Many many ages ago I wrote a small mode for GNU Emacs that does exactly this, but is entirely VCS agnostic. You can walk through a diff file and commit each hunk separately. You can also modify a diff accordingly, removing hunks, modifying bits and bobs, and then applying the whole shebang in one go. I use this with Fossil (and vc-fossil) quite often; the big difference on a work-flow with git is that you're committed (pun intended) to your changes. Where in git you could still do rebase, and revisit things.

Code can be found here: https://tumbleweed.nu/r/ams/file?name=diff-commit-hunk.el&ci=tip