die.drachen wrote:
> The git staging area is useful to my workflow because I am often
> making changes and testing something, but later decide to have
> separate commits within all the changes. This helps preserve a nicer
> history where commits usually have single-responsibility. For example,
> fixing a null pointer in a button click handler, but also tweaking the
> button's sizing/border/etc. to be consistent within the UI. I would
> likely make those two changes at once and test locally, but ultimately
> have separate commits for each change. On other occasions where I
> might end up in a similar situations is when finding out one bug is
> actually multiple bugs.
There are three points I'd like to make here:
First, the safer (and arguably overall better) approach is to recognize
that stash/shelve operations are the inverse of the staging area for
this purpose. I.e., rather than stage a partial commit, you stash
everything but the partial commit, then commit whatever changes remain
in toto. This does not require the staging area and ensures that, e.g.,
you're not committing something that doesn't even compile (which breaks
bisect, CI tools, etc.).
Second, even if you prefer not to do it this way, "git commit --amend"
essentially made the staging area superfluous a long time ago for the
purpose of splitting commits.
Third, while splitting commits (where you accidentally mashed multiple
things together that you later realize should be separated) is a very
relevant feature, this is largely a problem of the user interface, not
the staging area. The staging area is frequently used because many
graphical Git clients provide excellent UI tooling for staging parts of
a file as a commit. However, this does not require a staging area; see,
e.g., Bazaar's "qshelve" command for a graphical tool that provides a
similar feature for stashing partial commits.
> It sounds like fossil is similar to mercurial - mercurial's commit
> command by default includes all local changes, but arguments can be
> specified for including/excluding files (or file patterns).
Keep in mind that Mercurial also has Mercurial queues, which is (for
better or worse) a staging area on steroids. Also, what I said about
"git commit --amend" above applies equally to "hg commit --amend".
Reimer Behrends
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
