Stephan Beal wrote:
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques <abili...@gmail.com
<mailto:abili...@gmail.com>> wrote:
I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove
them from the actual files), or selectively pop/apply some changes
(but I imagine this one could get things confusing, specially if
used with apply).
...
What are your opinions? Is this useful? Is this powerful? What would
your approaches be?
IMO it's inherently evil because it promotes checking in untested
subsets. Automated tests require a full, valid tree. Checking in a part
of a change may well lead to code which runs on your machine but doesn't
run on remotes (continuous integration systems or other users).
A selective stash does not have these problems, since you're only
removing files from the working tree; it does not change the repository,
until you actually perform a (non-selective) commit.
Second, there are ways to do selective commits without the above
problems (assuming you find the feature desirable and worth the effort
of implementing it).
Give the commit command three subcommands:
fossil commit --tentative
fossil commit --amend
fossil commit --finalize
Here, `fossil commit --tentative` will begin a tentative commit. Such a
commit cannot be exported from the repository (via push, bundle, etc.),
but can be diffed against, viewed, etc. Then, `fossil commit --amend`
can change the commit by adding files or individual hunks to it or
removing them. Finally, once you're satisfied, you can use `fossil
commit --finalize` to turn the tentative commit into a regular one
(presumably after stashing all remaining changes and testing the
commit). You can even be strict and require that the tree be clean for
`fossil commit --finalize` to be permitted.
(Note: This is essentially a greatly simplified version of how Mercurial
Queues work.)
Such an approach should fix most of the issues with the Git staging
area, while retaining all its power; the main downside is that it adds a
lot of potential complexity to `commit`, while a selective stash (and
selective `stash apply`) would be equally powerful and much simpler to
implement, understand, and teach. (Note: Bzr uses selective stash --
called shelve -- and full commits by default, and to good effect.)
Reimer Behrends
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
