[c3RlcGhlbnI_]

The paper doesn't discuss much how their implementation does better on their listed issues. One particularly interesting issue git has is referred to at one point as "Incoherent Commit":

"The problem with commit is that it constitutes a violation of the coherence criterion: the same concept (commit) has more than one, unrelated, purpose: make a set of changes persistent (P1) and group logically related changes (P2).

"These two purposes are not only unrelated, but in tension with each other. On the one hand, you would like to save your changes as often as possible, so that if something bad happens you lose as little data as possible (thus encouraging early committing). On the other hand, a logically related group of changes usually involves multiple individual changes, which means that you might be working for quite some time before you have enough changes to group (thus encouraging late committing).

Now a fix for that would be useful. Git only provides you with the ability to create a graph, and you get to choose what you use it for. You have to choose though because there is only one graph. Gitless doesn't seem to fix this problem, you still have to choose what goes into your final commits. Though I don't know what you could do about it without changing git to support something like grouping commits into blocks that are modified as a unit.

[ww520]

You can use a branch to accomplish P1 and P2. Create a branch for the group of logically related changes. Commit as often as you want (P1). When all are done with the group of related changes (P2), merge back to base branch.

Git branching is lightweight so I don't see how it can't be used to support P1 and P2.

[tbrownaw]

Git allows you to do violence to history: it's very much possible to commit regularly as you work, and then rearrange those commits later to be more logical.

I have no idea how easy this is, but I've seen plenty about how horribly impolite it is when you rearrange any history that other people have seen.

[tylorr]

It helps if you keep unrelated code in separate commits. That way all you have to do is rearrange and merge commits. It gets more complicated if you have to split commits. I've been wanting to make a GUI for this purpose that allows you to drag and drop hunks/commits. Essentially a GUI for interactive rebase.

And yes, don't change history others have seen, but do it as much as you need locally.

EDIT: typo/clarity

[convolvatron]

what this really means in practice is "never branch off anything but master"

which is ok for maintenance bug fixes, but precludes a lot of interesting workflows involving speculative work, late binding the order of commits, early integration branches, etc.

my workaround for this usually just involves doing what i want up front, and then abandoning git for the merge process (since my history is polluted by false conflicts), constructing diffs and applying them as single commits against master.

which works, its just a bit silly

[paulmd]

There's nothing stopping you from using an amend-commit and just adding every change as you go, as long as you never push to other people. That's the exact veneer that gitless provides, albeit it renames what some of the commands do.

[deckar01]

One of the things that separates git from other command line tools is the way it handles program state. If you ask git to do something ambiguous (even when there are clear options) it bails and gives you a hint. It would be nice if it prompted with options.

`git checkout branch` with unstaged changes could interactively prompt you to stash, commit, discard, or keep the changes.

[KKKKkkkk1]

I hold my code and documents on a COW filesystem and create a snapshot every hour. The snapshots take care of P1 and git takes care of P2. I would argue that P1 is not the job of a version control system anyway.