emacs-devel
[Top][All Lists]
Advanced

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

Re: VC mode and git


From: Sergey Organov
Subject: Re: VC mode and git
Date: Wed, 01 Apr 2015 16:03:26 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

> Hello, Sergey.
>
> On Wed, Apr 01, 2015 at 12:28:25PM +0300, Sergey Organov wrote:
>> Alan Mackenzie <address@hidden> writes:
>
>> >>  > 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.
>
>> That's pure insinuation. Git documentation could be far from ideal, but
>> it has most of information there. Here is quote from Git manual page on
>> merge for you. It mentions what merge does to working tree 4 times, and
>> tells you exactly where it puts the two sources of conflicting merges:
>
> Exaggeration rather than insinuation, I think you mean.

I said what I meant: insinuation.

> The git documentation is very bad. The information may be there, but
> if it is buried deep down in the small print, it is not useful. We're
> not talking about arcane details here, we're talking about the basic
> functionality - what git merge actually does - what does it merge and
> where does it put the result?

If you are not interested in details, the manual page explains what
merge does and where it puts result in the first sentence of the
description:

"Incorporates changes from the named commits (since the time their
histories diverged from the current branch) into the current branch."

>> > this - it doesn't even say where the two sources for its merge come from,
>> > or where it puts the result.

Oh, really?

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

Oh, really? Anybody who doesn't actively avoid to understand anything
"git" will easily infer that the working tree should be updated
accordingly, as "the current" is those branch that working tree
reflects, by definition.

Haters will hate, anyway.

-- Sergey.



reply via email to

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