emacs-devel
[Top][All Lists]
Advanced

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

Re: VC mode and git


From: Eli Zaretskii
Subject: Re: VC mode and git
Date: Fri, 03 Apr 2015 10:12:58 +0300

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Sergey Organov <address@hidden>,
>     address@hidden
> Date: Fri, 03 Apr 2015 07:40:40 +0900
> 
> Eli Zaretskii writes:
>  > > From: Sergey Organov <address@hidden>
> 
>  > > Each commit has zero or more pointers to parents, usually 1. Merge
>  > > commit is commit that has more pointers to parents than 1 (usually 2).
>  > > That's all about the meta-data. Simple, eh?
>  > 
>  > And that meta-data needs to be brought in as part of the merge, in
>  > addition to changes to the tree.
> 
> No.  That's an important difference between git and other DVCSes.
> "git merge" does a 3-way merge in a tree that corresponds to a
> previously committed state, and sets up some (hidden) metadata that
> help automate the following multi-parent commit.  Optionally it will
> initiate that commit.
> 
> The meta-data must already be present in the repo pointed to by the
> workspace, brought in by a fetch.  Because it's a very common
> operation, especially in synchronizing mirror repos, git pull will
> automatically fetch and merge.  Perhaps that what you think about it.

I know all of the above, and I don't see where it contradicts what I
wrote.

The original issue was a claim that a merge (as an operation) is "just
a commit", and I said it's more than that.

>  > You can call all of this a "commit", but then you probably mean
>  > "commit object", a different beast.  Using confusing shorts in this
>  > discussion doesn't help understanding.
> 
> In discussing git, claiming that "commit" is anything other than a
> verb that means "to create a commit object" is what confuses
> understanding.  You will confuse those who are familiar with git and
> give incorrect ideas to those who aren't.  If you have a different
> concept of what a commit "should be", you need to explain that, and
> what sequence of git operations correspond to that concept.

My terminology follows the Git glossary man page, which I think
doesn't agree with the above, at least not 100%.  E.g., "commit",
neither as a noun nor as a verb, is not described there as "creating a
commit object".



reply via email to

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