[Top][All Lists]

[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: Sat, 04 Apr 2015 12:31:56 +0300

> Date: Sat, 04 Apr 2015 10:30:13 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
>  > I gathered enough stuff in this thread to fix GitQuickStartForEmacsDevs,
>  > to which I'd appreciate comments from everyone who has a moment to
>  > spare.
> Thanks.  Please consider the following:

Thank you for your comments.

> (1) Say that a pull is a fetch plus a merge and what these do.

Why would that matter for people who just want to copy their mental
models from CVS to Git with minimal changes?

Every VCS does some kind of a fetch and a merge when it pulls.  Git
and AFAIK also Mercurial are unique in that they let the user invoke
each of these separately.  But IMO that only matters if we then
explain how to use these separate steps to the user's benefit, and I
don't see how doing so is possible, let alone necessary, within a
CVS-like workflow.

Maybe I'm missing something, so please elaborate why you thought this
to be beneficial.

> (2) Distinguish the two ways a merge can fail: The one where git refuses
>      to merge because it would overwrite changes and the second one where
>      it detects conflicts.  And how to deal with them.

I think the way to deal with both is the same, and that's what the
instructions describe.  Again, maybe I'm mistaken, but then please
show an example where the instructions would fail in one of those

The intent is to try to preserve the CVS mental models, so the
description generally follows what one would do with conflicts created
by "cvs update", the only changes being those that are strictly
necessary with Git.

> (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
>      People will find them in the manuals and tutorials and we should at
>      least tell them why the method we propose here is sufficient or
>      better.

The fact that these are mentioned in the manuals is not a good
guidance for mentioning them, since the manuals mention a lot more
than just these two.

Stashing was not mentioned there to begin with; it isn't even
mentioned in the more advanced GitForEmacsDevs page, nor was its bzr
equivalent ever mentioned in the instructions we wrote for Bazaar.
CVS has no equivalent for stashing.  So I'm not sure why you think it
should be mentioned.  Perhaps the reason is that you yourself use it a
lot.  Once again, please elaborate.

Rebasing is a tricky issue.  Richard asked (off-line) for an
explanation of what it is, so the notion itself is not immediately
clear to everyone, and would need to be explained.  Next, we decided
not to recommend rebasing (because we merge from the release branch,
and generally prefer merge-based workflows), so if we want the readers
of those instructions to use rebase, we must describe it as a marginal
feature for rare situations.  Is it worth that, and if so, why?

It is possible that both of these issues could be explained in a
separate section near the end of the page, as some additional stuff
worth learning.  But then (a) we should think carefully how we would
like to categorize them, and (b) there's a real danger people won't
read something that has no direct bearing on the otherwise
cookbook-like approach of the instructions.

Those are my thoughts, feel free to point out where I'm wrong.


reply via email to

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