* [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Nicolas Sebrecht @ 2009-11-11 21:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Baz, Peter Krefting, Git Mailing List,
Johannes Schindelin, Björn Steinbrink, Nicolas Sebrecht
In-Reply-To: <7vskckn5b4.fsf@alter.siamese.dyndns.org>
The 11/11/09, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > ++
> > +Because the sides in a rebase are swapped, using this strategy with
> > +git-rebase is never a good idea.
>
> Looking very good.
If this strategy is _never_ a good idea in this case, I tend to think
that git should forbid this option, or at least, warn and refer to the
documentation.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Petr Baudis @ 2009-11-11 21:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0911111617440.16711@xanadu.home>
On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:
> On Wed, 11 Nov 2009, Petr Baudis wrote:
>
> > On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:
> > > According to strace, data from sideband channel #2 (prefixed with
> > > "remote: ") pertaining to object compression is printed way after pack
> > > data has already started to arrive locally. This is really weird.
> > >
> > > And this occurs only when fetching from repo.or.cz and not from
> > > git.kernel.org for example. So there is something to investigate on the
> > > server side. Pasky: anything you changed in your git installation
> > > lately?
> >
> > Yes, but nothing should have changed in git-daemon, that's the only part
> > of the infrastructure that uses system-wide git (which it perhaps
> > shouldn't). I cannot reproduce this problem, though. I have changed
> > git-daemon to use my local git version (about one week old master), does
> > this still happen for you?
>
> No, it doesn't happen anymore.
>
> What was the git-daemon version before?
1.5.6.5, the default version in debian lenny
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-11 21:55 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <20091111203413.GA9648@dcvr.yhbt.net>
Eric,
> Also, any chance you have multiple refs with "trunk" in the basename?
>
> git rev-parse --symbolic --all | grep '/trunk'
This reports:
$ git rev-parse --symbolic --all | grep '/trunk'
refs/remotes/svn/trunk
> It could be a backwards compatibility issue with git svn looking
> in multiple places for trunk.
But I have multiple trunk:
$ ls .git/svn/svn/trunk/
./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
$ ls .git/svn/refs/remotes/svn/trunk/
./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
Removing all the .rev_map* fix the problem.
Removing only the one in .git/svn/refs/remotes/svn/trunk/ fix the
problem too.
> With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first
> Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
Does this means that it was looking first in $GIT_DIR/svn/trunk/*
before? And the confusion come because now it is looking in
$GIT_DIR/svn/refs/remotes/trunk/* first?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Nicolas Sebrecht @ 2009-11-11 21:57 UTC (permalink / raw)
To: rhlee; +Cc: git, Nicolas Sebrecht
In-Reply-To: <1257959806206-3987667.post@n2.nabble.com>
The 11/11/09, rhlee wrote:
>
> I use branches for features. I have a branch and I merged it into my master
> branch as I thought it was finished. But it turns out I wasn't and so I need
> to work on it again.
>
> I have made some more changes (branches and merges) on master. So what I
> should do is checkout that branch, work on it committing along the way and
> then merge it again onto my master branch.
>
> However I though I am working on a feature branch I want to be also working
> from the master branch as reference.
If the feature branch is merged to the mainline, it should really mean
that the feature is ready : the feature branch life stop here. This also
means that if you see that this feature was not as ready as you thought,
you have to restart a _new_ feature branch off of the mainline.
That's why there is the "next" branch in the git releases process. This
way, we can test the feature branches without touching master for some
time.
> Yes I know I probably should not be
> working like this. My branches should be wholly independent. But I doing web
> development not kernel development so there is much less modularity and
> branches/features have a tendency to creep into one another.
This should not be the case. Modularity in the release process and the
development strategy is not tied to "what I am developing". I'm doing
some web development too and have no difficulty around this point.
> Or should I just create a new branch? But if I do this there is no link
> between the old and new branch.
Yes, feature branches have no reason to live after they are merged to
the mainline.
--
Nicolas Sebrecht
^ permalink raw reply
* ks/precompute-completion
From: Jonathan Nieder @ 2009-11-11 22:08 UTC (permalink / raw)
To: Kirill Smelkov
Cc: Sverre Rabbelier, Junio C Hamano, Stephen Boyd, Shawn O. Pearce,
git
In-Reply-To: <fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com>
Hi,
>> * ks/precompute-completion (2009-10-26) 3 commits.
>> (merged to 'next' on 2009-10-28 at cd5177f)
>> + completion: ignore custom merge strategies when pre-generating
>> (merged to 'next' on 2009-10-22 at f46a28a)
>> + bug: precomputed completion includes scripts sources
>> (merged to 'next' on 2009-10-14 at adf722a)
>> + Speedup bash completion loading
>>
>> What's the status of this thing? Last time I polled the list I had an
>> impression that it was not quite ready...
As a distro user, I don’t think I would be able to use it until there
is a command to update the installed completion, to call after adding
a new git command to my $PATH. This could mean:
- git-completion.bash.generate learns to read the .in file and
write the completion script to arbitrary paths (or just always
uses stdin and stdout?)
- distros install git-completion.bash.{generate,in} to /usr/share/git-core
- distros install a simple completion script to /etc/bash_completion.d
that passes the buck, e.g.
-- %< --
# bash completion support for core Git.
#
# Run update-git-completion to generate these files.
#
__git_user_completion=~/.cache/git-core/git-completion.bash
__git_system_completion=/var/cache/git-core/git-completion.bash
if test -r "$__git_user_completion"
then
. "$__git_user_completion"
elif test -r "$__git_system_completion"
then
. "$__git_system_completion"
fi
-- >% --
- new update-git-completion script, something like this:
-- %< --
#!/bin/sh
USAGE="update-git-completion {--system | --user | <filename>}"
datadir=/usr/share/git-core
die() {
echo >&2 "$*"
exit 1
}
if ! test $# -eq 1
then
die "usage: $USAGE"
fi
if test "$1" = "--system"
then
output=/var/cache/git-core/git-completion.bash
elif test "$1" = "--user"
then
output=$HOME/.cache/git-core/git-completion.bash
else
output=$1
fi
rm -f "$output+" || die "cannot remove $output+"
sh "$datadir"/git-completion.bash.generate \
< "$datadir"/git-completion.bash.in \
> "$output+" || die "failed to generate completion script"
bash -n "$output+" || {
rm -f "$output+"
die "generated script fails syntax check"
}
mv -f "$output+" "$output" || {
rm -f "$output+"
die "failed to install completion script"
}
-- >% --
Thoughts?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Todd Zullinger @ 2009-11-11 21:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3ljicsrg0.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The RPM binary packages for a few architectures are found in:
>>
>> RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
>
> I tried to install git from source RPM... and failed:
>
> $ rpmbuild --rebuild git-1.6.5.2-1.fc11.src.rpm
> Installing git-1.6.5.2-1.fc11.src.rpm
> warning: user junio does not exist - using root
> warning: group junio does not exist - using root
> error: unpacking of archive failed on file
> /home/local/builddir/SOURCES/git-1.6.5.2.tar.gz;
> 4afb1f6a: cpio: MD5 sum mismatch
> error: git-1.6.5.2-1.fc11.src.rpm cannot be installed
>
> Error messages are line wrapped for better readibility.
>
> Redownloading the file didn't help
>
> $ ls -l git-1.6.5.2-1.fc11.src.rpm
> -rw-r--r-- 1 jnareb users 2713416 Oct 26 03:59 git-1.6.5.2-1.fc11.src.rpm
> $ md5sum git-1.6.5.2-1.fc11.src.rpm
> 9f89a01b65e1b8e8934c3a2252064632 git-1.6.5.2-1.fc11.src.rpm
It looks like the kernel.org builders are now using Fedora 11 to
create the packages. Unfortunately, there were backward-incompatible
changes in rpm. Stronger hashes are now used and older rpm versions
do not understand these, leading to the error you got.
I don't know what the process is for creating the rpm's, but if it's
under Junio's control, a fix to create packages which can be read by
older rpm versions would be to add:
--define "_source_filedigest_algorithm md5" \
--define "_binary_filedigest_algorithm md5"
to the rpmbuild invocation.
Perhaps like this (I didn't test this, though the defines are what we
use in Fedora to create packages on Fedora >= 11 for building on
CentOS and older releases):
-- >8 --
From: Todd Zullinger <tmz@pobox.com>
Subject: [PATCH] Makefile: Ensure rpm packages can be read by older rpm versions
The kernel.org hosts where the packages are built are now using Fedora
11, which defaults to sha256 for file digests instead of md5. Older
versions of rpm can not handle these packages. Tell rpmbuild to use md5
file digests for better compatibility.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..35f5294 100644
--- a/Makefile
+++ b/Makefile
@@ -1806,7 +1806,10 @@ dist: git.spec git-archive$(X) configure
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
- $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
+ $(RPMBUILD) \
+ --define "_source_filedigest_algorithm md5" \
+ --define "_binary_filedigest_algorithm md5" \
+ -ta $(GIT_TARNAME).tar.gz
htmldocs = git-htmldocs-$(GIT_VERSION)
manpages = git-manpages-$(GIT_VERSION)
--
1.6.5.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Does it follow that I reject all authority? Perish the thought. In the
matter of boots, I defer to the authority of the boot-maker.
-- Mikhail Bakunin
^ permalink raw reply related
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Pitre @ 2009-11-11 22:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <20091111214216.GO12890@machine.or.cz>
On Wed, 11 Nov 2009, Petr Baudis wrote:
> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:
> > On Wed, 11 Nov 2009, Petr Baudis wrote:
> >
> > > Yes, but nothing should have changed in git-daemon, that's the only part
> > > of the infrastructure that uses system-wide git (which it perhaps
> > > shouldn't). I cannot reproduce this problem, though. I have changed
> > > git-daemon to use my local git version (about one week old master), does
> > > this still happen for you?
> >
> > No, it doesn't happen anymore.
> >
> > What was the git-daemon version before?
>
> 1.5.6.5, the default version in debian lenny
Go figure. I don't see anything that would explain the difference in
behavior with latest git from a quick look.
Nicolas
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Jakub Narebski @ 2009-11-11 22:23 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Junio C Hamano, git
In-Reply-To: <20091111215952.GR31109@inocybe.localdomain>
On Wed, 11 Nov 2009, Todd Zullinger wrote:
> Jakub Narebski wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > The RPM binary packages for a few architectures are found in:
> > >
> > > RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
> >
> > I tried to install git from source RPM... and failed:
> >
> > $ rpmbuild --rebuild git-1.6.5.2-1.fc11.src.rpm
> > Installing git-1.6.5.2-1.fc11.src.rpm
> > warning: user junio does not exist - using root
> > warning: group junio does not exist - using root
> > error: unpacking of archive failed on file
> > /home/local/builddir/SOURCES/git-1.6.5.2.tar.gz;
> > 4afb1f6a: cpio: MD5 sum mismatch
> > error: git-1.6.5.2-1.fc11.src.rpm cannot be installed
> >
> > Error messages are line wrapped for better readibility.
>
> It looks like the kernel.org builders are now using Fedora 11 to
> create the packages. Unfortunately, there were backward-incompatible
> changes in rpm. Stronger hashes are now used and older rpm versions
> do not understand these, leading to the error you got.
Thanks for an information.
Well, it looks like I would have to use "make rpm" to generate RPM
to install, at least until I finally upgrade my Linux distribution.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] give priority to progress messages
From: Nicolas Pitre @ 2009-11-11 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Nicolas Sebrecht, git
In-Reply-To: <20091111214216.GO12890@machine.or.cz>
In theory it is possible for sideband channel #2 to be delayed if
pack data is quick to come up for sideband channel #1. And because
data for channel #2 is read only 128 bytes at a time while pack data
is read 8192 bytes at a time, it is possible for many pack blocks to
be sent to the client before the progress message fifo is emptied,
making the situation even worse. This would result in totally garbled
progress display on the client's console as local progress gets mixed
with partial remote progress lines.
Let's prevent such situations by giving transmission priority to
progress messages over pack data at all times.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
On Wed, 11 Nov 2009, Petr Baudis wrote:
> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:
> > On Wed, 11 Nov 2009, Petr Baudis wrote:
> >
> > > On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:
> > > > According to strace, data from sideband channel #2 (prefixed with
> > > > "remote: ") pertaining to object compression is printed way after pack
> > > > data has already started to arrive locally. This is really weird.
> > > >
> > > > And this occurs only when fetching from repo.or.cz and not from
> > > > git.kernel.org for example. So there is something to investigate on the
> > > > server side. Pasky: anything you changed in your git installation
> > > > lately?
> > >
> > > Yes, but nothing should have changed in git-daemon, that's the only part
> > > of the infrastructure that uses system-wide git (which it perhaps
> > > shouldn't). I cannot reproduce this problem, though. I have changed
> > > git-daemon to use my local git version (about one week old master), does
> > > this still happen for you?
> >
> > No, it doesn't happen anymore.
> >
> > What was the git-daemon version before?
>
> 1.5.6.5, the default version in debian lenny
I don't see why the issue couldn't happen with latest git as well.
This patch however would plug any possibilities for this to happen again
though.
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index c4cd1e1..29446e8 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -132,7 +132,6 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
while (1) {
struct pollfd pfd[2];
- ssize_t processed[2] = { 0, 0 };
int status;
pfd[0].fd = fd1[0];
@@ -147,15 +146,14 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
}
continue;
}
- if (pfd[0].revents & POLLIN)
- /* Data stream ready */
- processed[0] = process_input(pfd[0].fd, 1);
if (pfd[1].revents & POLLIN)
/* Status stream ready */
- processed[1] = process_input(pfd[1].fd, 2);
- /* Always finish to read data when available */
- if (processed[0] || processed[1])
- continue;
+ if (process_input(pfd[1].fd, 2))
+ continue;
+ if (pfd[0].revents & POLLIN)
+ /* Data stream ready */
+ if (process_input(pfd[0].fd, 1))
+ continue;
if (waitpid(writer, &status, 0) < 0)
error_clnt("%s", lostchild);
diff --git a/upload-pack.c b/upload-pack.c
index 70badcf..6bfb500 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -310,6 +310,23 @@ static void create_pack_file(void)
}
continue;
}
+ if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
+ /* Status ready; we ship that in the side-band
+ * or dump to the standard error.
+ */
+ sz = xread(pack_objects.err, progress,
+ sizeof(progress));
+ if (0 < sz)
+ send_client_data(2, progress, sz);
+ else if (sz == 0) {
+ close(pack_objects.err);
+ pack_objects.err = -1;
+ }
+ else
+ goto fail;
+ /* give priority to status messages */
+ continue;
+ }
if (0 <= pu && (pfd[pu].revents & (POLLIN|POLLHUP))) {
/* Data ready; we keep the last byte to ourselves
* in case we detect broken rev-list, so that we
@@ -347,21 +364,6 @@ static void create_pack_file(void)
if (sz < 0)
goto fail;
}
- if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
- /* Status ready; we ship that in the side-band
- * or dump to the standard error.
- */
- sz = xread(pack_objects.err, progress,
- sizeof(progress));
- if (0 < sz)
- send_client_data(2, progress, sz);
- else if (sz == 0) {
- close(pack_objects.err);
- pack_objects.err = -1;
- }
- else
- goto fail;
- }
}
if (finish_command(&pack_objects)) {
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Junio C Hamano @ 2009-11-11 22:25 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20091111215952.GR31109@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> I don't know what the process is for creating the rpm's, but if it's
It is essentially "make rpm" at the top directory as you found out.
> under Junio's control, a fix to create packages which can be read by
> older rpm versions would be to add:
>
> --define "_source_filedigest_algorithm md5" \
> --define "_binary_filedigest_algorithm md5"
>
> to the rpmbuild invocation.
Thanks; will try. Will that have adverse effect when instsalled to FC11
by the way?
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-11 22:44 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <4AFB32DC.50505@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
>> Also, any chance you have multiple refs with "trunk" in the basename?
>>
>> git rev-parse --symbolic --all | grep '/trunk'
>
> This reports:
>
> $ git rev-parse --symbolic --all | grep '/trunk'
> refs/remotes/svn/trunk
Pascal,
OK, this is normal.
>> It could be a backwards compatibility issue with git svn looking
>> in multiple places for trunk.
>
> But I have multiple trunk:
>
> $ ls .git/svn/svn/trunk/
> ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
>
> $ ls .git/svn/refs/remotes/svn/trunk/
> ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
>
> Removing all the .rev_map* fix the problem.
>
> Removing only the one in .git/svn/refs/remotes/svn/trunk/ fix the
> problem too.
>
>> With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first
>> Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
>
> Does this means that it was looking first in $GIT_DIR/svn/trunk/*
> before? And the confusion come because now it is looking in
> $GIT_DIR/svn/refs/remotes/trunk/* first?
Yes, but somehow $GIT_DIR/svn/refs/remotes/trunk should not have
been created since $GIT_DIR/svn/svn/trunk already existed. Both
of those directories existing at the same time should not
Did you try an early version of Adam's patch before it made it into
git.git by any chance?
Or, did you by any chance start a fresh import with a v1.6.5 and then
rsync $GIT_DIR to one created with 1.6.4 and not use --delete with
rsync?
--
Eric Wong
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-11 20:32 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git list
In-Reply-To: <1257968052.26362.155.camel@heerbeest>
On Nov 11, 2009, at 8:34 PM, Jan Nieuwenhuizen wrote:
> Op woensdag 11-11-2009 om 20:10 uur [tijdzone +0100], schreef Tomas
> Carnecky:
>> On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:
>
> Hi Tomas,
>
>> You used this:
>> $ git config branch.master.remote = <something>
>> Do you see the difference between that and what I posted?
>
> Sure, I now know what syntax you and the advise mean. However,
> I'm just pointing out that the git pull advise makes no sense,
> however way you try to interpret it?
It didn't tell you to copy'n'paste the whole lines to a git-config(1)
commandline. But I do see that the output can be confusing for someone
not familiar with the git configuration files/git-config.
>>> I think it might be more helpful if this text said
>>> configuration file and gave a usable configuration file
>>> snippet, or alternatively said git config, and gave usable
>>> git config commands.
>>
>> Feel free to send a patch ;)
>
> [just maybe, if my uninstall patch goes in easily, but]
>
> First I need to know what the new advise should be. As you
> can see below, I'm still confused.
>
> I was hoping someone would say: Ah blast! That was me,
> stupid: Fixed in master :-) And everything would make
> sense and work.
You can use git-blame(1) to find out who wrote those lines ;)
>
>> branch.master.remote has two different values, git doesn't know which
>> remote to use.
>
> Well, it can see that there already is a value for
> branch.master.remote
> defined, and it /still/ advises to add one. It also uses <nickname>,
> which suggests there could be multiple values?
>
> For all I know, pull can only handle one nickname and it shouldn't
> give this advise at all?
>
>> Do you want to pull from origin or eddy?
>
> I'm publishing on origin -- that's what the original clone was
> from. Also, I use it to update from most often, when I work
> from different locations. All fine.
>
> Now this Eddy guy says: pull from here. I try it and get
> this advise. So, I'd like to have
>
> git pull # use origin by default
> git pull eddy # pull from eddy's url
I don't know the relationship between you and eddy, but usually you
shouldn't rebase (=rewrite) eddies commits. That also means you'd have
to live with the merge commits.
>
>> I would
>> recommend only keeping one [branch "master"] section and edit it
>> appropriately.
>
> Yes, I tried that and came up with
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> # advise from git pull, using <nickname> = eddy
> # branch.master.remote = <nickname>
> # branch.master.merge = <remote-ref>
> # remote.<nickname>.url = <url>
> # remote.<nickname>.fetch = <refspec>
> #[branch "master"]
> # remote = eddy # ignore branch.master.remote advise
> # merge = refs/heads/master
> [remote "eddy"]
> url = http://github.com/epronk/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
I see your mistake. Both the origin and eddy remote write to the same
namespace (refs/remotes/origin/*), and that's also why you get (force
update) below
. Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/
remotes/eddy/*. After that both command (pull -r / pull -r eddy)
should work (I hope).
>
> This /seems/ to work. However, I still get this
>
> $ git pull -r
> From git@github.com:janneke/gub
> + 7bb5905...8ff38da master -> origin/master (forced update)
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to 8ff38da0a7013a891de18a0b7bec12b9d1fa6637.
> 20:25:55 janneke@peder:~/vc/gub
>
> [looks okay]
>
> $ git pull -r eddy
> From http://github.com/epronk/gub
> + 8ff38da...7bb5905 master -> origin/master (forced update)
> [looks fine too, but still continues with]
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> specify which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
> [1]20:26:01 janneke@peder:~/vc/gub
> $
>
> so I'm still missing something?
>
>> Is 'git pull -r' not short enough for you?
>
> It's more of a usability thing. It annoys me that the most
> used functionality needs a command line option. Worse however,
> is that people [myself included] tend to forget that "-r",
> and our logs have lots of these ugly, unnecessary
>
> c377994 Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond
>
> Also, we need to explain this to all newcomers.
I've found that all the available guides and books about git explain
merging pretty well (it's a central part of git after all).
tom
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-11 23:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Michael J Gruber, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <20091025111438.GA11252@progeny.tock>
On Sun, Oct 25, 2009 at 1:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> Supposing that color.ui is 'auto' by default,
>
> Should it be? I think it would not be too hard to detect a color
> terminal by checking $TERM. Are many people bothered by color? Do we
> need some way to make it more obvious how to turn color _off_?
I think it should be.
>> No, but "improving" needs "changing", and the discussion I see is
>> biased towards "not changing".
> [...]
>> I don't think the user manual is achieving that purpose. I don't know
>> if it's the user manual's fault, or git's UI. Both areas need a lot of
>> improvement (as the git user survey suggests), and I've tried to
>> improve both with a lot resistance in both. So I'm not very hopeful
>> anymore.
>
> I hope you have not misunderstood. I cannot speak for everyone else
> here, but I know I am happier when (1) fixes match problems to be
> solved in a documented way and (2) fixes do not unnecessarily break
> unrelated habits. One way to bring this about is to justify each
> change by explaining what real problem it will solve and how it avoids
> collateral damage. Without that justification, a change is indeed
> dangerous and might be worth resisting until it gets clarified. But
> this is not meant to prevent fixes from occuring at all.
Well. I've sent many patches, and gone through several iterations.
After fixing all outstanding issues, addressing all the comments, and
getting several "I like this" votes, Junio suddenly decides he doesn't
like the initial changes at all and doesn't provide any way forward.
I don't see how that's an environment that fosters changes.
> Could you list some UI patches that were overlooked or not properly
> addressed? Maybe people just forgot about them or were waiting for an
> updated version, or maybe the problems some solve weren’t articulated
> clearly yet. I would be glad to help out in any way I can.
For example there have been many attempts to bring the 'git stage' to
foreground of the UI; right now it's kind of hidden and many people
don't even realize it's there. Even simplistic attempts as
standardizing --index, --cache and so on into --stage have failed
miserably.
Again, there doesn't seem to be a path forward. Perhaps the git's
stage will remain an obscure feature of git forever. (all the input
from git user's survey points out that people are not really using it)
>> Judging from the luck I've had pushing even the simplest
>> changes I don't think it will improve much more, unfortunately.
>
> Even the simplest changes can be hard. But I hope they do not amount
> to nothing. I hope at the very least the git-config manual page will
> improve...
What I mean is: if the simplest changes are *impossible*, then there's
barely any hope of progress.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Todd Zullinger @ 2009-11-11 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vfx8kn1h7.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Junio C Hamano wrote:
> Thanks; will try. Will that have adverse effect when instsalled to
> FC11 by the way?
None that I am aware of (aside from using a less secure file digest
algorith, of course :). I've installed packages built that way on
Fedora 12 systems without issue.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Blessed are they who can laugh at themselves for they shall never
cease to be amused.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Thomas Rast @ 2009-11-11 23:37 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Baz, Peter Krefting, Git Mailing List,
Johannes Schindelin, Björn Steinbrink
In-Reply-To: <20091111213049.GJ27518@vidovic>
Nicolas Sebrecht wrote:
> The 11/11/09, Junio C Hamano wrote:
> > Thomas Rast <trast@student.ethz.ch> writes:
> >
> > > ++
> > > +Because the sides in a rebase are swapped, using this strategy with
> > > +git-rebase is never a good idea.
> >
> > Looking very good.
>
> If this strategy is _never_ a good idea in this case, I tend to think
> that git should forbid this option, or at least, warn and refer to the
> documentation.
Then again, I'm not sure if resolve vs. recursive makes a difference
in a rebase. Octopus is weird for a two-head merge, I'm not sure why
the docs even talk about it. That would leave only subtree, which
indeed has its uses. Should we add a note to that effect to
git-rebase.txt? Like, say,
diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 33e0ef1..6e54a57 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt
@@ -228,13 +228,19 @@ OPTIONS
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
++
+Note that in a rebase merge (hence merge conflict), the sides are
+swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
+rebased series, starting with <upstream>.
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy.
- If there is no `-s` option, a built-in list of strategies
- is used instead ('git-merge-recursive' when merging a single
- head, 'git-merge-octopus' otherwise). This implies --merge.
+ If there is no `-s` option 'git-merge-recursive' is used
+ instead. This implies --merge.
++
+Due to the peculiarities of 'git-rebase' (see \--merge above) the only
+built-in strategy that is actually useful is 'subtree'.
-q::
--quiet::
diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
index 4365b7e..c1c3add 100644
--- i/Documentation/merge-strategies.txt
+++ w/Documentation/merge-strategies.txt
@@ -33,6 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
++
+Because the sides in a rebase are swapped, using this strategy with
+'git-rebase' is never a good idea.
subtree::
This is a modified recursive strategy. When merging trees A and
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* [PATCH v4 0/9] Default pager and editor
From: Jonathan Nieder @ 2009-11-11 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091031012050.GA5160@progeny.tock>
Junio C Hamano wrote:
> * jn/editor-pager (2009-10-30) 8 commits
> - Provide a build time default-pager setting
> - Provide a build time default-editor setting
> - am -i, git-svn: use "git var GIT_PAGER"
> - add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
> - Teach git var about GIT_PAGER
> - Teach git var about GIT_EDITOR
> - Do not use VISUAL editor on dumb terminals
> - Handle more shell metacharacters in editor names
>
> Any comments?
Here’s a reroll. The interdiff is very small:
diff --git a/ident.c b/ident.c
index 99f1c85..26409b2 100644
--- a/ident.c
+++ b/ident.c
@@ -205,7 +205,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git var -l" */
+ env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
and the corresponding hunk in patch 3 could be safely discarded.
Aside from that, patch 3 has been unsquashed from patch 4, since it is
an independent fix that might be worth ejecting; the Signed-off-by
lines on patches 2 and 4 have been fixed; and the commit message for
patch 4 has been expanded to explain more.
In short, nothing of substance has changed. If you are reminded of
any thoughts on the series, please let me know.
I think it is fair to say every one of these patches except the first
was someone else’s idea. Thanks, everyone.
Jonathan Nieder (8):
Handle more shell metacharacters in editor names
Do not use VISUAL editor on dumb terminals
Suppress warnings from "git var -l"
Teach git var about GIT_EDITOR
Teach git var about GIT_PAGER
add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
am -i, git-svn: use "git var GIT_PAGER"
Provide a build time default-editor setting
Junio C Hamano (1):
Provide a build time default-pager setting
Documentation/config.txt | 4 +--
Documentation/git-commit.txt | 2 +-
Documentation/git-send-email.txt | 4 +-
Documentation/git-var.txt | 14 +++++++++++
Makefile | 28 ++++++++++++++++++++++
cache.h | 2 +
contrib/fast-import/git-p4 | 5 +---
editor.c | 32 ++++++++++++++++++-------
git-add--interactive.perl | 3 +-
git-am.sh | 5 +++-
git-send-email.perl | 3 +-
git-sh-setup.sh | 19 +++++----------
git-svn.perl | 11 +++-----
ident.c | 2 +-
pager.c | 24 ++++++++++++++++---
t/t7005-editor.sh | 47 ++++++++++++++++++++++++++++---------
t/t7501-commit.sh | 8 +++---
t/test-lib.sh | 8 +++---
var.c | 26 ++++++++++++++++++++-
19 files changed, 178 insertions(+), 69 deletions(-)
^ permalink raw reply related
* [PATCH 1/9] Handle more shell metacharacters in editor names
From: Jonathan Nieder @ 2009-11-11 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Pass the editor name to the shell if it contains any susv3 shell
special character (globs, redirections, variable substitutions,
escapes, etc). This way, the meaning of some characters will not
meaninglessly change when others are added, and git commands
implemented in C and in shell scripts will interpret editor names
in the same way.
This does not make the GIT_EDITOR setting any more expressive,
since one could always use single quotes to force the editor to
be passed to the shell.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged from jn/editor-pager, included only for reference.
editor.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/editor.c b/editor.c
index 4d469d0..941c0b2 100644
--- a/editor.c
+++ b/editor.c
@@ -28,7 +28,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
const char *args[6];
struct strbuf arg0 = STRBUF_INIT;
- if (strcspn(editor, "$ \t'") != len) {
+ if (strcspn(editor, "|&;<>()$`\\\"' \t\n*?[#~=%") != len) {
/* there are specials */
strbuf_addf(&arg0, "%s \"$@\"", editor);
args[i++] = "sh";
--
1.6.5.2
^ permalink raw reply related
* [PATCH 2/9] Do not use VISUAL editor on dumb terminals
From: Jonathan Nieder @ 2009-11-11 23:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Fixes broken sign-off, patch unchanged.
I am personally most interested in this for usage from a text editor,
but vim does not set TERM=dumb like it probably ought to. A more
realistic everyday example might be "ssh user@domain git commit".
editor.c | 12 ++++++------
t/t7005-editor.sh | 10 ++++++++++
t/t7501-commit.sh | 8 ++++----
t/test-lib.sh | 8 ++++----
4 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/editor.c b/editor.c
index 941c0b2..3f13751 100644
--- a/editor.c
+++ b/editor.c
@@ -4,19 +4,19 @@
int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
{
- const char *editor, *terminal;
+ const char *editor = getenv("GIT_EDITOR");
+ const char *terminal = getenv("TERM");
+ int terminal_is_dumb = !terminal || !strcmp(terminal, "dumb");
- editor = getenv("GIT_EDITOR");
if (!editor && editor_program)
editor = editor_program;
- if (!editor)
+ if (!editor && !terminal_is_dumb)
editor = getenv("VISUAL");
if (!editor)
editor = getenv("EDITOR");
- terminal = getenv("TERM");
- if (!editor && (!terminal || !strcmp(terminal, "dumb")))
- return error("Terminal is dumb but no VISUAL nor EDITOR defined.");
+ if (!editor && terminal_is_dumb)
+ return error("terminal is dumb, but EDITOR unset");
if (!editor)
editor = "vi";
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index b647957..a95fe19 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -42,6 +42,16 @@ test_expect_success 'dumb should error out when falling back on vi' '
fi
'
+test_expect_success 'dumb should prefer EDITOR to VISUAL' '
+
+ EDITOR=./e-EDITOR.sh &&
+ VISUAL=./e-VISUAL.sh &&
+ export EDITOR VISUAL &&
+ git commit --amend &&
+ test "$(git show -s --format=%s)" = "Edited by EDITOR"
+
+'
+
TERM=vt100
export TERM
for i in vi EDITOR VISUAL core_editor GIT_EDITOR
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index d2de576..a603f6d 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -86,7 +86,7 @@ chmod 755 editor
test_expect_success \
"amend commit" \
- "VISUAL=./editor git commit --amend"
+ "EDITOR=./editor git commit --amend"
test_expect_success \
"passing -m and -F" \
@@ -107,7 +107,7 @@ chmod 755 editor
test_expect_success \
"editing message from other commit" \
"echo 'hula hula' >file && \
- VISUAL=./editor git commit -c HEAD^ -a"
+ EDITOR=./editor git commit -c HEAD^ -a"
test_expect_success \
"message from stdin" \
@@ -141,10 +141,10 @@ EOF
test_expect_success \
'editor not invoked if -F is given' '
echo "moo" >file &&
- VISUAL=./editor git commit -a -F msg &&
+ EDITOR=./editor git commit -a -F msg &&
git show -s --pretty=format:"%s" | grep -q good &&
echo "quack" >file &&
- echo "Another good message." | VISUAL=./editor git commit -a -F - &&
+ echo "Another good message." | EDITOR=./editor git commit -a -F - &&
git show -s --pretty=format:"%s" | grep -q good
'
# We could just check the head sha1, but checking each commit makes it
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..ec3336a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -30,7 +30,7 @@ TZ=UTC
TERM=dumb
export LANG LC_ALL PAGER TERM TZ
EDITOR=:
-VISUAL=:
+unset VISUAL
unset GIT_EDITOR
unset AUTHOR_DATE
unset AUTHOR_EMAIL
@@ -58,7 +58,7 @@ GIT_MERGE_VERBOSITY=5
export GIT_MERGE_VERBOSITY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
-export EDITOR VISUAL
+export EDITOR
GIT_TEST_CMP=${GIT_TEST_CMP:-diff -u}
# Protect ourselves from common misconfiguration to export
@@ -207,8 +207,8 @@ trap 'die' EXIT
test_set_editor () {
FAKE_EDITOR="$1"
export FAKE_EDITOR
- VISUAL='"$FAKE_EDITOR"'
- export VISUAL
+ EDITOR='"$FAKE_EDITOR"'
+ export EDITOR
}
test_tick () {
--
1.6.5.2
^ permalink raw reply related
* [PATCH 3/9] Suppress warnings from "git var -l"
From: Jonathan Nieder @ 2009-11-11 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
For scripts using "git var -l" to read all logical variables at
once, not all per-variable warnings will be relevant. So suppress
them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This is a separate issue that might even deserve to be ejected
from the series.
Changes from jn/editor-pager: unsquashed from the next patch, added
back comment-changing hunk. Of course, there’s no harm in omitting
the comment change, but it describes a change in reality: before this
patch, that code gets run multiple times by "git var -l"; afterwards,
by no one (except possible out-of-tree users).
ident.c | 2 +-
var.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 99f1c85..26409b2 100644
--- a/ident.c
+++ b/ident.c
@@ -205,7 +205,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git var -l" */
+ env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
diff --git a/var.c b/var.c
index 125c0d1..dacbaab 100644
--- a/var.c
+++ b/var.c
@@ -22,7 +22,7 @@ static void list_vars(void)
{
struct git_var *ptr;
for (ptr = git_vars; ptr->read; ptr++)
- printf("%s=%s\n", ptr->name, ptr->read(IDENT_WARN_ON_NO_NAME));
+ printf("%s=%s\n", ptr->name, ptr->read(0));
}
static const char *read_var(const char *var)
--
1.6.5.2
^ permalink raw reply related
* [PATCH 4/9] Teach git var about GIT_EDITOR
From: Jonathan Nieder @ 2009-11-12 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Expose the command used by launch_editor() for scripts to use.
This should allow one to avoid searching for a proper editor
separately in each command.
git_editor(void) uses the logic to decide which editor to use
that used to live in launch_editor(). The function returns NULL
if there is no suitable editor; the caller is expected to issue
an error message when appropriate.
launch_editor() uses git_editor() and gives the error message the
same way as before when EDITOR is not set.
"git var GIT_EDITOR" gives the editor name, or an error message
when there is no appropriate one.
"git var -l" gives GIT_EDITOR=name only if there is an
appropriate editor.
Originally-submitted-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Changes from the version in pu:
* unsquashed with the previous patch;
* replaces Hannes’s sign-off with something more descriptive (see
<http://thread.gmane.org/gmane.comp.version-control.git/131471/focus=131851>);
* nicer commit message based on Junio’s summary.
Documentation/git-var.txt | 8 ++++++++
cache.h | 1 +
editor.c | 14 ++++++++++++--
var.c | 16 +++++++++++++++-
4 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index e2f4c09..89e4b4f 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -36,6 +36,14 @@ GIT_AUTHOR_IDENT::
GIT_COMMITTER_IDENT::
The person who put a piece of code into git.
+GIT_EDITOR::
+ Text editor for use by git commands. The value is meant to be
+ interpreted by the shell when it is used. Examples: `~/bin/vi`,
+ `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe"
+ --nofork`. The order of preference is the `$GIT_EDITOR`
+ environment variable, then `core.editor` configuration, then
+ `$VISUAL`, then `$EDITOR`, and then finally 'vi'.
+
Diagnostics
-----------
You don't exist. Go away!::
diff --git a/cache.h b/cache.h
index 96840c7..311cfe1 100644
--- a/cache.h
+++ b/cache.h
@@ -750,6 +750,7 @@ extern const char *git_author_info(int);
extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
extern const char *fmt_name(const char *name, const char *email);
+extern const char *git_editor(void);
struct checkout {
const char *base_dir;
diff --git a/editor.c b/editor.c
index 3f13751..70618f1 100644
--- a/editor.c
+++ b/editor.c
@@ -2,7 +2,7 @@
#include "strbuf.h"
#include "run-command.h"
-int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
+const char *git_editor(void)
{
const char *editor = getenv("GIT_EDITOR");
const char *terminal = getenv("TERM");
@@ -16,11 +16,21 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
editor = getenv("EDITOR");
if (!editor && terminal_is_dumb)
- return error("terminal is dumb, but EDITOR unset");
+ return NULL;
if (!editor)
editor = "vi";
+ return editor;
+}
+
+int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
+{
+ const char *editor = git_editor();
+
+ if (!editor)
+ return error("Terminal is dumb, but EDITOR unset");
+
if (strcmp(editor, ":")) {
size_t len = strlen(editor);
int i = 0;
diff --git a/var.c b/var.c
index dacbaab..b502487 100644
--- a/var.c
+++ b/var.c
@@ -8,6 +8,16 @@
static const char var_usage[] = "git var [-l | <variable>]";
+static const char *editor(int flag)
+{
+ const char *pgm = git_editor();
+
+ if (!pgm && flag & IDENT_ERROR_ON_NO_NAME)
+ die("Terminal is dumb, but EDITOR unset");
+
+ return pgm;
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
@@ -15,14 +25,18 @@ struct git_var {
static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
{ "GIT_AUTHOR_IDENT", git_author_info },
+ { "GIT_EDITOR", editor },
{ "", NULL },
};
static void list_vars(void)
{
struct git_var *ptr;
+ const char *val;
+
for (ptr = git_vars; ptr->read; ptr++)
- printf("%s=%s\n", ptr->name, ptr->read(0));
+ if ((val = ptr->read(0)))
+ printf("%s=%s\n", ptr->name, val);
}
static const char *read_var(const char *var)
--
1.6.5.2
^ permalink raw reply related
* [PATCH 5/9] Teach git var about GIT_PAGER
From: Jonathan Nieder @ 2009-11-12 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Expose the command found by setup_pager() for scripts to use.
Scripts can use this to avoid repeating the logic to look for a
proper pager in each command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
The rest of the series is unchanged from pu.
Documentation/git-var.txt | 6 ++++++
cache.h | 1 +
| 18 +++++++++++++++---
var.c | 10 ++++++++++
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 89e4b4f..ef6aa81 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -44,6 +44,12 @@ GIT_EDITOR::
environment variable, then `core.editor` configuration, then
`$VISUAL`, then `$EDITOR`, and then finally 'vi'.
+GIT_PAGER::
+ Text viewer for use by git commands (e.g., 'less'). The value
+ is meant to be interpreted by the shell. The order of preference
+ is the `$GIT_PAGER` environment variable, then `core.pager`
+ configuration, then `$PAGER`, and then finally 'less'.
+
Diagnostics
-----------
You don't exist. Go away!::
diff --git a/cache.h b/cache.h
index 311cfe1..5aaa4ba 100644
--- a/cache.h
+++ b/cache.h
@@ -751,6 +751,7 @@ extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
extern const char *fmt_name(const char *name, const char *email);
extern const char *git_editor(void);
+extern const char *git_pager(void);
struct checkout {
const char *base_dir;
--git a/pager.c b/pager.c
index 86facec..0b63d99 100644
--- a/pager.c
+++ b/pager.c
@@ -44,12 +44,14 @@ static void wait_for_pager_signal(int signo)
raise(signo);
}
-void setup_pager(void)
+const char *git_pager(void)
{
- const char *pager = getenv("GIT_PAGER");
+ const char *pager;
if (!isatty(1))
- return;
+ return NULL;
+
+ pager = getenv("GIT_PAGER");
if (!pager) {
if (!pager_program)
git_config(git_default_config, NULL);
@@ -60,6 +62,16 @@ void setup_pager(void)
if (!pager)
pager = "less";
else if (!*pager || !strcmp(pager, "cat"))
+ pager = NULL;
+
+ return pager;
+}
+
+void setup_pager(void)
+{
+ const char *pager = git_pager();
+
+ if (!pager)
return;
spawned_pager = 1; /* means we are emitting to terminal */
diff --git a/var.c b/var.c
index b502487..d9892f8 100644
--- a/var.c
+++ b/var.c
@@ -18,6 +18,15 @@ static const char *editor(int flag)
return pgm;
}
+static const char *pager(int flag)
+{
+ const char *pgm = git_pager();
+
+ if (!pgm)
+ pgm = "cat";
+ return pgm;
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
@@ -26,6 +35,7 @@ static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
{ "GIT_AUTHOR_IDENT", git_author_info },
{ "GIT_EDITOR", editor },
+ { "GIT_PAGER", pager },
{ "", NULL },
};
--
1.6.5.2
^ permalink raw reply related
* [PATCH 6/9] add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
From: Jonathan Nieder @ 2009-11-12 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged from pu.
Documentation/config.txt | 4 +---
Documentation/git-commit.txt | 2 +-
Documentation/git-send-email.txt | 4 ++--
contrib/fast-import/git-p4 | 5 +----
git-add--interactive.perl | 3 +--
git-send-email.perl | 3 ++-
git-sh-setup.sh | 19 ++++++-------------
git-svn.perl | 5 ++---
8 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..5181b77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -387,9 +387,7 @@ core.editor::
Commands such as `commit` and `tag` that lets you edit
messages by launching an editor uses the value of this
variable when it is set, and the environment variable
- `GIT_EDITOR` is not set. The order of preference is
- `GIT_EDITOR` environment, `core.editor`, `VISUAL` and
- `EDITOR` environment variables and then finally `vi`.
+ `GIT_EDITOR` is not set. See linkgit:git-var[1].
core.pager::
The command that git will use to paginate output. Can
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0578a40..3ea80c8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -323,7 +323,7 @@ ENVIRONMENT AND CONFIGURATION VARIABLES
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+order). See linkgit:git-var[1] for details.
HOOKS
-----
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 767cf4d..c85d7f4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -60,8 +60,8 @@ The --bcc option must be repeated for each user you want on the bcc list.
The --cc option must be repeated for each user you want on the cc list.
--compose::
- Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
- introductory message for the patch series.
+ Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1])
+ to edit an introductory message for the patch series.
+
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..48059d0 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -729,13 +729,10 @@ class P4Submit(Command):
tmpFile.write(submitTemplate + separatorLine + diff + newdiff)
tmpFile.close()
mtime = os.stat(fileName).st_mtime
- defaultEditor = "vi"
- if platform.system() == "Windows":
- defaultEditor = "notepad"
if os.environ.has_key("P4EDITOR"):
editor = os.environ.get("P4EDITOR")
else:
- editor = os.environ.get("EDITOR", defaultEditor);
+ editor = read_pipe("git var GIT_EDITOR")
system(editor + " " + fileName)
response = "y"
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 69aeaf0..0c74e5c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -987,8 +987,7 @@ sub edit_hunk_manually {
EOF
close $fh;
- my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
- || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+ chomp(my $editor = run_cmd_pipe(qw(git var GIT_EDITOR)));
system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
if ($? != 0) {
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..4f5da4e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -162,7 +162,8 @@ my $compose_filename;
# Handle interactive edition of files.
my $multiedit;
-my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+my $editor = Git::command_oneline('var', 'GIT_EDITOR');
+
sub do_edit {
if (defined($multiedit) && !$multiedit) {
map {
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..99cceeb 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -99,19 +99,12 @@ set_reflog_action() {
}
git_editor() {
- : "${GIT_EDITOR:=$(git config core.editor)}"
- : "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
- case "$GIT_EDITOR,$TERM" in
- ,dumb)
- echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
- echo >&2 "or EDITOR. Tried to fall back to vi but terminal is dumb."
- echo >&2 "Please set one of these variables to an appropriate"
- echo >&2 "editor or run $0 with options that will not cause an"
- echo >&2 "editor to be invoked (e.g., -m or -F for git-commit)."
- exit 1
- ;;
- esac
- eval "${GIT_EDITOR:=vi}" '"$@"'
+ if test -z "${GIT_EDITOR:+set}"
+ then
+ GIT_EDITOR="$(git var GIT_EDITOR)" || return $?
+ fi
+
+ eval "$GIT_EDITOR" '"$@"'
}
is_bare_repository () {
diff --git a/git-svn.perl b/git-svn.perl
index 6a3b501..42c9a72 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1321,9 +1321,8 @@ sub get_commit_entry {
close $log_fh or croak $!;
if ($_edit || ($type eq 'tree')) {
- my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
- # TODO: strip out spaces, comments, like git-commit.sh
- system($editor, $commit_editmsg);
+ chomp(my $editor = command_oneline(qw(var GIT_EDITOR)));
+ system('sh', '-c', $editor.' "$@"', $editor, $commit_editmsg);
}
rename $commit_editmsg, $commit_msg or croak $!;
{
--
1.6.5.2
^ permalink raw reply related
* [PATCH 7/9] am -i, git-svn: use "git var GIT_PAGER"
From: Jonathan Nieder @ 2009-11-12 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Use the new "git var GIT_PAGER" command to ask what pager to use.
Without this change, the core.pager configuration is ignored by
these commands.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged.
git-am.sh | 5 ++++-
git-svn.perl | 6 ++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c132f50..2649487 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -649,7 +649,10 @@ do
[eE]*) git_editor "$dotest/final-commit"
action=again ;;
[vV]*) action=again
- LESS=-S ${PAGER:-less} "$dotest/patch" ;;
+ : ${GIT_PAGER=$(git var GIT_PAGER)}
+ : ${LESS=-FRSX}
+ export LESS
+ $GIT_PAGER "$dotest/patch" ;;
*) action=again ;;
esac
done
diff --git a/git-svn.perl b/git-svn.perl
index 42c9a72..c4ca548 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5171,10 +5171,8 @@ sub git_svn_log_cmd {
# adapted from pager.c
sub config_pager {
- $pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
- if (!defined $pager) {
- $pager = 'less';
- } elsif (length $pager == 0 || $pager eq 'cat') {
+ chomp(my $pager = command_oneline(qw(var GIT_PAGER)));
+ if ($pager eq 'cat') {
$pager = undef;
}
$ENV{GIT_PAGER_IN_USE} = defined($pager);
--
1.6.5.2
^ permalink raw reply related
* [PATCH 8/9] Provide a build time default-editor setting
From: Jonathan Nieder @ 2009-11-12 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Provide a DEFAULT_EDITOR knob to allow setting the fallback
editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR
are unset). The value can be set at build time according to a
system’s policy. For example, on Debian systems, the default
editor should be the 'editor' command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged.
Makefile | 17 +++++++++++++++++
editor.c | 6 +++++-
t/t7005-editor.sh | 37 +++++++++++++++++++++++++------------
3 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 268aede..625866c 100644
--- a/Makefile
+++ b/Makefile
@@ -200,6 +200,14 @@ all::
# memory allocators with the nedmalloc allocator written by Niall Douglas.
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
+#
+# Define DEFAULT_EDITOR to a sensible editor command (defaults to "vi") if you
+# want to use something different. The value will be interpreted by the shell
+# if necessary when it is used. Examples:
+#
+# DEFAULT_EDITOR='~/bin/vi',
+# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
+# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1363,6 +1371,15 @@ BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
$(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
+# Quote for C
+
+ifdef DEFAULT_EDITOR
+DEFAULT_EDITOR_CQ = "$(subst ",\",$(subst \,\\,$(DEFAULT_EDITOR)))"
+DEFAULT_EDITOR_CQ_SQ = $(subst ','\'',$(DEFAULT_EDITOR_CQ))
+
+BASIC_CFLAGS += -DDEFAULT_EDITOR='$(DEFAULT_EDITOR_CQ_SQ)'
+endif
+
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
diff --git a/editor.c b/editor.c
index 70618f1..615f575 100644
--- a/editor.c
+++ b/editor.c
@@ -2,6 +2,10 @@
#include "strbuf.h"
#include "run-command.h"
+#ifndef DEFAULT_EDITOR
+#define DEFAULT_EDITOR "vi"
+#endif
+
const char *git_editor(void)
{
const char *editor = getenv("GIT_EDITOR");
@@ -19,7 +23,7 @@ const char *git_editor(void)
return NULL;
if (!editor)
- editor = "vi";
+ editor = DEFAULT_EDITOR;
return editor;
}
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index a95fe19..5257f4d 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -4,7 +4,21 @@ test_description='GIT_EDITOR, core.editor, and stuff'
. ./test-lib.sh
-for i in GIT_EDITOR core_editor EDITOR VISUAL vi
+unset EDITOR VISUAL GIT_EDITOR
+
+test_expect_success 'determine default editor' '
+
+ vi=$(TERM=vt100 git var GIT_EDITOR) &&
+ test -n "$vi"
+
+'
+
+if ! expr "$vi" : '^[a-z]*$' >/dev/null
+then
+ vi=
+fi
+
+for i in GIT_EDITOR core_editor EDITOR VISUAL $vi
do
cat >e-$i.sh <<-EOF
#!$SHELL_PATH
@@ -12,19 +26,18 @@ do
EOF
chmod +x e-$i.sh
done
-unset vi
-mv e-vi.sh vi
-unset EDITOR VISUAL GIT_EDITOR
+
+if ! test -z "$vi"
+then
+ mv e-$vi.sh $vi
+fi
test_expect_success setup '
- msg="Hand edited" &&
+ msg="Hand-edited" &&
+ test_commit "$msg" &&
echo "$msg" >expect &&
- git add vi &&
- test_tick &&
- git commit -m "$msg" &&
- git show -s --pretty=oneline |
- sed -e "s/^[0-9a-f]* //" >actual &&
+ git show -s --format=%s > actual &&
diff actual expect
'
@@ -54,7 +67,7 @@ test_expect_success 'dumb should prefer EDITOR to VISUAL' '
TERM=vt100
export TERM
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in $vi EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
unset EDITOR VISUAL GIT_EDITOR
@@ -78,7 +91,7 @@ done
unset EDITOR VISUAL GIT_EDITOR
git config --unset-all core.editor
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in $vi EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
case "$i" in
--
1.6.5.2
^ permalink raw reply related
* [PATCH 9/9] Provide a build time default-pager setting
From: Jonathan Nieder @ 2009-11-12 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.
Examples:
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.
On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
As in pu.
Makefile | 11 +++++++++++
| 6 +++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 625866c..18fc50a 100644
--- a/Makefile
+++ b/Makefile
@@ -201,6 +201,10 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
+# Define DEFAULT_PAGER to a sensible pager command (defaults to "less") if
+# you want to use something different. The value will be interpreted by the
+# shell at runtime when it is used.
+#
# Define DEFAULT_EDITOR to a sensible editor command (defaults to "vi") if you
# want to use something different. The value will be interpreted by the shell
# if necessary when it is used. Examples:
@@ -1380,6 +1384,13 @@ DEFAULT_EDITOR_CQ_SQ = $(subst ','\'',$(DEFAULT_EDITOR_CQ))
BASIC_CFLAGS += -DDEFAULT_EDITOR='$(DEFAULT_EDITOR_CQ_SQ)'
endif
+ifdef DEFAULT_PAGER
+DEFAULT_PAGER_CQ = "$(subst ",\",$(subst \,\\,$(DEFAULT_PAGER)))"
+DEFAULT_PAGER_CQ_SQ = $(subst ','\'',$(DEFAULT_PAGER_CQ))
+
+BASIC_CFLAGS += -DDEFAULT_PAGER='$(DEFAULT_PAGER_CQ_SQ)'
+endif
+
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
--git a/pager.c b/pager.c
index 0b63d99..92c03f6 100644
--- a/pager.c
+++ b/pager.c
@@ -2,6 +2,10 @@
#include "run-command.h"
#include "sigchain.h"
+#ifndef DEFAULT_PAGER
+#define DEFAULT_PAGER "less"
+#endif
+
/*
* This is split up from the rest of git so that we can do
* something different on Windows.
@@ -60,7 +64,7 @@ const char *git_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = DEFAULT_PAGER;
else if (!*pager || !strcmp(pager, "cat"))
pager = NULL;
--
1.6.5.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox