On Fri, Nov 6, 2015 at 11:10 AM, Eli Zaretskii <
address@hidden> wrote:
> The idea of that passage is that merge is not to be afraid of. That
> is correct with any modern dVCS.
This is inside a section about merging changes from the release branch to the trunk. I wouldn't expect there a general discussion of merge, but of merge policies in Emacs, and about gitmerge.el.
> I don't think so.
In this case, before codifying these policies we should agree on them, shouldn't we?
In general (this is *not* a complain, just an impression), having been out for a year, so I missed the switch to git, I think that for a newcomer, the information about using git with Emacs is a bit scattered. We have sections in CONTRIBUTE, we have admin/notes/repo, admin/notes/git-workflow, which starts with the not-very-reassuring "(This is a draft. The method here won't actually work yet, because neither git-new-workdir nor merge-changelog are in the Emacs distribution yet.)". And then we have two different documents on EmacsWiki.
A trivial change for the obsolete references to Bazaar.
diff --git a/admin/notes/repo b/admin/notes/repo
index b27a3f4..d28955c 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -41,8 +41,8 @@ preferable not to merge from master until you are done with the
feature. Unless you really need some change that was done on the
master while you were developing on the branch, you don't really need
those merges; just merge once, when you are done with the feature, and
-Bazaar will take care of the rest. Bazaar is much better in this than
-CVS, so interim merges are unnecessary.
+Git will take care of the rest. Git is much better in this than CVS
+or Bazaar, so interim merges are unnecessary.
Or use shelves; or rebase; or do something else. See the thread for
yet another fun excursion into the exciting world of version control.
warning: LF will be replaced by CRLF in admin/notes/repo.
The file will have its original line endings in your working directory.