W dniu 01.10.2016 o 22:13, Kevin Daudt pisze: > On Sat, Oct 01, 2016 at 12:24:57AM +0200, Jakub Narębski wrote: >> >> | 7.2.1 Discussion >> [...] >> | There could be other use cases for the >> | staging area that Gitless doesn’t handle well but we expect >> | these to be fairly infrequent. I'd like to point to the word "other" in the above sentence... >> >> Like handling merge conflict...??? Infrequent doesn't mean >> unimportant. > > For me the most important thing is that the lack of staging area leads > on commits that have no clear goal, people just commit everything they > have changed at some point, as a sort of checkpoint. > > Although lots of people still do this with git currently, they don't > even have the possibility[1] to improve on this. > > This makes history and features like git bisect less useful. > > > [1] At most they can specify the files they want to commit, but this is > still a very crude way to group together changes. ... If you had read the original discussed research paper http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf you would notice that this use case is covered by Gitless, though imperfectly. Common use cases for the staging area in Git are to select files to commit, split up a large change into multiple commits, and review the changes selected to be committed. We address the first by providing a more flexible `commit` command that lets the user easily customize the set of files to commit (with `only`, `include` and `exclude` flags). For the second use case we have a `partial` flag in `commit` that allows the user to interactively select segments of files to commit (like Git’s `commit --patch`). First imperfection is that only equivalent of `git commit --patch`, that is additive selection of changes during commit. There are, from what I understand, no equivalents of `git add --interactive` (crafting additively and subtractively part by part, not all at once), `git reset --patch` (crafting additively from any commit, defaults to HEAD), `git checkout --patch` (crafting subtractively). It is a good thing to have those possibilities when disentangling working area, or splitting commit during interactive rebase. Though all of those could be added (if they are not present already) to the interactive interface of `partial` flag in `gl commit`. Second imperfection is that you cannot test the crafted state without creating a commit. In Git you have `git stash --keep-index` for this; go to the state crafted in the staging area (the index), and you can test it. Though you can always create a [temporary] commit, run tests, and then if necessary amend this commit. On the other hand the index / the staging area is important and useful thing in helping to resolve merge conflicts, for example the one where one side changed file and other deleted it, or where one side renamed file and other changed it, etc. -- Jakub Narębski mailto:jnareb@xxxxxxxxx mailto:jnareb@xxxxxxxxxx