Improve content of tree.gittxt

Improve content of tree.gittxt

[knupero, 2019-07-12 21:36:36]

Hi everybody!

With the proposed patch tree.gittxt will contain the name of the current branch
as well as up to 10 commits of history. Example tree:gittxt:


 BRANCH: IMPROVE_TREE.GITTXT

HISTORY:
========

   HASH: b9a2c64a66147f3b1b4a30f27ca4d3c96a01e982
SUBJECT: Improve content of tree.gittxt

   HASH: 49f41bf1c64ae1e2490571e73a85cbc4b2a9fb27
SUBJECT: Issue 4362/2: add regtest

   HASH: 17d3d3a1515e74f5aaa7f62604994cfdc1391361
SUBJECT: Issue 4362/1: head completion uses dotted breves

   HASH: 2b52bc2bf1d4d4e505792f074442d4cabb031f06
SUBJECT: Issue 5520/2: add \ambitusAfter to Changes

   HASH: 03f4723afcdee9ede15feddacad336d9a067ca8e
SUBJECT: Issue 5520/1: Improvements to \ambitusAfter

   HASH: 00b4c4c7577ea8fee61ed9b1fee515dbdba494f5
SUBJECT: Doc: NR - expressive.itely - accidentals for naturals using pitched
trills

   HASH: 189cfb95ea0b105e9ea7634c3cf869a0d4a72cdc
SUBJECT: Doc: NR 2.9 Ancient Notation - add verbatim to @lilypond example for
custodes

   HASH: 4cc884ee0904fce4f05774b2db6dcf0ba4c70d59
SUBJECT: ly: turkish-makam.ly - minor edit to sultaniyegah

[Carl, 2019-07-12 22:36:29]

Why do we want 10 commits instead of just 1?  I don't see the rationale for this
patch.

[knupero, 2019-07-13 07:56:47]

On 2019/07/12 22:36:29, Carl wrote:
> Why do we want 10 commits instead of just 1?  I don't see the rationale for
this
> patch.

Well, the patch first adds the name of the branch used and increases the number
of commits in the history.

Whether or not this is helpful depends on the situation. When I test a patch in
a temporary branch, only a hash with the subject is in tree.gittxt. The
information which commit was the base on which I applied the patch is lost, and
the hash of a temporary branch no longer exists. And then there are the
situations where you want to test a patch on top of a patch ... on top of commit
xyz. A short history doesn't hurt, but can be quite helpful in some situations.

[wl_gnu.org, 2019-07-13 08:52:17]

> Well, the patch first adds the name of the branch used

This is quite useful.

> When I test a patch in a temporary branch, only a hash with the
> subject is in tree.gittxt.  The information which commit was the
> base on which I applied the patch is lost, and the hash of a
> temporary branch no longer exists.

What I would like to see for such branches is the ID of the commit
where the branch is rooted in master, this is, if we have

             o---o---o branch
            /
   o---o---o---o---o master
   0   1   2   3   4

I want to see ID 2 in this file, marked as the root of `branch'.


    Werner

[knupero, 2019-07-14 08:34:26]

> What I would like to see for such branches is the ID of the commit
> where the branch is rooted in master, this is, if we have
> 
>              o---o---o branch
>             /
>    o---o---o---o---o master
>    0   1   2   3   4
> 
> I want to see ID 2 in this file, marked as the root of `branch'.

So you ask for the equivalent of the output of the following script?

#!/bin/bash

BR=`LANG=c git branch | grep "^\*" | sed -e "s|^* *||"`

HD=`git rev-parse --verify HEAD`

FP=`git merge-base --octopus master HEAD`

echo "    BRANCH: $BR"
echo "      HEAD: $HD"
if [ ! -z $FP ]; then
  echo "MERGE_BASE: $FP"
  echo -e '\n   HISTORY:\n   ========\n';
  git log --pretty=format:"      HASH: %H%n   SUBJECT: %s%n" $FP~1..HEAD | cat
fi

[wl_gnu.org, 2019-07-14 08:58:04]

>> What I would like to see for such branches is the ID of the commit
>> where the branch is rooted in master, this is, if we have
>>
>>               o---o---o branch
>>              /
>>     o---o---o---o---o master
>>     0   1   2   3   4
>>
>> I want to see ID 2 in this file, marked as the root of `branch'.
>
> So you ask for the equivalent of the output of the following script?

I think so, yes — thanks!  Not sure if everyone considers this useful,
though...


    Werner

[knupero, 2019-07-15 20:45:32]

2nd patchset - improve tree.gittxt

[knupero, 2019-07-15 21:11:39]

We display BRANCH and HEAD.

If we find a merge-point with master, we display that 
merge-point and the history from merge-point to HEAD.
If not, we display up to 10 commits of history.

Finding a merge-point may fail if we are in a git repository
that is not a full clone of the master repository.

Displaying 10 commits might fail after some commits if there
are e.g. cherry-picks from unknown branches in repositories
that are not full clones of our master repository. Errors
are ignored.

Current gub will display the wrong branch unless you apply
the following patch:

--- cut here ---
diff --git a/gub/repository.py b/gub/repository.py
index 5c2c36c551..c91a1156ca 100644
--- a/gub/repository.py
+++ b/gub/repository.py
@@ -701,7 +701,8 @@ cd %(dir_slash_vcs)s && mv *bz2 *deb *gz *zip .. || :
             self._update_workdir (destdir)
     def _update_workdir_shallow (self, destdir):
         branch = self.branch # branch is empty?
-        branch = 'master'
+        if not branch:
+            branch = 'master'
         HEAD = self.checksum ()
         if HEAD == 'invalid':
             barf
--- cut here ---

Without the patch, BRANCH is always 'master'. The gub patch
fixes a problem introduced 10 years and one day ago in commit
e0ed3589241383db0b8d77c1c7738ad3432a4fd5 ;-)

[Carl, 2019-07-16 20:59:37]

LGTM.  THanks for doing this!

Carl

[knupero, 2019-07-31 06:30:40]

Version 2 of patch, don't assume there is a local master

[knupero, 2019-07-31 06:40:02]

Patchset 2 was reviewed, counted down, pushed to staging, made it to master.
Then David's patchy broke because I incorrectly assumed that every clone of a
lilypond repository has a local copy of the master branch. Consequently the
patch was reverted in staging and master.

The fix is obvious, we must use 'origin/master' instead of 'master'.

Please review and countdown again.