[PATCH 0/4] nmbug without an upstream repository (and init)

[PATCH 0/4] nmbug without an upstream repository (and init)

[W. Trevor King]

Currently 'nmbug status' errors out if there is no @{upstream} branch.
To support folks who are just using nmbug locally, add exit code
checking and stderr catching to handle this case appropriately.  The
final commit isn't closely related, but it allows folks to easily
initialize nmbug repositories (e.g. if they want to version-controll
*all* their tags, or tags for a different project).  After this
series, you can run something like:

  export NMBGIT=/tmp/nmbug
  nmbug init
  export NMBPREFIX=''
  nmbug status
  nmbug commit

to create a new repository with all your tags.  Replace the NMBPREFIX
with something else (e.g. NMBPREFIX='myproject::') to only track tags
for a particular project.  You could also define aliases to set the
appropriate environment variables on the fly:

  $ alias mpbug='NMBGIT=/tmp/nmbug NMBPREFIX="myproject::" nmbug'
  $ mpbug status

W. Trevor King (4):
  nmbug: Add a git_with_status helper function
  nmbug: Handle missing @upstream in is_unmerged
  nmbug: Catch stderr in is_unmerged
  nmbug: Add an 'init' command

 devel/nmbug/nmbug | 49 +++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 43 insertions(+), 6 deletions(-)

-- 
1.9.1.353.gc66d89d

[PATCH 1/4] nmbug: Add a git_with_status helper function

[W. Trevor King]

Sometimes we want to catch Git errors and handle them, instead of
dying with an error message.  This lower-level version of git() allows
us to get the error status when we want it.
---
 devel/nmbug/nmbug | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index b18ded7..4a79722 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -63,13 +63,20 @@ sub git_pipe {
   spawn ($envref, defined $ioref ? $ioref : (), defined $dir ? $dir : (), @_);
 }
 
-sub git {
+sub git_with_status {
   my $fh = git_pipe (@_);
   my $str = join ('', <$fh>);
-  unless (close $fh) {
+  close $fh;
+  my $status = $?;
+  chomp($str);
+  return ($str, $status);
+}
+
+sub git {
+  my ($str, $status) = git_with_status (@_);
+  if ($status) {
     die "'git @_' exited with nonzero value\n";
   }
-  chomp($str);
   return $str;
 }
 
-- 
1.9.1.353.gc66d89d

Re: [PATCH 1/4] nmbug: Add a git_with_status helper function

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> Sometimes we want to catch Git errors and handle them, instead of
> dying with an error message.  This lower-level version of git() allows
> us to get the error status when we want it.

pushed this one patch.

d

[PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[W. Trevor King]

If we don't have an upstream, there is nothing to merge, so nothing is
unmerged.  This avoids errors like:

  $ nmbug status
  error: No upstream configured for branch 'master'
  error: No upstream configured for branch 'master'
  fatal: ambiguous argument '@{upstream}': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'
  'git rev-parse @{upstream}' exited with nonzero value

You might not have an upstream if you're only using nmbug locally to
version-control your tags.
---
 devel/nmbug/nmbug | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 4a79722..998ee6b 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -430,7 +430,10 @@ sub do_status {
 sub is_unmerged {
   my $commit = shift || '@{upstream}';
 
-  my $fetch_head = git ('rev-parse', $commit);
+  my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
+  if ($status) {
+    return 0;
+  }
   my $base = git ( 'merge-base', 'HEAD', $commit);
 
   return ($base ne $fetch_head);
-- 
1.9.1.353.gc66d89d

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> -  my $fetch_head = git ('rev-parse', $commit);
> +  my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
> +  if ($status) {
> +    return 0;
> +  }

Could there be other errors here, other than @{upstream} not existing?
At first glance it seems like there is potential to hide errors here.

d

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Tue, Jul 15, 2014 at 08:44:53PM -0300, David Bremner wrote:
> W. Trevor King writes:
> > -  my $fetch_head = git ('rev-parse', $commit);
> > +  my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
> > +  if ($status) {
> > +    return 0;
> > +  }
> 
> Could there be other errors here, other than @{upstream} not
> existing?  At first glance it seems like there is potential to hide
> errors here.

Possible errors that I can find:

* fatal: Not a git repository: … (with a poor GIT_DIR config)
* fatal: ambiguous argument … (with an invalid/missing revision name)
* fatal: No upstream configured for branch … (when
  branch.<name>.remote or branch.<name>.merge aren't set)

All of which return 128 as of Git v1.9.1.  We're only interested in
the last.  I'm fine looking for “No upstream configured for branch”
after we capture stderr with “nmbug: Catch stderr in is_unmerged” [1],
but I don't expect the other two error cases to happen very often.  At
least, I doubt you could get this far into do_status with a broken
GIT_DIR, and we're hard-coding '@{upstream}' here.

Cheers,
Trevor

[1]: id:d55cf02465c5f2d83f2dd0bc666831ee524b0fb7.1404678709.git.wking@tremily.us
     http://article.gmane.org/gmane.mail.notmuch.general/18627

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> If we don't have an upstream, there is nothing to merge, so nothing is
> unmerged.  This avoids errors like:

pushed this one patch.

d

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
> W. Trevor King writes:
> > If we don't have an upstream, there is nothing to merge, so
> > nothing is unmerged.  This avoids errors like:
> 
> pushed this one patch.

Without the stderr-catching of something like patch 3, this means
folks without an upstream are going to see a distracting:

  error: No upstream configured for branch 'master'

if they run 'nmbug status' without an @upstream.

I'm working through the Python translation now ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
>> W. Trevor King writes:
>> > If we don't have an upstream, there is nothing to merge, so
>> > nothing is unmerged.  This avoids errors like:
>> 
>> pushed this one patch.
>
> Without the stderr-catching of something like patch 3, this means
> folks without an upstream are going to see a distracting:
>
>   error: No upstream configured for branch 'master'
>
> if they run 'nmbug status' without an @upstream.
>
> I'm working through the Python translation now ;).

Perhaps the best thing is to revert that patch then?

d

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Thu, Jul 17, 2014 at 06:28:55AM -0300, David Bremner wrote:
> W. Trevor King writes:
> > On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
> >> W. Trevor King writes:
> >> > If we don't have an upstream, there is nothing to merge, so
> >> > nothing is unmerged.  This avoids errors like:
> >> 
> >> pushed this one patch.
> >
> > Without the stderr-catching of something like patch 3, this means
> > folks without an upstream are going to see a distracting:
> >
> >   error: No upstream configured for branch 'master'
> >
> > if they run 'nmbug status' without an @upstream.
> >
> > I'm working through the Python translation now ;).
> 
> Perhaps the best thing is to revert that patch then?

Sure.

Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> On Wed, Jul 16, 2014 at 07:36:10PM -0300, David Bremner wrote:
>> W. Trevor King writes:
>> > If we don't have an upstream, there is nothing to merge, so
>> > nothing is unmerged.  This avoids errors like:
>> 
>> pushed this one patch.
>
> Without the stderr-catching of something like patch 3, this means
> folks without an upstream are going to see a distracting:
>
>   error: No upstream configured for branch 'master'
>

On reflection, I don't think that patch made things worse for this use
case. So I don't think it really hurts to leave it there for now.

d

[PATCH 3/4] nmbug: Catch stderr in is_unmerged

[W. Trevor King]

Add a '-2|' dir for "execute the command and pipe both stdout and
stderr to us".  Use this to catch stderr from the rev-parse call in
is_unmerged.  We already check the status, so we don't want to confuse
users with stuff like:

  error: No upstream configured for branch 'master'

on nmbug's stderr.
---
 devel/nmbug/nmbug | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 998ee6b..c9ac046 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -56,7 +56,7 @@ my $EMPTYBLOB = git (qw{hash-object -t blob /dev/null});
 sub git_pipe {
   my $envref = (ref $_[0] eq 'HASH') ? shift : {};
   my $ioref  = (ref $_[0] eq 'ARRAY') ? shift : undef;
-  my $dir = ($_[0] eq '-|' or $_[0] eq '|-') ? shift : undef;
+  my $dir = ($_[0] eq '-|' or $_[0] eq '-2|' or $_[0] eq '|-') ? shift : undef;
 
   unshift @_, 'git';
   $envref->{GIT_DIR} ||= $NMBGIT;
@@ -83,10 +83,15 @@ sub git {
 sub spawn {
   my $envref = (ref $_[0] eq 'HASH') ? shift : {};
   my $ioref  = (ref $_[0] eq 'ARRAY') ? shift : undef;
-  my $dir = ($_[0] eq '-|' or $_[0] eq '|-') ? shift : '-|';
+  my $dir = ($_[0] eq '-|' or $_[0] eq '-2|' or $_[0] eq '|-') ? shift : '-|';
+  my $stderr_to_stdout = $dir eq '-2|';
 
   die unless @_;
 
+  if ($dir eq '-2|') {
+    $dir = '-|';
+  }
+
   if (open my $child, $dir) {
     return $child;
   }
@@ -105,6 +110,9 @@ sub spawn {
       if ($dir ne '|-') {
 	open STDIN, '<', '/dev/null' or die "reopening stdin: $!"
       }
+      if ($stderr_to_stdout) {
+	open(STDERR, ">&STDOUT");
+      }
       exec @_;
       die "exec @_: $!";
     }
@@ -430,7 +438,7 @@ sub do_status {
 sub is_unmerged {
   my $commit = shift || '@{upstream}';
 
-  my ($fetch_head, $status) = git_with_status ('rev-parse', $commit);
+  my ($fetch_head, $status) = git_with_status ('-2|', 'rev-parse', $commit);
   if ($status) {
     return 0;
   }
-- 
1.9.1.353.gc66d89d

Re: [PATCH 3/4] nmbug: Catch stderr in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> +  if ($dir eq '-2|') {
> +    $dir = '-|';
> +  }
> +

I think I'd prefer an extra flag, rather than making new syntax.
The existing syntax is not pretty, but it is standard perl

Re: [PATCH 3/4] nmbug: Catch stderr in is_unmerged

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Tue, Jul 15, 2014 at 08:49:58PM -0300, David Bremner wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> 
> > +  if ($dir eq '-2|') {
> > +    $dir = '-|';
> > +  }
> > +
> 
> I think I'd prefer an extra flag, rather than making new syntax.
> The existing syntax is not pretty, but it is standard perl

There should be standard Perl syntax for capturing both streams ;).  I
can add a separate parameter instead, but Perl doesn't seem to have
keyword-arguments.  At least, nmbug relies on assumptions about
argument values:

  sub git_pipe {
    my $envref = (ref $_[0] eq 'HASH') ? shift : {};
    my $ioref  = (ref $_[0] eq 'ARRAY') ? shift : undef;
    my $dir = ($_[0] eq '-|' or $_[0] eq '|-') ? shift : undef;
    …
  }

to map positional arguments back into particular semantic meanings.
That seemed ugly enough (can we only have a single boolean argument
with this pattern?) that I'd prefer piggy-backing on Perl's
stream-direction syntax.  But let me know what you like best, and I'll
go that way with v2.  I'd be happy to rewrite nmbug in Python too,
which has (to my eyes) much saner kwargs and subprocess handling.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/4] nmbug: Catch stderr in is_unmerged

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

>
> There should be standard Perl syntax for capturing both streams ;).  I
> can add a separate parameter instead, but Perl doesn't seem to have
> keyword-arguments.  At least, nmbug relies on assumptions about
> argument values:
>
>   sub git_pipe {
>     my $envref = (ref $_[0] eq 'HASH') ? shift : {};
>     my $ioref  = (ref $_[0] eq 'ARRAY') ? shift : undef;
>     my $dir = ($_[0] eq '-|' or $_[0] eq '|-') ? shift : undef;
>     …
>   }
>

Perl supports keyword arguments fine, by passing a single hash 
to the subroutine. This particular sub doesn't do things that way, but
it's only called in three places, so it would be simple enough to change
the calling convention to to

git_pipe (env => {}, lines=>[], 
         command => [  qw/diff-index --cached/,
		 "--diff-filter=$filter", qw/--name-only HEAD/ ],
         redirect => [ whatever you want here ]                 
         )


>  I'd be happy to rewrite nmbug in Python too, which has (to my eyes)
> much saner kwargs and subprocess handling.

Although I think that's an extreme answer to this particular issue ;), I
do think it's worth discussing. In particular I think it would be
reasonable to consider an updated nmbug that used the python bindings to
notmuch, for possibly more speed. Of the people that currently work on
nmbug (I count myself, yourself, and Tomi), I think we're all ok with
python.  I know at least Jani mentioned he'd be more interested in
contributing to a python version.

d

[PATCH 4/4] nmbug: Add an 'init' command

[W. Trevor King]

For folks that want to start versioning a new tag-space, instead of
cloning one that someone else has already started.

The empty-blob hash-object call avoids errors like:

  $ nmbug commit
  error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for 'tags/...'
  fatal: git-write-tree: error building trees
  'git HASH(0x9ef3eb8) write-tree' exited with nonzero value
---
 devel/nmbug/nmbug | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index c9ac046..b64dab9 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -30,6 +30,7 @@ my %command = (
 	     commit	=> \&do_commit,
 	     fetch	=> \&do_fetch,
 	     help	=> \&do_help,
+	     init	=> \&do_init,
 	     log	=> \&do_log,
 	     merge	=> \&do_merge,
 	     pull	=> \&do_pull,
@@ -152,6 +153,18 @@ sub do_clone {
   git ('config', 'core.bare', 'true');
 }
 
+sub do_init {
+  my $tempwork = tempdir ('/tmp/nmbug-init.XXXXXX', CLEANUP => 1);
+  system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) == 0
+    or die "'git init' exited with nonzero value\n";
+  git ('config', '--unset', 'core.worktree');
+  git ('config', 'core.bare', 'true');
+  # create an empty blob (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
+  git ('hash-object', '-w', '--stdin');
+  git ( { GIT_WORK_TREE => $tempwork }, 'commit', '--allow-empty',
+        '-m', 'Start a new nmbug repository' );
+}
+
 sub is_committed {
   my $status = shift;
   return scalar (@{$status->{added}} ) + scalar (@{$status->{deleted}} ) == 0;
@@ -610,6 +623,12 @@ Create a local nmbug repository from a remote source.  This wraps
 C<git clone>, adding some options to avoid creating a working tree
 while preserving remote-tracking branches and upstreams.
 
+=item B<init>
+
+Create a local nmbug repository from scratch.  This wraps C<git init>
+and performs other setup to support subsequent status and commit
+commands.
+
 =item B<checkout>
 
 Update the notmuch database from git. This is mainly useful to discard
-- 
1.9.1.353.gc66d89d

Re: [PATCH 4/4] nmbug: Add an 'init' command

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

> +sub do_init {
> +  my $tempwork = tempdir ('/tmp/nmbug-init.XXXXXX', CLEANUP => 1);
> +  system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) == 0
> +    or die "'git init' exited with nonzero value\n";
> +  git ('config', '--unset', 'core.worktree');
> +  git ('config', 'core.bare', 'true');
> +  # create an empty blob (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
> +  git ('hash-object', '-w', '--stdin');
> +  git ( { GIT_WORK_TREE => $tempwork }, 'commit', '--allow-empty',
> +        '-m', 'Start a new nmbug repository' );
> +}
> +


Shouldn't this empty blob already be created by the following line:

my $EMPTYBLOB = git (qw{hash-object -t blob /dev/null});

Or is the key point to write it into the database?  Anyway I like my
hack slightly better than yours ;).

d


 

Re: [PATCH 4/4] nmbug: Add an 'init' command

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Tue, Jul 15, 2014 at 08:54:28PM -0300, David Bremner wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> 
> > +sub do_init {
> > +  my $tempwork = tempdir ('/tmp/nmbug-init.XXXXXX', CLEANUP => 1);
> > +  system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) == 0
> > +    or die "'git init' exited with nonzero value\n";
> > +  git ('config', '--unset', 'core.worktree');
> > +  git ('config', 'core.bare', 'true');
> > +  # create an empty blob (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
> > +  git ('hash-object', '-w', '--stdin');
> > +  git ( { GIT_WORK_TREE => $tempwork }, 'commit', '--allow-empty',
> > +        '-m', 'Start a new nmbug repository' );
> > +}
> > +
> 
> 
> Shouldn't this empty blob already be created by the following line:
> 
> my $EMPTYBLOB = git (qw{hash-object -t blob /dev/null});
> 
> Or is the key point to write it into the database?  Anyway I like my
> hack slightly better than yours ;).

We need to write it to the database.  I'll use /dev/null in v2,
though.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] nmbug: Add an 'init' command

[David Edmondson]

On Sun, Jul 06 2014, W. Trevor King wrote:
> For folks that want to start versioning a new tag-space, instead of
> cloning one that someone else has already started.

I tried this patch, and it (appeared) to work for me. Given that the
procedure for creating a new tag repository is arcane, could this patch
(or a version of it) be pushed?

> The empty-blob hash-object call avoids errors like:
>
>   $ nmbug commit
>   error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for 'tags/...'
>   fatal: git-write-tree: error building trees
>   'git HASH(0x9ef3eb8) write-tree' exited with nonzero value
> ---
>  devel/nmbug/nmbug | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
> index c9ac046..b64dab9 100755
> --- a/devel/nmbug/nmbug
> +++ b/devel/nmbug/nmbug
> @@ -30,6 +30,7 @@ my %command = (
>  	     commit	=> \&do_commit,
>  	     fetch	=> \&do_fetch,
>  	     help	=> \&do_help,
> +	     init	=> \&do_init,
>  	     log	=> \&do_log,
>  	     merge	=> \&do_merge,
>  	     pull	=> \&do_pull,
> @@ -152,6 +153,18 @@ sub do_clone {
>    git ('config', 'core.bare', 'true');
>  }
>  
> +sub do_init {
> +  my $tempwork = tempdir ('/tmp/nmbug-init.XXXXXX', CLEANUP => 1);
> +  system ('git', 'init', '--separate-git-dir', $NMBGIT, $tempwork) == 0
> +    or die "'git init' exited with nonzero value\n";
> +  git ('config', '--unset', 'core.worktree');
> +  git ('config', 'core.bare', 'true');
> +  # create an empty blob (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
> +  git ('hash-object', '-w', '--stdin');
> +  git ( { GIT_WORK_TREE => $tempwork }, 'commit', '--allow-empty',
> +        '-m', 'Start a new nmbug repository' );
> +}
> +
>  sub is_committed {
>    my $status = shift;
>    return scalar (@{$status->{added}} ) + scalar (@{$status->{deleted}} ) == 0;
> @@ -610,6 +623,12 @@ Create a local nmbug repository from a remote source.  This wraps
>  C<git clone>, adding some options to avoid creating a working tree
>  while preserving remote-tracking branches and upstreams.
>  
> +=item B<init>
> +
> +Create a local nmbug repository from scratch.  This wraps C<git init>
> +and performs other setup to support subsequent status and commit
> +commands.
> +
>  =item B<checkout>
>  
>  Update the notmuch database from git. This is mainly useful to discard
> -- 
> 1.9.1.353.gc66d89d

Re: [PATCH 4/4] nmbug: Add an 'init' command

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
> On Sun, Jul 06 2014, W. Trevor King wrote:
> > For folks that want to start versioning a new tag-space, instead
> > of cloning one that someone else has already started.
> 
> I tried this patch, and it (appeared) to work for me. Given that the
> procedure for creating a new tag repository is arcane, could this
> patch (or a version of it) be pushed?

Rewriting this patch is the first thing on my list after nmbug's
Python translation lands [1].  Interestingly, there have been versions
of 'nmbug init' kicking around in the wings for some time [2].

Cheers,
Trevor

[1]: id:e630b6763e9d0771718afee41ea15b29bb4a1de8.1409935538.git.wking%40tremily.us
     http://thread.gmane.org/gmane.mail.notmuch.general/19007
[2]: id:87obf66k7x.fsf@zancas.localnet
     http://thread.gmane.org/gmane.mail.notmuch.general/14474/focus=14493

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] nmbug: Add an 'init' command

[David Edmondson]

On Mon, Sep 15 2014, W. Trevor King wrote:
> On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
>> On Sun, Jul 06 2014, W. Trevor King wrote:
>> > For folks that want to start versioning a new tag-space, instead
>> > of cloning one that someone else has already started.
>> 
>> I tried this patch, and it (appeared) to work for me. Given that the
>> procedure for creating a new tag repository is arcane, could this
>> patch (or a version of it) be pushed?
>
> Rewriting this patch is the first thing on my list after nmbug's
> Python translation lands [1].

What is required to make that happen?

Re: [PATCH 4/4] nmbug: Add an 'init' command

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Mon, Sep 15, 2014 at 05:32:59PM +0100, David Edmondson wrote:
> On Mon, Sep 15 2014, W. Trevor King wrote:
> > On Mon, Sep 15, 2014 at 05:13:50PM +0100, David Edmondson wrote:
> >> On Sun, Jul 06 2014, W. Trevor King wrote:
> >> > For folks that want to start versioning a new tag-space, instead
> >> > of cloning one that someone else has already started.
> >> 
> >> I tried this patch, and it (appeared) to work for me. Given that the
> >> procedure for creating a new tag repository is arcane, could this
> >> patch (or a version of it) be pushed?
> >
> > Rewriting this patch is the first thing on my list after nmbug's
> > Python translation lands [1].
> 
> What is required to make that happen?

Give it a spin to kick the tires, and reply to the v4 patch saying
that none of the pieces fell off while you were kicking it ;).
Basically, it's just waiting for review and a consensus that it's a
solid change.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 4/4] nmbug: Add an 'init' command

[David Bremner]

"W. Trevor King" <wking@tremily.us> writes:

>
> Give it a spin to kick the tires, and reply to the v4 patch saying
> that none of the pieces fell off while you were kicking it ;).
> Basically, it's just waiting for review and a consensus that it's a
> solid change.

v3 crashed when merging quite often for me. I'm sortof waiting to see if
it happens again with v4, at which point I guess I'll send my repo by
carrier pigeon to Trevor.

Unfortunately there hasn't been enough nmbug activity to trigger the
bug, so get reviewing patches everyone ;).

d

Re: [PATCH 4/4] nmbug: Add an 'init' command

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Mon, Sep 15, 2014 at 08:09:11PM +0200, David Bremner wrote:
> W. Trevor King writes:
> > Give it a spin to kick the tires, and reply to the v4 patch saying
> > that none of the pieces fell off while you were kicking it ;).
> > Basically, it's just waiting for review and a consensus that it's
> > a solid change.
> 
> v3 crashed when merging quite often for me.

I didn't actually change anything there, because I was unable to
reproduce the crash (as I point out in my v4 message, “I've also left
off the merge/pull checkouts, since I haven't been able to reproduce
David's error locally…” [1]).  Any advice on reproducing the merge
errors would be helpful :).

Cheers,
Trevor

[1]: id:e630b6763e9d0771718afee41ea15b29bb4a1de8.1409935538.git.wking@tremily.us
     http://article.gmane.org/gmane.mail.notmuch.general/19007

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH] potential fix for nmbug merge problems

[David Bremner]

---
 scripts/nmbug | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

This seems to fix the problems with merges failing on dirty indexes.
I didn't have time to trace through all of the ramifications, but it
seems to me by doing a merge with the default index, we are getting
some kind of random state (or maybe the state of the last merge).

I'll have to road test this a bit more to be sure it's a fix, but maybe you can think about whether it's the righ thing (TM) to do in any case.

diff --git a/scripts/nmbug b/scripts/nmbug
index 77bec64..47e4ee8 100755
--- a/scripts/nmbug
+++ b/scripts/nmbug
@@ -457,10 +457,13 @@ def merge(reference='@{upstream}'):
     The default reference is '@{upstream}'.
     """
     _insist_committed()
+    path = _os.path.join(NMBGIT, 'nmbug.index')
+
     with _tempfile.TemporaryDirectory(prefix='nmbug-merge.') as workdir:
         _git(
             args=['merge', reference],
-            additional_env={'GIT_WORK_TREE': workdir},
+            additional_env={'GIT_WORK_TREE': workdir,
+                            'GIT_INDEX_FILE': path},
             wait=True)
     checkout()
 
-- 
2.1.0