Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes

Subject: Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes

Date: Wed, 09 Apr 2014 22:01:25 -0300

To: W. Trevor King

Cc: notmuch

From: David Bremner


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

> We need non-bare repositories to have remote-tracking branches
> (distinct from local branches) [3], and we need remote-tracking
> branches to have working @{upstream}.

OK, I see what you mean, the repository has "bare = false". On the other
hand we immediately blow away the work tree, and after the initial clone
it seems to work fine to set bare = true. It might even make sense to
apply


diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index d6f5213..b18ded7 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -134,6 +134,7 @@ sub do_clone {
           $repository, $tempwork) == 0
     or die "'git clone' exited with nonzero value\n";
   git ('config', '--unset', 'core.worktree');
+  git ('config', 'core.bare', 'true');
 }


> I think that's reasonable support for my claim (and most of it is in
> the original c200167 commit message), but maybe not?

In any case, I think I think it's mainly a technicality, and that we
want to keep the level of detail in the release notes down a bit.  If
you don't like the above mini-patch, then maybe a NOTES section in the
nmbug docs.

>> Is the "remote repository" in step 1 meant to be the central repo? or
>> just a backup?
>
> The backup.  If you have nothing to backup, you already got everything
> back after cloning the central repo.

It might be less confusing to explicitly use the word "backup" in step 1 then.

Thread: