Re: Git transition checklist

[Eli Zaretskii]

> From: address@hidden (Eric S. Raymond)
> Date: Wed,  8 Jan 2014 08:52:00 -0500 (EST)
> 
> > 5. Have the procedures and the recommended workflows described on the
> >    wiki, similar to what was done with bzr migration.
> 
> That is now done.  I have created two new pages on EmacsWiki,
> GitForEmacsDevs and GitQuickStartForEmacsDevs. These are adapted from
> the corresponding *Bzr* pages but describe git commands to perform
> equivalent operations.

Thanks.  I have some comments/questions on that:

 . The section about merging to the upstream master seems to omit "git
   push" after merging the task onto the master branch.  It ends with
   the "git commit" command, which AFAIK is not the end of the story.

 . The few places that describe a merge from another branch seem to
   say that one needs to issue 2 commands: "git merge" and "git commit".
   Perhaps I'm confused, but isn't it true that "git merge"
   automatically commits if there are no conflicts?  If I'm right, an
   explicit commit is needed after merge only when there are conflicts
   to be resolved.

   For the same reason, is "git revert" TRT when a push upstream fails
   after a merge from the local task branch, because someone else
   pushed meanwhile?  The merge is already committed locally, so what
   will revert do?  I think one will need "git reset" in this case.

 . I would suggest describing the setup of git-merge-changelog,
   because as long as we keep ChangeLog files in the repository,
   people might bump into conflicts in the logs, and it would be nice
   to avoid that.

 . I think we should discuss some more how to work with the
   development trunk and the release branch in parallel, and reflect
   the results of the discussion in the Wiki.

   The issue here is that the release branch and the trunk diverge
   very quickly after the branch point, and the result is that after
   you checkout the other branch, you generally need a very long
   build, many times a full bootstrap.  While on a modern system, a
   full bootstrap should take a few minutes, it is still annoyingly
   long, and makes higher the risk of losing the race against other
   committers.  In addition, you only have a single executable at any
   given time, so comparison of behavior between the two branches is
   difficult.

   So perhaps we should find a way of having two separate branches,
   such that switching between them does not require a build if
   nothing changed.

> The only omission is that I left out the git equivalent of bzr bundle.

I think the section about publishing a task was also omitted.  Was
that on purpose?

> An interesting side effect of doing this translation, by the way, is
> that I now know the exact git-command equivalents for the recommended
> workflow in Bazaar.  Rather to my surprise, the git procedures are
> simpler!
> 
> I'm surprised at this because Bazaar, whatever its other failings, had
> a reputation as being simpler to use than git which I believed was
> deserved. But, at least for the workflows described, git avoids so
> much complexity and ceremony by not having the branch-vs.-repo
> distinction that the gain from this swamps git's other UI
> shortcomings.

Can we please stop the apology and concentrate on the task at hand?
This kind of comments can only annoy those who are still in mourning
of the need to switch.  (And no, I don't see how the git procedures
are simpler, except due to some omissions and non-existent features,
they are roughly the same.)