Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Tue, Mar 31, 2015 at 11:02:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

> "Commit early, commit often", and you won't have to worry about
> remembering the details of your workflow.

And have my repository clogged up with meaningless arbitrary commits with
commit messages like "Just before resync with savannah, 2015-03-31
22-58"?  Then I'd have the hassle of somehow ensuring these silly commits
wouldn't find their way back to savannah.  I know vaguely this is a
solved problem, but it's one more thankless bit of drudgery I don't want
to get involved with.

>  > > It does, the same way that bzr or Mercurial does.[1]  I don't see
>  > > why you would think otherwise.

>  > Partly due to the following bug report which is near the start of the
>  > git-merge man page:  "Warning: Running git merge with non-trivial
>  > uncommitted changes is discouraged: while possible, it may leave you in a
>  > state that is hard to back out of in the case of a conflict.".  I can't
>  > imagine why the git maintainers don't fix this.

> Fix what?  One can do it if one wants to.  It's usually not dangerous
> because merge will abort if there are any local uncommitted changes in
> a file that would be changed by the merge.  It's actually rather
> useful in certain limited use cases, for example when I have a
> different ignore file from upstream.  In Mercurial, I have a patch in
> a queue that handles this but it's PITA to deal with.  (Note that
> everybody's favorite blunted plastic scissors, aka Bazaar, has a
> "merge --force" option to allow the user to make the choice.)

> It is indeed a bad idea to do a lot of work without committing and
> then merging.

Why?

> But that's a trivial deduction from the general theorem: it is a bad
> idea to do a lot of work without committing.

Why?

These two "why?"s are not rhetorical questions.

[ .... ]

>  > Mercurial will complete hg pull regardless of any changes in its working
>  > directory; in the case of conflicts it may leave several heads which
>  > require merging.

> Which is exactly what git does:

>     b 22:00$ git pull
>     remote: Counting objects: 3, done.
>     remote: Compressing objects: 100% (3/3), done.
>     remote: Total 3 (delta 1), reused 0 (delta 0)
>     Unpacking objects: 100% (3/3), done.
>     From /tmp/test/./a
>        684eca7..d47c24c  master     -> origin/master  <<<< LOOK LOOK LOOK
>     Updating 684eca7..d47c24c
>     error: Your local changes to the following files would be overwritten
>     by merge:
>        quuz
>     Please, commit your changes or stash them before you can merge.
>     Aborting

> I think you're partly confused by the fact that what Mercurial calls
> pull is what git calls fetch, and what git calls pull has no
> equivalent in core Mercurial AFAIK (pull -u only updates on a fast
> forward).

No, I'm not confused on this point.  There is hg fetch (deprecated) which
does hg pull followed (possibly) by hg merge, then hg update, more or
less.  I've never used it.

>  > Part of the problem is that the git-merge man page doesn't say that
>  > it messes with the working tree

> What else would it do?  Merge tools have changed the working tree from
> time immemorial.

That's poor, Stephen.  It might well merge in the repository without
touching the working tree.  The fact is, the documentation doesn't say
this - it doesn't even say where the two sources for its merge come from,
or where it puts the result.

> What's different from traditional 3-way merge tools (that aren't part
> of a VCS) is that git *also* creates a commit with more than one
> parent (which is what is meant by joining development histories).

Do development histories have 40-byte hashes?  :-)

> I find it a PITA that Mercurial doesn't, but rather requires a separate
> merge operation and then an explicit commit.

>  > By contrast, hg merge is documented concisely and adequately as
>  > "merge another revision into working directory".

> Everybody hates git's documentation.  I thought you were complaining
> about bugs in the program?

The documentation is part of the program.  Whether bugs are in the doc or
the prog, it costs just as much wasted time and energy.

-- 
Alan Mackenzie (Nuremberg, Germany).