I kinda disagree. It’s tedious in the same way that organizing your life in general is tedious… you’re moving the cost up front instead of having to deal with the cost of disorganization later

Here is how I do it:

1. Commit everything on a branch dev/andy. Whenever I get something working, i.e. make a test pass, I commit. Then git diff becomes a useful aid – what’s changed since something last worked? – and I can experiment without worrying.

2. Then git rebase -i master when I have a logical piece of work that should land on the main branch.

3. Then ./local.sh git-merge-to-master which does this:

git-merge-to-master() {
  local branch=$(git rev-parse --abbrev-ref HEAD)  # find current branch

  git checkout master
  git merge $branch  # merge my work into master
  git push
  git checkout $branch  # so I continue working on the branch
}

Is there an advantage to using this dura tool? git can be tedious but it’s also very easily automated with shell.

git branch foo-changes

… then just:

git add . && git commit -m "boop $(date +'%Y%m%d-%H%M')"

https://xkcd.com/1205/

Please tell me where I can find this ZFS on windows ;)

Windows now has an NFS client out of the box, so it’s actually pretty easy to run a FreeBSD VM under Hyper-V and mount folders via NFSv4 from Windows. Performance isn’t great though (at least for me, the Windows NFS client seems to have very high latency the first time you access a file).

There was a port of OpenZFS as a Windows installable filesystem (IFS). It doesn’t seem to have had much development for a few months though. Note that, unlike Linux, there is no legal impediment to using a CDDL filesystem on Windows.

Please tell me where I can find this ZFS on windows ;)

You don’t.

I’d be inclined to do the same sort of thing that you do with filesystem snapshots: decrease granularity as they age. I might want to keep changes for every 5 seconds for a few hours, then every minute for a few days, then every hour for a few weeks, and so on. Git lets you splice parents, so you can delete intermediate git commits and fix up the tree so that the surviving commits still work.

Last time I used git-imerge on a very large tree, I discovered that git really doesn’t scale well to large numbers of commits without regular git gc invocations (imerge creates NxM commits, where N and M are the number of commits in each of the two branches that you’re merging and operations ended up taking 3-4 seconds on my laptop, then closer to 200ms after a git gc) so it’s probably important to do something like this.

Personally, I’d love to have my editor use git for undo history. I love the fact that vim has persistent undo (I set insane limits, so I can use undo to go back to a version many hours of editing ago if I realise I’d deleted something ages ago by mistake) but it grates slightly that I have two independent mechanisms for doing this.

Does each dura branch record which branch you were working off of at that time?

If so, you could give a list of them next to what HEAD was at the time, with ones that have been merged into the current branch highlighted (a la git branch -d)

you dont need a full object prune per-say, just packing up all the objects into packfile and have them delta compressed already go a long way. Even better if you give them proper commit-graph with Bloom filter backing.

See MSFT’s Scalar or my poor man rewrite of it here: https://github.com/sluongng/git-care/blob/master/git-care.sh . (Most of these have also been ported to git-maintenance).

Another technique is that: while working on branch feature-A, you can store all the snapshot commits into a special refs at refs/snapshot/feature-A (as opposed to refs/heads/feature-A). After that, you can implement logic of checking ages of refs in refs/snapshot/* and implement clean up accordingly.

[Comment removed by author]

I’d try something like adding a cleanup of “older than X days”, if you want to be defensive set that to 90 per default. Other people might want to reduce that, depending on how much binary stuff they’re abusing git for.

Then if people are still crying you could backup the whole git folder before that to a different place which is also only removed every X days, so if the cleanup goes wrong they can still revert. (Credits to bfg repo cleaner )

[Comment removed by author]

notify supports inotify on Linux, FSEvents on macOS, ReadDirectoryChangesW on Windows, kqueue on the BSDs, and polling on everything else.

I’d be happy to PR a change implementing this, if you’d like.