bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Ulrich Mueller]

The function tries to determine the version by calling:

   git log -1 --pretty=format:%N

According to git documentation, format:%N will output "commit notes"
which will be empty usually. Presumably, this should be format:%H, in
order to output the commit hash. Patch is included below.


From bbe5ea6655c85e15ca7a2538f0c12c03b46fed6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Thu, 13 Nov 2014 23:43:23 +0100
Subject: [PATCH] emacs-repository-get-version: Fix git argument.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* version.el (emacs-repository-get-version): Call `git log'
command with proper format argument.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 lisp/ChangeLog  | 5 +++++
 lisp/version.el | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 5c0ec99..e2276d2 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-13  Ulrich Müller  <ulm@gentoo.org>
+
+	* version.el (emacs-repository-get-version): Call `git log'
+	command with proper format argument.
+
 2014-11-13  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* net/shr.el (shr-inhibit-images): Add a doc string.
diff --git a/lisp/version.el b/lisp/version.el
index 68b502c..1ea38da 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -188,7 +188,7 @@ only ask the VCS if we cannot find any information ourselves."
 	     (and (eq 0
 		      (condition-case nil
 			  (call-process "git" nil '(t nil) nil "log"
-					"-1" "--pretty=format:%N")
+					"-1" "--pretty=format:%H")
 			(error nil)))
 		  (not (zerop (buffer-size)))
 		  (replace-regexp-in-string "\n" "" (buffer-string))))))))
-- 
2.1.3

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Ulrich Mueller <ulm@gentoo.org> writes:

> The function tries to determine the version by calling:
>
>    git log -1 --pretty=format:%N
>
> According to git documentation, format:%N will output "commit notes"
> which will be empty usually. Presumably, this should be format:%H, in
> order to output the commit hash. Patch is included below.

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ulrich Mueller <ulm@gentoo.org> writes:
>
>> The function tries to determine the version by calling:
>>
>>    git log -1 --pretty=format:%N
>>
>> According to git documentation, format:%N will output "commit notes"
>> which will be empty usually. Presumably, this should be format:%H, in
>> order to output the commit hash. Patch is included below.
>
> Thanks; applied.

Oops.  I should have applied that to the emacs-24 branch instead.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Ulrich Mueller]

Also, according to the message in commit 0abf413 (of 2014-01-11):
"The Bazaar case can be discarded after the repo transition."

Should that be done now?

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 08:19:54 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> Also, according to the message in commit 0abf413 (of 2014-01-11):
> "The Bazaar case can be discarded after the repo transition."
> 
> Should that be done now?

No.  The migration to git is just an experiment.  We plan on going
back to bzr in a month or so.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Ulrich Mueller]

>>>>> On Fri, 14 Nov 2014, Eli Zaretskii wrote:

>> Also, according to the message in commit 0abf413 (of 2014-01-11):
>> "The Bazaar case can be discarded after the repo transition."
>> 
>> Should that be done now?

> No.  The migration to git is just an experiment.  We plan on going
> back to bzr in a month or so.

:-)

From 2936042bd87ef1a626578819a23c18b5e1e634b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Fri, 14 Nov 2014 09:05:02 +0100
Subject: [PATCH] Discard the Bazaar case in repository version detection

* version.el (emacs-bzr-version-dirstate, emacs-bzr-version-bzr):
Remove.
(emacs-repository-get-version): Discard the Bazaar case.

* vc/vc-bzr.el (vc-bzr-version-dirstate): Rename from
emacs-bzr-version-dirstate and move from version.el to here.
(vc-bzr-working-revision): Use it.
---
 lisp/ChangeLog    | 10 ++++++++
 lisp/vc/vc-bzr.el | 17 +++++++++++--
 lisp/version.el   | 73 +------------------------------------------------------
 3 files changed, 26 insertions(+), 74 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index c3b879a..9044804 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,13 @@
+2014-11-14  Ulrich Müller  <ulm@gentoo.org>
+
+	* version.el (emacs-bzr-version-dirstate, emacs-bzr-version-bzr):
+	Remove.
+	(emacs-repository-get-version): Discard the Bazaar case.
+
+	* vc/vc-bzr.el (vc-bzr-version-dirstate): Rename from
+	emacs-bzr-version-dirstate and move from version.el to here.
+	(vc-bzr-working-revision): Use it.
+
 2014-11-14  Fabián Ezequiel Gallina  <fgallina@gnu.org>
 
 	* progmodes/python.el (python-shell-virtualenv-root): Rename from
diff --git a/lisp/vc/vc-bzr.el b/lisp/vc/vc-bzr.el
index a093bcb..3a5de22 100644
--- a/lisp/vc/vc-bzr.el
+++ b/lisp/vc/vc-bzr.el
@@ -496,6 +496,19 @@ in the branch repository (or whose status not be determined)."
 (defun vc-bzr-workfile-unchanged-p (file)
   (eq 'unchanged (car (vc-bzr-status file))))
 
+(defun vc-bzr-version-dirstate (dir)
+  "Try to return as a string the bzr revision ID of directory DIR.
+This uses the dirstate file's parent revision entry.
+Returns nil if unable to find this information."
+  (let ((file (expand-file-name ".bzr/checkout/dirstate" dir)))
+    (when (file-readable-p file)
+      (with-temp-buffer
+        (insert-file-contents file)
+        (and (looking-at "#bazaar dirstate flat format 3")
+             (forward-line 3)
+             (looking-at "[0-9]+\0\\([^\0\n]+\\)\0")
+             (match-string 1))))))
+
 (defun vc-bzr-working-revision (file)
   ;; Together with the code in vc-state-heuristic, this makes it possible
   ;; to get the initial VC state of a Bzr file even if Bzr is not installed.
@@ -543,8 +556,8 @@ in the branch repository (or whose status not be determined)."
 			 ;; files exist.
 			 (and (file-exists-p branch-format-file)
 			      (file-exists-p lastrev-file)
-			      (equal (emacs-bzr-version-dirstate l-c-parent-dir)
-				     (emacs-bzr-version-dirstate rootdir))))))
+			      (equal (vc-bzr-version-dirstate l-c-parent-dir)
+				     (vc-bzr-version-dirstate rootdir))))))
 		 t)))
         (with-temp-buffer
           (insert-file-contents branch-format-file)
diff --git a/lisp/version.el b/lisp/version.el
index 1ea38da..410e730 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -93,41 +93,6 @@ or if we could not determine the revision.")
 (define-obsolete-variable-alias 'emacs-bzr-version
                                 'emacs-repository-version "24.4")
 
-(defun emacs-bzr-version-dirstate (dir)
-  "Try to return as a string the bzr revision ID of directory DIR.
-This uses the dirstate file's parent revision entry.
-Returns nil if unable to find this information."
-  (let ((file (expand-file-name ".bzr/checkout/dirstate" dir)))
-    (when (file-readable-p file)
-      (with-temp-buffer
-        (insert-file-contents file)
-        (and (looking-at "#bazaar dirstate flat format 3")
-             (forward-line 3)
-             (looking-at "[0-9]+\0\\([^\0\n]+\\)\0")
-             (match-string 1))))))
-
-(defun emacs-bzr-version-bzr (dir)
-  "Ask bzr itself for the version information for directory DIR."
-  ;; Comments on `bzr version-info':
-  ;; i) Unknown files also cause clean != 1.
-  ;; ii) It can be slow, contacting the upstream repo to get the
-  ;; branch nick if one is not set locally, even with a custom
-  ;; template that is not asking for the nick (as used here).  You'd
-  ;; think the latter part would be trivial to fix:
-  ;; https://bugs.launchpad.net/bzr/+bug/882541/comments/3
-  ;; https://bugs.launchpad.net/bzr/+bug/629150
-  ;; You can set the nick locally with `bzr nick ...', which speeds
-  ;; things up enormously.  `bzr revno' does not have this issue, but
-  ;; has no way to print the revision_id AFAICS.
-  (message "Waiting for bzr...")
-  (with-temp-buffer
-    (if (zerop
-         (call-process "bzr" nil '(t nil) nil "version-info"
-                       "--custom"
-                       "--template={revno} {revision_id} (clean = {clean})"
-                       dir))
-        (buffer-string))))
-
 (define-obsolete-function-alias 'emacs-bzr-get-version
                                 'emacs-repository-get-version "24.4")
 
@@ -145,43 +110,7 @@ maybe ask the VCS itself, if the sources appear to be under
 version control.  If `force', always ask.  the VCS. Otherwise
 only ask the VCS if we cannot find any information ourselves."
   (or dir (setq dir source-directory))
-  (cond ((file-directory-p (expand-file-name ".bzr/branch" dir))
-	 (if (eq external 'force)
-	     (emacs-bzr-version-bzr dir)
-	   (let (file loc rev)
-	     (cond ((file-readable-p
-		     (setq file (expand-file-name
-				 ".bzr/branch/last-revision" dir)))
-		    (with-temp-buffer
-		      (insert-file-contents file)
-		      (goto-char (point-max))
-		      (if (looking-back "\n")
-			  (delete-char -1))
-		      (buffer-string)))
-		   ;; OK, no last-revision.  Is it a lightweight checkout?
-		   ((file-readable-p
-		     (setq file (expand-file-name ".bzr/branch/location" dir)))
-		    (setq rev (emacs-bzr-version-dirstate dir))
-		    ;; If parent branch is local, try looking there for the rev.
-		    ;; Note: there is no guarantee that the parent branch's rev
-		    ;; corresponds to this branch.  This branch could have
-		    ;; been made with a specific -r revno argument, or the
-		    ;; parent could have been updated since this branch was
-		    ;; created.
-		    ;; To try and detect this, we check the dirstate revids
-		    ;; to see if they match.
-		    (if (and (setq loc (with-temp-buffer
-					 (insert-file-contents file)
-					 (if (looking-at "file://\\(.*\\)")
-					     (match-string 1))))
-			     (equal rev (emacs-bzr-version-dirstate loc)))
-			(emacs-repository-get-version loc)
-		      ;; If parent does not match, the best we can do without
-		      ;; calling external commands is to use the dirstate rev.
-		      rev))
-		   (external
-		    (emacs-bzr-version-bzr dir))))))
-	((file-directory-p (expand-file-name ".git" dir))
+  (cond ((file-directory-p (expand-file-name ".git" dir))
 	 (message "Waiting for git...")
 	 (with-temp-buffer
 	   (let ((default-directory (file-name-as-directory dir)))
-- 
2.1.3

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 14 Nov 2014 05:01:38 +0100
> MailScanner-NULL-Check: 1416542500.75391@gxilGrUuOUNOorim2WEIOg
> Cc: 19049@debbugs.gnu.org
> 
> Ulrich Mueller <ulm@gentoo.org> writes:
> 
> > The function tries to determine the version by calling:
> >
> >    git log -1 --pretty=format:%N
> >
> > According to git documentation, format:%N will output "commit notes"
> > which will be empty usually. Presumably, this should be format:%H, in
> > order to output the commit hash. Patch is included below.
> 
> Thanks; applied.

To the wrong branch again.  Please backport this to the emacs-24
branch.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To the wrong branch again.  Please backport this to the emacs-24
> branch.

I would if I knew how.  admin/repo says

----

* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").

Indicate in the commit log that there is no need to merge the commit
to the trunk, e.g. start the commit message with "Backport:".  This is
helpful for the person merging the release branch to the trunk.

http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html

* How to merge changes from emacs-24 to trunk

[The section on git merge procedure has not yet been written]

----

neither of which helps, and the Emacs for Git Devs wiki doesn't say how
to cherry-pick stuff, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Dmitry Gutov]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> neither of which helps, and the Emacs for Git Devs wiki doesn't say how
> to cherry-pick stuff, either.

Have you tried 'git cherry-pick <hash>'? Seems rather obvious, doesn't it?

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> neither of which helps, and the Emacs for Git Devs wiki doesn't say how
>> to cherry-pick stuff, either.
>
> Have you tried 'git cherry-pick <hash>'? Seems rather obvious, doesn't it?

It's funny how everything is obvious after you know what how to do
something?

Thanks, I think that worked...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Argh!  But now my backported change didn't get marked with "Backport:"
as per admin/notes.

Or is that outdated information?

I just did

larsi@stories ~/src/24-emacs]$ git cherry-pick 7169391ddb735892a8463aa96407e0448a3820a0
[emacs-24 df33e85] (emacs-repository-get-version): Call `git log' with proper format argument
 Author: Ulrich Müller <ulm@gentoo.org>
 2 files changed, 6 insertions(+), 1 deletion(-)
[larsi@stories ~/src/24-emacs]$ git push
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 671 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Sending notification emails to: emacs-diffs@gnu.org
To larsi@git.sv.gnu.org:/srv/git/emacs.git
   6a079d5..df33e85  emacs-24 -> emacs-24

Not really a step where I could put "Backport:" anywhere...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Dmitry Gutov]

On 11/14/2014 04:25 PM, Lars Magne Ingebrigtsen wrote:
> Argh!  But now my backported change didn't get marked with "Backport:"
> as per admin/notes.

Err, you'd need to change the commit message, of course.

Either with a separate step of 'git commit --amend', or by passing '-e' 
to 'git cherry-pick' (just found about it by reading the man page).

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11/14/2014 04:25 PM, Lars Magne Ingebrigtsen wrote:
>> Argh!  But now my backported change didn't get marked with "Backport:"
>> as per admin/notes.
>
> Err, you'd need to change the commit message, of course.
>
> Either with a separate step of 'git commit --amend', or by passing
> '-e' to 'git cherry-pick' (just found about it by reading the man
> page).

Of course.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 16:37:27 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, 19049@debbugs.gnu.org
> 
> On 11/14/2014 04:25 PM, Lars Magne Ingebrigtsen wrote:
> > Argh!  But now my backported change didn't get marked with "Backport:"
> > as per admin/notes.
> 
> Err, you'd need to change the commit message, of course.
> 
> Either with a separate step of 'git commit --amend', or by passing '-e' 
> to 'git cherry-pick' (just found about it by reading the man page).

There goes the "obvious" part.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Dmitry Gutov]

On 11/14/2014 04:52 PM, Eli Zaretskii wrote:

>> Either with a separate step of 'git commit --amend', or by passing '-e'
>> to 'git cherry-pick' (just found about it by reading the man page).
>
> There goes the "obvious" part.

It just requires a bit more thought, in order to realize that Git won't 
exactly add anything to the commit message, just because it's an Emacs 
convention.

Sorry, as a Git user, I'm quite used to doing some history rewriting 
before doing push. I suppose others will get used to it, too.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 16:58:01 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: larsi@gnus.org, 19049@debbugs.gnu.org
> 
> Sorry, as a Git user, I'm quite used to doing some history rewriting 
> before doing push. I suppose others will get used to it, too.

It's easy to get used, yes.  It is _not_ easy to figure out for the
first time how to do it.  If we had that in writing, we could just
point people there (and many would read out of their own initiative).

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  19049@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 15:25:40 +0100
> 
> Argh!  But now my backported change didn't get marked with "Backport:"
> as per admin/notes.
> 
> Or is that outdated information?

No, it isn't outdated.  We haven't yet given up on having gitmerge.el
similar to bzrmerge.el, although I don't see anybody (besides Glenn)
who cares.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Eli Zaretskii <eliz@gnu.org>,  19049@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 16:17:01 +0200
> 
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > neither of which helps, and the Emacs for Git Devs wiki doesn't say how
> > to cherry-pick stuff, either.
> 
> Have you tried 'git cherry-pick <hash>'? Seems rather obvious, doesn't it?

No, it isn't obvious if you never did that before.  More importantly,
it's not the way changes should be backported, because cherry-pick
also commits reusing the same commit message, as Lars has just
discovered, which is bad.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 19049@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 15:12:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To the wrong branch again.  Please backport this to the emacs-24
> > branch.
> 
> I would if I knew how.

Just commit the same changes to the branch and mention "backported" in
the commit message.

> admin/repo says
> 
> ----
> 
> * Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
> 
> Indicate in the commit log that there is no need to merge the commit
> to the trunk, e.g. start the commit message with "Backport:".  This is
> helpful for the person merging the release branch to the trunk.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
> 
> * How to merge changes from emacs-24 to trunk
> 
> [The section on git merge procedure has not yet been written]
> 
> ----
> 
> neither of which helps, and the Emacs for Git Devs wiki doesn't say how
> to cherry-pick stuff, either.

Where were you 10 months ago, when I wrote that this is what will
happen, if the instructions are left at what was written back then?

If some of those who are mightily confused now, as I predicted they
will be, supported what I said back then, perhaps we could have had
enough leverage to insist on better write-ups.  But nooo! everyone who
cared to reply claimed that this is all either obvious or too personal
to describe, and some even said I'm a "bullshitter".

Now you-all get to learn this stuff the hard way.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If some of those who are mightily confused now, as I predicted they
> will be, supported what I said back then, perhaps we could have had
> enough leverage to insist on better write-ups.  But nooo! everyone who
> cared to reply claimed that this is all either obvious or too personal
> to describe, and some even said I'm a "bullshitter".

I didn't.  >"?  That git is a pile of incomprehensibility should be
pretty obvious to everybody.

> Now you-all get to learn this stuff the hard way.

Indeed.  Hopefully after a few more days we'll have real recipes for how
to do all these "obvious if you've studied the Gnomic Scriptures" tasks,
and we can update the documentation with docs that actually say how to
do things.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 19049@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 15:59:37 +0100
> 
> > Now you-all get to learn this stuff the hard way.
> 
> Indeed.  Hopefully after a few more days we'll have real recipes for how
> to do all these "obvious if you've studied the Gnomic Scriptures" tasks,
> and we can update the documentation with docs that actually say how to
> do things.

No, that's just the beginning.  Almost every question asked about this
resulted in umpteen different answers.  Which one(s) to choose is
another obstacle to negotiate, and it's not always easy, because each
alternative has its subtle pro's and con's.

We had 10 months and enough git expertise to discuss this and decide
what's best.  And we wasted it.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, that's just the beginning.  Almost every question asked about this
> resulted in umpteen different answers.  Which one(s) to choose is
> another obstacle to negotiate, and it's not always easy, because each
> alternative has its subtle pro's and con's.
>
> We had 10 months and enough git expertise to discuss this and decide
> what's best.  And we wasted it.

Well, I think the problem here is that git experts really aren't the
people who are best suited to explain these things.  They don't know
what the incomprehensible things are.  "Well, of course you have to
stash the refs in the staging area!  That's self-evident!  You can't
merge if you have unstaged refs that point to the foreign origin!  I
mean master!"

So we get these recipes when people who aren't interested in git (like
me) are forced to learn how to use it.

I'll be summarising my experience in admin/notes tomorrow, since I now
have a (more or less) working setup.

And it'll be short, and won't mention the words "refs", "stash" or
"staging", but will just give the commands that you should use.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 19049@debbugs.gnu.org
> Date: Fri, 14 Nov 2014 16:16:57 +0100
> 
> > We had 10 months and enough git expertise to discuss this and decide
> > what's best.  And we wasted it.
> 
> Well, I think the problem here is that git experts really aren't the
> people who are best suited to explain these things.  They don't know
> what the incomprehensible things are.

Some of them are the best people, and some of them do know what's hard
to comprehend.  Some people do have the ability to document and
explain something in your area of expertise.  And if they don't,
others could have done that, given the right recipes.

> I'll be summarising my experience in admin/notes tomorrow, since I now
> have a (more or less) working setup.

I suggest to post that here first, and see that the advice you want to
put in notes is sound.  As you already understand, it's easy to become
confused about these things.

bug#19049: 25.0.50; emacs-repository-get-version doesn't work with git

[Eli Zaretskii]

> Date: Fri, 14 Nov 2014 17:23:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 19049@debbugs.gnu.org
> 
> > I'll be summarising my experience in admin/notes tomorrow, since I now
> > have a (more or less) working setup.
> 
> I suggest to post that here first

By "here" I meant emacs-devel, of course.