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

[W. Trevor King]

On Wed, Apr 09, 2014 at 10:01:25PM -0300, David Bremner wrote:
> W. Trevor King 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,

But whenever we do anything that might involve a working directory
(just merging), we create a temporary one and set GIT_WORK_TREE.  So
the ~/.nmbug repo is a plain-vanilla, non-bare repo with an ephemeral
working directory.

> > 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.

Sure.  I think my previous email was my shot at explaining the
situation ;).  If it wasn't clear, maybe someone else could take a
stab at a NOTES blurb.

> >> 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.

How about:

  1. If you have any purely local commits (i.e. they aren't in the
     nmbug repository on nmbug.tethera.net), push them to a remote
     repository.  We'll restore them from the backup in step 4.

?

We can also use the suggested ~/.nmbug.bak from step 2 as the backup
repository in step 4.  I chose the current broad-sketch approach for
steps 1 and 4, because I assumed folks with local commits would be
comfortable pushing Git branches around, and didn't want to imply that
I'd covered all the corner cases (e.g. folks with my-funky-tags
branches or other wonky repos).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140409/62e85404/attachment.pgp>