On 2 November 2015 at 18:20, Scott Robison <[email protected]> wrote:
> > Given that the git cli interface was the only interface for humans from the > start, I dare say it was meant for humans. > Any git reference I have seen has that notion of 'porcelain' and 'plumbing' with plumbing being the internals and porcelain being the interface for the user. To perform everyday tasks with git you will need some of the 'plumbing' commands because the 'porcelain' part just never happened/was finished. So yes, there is some issue here. What we are left with is the plumbing without the sink and it *does* stink when you get anywhere near it unless you go out of your way to make that U-shape with plain pipes. On 2 November 2015 at 20:40, Richard Hipp <[email protected]> wrote: > On 11/2/15, Michal Suchanek <[email protected]> wrote: >> >> when you >> want to separate the changes you want to commit and changes you want >> to ... keep uncommitted to do more work on them this is quite >> useful. And don't tell me nobody ever mixes unrelated and possibly >> conflicting changes in the same working directory. > > People do that. But it is much more easily accomplished by simply > listing the files you want to commit on the "commit" command line. > That's what every other VCS in the world other than Git does. And it > works great. And it does not require the added confusion of a staging > area. Unless you have unrelated changes in the same file, of course. > > But on the other hand, you should not be checking-in untested changes. > The proper way to do incremental check-ins is to stash the whole lot, > then pull out individual pieces from the stash and test and commit > them separately. And that's what the staging area allows for easily. You add and remove hunks from staging area until you like the split and commit the staging area at which point CI fires or you stash the remaining changes and run your tests. Or you just don't care, of course. Also note that when using a frontend the staging area is something the frontend can present to the user and it's unlikely to change until the user acks the commit, unlike the files in the working directory. On 2 November 2015 at 23:51, Richard Hipp <[email protected]> wrote: > On 11/2/15, Warren Young <[email protected]> wrote: >> On Oct 30, 2015, at 11:27 PM, Michal Suchanek <[email protected]> wrote: >>> >>> Unless you delete .git your checkout is always in well defined state. >> >> Three words: Detached Head State. >> > > Forgot about that one. > > I amend my earlier disparaging remarks about Git to include now a > second reason why Git is not better for developers: > > (1) Requires too much mental load > (2) Detached head state > > Note that detached head state is impossible in Fossil and in most > other VCSs. (Unsure about Hg.) Detached head state is the state which you enter when you check out some random commit id. That is you are not on a tip of any branch. Any VCS can do that. What git does that other VCS do not is it allows you to work as normal adding commits on top of the detached head. Unless you create another branch which serves as as bookmark or pointer to this head you may have hard time finding it again and it may go away due to garbage collection on the repo. This is the result of using the debug interface for everyday tasks. It's completely fine to allow detached head state but it's not something the users should see. As in the 'porcelain' commands should prevent you from using the detached head for anythign but checkout and bug you to create a branch if you want to commit or automagically create one. Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
