gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making git as easy as CVS, for handling merge conflicts


From: Paul Smith
Subject: Re: Making git as easy as CVS, for handling merge conflicts
Date: Sun, 03 Nov 2019 23:55:51 -0500
User-agent: Evolution 3.32.1-2

On Sun, 2019-11-03 at 22:50 -0500, Richard Stallman wrote:
>   > git uses fundamentally different paradigm to the model on which VC
>   > was designed.  One of many examples of this is that it requires
>   > staging changes before committing them.
> 
> Maybe that is the aspect that convinced me to give up on using git.
> Or maybe it was "stashing".  I am not sure what the difference is.

It was likely not stashing.

Stashing is an extra command (git stash ...) that you can run if you
want, but is not part of a simple workflow and is not needed for normal
commit creation.

Stashing allows you to save away ("stash") your modifications without
making a commit or branch.  This is useful if you want to switch to
another branch or pull changes from somewhere else, or even put away
some changes and work on something else, without the cognitive overhead
of making a new branch, committing content there, then switching back,
etc.  Think of stashes as a set of patches (with a comment) that are
managed by Git, that you can view, apply, or throw away as you wish.

I'm sure that the issue you ran into was with staging.

It does take some getting used to, the idea that there's an
intermediate step between "modified" and "committed".  However, the
staging state is immensely useful once you get accustomed to it, and
it's critical because Git is not a file-based tool.  Each commit
represents a coherent state of the entire directory tree.

Thus, you need a way to choose which changes should go into each
commit.  It would be a very painful workflow if the only option was
"make a commit of all the changes in my workspace".  Then if you wanted
to commit just some of the changes, you'd have to copy the other ones
somewhere else and undo those changes, etc.

The staging area allows Git to help you with this: you pick and choose
which modifications you want to stage and when you make a commit it
will be created from only the staged changes, leaving the other
modifications alone so you can make another commit of those later.

Of course, there are simple options to just commit all the
modifications if that's what you want to do.


It also doesn't help that Linus originally called the staging area "the
index", which is IMO a confusing name, and there's a lot of
documentation still floating around out there that uses this name
instead :).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]