[PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
"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, 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.
[PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
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>
[PATCH] News for emacs saved-searches change.
--- The important point is that the changed search variable is not forward compatible (it *is* backwards compatible): that is previous version of notmuch-emacs will be unusable with a new style notmuch-saved-search variable. Best wishes Mark NEWS | 17 + 1 file changed, 17 insertions(+) diff --git a/NEWS b/NEWS index d4f4ea4..8aa4182 100644 --- a/NEWS +++ b/NEWS @@ -15,6 +15,23 @@ Command-Line Interface Emacs Interface --- +Changed format for saved searches. + + The format for `notmuch-saved-searches` has changed, but old style + saved searches are still supported. The new style means that a saved + search can store the desired sort order for the search, and it can + store a separate query to use for generating the count notmuch + shows. + + The variable is fully customizable and any configuration done + through customize should `just work', with the additional options + mentioned above. For manual customization see the documentation for + `notmuch-saved-searches`. + + IMPORTANT: a new style notmuch-saved-searches variable will break + previous versions of notmuch-emacs (even search will not work); to + fix remove the customization for notmuch-saved-searches. + Bug fix for saved searches with newlines in them. Split lines confuse `notmuch count --batch`, so we remove embedded -- 1.7.10.4
[PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
On Wed, Apr 09, 2014 at 08:22:26AM -0300, David Bremner wrote:
> W. Trevor King writes:
>
> > The changes just landed with c200167 (nmbug: Add 'clone' and replace
> > FETCH_HEAD with @{upstream}, 2014-03-09).
> >
> > The preferred markup language for NEWS seems to be Markdown, which is
> > parsed by devel/news2wiki.pl into Markdown chunks for rendering by
> > ikiwiki [1].
> >
> > [1]: http://notmuchmail.org/news/
> > ---
> > NEWS | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/NEWS b/NEWS
> > index d4f4ea4..e26fa0a 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -20,6 +20,26 @@ Bug fix for saved searches with newlines in them.
> >Split lines confuse `notmuch count --batch`, so we remove embedded
> >newlines before calling notmuch count.
> >
> > +nmbug
> > +-
> > +
> > +nmbug adds a `clone` command for setting up the initial repository and
> > +uses `@{upstream}` instead of `FETCH_HEAD` to track upstream changes.
> > +
> > + The `@{upstream}` change reduces ambiguity when fetching multiple
> > + branches, but requires existing users update their bare `NMBGIT`
> > + repository (usually `~/.nmbug`) to a non-bare repository. The
> > + easiest way to do this is:
>
> That bit about non-bare seems to be untrue/misleading?
The old repositories were bare [1]:
git clone --bare http://nmbug.tethera.net/git/nmbug-tags.git $HOME/.nmbug
the new repositories are not [2]:
system ('git', 'clone', '--no-checkout', '--separate-git-dir', $NMBGIT,
$repository, $tempwork) == 0
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}.
I think that's reasonable support for my claim (and most of it is in
the original c200167 commit message), but maybe not?
> As a step 0, I guess commit any tag changes to nmbug?
> > +
> > + 1. Push any local commits to a remote repository.
> > + 2. Remove your `NMBGIT` repository (e.g. `mv .nmbug .nmbug.bak`).
> > + 3. Use the new `clone` command to create a fresh clone:
> > +
> > +nmbug clone nmbug at nmbug.tethera.net:nmbug-tags
> > +
>
> Jani mentioned on IRC that some people might track nmbug in a read only
> way via git://
Sure. The current docs suggest HTTP [1], so I'm fine changing this to
the HTTP URL (or the Git URL). I think folks will get the idea
regardless. I can resubmit v2 with this update, or you can just
squash it in if/when this patch lands in master, whatever is easiest.
> > + 4. If you had local commits in step 1, add a remote for that
> > + repository and fetch them into the new repository.
>
> 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.
Cheers,
Trevor
[1]: http://notmuchmail.org/nmbug/
[2]:
http://git.notmuchmail.org/git/notmuch/blob/c20016742681e1ed48c83de32639e10507ffa14d:/devel/nmbug/nmbug#l133
[3]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/git-clone.txt
--bare::
Make a 'bare' Git repository?
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`. When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.
--
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/4a292b62/attachment.pgp>
[PATCH 2/2] configure: fix comment, pass HAVE_CANONICALIZE_FILE_NAME to build
Apparently omitting it is not fatal, but let's be consistent with the
other compat functions.
---
configure | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 09f4650..256c918 100755
--- a/configure
+++ b/configure
@@ -812,7 +812,7 @@ bash_completion_dir =
${BASHCOMPLETIONDIR:=\$(sysconfdir)/bash_completion.d}
# The directory to which zsh completions files should be installed
zsh_completion_dir =
${ZSHCOMLETIONDIR:=\$(prefix)/share/zsh/functions/Completion/Unix}
-# Whether the getline function is available (if not, then notmuch will
+# Whether the canonicalize_file_name function is available (if not, then
notmuch will
# build its own version)
HAVE_CANONICALIZE_FILE_NAME = ${have_canonicalize_file_name}
@@ -887,6 +887,7 @@ WITH_ZSH = ${WITH_ZSH}
# Combined flags for compiling and linking against all of the above
CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS) \\
+
-DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
\$(VALGRIND_CFLAGS) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR) \\
@@ -898,6 +899,7 @@ CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE)
\$(GMIME_CFLAGS) \\
-DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER)
CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
+
-DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR) \\
--
1.9.0
[PATCH 1/2] build: add canonicalize_file_name to symbols exported from libnotmuch.so
This is needed for our compat version of canonicalize_file_name to be used.
---
lib/gen-version-script.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/gen-version-script.sh b/lib/gen-version-script.sh
index 76670d5..64a7374 100644
--- a/lib/gen-version-script.sh
+++ b/lib/gen-version-script.sh
@@ -23,6 +23,6 @@ while read sym; do
;;
esac
done
-nm $* | awk '$1 ~ "^[0-9a-fA-F][0-9a-fA-F]*$" && $2 == "T" && $3 ~
"^get(line|delim)$" {print $3 ";"}'
+nm $* | awk '$1 ~ "^[0-9a-fA-F][0-9a-fA-F]*$" && $2 == "T" && $3 ~
"^(getline|getdelim|canonicalize_file_name)$" {print $3 ";"}'
sed -n 's/^[[:space:]]*\(notmuch_[a-z_]*\)[[:space:]]*(.*/ \1;/p' $HEADER
printf "local: *;\n};\n"
--
1.9.0
[PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
"W. Trevor King" writes:
> The changes just landed with c200167 (nmbug: Add 'clone' and replace
> FETCH_HEAD with @{upstream}, 2014-03-09).
>
> The preferred markup language for NEWS seems to be Markdown, which is
> parsed by devel/news2wiki.pl into Markdown chunks for rendering by
> ikiwiki [1].
>
> [1]: http://notmuchmail.org/news/
> ---
> NEWS | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/NEWS b/NEWS
> index d4f4ea4..e26fa0a 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -20,6 +20,26 @@ Bug fix for saved searches with newlines in them.
>Split lines confuse `notmuch count --batch`, so we remove embedded
>newlines before calling notmuch count.
>
> +nmbug
> +-
> +
> +nmbug adds a `clone` command for setting up the initial repository and
> +uses `@{upstream}` instead of `FETCH_HEAD` to track upstream changes.
> +
> + The `@{upstream}` change reduces ambiguity when fetching multiple
> + branches, but requires existing users update their bare `NMBGIT`
> + repository (usually `~/.nmbug`) to a non-bare repository. The
> + easiest way to do this is:
That bit about non-bare seems to be untrue/misleading?
As a step 0, I guess commit any tag changes to nmbug?
> +
> + 1. Push any local commits to a remote repository.
> + 2. Remove your `NMBGIT` repository (e.g. `mv .nmbug .nmbug.bak`).
> + 3. Use the new `clone` command to create a fresh clone:
> +
> +nmbug clone nmbug at nmbug.tethera.net:nmbug-tags
> +
Jani mentioned on IRC that some people might track nmbug in a read only
way via git://
> + 4. If you had local commits in step 1, add a remote for that
> + repository and fetch them into the new repository.
Is the "remote repository" in step 1 meant to be the central repo? or
just a backup?
Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
W. Trevor King wk...@tremily.us writes:
The changes just landed with c200167 (nmbug: Add 'clone' and replace
FETCH_HEAD with @{upstream}, 2014-03-09).
The preferred markup language for NEWS seems to be Markdown, which is
parsed by devel/news2wiki.pl into Markdown chunks for rendering by
ikiwiki [1].
[1]: http://notmuchmail.org/news/
---
NEWS | 20
1 file changed, 20 insertions(+)
diff --git a/NEWS b/NEWS
index d4f4ea4..e26fa0a 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,26 @@ Bug fix for saved searches with newlines in them.
Split lines confuse `notmuch count --batch`, so we remove embedded
newlines before calling notmuch count.
+nmbug
+-
+
+nmbug adds a `clone` command for setting up the initial repository and
+uses `@{upstream}` instead of `FETCH_HEAD` to track upstream changes.
+
+ The `@{upstream}` change reduces ambiguity when fetching multiple
+ branches, but requires existing users update their bare `NMBGIT`
+ repository (usually `~/.nmbug`) to a non-bare repository. The
+ easiest way to do this is:
That bit about non-bare seems to be untrue/misleading?
As a step 0, I guess commit any tag changes to nmbug?
+
+ 1. Push any local commits to a remote repository.
+ 2. Remove your `NMBGIT` repository (e.g. `mv .nmbug .nmbug.bak`).
+ 3. Use the new `clone` command to create a fresh clone:
+
+nmbug clone nm...@nmbug.tethera.net:nmbug-tags
+
Jani mentioned on IRC that some people might track nmbug in a read only
way via git://
+ 4. If you had local commits in step 1, add a remote for that
+ repository and fetch them into the new repository.
Is the remote repository in step 1 meant to be the central repo? or
just a backup?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] build: add canonicalize_file_name to symbols exported from libnotmuch.so
This is needed for our compat version of canonicalize_file_name to be used.
---
lib/gen-version-script.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/gen-version-script.sh b/lib/gen-version-script.sh
index 76670d5..64a7374 100644
--- a/lib/gen-version-script.sh
+++ b/lib/gen-version-script.sh
@@ -23,6 +23,6 @@ while read sym; do
;;
esac
done
-nm $* | awk '$1 ~ ^[0-9a-fA-F][0-9a-fA-F]*$ $2 == T $3 ~
^get(line|delim)$ {print $3 ;}'
+nm $* | awk '$1 ~ ^[0-9a-fA-F][0-9a-fA-F]*$ $2 == T $3 ~
^(getline|getdelim|canonicalize_file_name)$ {print $3 ;}'
sed -n 's/^[[:space:]]*\(notmuch_[a-z_]*\)[[:space:]]*(.*/ \1;/p' $HEADER
printf local: *;\n};\n
--
1.9.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] configure: fix comment, pass HAVE_CANONICALIZE_FILE_NAME to build
Apparently omitting it is not fatal, but let's be consistent with the
other compat functions.
---
configure | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 09f4650..256c918 100755
--- a/configure
+++ b/configure
@@ -812,7 +812,7 @@ bash_completion_dir =
${BASHCOMPLETIONDIR:=\$(sysconfdir)/bash_completion.d}
# The directory to which zsh completions files should be installed
zsh_completion_dir =
${ZSHCOMLETIONDIR:=\$(prefix)/share/zsh/functions/Completion/Unix}
-# Whether the getline function is available (if not, then notmuch will
+# Whether the canonicalize_file_name function is available (if not, then
notmuch will
# build its own version)
HAVE_CANONICALIZE_FILE_NAME = ${have_canonicalize_file_name}
@@ -887,6 +887,7 @@ WITH_ZSH = ${WITH_ZSH}
# Combined flags for compiling and linking against all of the above
CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS) \\
+
-DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
\$(VALGRIND_CFLAGS) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR) \\
@@ -898,6 +899,7 @@ CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE)
\$(GMIME_CFLAGS) \\
-DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER)
CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
+
-DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR) \\
--
1.9.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] News for emacs saved-searches change.
--- The important point is that the changed search variable is not forward compatible (it *is* backwards compatible): that is previous version of notmuch-emacs will be unusable with a new style notmuch-saved-search variable. Best wishes Mark NEWS | 17 + 1 file changed, 17 insertions(+) diff --git a/NEWS b/NEWS index d4f4ea4..8aa4182 100644 --- a/NEWS +++ b/NEWS @@ -15,6 +15,23 @@ Command-Line Interface Emacs Interface --- +Changed format for saved searches. + + The format for `notmuch-saved-searches` has changed, but old style + saved searches are still supported. The new style means that a saved + search can store the desired sort order for the search, and it can + store a separate query to use for generating the count notmuch + shows. + + The variable is fully customizable and any configuration done + through customize should `just work', with the additional options + mentioned above. For manual customization see the documentation for + `notmuch-saved-searches`. + + IMPORTANT: a new style notmuch-saved-searches variable will break + previous versions of notmuch-emacs (even search will not work); to + fix remove the customization for notmuch-saved-searches. + Bug fix for saved searches with newlines in them. Split lines confuse `notmuch count --batch`, so we remove embedded -- 1.7.10.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
On Wed, Apr 09, 2014 at 08:22:26AM -0300, David Bremner wrote:
W. Trevor King writes:
The changes just landed with c200167 (nmbug: Add 'clone' and replace
FETCH_HEAD with @{upstream}, 2014-03-09).
The preferred markup language for NEWS seems to be Markdown, which is
parsed by devel/news2wiki.pl into Markdown chunks for rendering by
ikiwiki [1].
[1]: http://notmuchmail.org/news/
---
NEWS | 20
1 file changed, 20 insertions(+)
diff --git a/NEWS b/NEWS
index d4f4ea4..e26fa0a 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,26 @@ Bug fix for saved searches with newlines in them.
Split lines confuse `notmuch count --batch`, so we remove embedded
newlines before calling notmuch count.
+nmbug
+-
+
+nmbug adds a `clone` command for setting up the initial repository and
+uses `@{upstream}` instead of `FETCH_HEAD` to track upstream changes.
+
+ The `@{upstream}` change reduces ambiguity when fetching multiple
+ branches, but requires existing users update their bare `NMBGIT`
+ repository (usually `~/.nmbug`) to a non-bare repository. The
+ easiest way to do this is:
That bit about non-bare seems to be untrue/misleading?
The old repositories were bare [1]:
git clone --bare http://nmbug.tethera.net/git/nmbug-tags.git $HOME/.nmbug
the new repositories are not [2]:
system ('git', 'clone', '--no-checkout', '--separate-git-dir', $NMBGIT,
$repository, $tempwork) == 0
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}.
I think that's reasonable support for my claim (and most of it is in
the original c200167 commit message), but maybe not?
As a step 0, I guess commit any tag changes to nmbug?
+
+ 1. Push any local commits to a remote repository.
+ 2. Remove your `NMBGIT` repository (e.g. `mv .nmbug .nmbug.bak`).
+ 3. Use the new `clone` command to create a fresh clone:
+
+nmbug clone nm...@nmbug.tethera.net:nmbug-tags
+
Jani mentioned on IRC that some people might track nmbug in a read only
way via git://
Sure. The current docs suggest HTTP [1], so I'm fine changing this to
the HTTP URL (or the Git URL). I think folks will get the idea
regardless. I can resubmit v2 with this update, or you can just
squash it in if/when this patch lands in master, whatever is easiest.
+ 4. If you had local commits in step 1, add a remote for that
+ repository and fetch them into the new repository.
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.
Cheers,
Trevor
[1]: http://notmuchmail.org/nmbug/
[2]:
http://git.notmuchmail.org/git/notmuch/blob/c20016742681e1ed48c83de32639e10507ffa14d:/devel/nmbug/nmbug#l133
[3]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/git-clone.txt
--bare::
Make a 'bare' Git repository…
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`. When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.
--
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
signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
W. Trevor King wk...@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: Document the recent 'nmbug clone' and @{upstream} changes
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
signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
