* Re: [PATCH v3] convert filter: supply path to external driver
From: Jonathan Nieder @ 2010-12-21 18:19 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Junio C Hamano, git, Jeff King, Johannes Sixt
In-Reply-To: <20101221134403.GA10401@honk.padd.com>
Hi,
Pete Wyckoff wrote:
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
Nitpicks (some silly, some not):
> @@ -93,4 +93,51 @@ test_expect_success expanded_in_repo '
> cmp expanded-keywords expected-output
> '
>
> +cat <<EOF >argc.sh
> +#!$SHELL_PATH
> +echo argc: \$# "\$@"
> +echo argc running >&2
> +EOF
> +chmod +x argc.sh
You can embed this in a test_expect_success stanza (like the next
one or the earlier "setup") like so:
cat <<-EOF >argc.sh &&
#!$SHELL_PATH
...
EOF
chmod +x argc.sh &&
This way if the "chmod" fails on some platform the test would
catch that.
> +
> +#
> +# The use of %f in a filter definition is expanded to the path to
> +# the filename being smudged or cleaned. It must be shell escaped.
> +#
I'd even prefer to see this comment inside the test_expect_success
assertion so it can be printed when running the test with "-v".
But I suppose consistency with the other test in the script suggests
otherwise.
[...]
> + echo some test text > test
> + cat test > $norm &&
> + cat test > "$spec" &&
Missing && after "> test". Probably best to remove the space
after > (just for consistency[1]). Also, please use tabs to indent.
[...]
> + # make sure argc.sh counted the right number of args
> + echo "argc: 1 $norm" > res &&
> + cmp res $norm &&
test_cmp? (for nicer output) See t/README.
[...]
> + # %f with other args
> + git config filter.argc.smudge "./argc.sh %f --myword" &&
> + rm $norm "$spec" &&
> + git checkout -- $norm "$spec" &&
> +
> + # make sure argc.sh counted the right number of args
> + echo "argc: 2 $norm --myword" > res &&
> + cmp res $norm &&
> + echo "argc: 2 $spec --myword" > res &&
> + cmp res "$spec" &&
Probably would be clearer if this were a separate test assertion.
> + :
> +'
> +
> test_done
Thanks for the tests. I haven't looked at the substance, alas,
but hope that helps nonetheless.
Jonathan
[1] Trumped up justification for the "no space after >" style: if I
always include a space after, I would be tempted to use
noisy_command > /dev/null 2> &1
But that does not work because >& is recognized as a single token.
^ permalink raw reply
* Re: 'show' pretty %B without a diff
From: Jonathan Nieder @ 2010-12-21 18:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Vereshagin, Junio C Hamano, git
In-Reply-To: <m38vzjl1yr.fsf@localhost.localdomain>
Jakub Narebski wrote:
> I guess that `-s' should be present also in git-show manpage.
It is mentioned in the examples section since v1.7.3.3~42. That
manpage needs a rework in general, though.
> There is also `git log -1` (or `git log -1 --no-walk` for paranoid).
Or even "git diff-tree -s --pretty=%B <commit>" if that is the intent.
As much as a person might dislike plumbing, plumbing is git's current
stable API. Maybe the libgit2 project will come up with something
better[1]. Until then, I am happy to have some commands that avoid
user-friendliness niceties (like implied "HEAD") that would create
pitfalls when scripting.
Maybe it would be worth adding a plumbing example under the EXAMPLES
for each porcelain? I can see that having to learn a second set of
commands might make life hard (like scripting in the bourne shell
when one is a csh user).
[1] I am pessimistic since that project has not made itself very
visible for feedback from the git list or submitted changes back to
git. It would be great to be surprised.
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Junio C Hamano @ 2010-12-21 17:50 UTC (permalink / raw)
To: Thiago Farina
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, Johannes Sixt, Drew Northup,
Vasyl', git
In-Reply-To: <AANLkTikvV1chYnSJUMGGoHTFv8EaXuK5B7Vo71jVyTRy@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> Maybe I'm missing something, or I'm confused (or I do not understand
> what I'm reading), but how you are assign routine to do_nothing if you
> have removed do_nothing above?
Apply the patch and read the first twenty lines of resulting wrapper.c
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Thiago Farina @ 2010-12-21 17:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, Johannes Sixt, Drew Northup, Vasyl',
git
In-Reply-To: <7vbp4f9gzh.fsf@alter.siamese.dyndns.org>
On Tue, Dec 21, 2010 at 3:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> This is pretty much a clean-up patch from my perspective. Do we really
>> need two paragraph explanation for marking a function static?
>
> I've already applied it, but I think it is much better to do this instead
> (on top of Vasyl' Vavrychuk's patch).
>
> A more interesting topic is why the try-to-free-pack-memory logic needs to
> be disabled in the first place. 3a09425 (Do not call release_pack_memory
> in malloc wrappers when GIT_TRACE is used, 2010-05-08) explains that it is
> to avoid a race on Windows, and it looks like a workaround not a solution
> ("can be called without locking"---"why aren't we locking then?").
>
> Not that it matters in the context of "trace", which is a debugging
> facility, that this is a workaround.
>
> -- >8 --
> Subject: set_try_to_free_routine(NULL) means "do nothing special"
>
> This way, the next caller that wants to disable our memory reclamation
> machinery does not have to define its own do_nothing() stub.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> trace.c | 8 ++------
> wrapper.c | 2 ++
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/trace.c b/trace.c
> index 62586fa..0fb2a2c 100644
> --- a/trace.c
> +++ b/trace.c
> @@ -25,10 +25,6 @@
> #include "cache.h"
> #include "quote.h"
>
> -static void do_nothing(size_t unused)
> -{
> -}
> -
> /* Get a trace file descriptor from GIT_TRACE env variable. */
> static int get_trace_fd(int *need_close)
> {
> @@ -76,7 +72,7 @@ void trace_printf(const char *fmt, ...)
> if (!fd)
> return;
>
> - set_try_to_free_routine(do_nothing); /* is never reset */
> + set_try_to_free_routine(NULL); /* is never reset */
> strbuf_init(&buf, 64);
> va_start(ap, fmt);
> len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
> @@ -108,7 +104,7 @@ void trace_argv_printf(const char **argv, const char *fmt, ...)
> if (!fd)
> return;
>
> - set_try_to_free_routine(do_nothing); /* is never reset */
> + set_try_to_free_routine(NULL); /* is never reset */
> strbuf_init(&buf, 64);
> va_start(ap, fmt);
> len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
> diff --git a/wrapper.c b/wrapper.c
> index 4c1639f..8d7dd31 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -12,6 +12,8 @@ static void (*try_to_free_routine)(size_t size) = do_nothing;
> try_to_free_t set_try_to_free_routine(try_to_free_t routine)
> {
> try_to_free_t old = try_to_free_routine;
> + if (!routine)
> + routine = do_nothing;
Maybe I'm missing something, or I'm confused (or I do not understand
what I'm reading), but how you are assign routine to do_nothing if you
have removed do_nothing above?
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Junio C Hamano @ 2010-12-21 17:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Johannes Sixt
Cc: Drew Northup, Thiago Farina, Vasyl', git
In-Reply-To: <AANLkTinL6RytF=x7a8URoxGQoLHhx0ip7gRNMp+nRaNB@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> This is pretty much a clean-up patch from my perspective. Do we really
> need two paragraph explanation for marking a function static?
I've already applied it, but I think it is much better to do this instead
(on top of Vasyl' Vavrychuk's patch).
A more interesting topic is why the try-to-free-pack-memory logic needs to
be disabled in the first place. 3a09425 (Do not call release_pack_memory
in malloc wrappers when GIT_TRACE is used, 2010-05-08) explains that it is
to avoid a race on Windows, and it looks like a workaround not a solution
("can be called without locking"---"why aren't we locking then?").
Not that it matters in the context of "trace", which is a debugging
facility, that this is a workaround.
-- >8 --
Subject: set_try_to_free_routine(NULL) means "do nothing special"
This way, the next caller that wants to disable our memory reclamation
machinery does not have to define its own do_nothing() stub.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
trace.c | 8 ++------
wrapper.c | 2 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/trace.c b/trace.c
index 62586fa..0fb2a2c 100644
--- a/trace.c
+++ b/trace.c
@@ -25,10 +25,6 @@
#include "cache.h"
#include "quote.h"
-static void do_nothing(size_t unused)
-{
-}
-
/* Get a trace file descriptor from GIT_TRACE env variable. */
static int get_trace_fd(int *need_close)
{
@@ -76,7 +72,7 @@ void trace_printf(const char *fmt, ...)
if (!fd)
return;
- set_try_to_free_routine(do_nothing); /* is never reset */
+ set_try_to_free_routine(NULL); /* is never reset */
strbuf_init(&buf, 64);
va_start(ap, fmt);
len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
@@ -108,7 +104,7 @@ void trace_argv_printf(const char **argv, const char *fmt, ...)
if (!fd)
return;
- set_try_to_free_routine(do_nothing); /* is never reset */
+ set_try_to_free_routine(NULL); /* is never reset */
strbuf_init(&buf, 64);
va_start(ap, fmt);
len = vsnprintf(buf.buf, strbuf_avail(&buf), fmt, ap);
diff --git a/wrapper.c b/wrapper.c
index 4c1639f..8d7dd31 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -12,6 +12,8 @@ static void (*try_to_free_routine)(size_t size) = do_nothing;
try_to_free_t set_try_to_free_routine(try_to_free_t routine)
{
try_to_free_t old = try_to_free_routine;
+ if (!routine)
+ routine = do_nothing;
try_to_free_routine = routine;
return old;
}
^ permalink raw reply related
* "git pull" doesn't respect --work-tree parameter
From: Alexey Zakhlestin @ 2010-12-21 16:04 UTC (permalink / raw)
To: git
I am trying to use the following command:
git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
and get this error:
"git-pull cannot be used without a working tree"
I get the same error, if I try to use corresponding environment variables
looks like a bug, because I can, successfully, use "git status" with
the same --git-dir and --work-tree parameters
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Thiago Farina @ 2010-12-21 15:59 UTC (permalink / raw)
To: Drew Northup; +Cc: Vasyl', git
In-Reply-To: <1292934581.26698.14.camel@drew-northup.unet.maine.edu>
On Tue, Dec 21, 2010 at 10:29 AM, Drew Northup <drew.northup@maine.edu> wrote:
> While I think the code change is fairly clear, as I said earlier: without a commit message we don't have
> a good reason for not making it non-static again later on, flip-flopping
> ad-infinitum.
>
Why you are complain about a one word change at all? Are you the
maintainer? Are you going to make a change that uses do_nothing in
future? If for some reason someone needs to use this function in other
place, the problem is of this person not you, he you will have to
argue and defend his change for whatever reasons he has, and will be a
problem for the maintainer not for you.
> Commit messages for isolated changes such as this build up a story, if
> you will, providing future contributors with insight as to why the group
> made a change when it did--even when the change is minor (in fact often
> most importantly when the change is minor)--by putting it in context.
>
We all know that, and Junio is doing a good job enforcing GOOD commit
messages. But in this case this is STUPID in my pov (others can and
probably will disagree with me, but I don't care).
>> > Alas the best way to avoid such a situation is to explain why a change
>> > was made to begin with.
>> >
>>
>> So, you are welcome to contribute and suggest such description for
>> this trivial (that may break non-trivial things) patch. So we can
>> please you and others in the future.
>
> As I am complaining that I don't know what the submitter was thinking
> that sounds particularly odd to me. How I am supposed to describe for
> the group what the commit's author was thinking in a commit message that
> I would like to see added to a patch when in fact the whole problem is
> that I don't know specifically what he was thinking?
Well, what the hell we are talking about so? If you are arguing for a
commit message, I would expect that you would have a suggestion, at
least to show why you are so interested in this particular patch.
And many contributors here, besides suggesting BETTER commit messages,
they help others with how the patch could be written, and you are not
helping in either way.
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Drew Northup @ 2010-12-21 15:19 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Thiago Farina, Vasyl', git
In-Reply-To: <AANLkTinL6RytF=x7a8URoxGQoLHhx0ip7gRNMp+nRaNB@mail.gmail.com>
On Tue, 2010-12-21 at 21:52 +0700, Nguyen Thai Ngoc Duy wrote:
> On Mon, Dec 20, 2010 at 11:53 PM, Drew Northup <drew.northup@maine.edu> wrote:
> Yeah I would expect somebody reverting this patch _if_ this function
> is useful outside trace.c again. On the other hand, this patch saves
> do_nothing from global namespace so somewhere, some time, somebody can
> use it.
>
> This is pretty much a clean-up patch from my perspective. Do we really
> need two paragraph explanation for marking a function static?
No, but 1 sentence would be dandy.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Nguyen Thai Ngoc Duy @ 2010-12-21 14:52 UTC (permalink / raw)
To: Drew Northup; +Cc: Thiago Farina, Vasyl', git
In-Reply-To: <1292863989.19322.27.camel@drew-northup.unet.maine.edu>
On Mon, Dec 20, 2010 at 11:53 PM, Drew Northup <drew.northup@maine.edu> wrote:
>> Why such trivial thing needs further explanation?
>
> Because even trivial fixes may break non-trivial things.
The only thing it could break is compilation.
> In addition, without justification we'd just as soon have somebody come
> back with another patch six months down the road that changes it back to
> the original code. Now that wouldn't make a whole lot of sense, now
> would it?
Yeah I would expect somebody reverting this patch _if_ this function
is useful outside trace.c again. On the other hand, this patch saves
do_nothing from global namespace so somewhere, some time, somebody can
use it.
This is pretty much a clean-up patch from my perspective. Do we really
need two paragraph explanation for marking a function static?
--
Duy
^ permalink raw reply
* git-cvsimport is setting incorrect timestamps in the master reflog
From: Bobby Eickhoff @ 2010-12-21 14:18 UTC (permalink / raw)
To: git
When I run git-cvsimport, the timestamps that it shows in the reflog
for refs/heads/master do not reflect the actual times that the ref is
updated but rather reflect commit times in CVS.
In fact, it looks as if the reflog timestamp is always set to the
timestamp of the last patch appearing in the cvsps cache, regardless
of what branch that patch affects and regardless of when the actual
update to the local "master" ref took place.
Until yesterday, I was using git version 1.7.2.3, and as of yesterday
I upgraded to git version 1.7.3.3, which is currently the highest
version offered by Cygwin. Both versions exhibit this behavior.
^ permalink raw reply
* Re: Rebasing multiple branches
From: Johannes Sixt @ 2010-12-21 14:06 UTC (permalink / raw)
To: Leonid Podolny; +Cc: git
In-Reply-To: <4D10AE5B.2080700@gmail.com>
Am 12/21/2010 14:40, schrieb Leonid Podolny:
> B--o--o--o--o--o--o <--branch A
> / \
> o--o--A--o--E <--master C--o--o--o--D <--branch C
> \ /
> C--o--o--o--o--o--o <--branch B
>
> I would like to rebase all three branches A, B and C onto commit E,...
git rebase master A
git rebase master B
git merge A
git rebase -i HEAD C
The last rebase I propose as interactive so that you can remove those
commits before D~3 that you have already rebased, because they are likely
to conflict unnecessarily, and you would --skip them anyway.
(Note: "C" is the branch C, not the commit C. Please make labels
unambiguous next time.)
-- Hannes
^ permalink raw reply
* [PATCH v3] convert filter: supply path to external driver
From: Pete Wyckoff @ 2010-12-21 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <7v8vzkcol8.fsf@alter.siamese.dyndns.org>
Filtering to support keyword expansion may need the name of
the file being filtered. In particular, to support p4 keywords
like
$File: //depot/product/dir/script.sh $
the smudge filter needs to know the name of the file it is
smudging.
Add a "%f" conversion specifier to the gitattribute for filter.
It will be expanded with the path name to the file when invoking
the external filter command. The path name is quoted and
special characters are escaped to prevent the shell from splitting
incorrectly.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
gitster@pobox.com wrote on Mon, 20 Dec 2010 09:59 -0800:
> Another nitpick is if 's' is the right letter to use for the pathname
> information. I think you took 's' after "string", but if this is to be
> extensible, you should anticipate that later there will be other kinds of
> information you may want to throw at the filters, and expect that some of
> them also will be of type "string", and you will have painted the person
> who wants to add that new information into a tight corner as you already
> took the valuable 's'.
>
> Which would suggest that you shouldn't be naming the placeholder after the
> type but after what the placeholder means, no? Perhaps %f (for filename)
> would be a better choice?
Agree. The "s" doesn't convey much meaning. Nothing in
pretty-formats.txt really applies either, but "f" makes sense.
-- Pete
Documentation/gitattributes.txt | 12 ++++++++++
convert.c | 22 +++++++++++++++++-
t/t0021-conversion.sh | 47 +++++++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 564586b..1afcf01 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -317,6 +317,18 @@ command is "cat").
smudge = cat
------------------------
+If your filter needs the path of the file it is working on,
+you can use the "%f" conversion specification. It will be
+replaced with the relative path to the file. This is important
+for keyword substitution that depends on the name of the
+file. Like this:
+
+------------------------
+[filter "p4"]
+ clean = git-p4-filter --clean %f
+ smudge = git-p4-filter --smudge %f
+------------------------
+
Interaction between checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/convert.c b/convert.c
index e41a31e..8f020bc 100644
--- a/convert.c
+++ b/convert.c
@@ -317,6 +317,7 @@ struct filter_params {
const char *src;
unsigned long size;
const char *cmd;
+ const char *path;
};
static int filter_buffer(int in, int out, void *data)
@@ -329,7 +330,23 @@ static int filter_buffer(int in, int out, void *data)
int write_err, status;
const char *argv[] = { NULL, NULL };
- argv[0] = params->cmd;
+ /* apply % substitution to cmd */
+ struct strbuf cmd = STRBUF_INIT;
+ struct strbuf path = STRBUF_INIT;
+ struct strbuf_expand_dict_entry dict[] = {
+ "f", NULL,
+ NULL, NULL,
+ };
+
+ /* quote the path to preserve spaces, etc. */
+ sq_quote_buf(&path, params->path);
+ dict[0].value = path.buf;
+
+ /* expand all %f with the quoted path */
+ strbuf_expand(&cmd, params->cmd, strbuf_expand_dict_cb, &dict);
+ strbuf_release(&path);
+
+ argv[0] = cmd.buf;
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -349,6 +366,8 @@ static int filter_buffer(int in, int out, void *data)
status = finish_command(&child_process);
if (status)
error("external filter %s failed %d", params->cmd, status);
+
+ strbuf_release(&cmd);
return (write_err || status);
}
@@ -376,6 +395,7 @@ static int apply_filter(const char *path, const char *src, size_t len,
params.src = src;
params.size = len;
params.cmd = cmd;
+ params.path = path;
fflush(NULL);
if (start_async(&async))
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 828e35b..534a735 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -93,4 +93,51 @@ test_expect_success expanded_in_repo '
cmp expanded-keywords expected-output
'
+cat <<EOF >argc.sh
+#!$SHELL_PATH
+echo argc: \$# "\$@"
+echo argc running >&2
+EOF
+chmod +x argc.sh
+
+#
+# The use of %f in a filter definition is expanded to the path to
+# the filename being smudged or cleaned. It must be shell escaped.
+#
+test_expect_success 'shell-escaped filenames' '
+ norm=name-no-magic &&
+ spec=$(echo name:sgl\"dbl\ spc!bang | tr : \\047) &&
+ echo some test text > test
+ cat test > $norm &&
+ cat test > "$spec" &&
+ git add $norm &&
+ git add "$spec" &&
+ git commit -m "add files" &&
+
+ echo "name* filter=argc" > .gitattributes &&
+
+ # delete the files and check them out again, using the smudge filter
+ git config filter.argc.smudge "./argc.sh %f" &&
+ rm $norm "$spec" &&
+ git checkout -- $norm "$spec" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 1 $norm" > res &&
+ cmp res $norm &&
+ echo "argc: 1 $spec" > res &&
+ cmp res "$spec" &&
+
+ # %f with other args
+ git config filter.argc.smudge "./argc.sh %f --myword" &&
+ rm $norm "$spec" &&
+ git checkout -- $norm "$spec" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 2 $norm --myword" > res &&
+ cmp res $norm &&
+ echo "argc: 2 $spec --myword" > res &&
+ cmp res "$spec" &&
+ :
+'
+
test_done
--
1.7.2.3
^ permalink raw reply related
* Rebasing multiple branches
From: Leonid Podolny @ 2010-12-21 13:40 UTC (permalink / raw)
To: git
Hi,
I need to rebase a rather complicated formation of branches.
My situation is like this (I hope ASCII graphics survive the sending):
B--o--o--o--o--o--o <--branch A
/ \
o--o--A--o--E <--master C--o--o--o--D <--branch C
\ /
C--o--o--o--o--o--o <--branch B
I would like to rebase all three branches A, B and C onto commit E, and
it's very important to keep the information about merges. For instance,
if I take commit C and rebase it onto D, it serializes all the
intermediate commits.
The only solution I managed to come up with is as follows:
- Take branch A and rebase it onto D (branch A').
- Same with branch B.
- Open a new branch C' from commit E.
- Merge A' and B' into C'.
- Manually cherry-pick all commits from commit C to commit D into branch C'.
The last step is way too ugly to be the only possible solution :)
^ permalink raw reply
* Re: Commiting automatically (2)
From: Jakub Narebski @ 2010-12-21 13:06 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <loom.20101221T092948-59@post.gmane.org>
Please try to not cull Cc list (use 'reply via email', if possible)
Maaartin <grajcar1@seznam.cz> writes:
> I let the snapshot point to the current head, which is where I get a problem now:
>
> git show-ref HEAD
>
> returns nothing,
>
> git show-ref --head
>
> returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD
> reference? I'm using git version 1.7.2.3 on cygwin.
You can use `git rev-parse --verify HEAD`, for example. Generally
scripted commands (including those in contrib/examples/) are good
sources of inspiration. Or if you want symbolic name, you can use
`git symbolic-ref HEAD` or `git rev-parse --symbolic-full-name HEAD`.
As for `git show-ref HEAD` - git-show-ref uses its own way of pattern
matching; in new enough version of git-show-ref manpage you can read
that:
<pattern>...::
Show references matching one or more patterns. Patterns are matched from
the end of the full name, and only complete parts are matched, e.g.
'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
'refs/remotes/master/jedi'.
So `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`,
but not `HEAD` which is outside `refs/`.
I tripped over strange git-show-ref <pattern> semantic too.
P.S. there is also git-for-each-ref.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: 'show' pretty %B without a diff
From: Jakub Narebski @ 2010-12-21 12:56 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: Junio C Hamano, git
In-Reply-To: <20101221104641.GA8600@external.screwed.box>
Peter Vereshagin <peter@vereshagin.org> writes:
> 2010/12/20 10:05:16 -0800 Junio C Hamano <gitster@pobox.com> => To Peter Vereshagin :
> JCH> If your script is _not_ parsing the git command output, but is just
> JCH> blindly spewing it out to the invoking user, it is Ok to use "show",
> JCH> though. Check "-s" option to the "show" command in that case.
>
> "show" command doesn't seem to have "-s" switch. Skip it up though ;-)
Hmmm... true, unfortunately it is described in hidden corner: when
git-show is used to display commits, it accepts diff family
options... including `-s' described in git-diff-tree manpage:
-s::
By default, 'git diff-tree --stdin' shows differences,
either in machine-readable form (without '-p') or in patch
form (with '-p'). This output can be suppressed. It is
only useful with '-v' flag.
-v::
This flag causes 'git diff-tree --stdin' to also show
the commit message before the differences.
I guess that `-s' should be present also in git-show manpage.
There is also `git log -1` (or `git log -1 --no-walk` for paranoid).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Drew Northup @ 2010-12-21 12:29 UTC (permalink / raw)
To: Thiago Farina; +Cc: Vasyl', git
In-Reply-To: <AANLkTin2QuMF93RqrRcScxvkzhU4OFJ9Nt42tV+FOjxS@mail.gmail.com>
On Mon, 2010-12-20 at 22:28 -0200, Thiago Farina wrote:
> On Mon, Dec 20, 2010 at 2:53 PM, Drew Northup <drew.northup@maine.edu> wrote:
> >
> > On Mon, 2010-12-20 at 13:17 -0200, Thiago Farina wrote:
> >> On Mon, Dec 20, 2010 at 10:00 AM, Drew Northup <drew.northup@maine.edu> wrote:
> >> >
> >> > On Thu, 2010-12-16 at 21:43 -0200, Thiago Farina wrote:
> >> >> On Thu, Dec 16, 2010 at 8:38 PM, Vasyl' <vvavrychuk@gmail.com> wrote:
> >> >> > Signed-off-by: Vasyl' Vavrychuk <vvavrychuk@gmail.com>
> >> >> > ---
> >> >> > trace.c | 2 +-
> >> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >> >
> >> >> > diff --git a/trace.c b/trace.c
> >> >> > index 1e560cb..62586fa 100644
> >> >> > --- a/trace.c
> >> >> > +++ b/trace.c
> >> >> > @@ -25,7 +25,7 @@
> >> >> > #include "cache.h"
> >> >> > #include "quote.h"
> >> >> >
> >> >> > -void do_nothing(size_t unused)
> >> >> > +static void do_nothing(size_t unused)
> >> >> > {
> >> >> > }
> >> >> >
> >> >> If it means something, this looks sane to me.
> >> >>
> >> >> Acked-by: Thiago Farina <tfransosi@gmail.com>
> >> >
> >> > It may be sane, but why should we trust that it is without a commit
> >> > message?
> >>
> >> Why such trivial thing needs further explanation?
> >
> > Because even trivial fixes may break non-trivial things.
> > In addition, without justification we'd just as soon have somebody come
> > back with another patch six months down the road that changes it back to
> > the original code. Now that wouldn't make a whole lot of sense, now
> > would it?
>
> I don't think so, it's making the function private, because the
> function is used only in that file and as such if you see a function
> marked as static you know that and doesn't need further explanation in
> my pov (but it seems you don't think like that).
All the patch above does is tell the compiler to enforce compilation of
that function as static. That is most definitely not the same thing as
making it private. (I think we can agree that it is being used as if it
were being enforced as private at some meta-level, but the compiler
isn't going to enforce it for us...) While I think the code change is
fairly clear, as I said earlier: without a commit message we don't have
a good reason for not making it non-static again later on, flip-flopping
ad-infinitum.
Commit messages for isolated changes such as this build up a story, if
you will, providing future contributors with insight as to why the group
made a change when it did--even when the change is minor (in fact often
most importantly when the change is minor)--by putting it in context.
> > Alas the best way to avoid such a situation is to explain why a change
> > was made to begin with.
> >
>
> So, you are welcome to contribute and suggest such description for
> this trivial (that may break non-trivial things) patch. So we can
> please you and others in the future.
As I am complaining that I don't know what the submitter was thinking
that sounds particularly odd to me. How I am supposed to describe for
the group what the commit's author was thinking in a commit message that
I would like to see added to a patch when in fact the whole problem is
that I don't know specifically what he was thinking? "Changed function
to static for no known reason whatsoever" isn't much of a commit
message.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: 'show' pretty %B without a diff
From: Peter Vereshagin @ 2010-12-21 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4oa8cobn.fsf@alter.siamese.dyndns.org>
You know St. Peter won't call my name, Junio!
2010/12/20 10:05:16 -0800 Junio C Hamano <gitster@pobox.com> => To Peter Vereshagin :
JCH> > JCH> Especially if you are doing a script, you probably should be using
JCH> > JCH> "cat-file commit" anyway, no?
JCH> >
JCH> > cat-file doesn't seem to support formatting option?
JCH>
JCH> That is exactly why I suggested "cat-file", as you are scripting. We
JCH> reserve the right to change the human-visible formatting output from
JCH> Porcelain commands like "show" any time to make it "prettier" (we may
JCH> start coloring strings that look like object names in the commit log
JCH> message in "git show" output, for example), while giving scripts more
JCH> stable output through the plumbing commands like "cat-file" so that they
JCH> can parse and process without having to worry about the output format
JCH> changing under them.
IMHO there is a difference between coloring the output and digging the data
from the storage, the what is the %B is about for me.
In a context of a script I believe every scriptwriter should expect a function
like get_comment_raw( $commitId ) than to worry about command output stability.
This is just where I believe the Git.pm will get closer to. One day.
No matter if such a function should look more like this: $gitObject->newById(
$commitId )->showDetails( '%B' ); . The I/O operations for this I believe
should be the storage files opening and reading, thus the piping from commands
like 'cat-file' is only the temporary solution.
Isn't it?
For the applications such an API approach is just more expectable than
porcelain versus plumbing commands. Although this requires care about features
like the particular (e.g., Perl) bindings, it is a must for the applications
efficiency which is a sense for a modern web at least.
JCH> If your script is _not_ parsing the git command output, but is just
JCH> blindly spewing it out to the invoking user, it is Ok to use "show",
JCH> though. Check "-s" option to the "show" command in that case.
"show" command doesn't seem to have "-s" switch. Skip it up though ;-)
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply
* Re: Commiting automatically (2)
From: Maaartin @ 2010-12-21 8:36 UTC (permalink / raw)
To: git
In-Reply-To: <20101220073312.GA23482@nibiru.local>
Enrico Weigelt <weigelt <at> metux.de> writes:
> * Maaartin <grajcar1 <at> seznam.cz> wrote:
>
> > Yes, I wonder why it wasn't already implemented. I do something like
> > make all; git snapshot; send_the_executable_to_the_customer
> > which is IMHO needed quite often.
>
> Perhaps it's wise to just use a separate repository on the same
> repository. Maybe make it more convenient using some little
> shell functions. I'm also using that for backup purposes, where
> the repo lies outside the to-be-backed-up tree.
I considered using a separate repository, too, but having "all in one" feels
somehow better. It allows me to push everything to a single remote repo and
compare the snapshots to ordinal commits, etc.
I let the snapshot point to the current head, which is where I get a problem now:
git show-ref HEAD
returns nothing,
git show-ref --head
returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD
reference? I'm using git version 1.7.2.3 on cygwin.
^ permalink raw reply
* Re: Performance issue exposed by git-filter-branch
From: Ken Brownfield @ 2010-12-21 4:59 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTi=eWaaGKGpUptdkVg5iEMiZK5FQ9URjUTgd+LxB@mail.gmail.com>
Filename lengths: min 4 avg 50 median 51 max 178
Directory depths: min 1 avg 5 median 6 max 13
Pretty standard Python naming/hierarchy, really.
Thanks!
Ken
On Dec 17, 2010, at 5:01 AM, Nguyen Thai Ngoc Duy wrote:
> On Fri, Dec 17, 2010 at 8:07 AM, Ken Brownfield <krb@irridia.com> wrote:
>> cache_name_compare (and the presumed follow-ons of memcpy/sha/malloc/etc) is the major consumer.
>
> Other people have given you alternative approaches. I'm just wondering
> if we can improve something here. cache_name_compare() is essentially
> memcmp() on two full paths. A tree-based index might help. How long
> are your file names on average? Are your trees deep?
> --
> Duy
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Performance issue exposed by git-filter-branch
From: Ken Brownfield @ 2010-12-21 4:49 UTC (permalink / raw)
To: git
In-Reply-To: <m3lj4sll39.fsf@localhost.localdomain>
This does pretty much exactly what I want (and a lot more), but reposurgeon is now over three days into reading the fast-export stream at 100% CPU. My guess is that it's about 30% done.
It does look like a great tool for smaller repositories.
Thanks for the suggestion, though! It looks like git_fast_filter is my next stop.
Ken
On Dec 16, 2010, at 6:51 PM, Jakub Narebski wrote:
> Please do not toppost.
>
> Ken Brownfield <krb@irridia.com> writes:
>
>> I had considered this approach (and the one mentioned by Jonathan)
>> but there are no git tools to actually perform the filter I wanted
>> on the export in this form. I could (and will) parse fast-export
>> and make an attempt a filtering files/directories... my concern is
>> that I won't do it right, and will introduce subtle corruption. But
>> if there's no existing tool, I'll take a crack at it. :-)
>
> You can try ESR's reposurgeon:
>
> http://www.catb.org/~esr/reposurgeon/
>
> It's limitation is that it loads structure of DAG of revisions (but
> not blobs i.e. contents of file) to memory. IIRC. It is not
> streaming, but "DOM" based, otherwise some commands would not work.
>
>
> By the way, git-filter-branch documentation recomments to use
> index-filter with git-update-index instead of tree-filter with git-rm,
> and if tree-filter is needed, to use some fast filesystem, e.g. RAM
> one.
>
> But probably you know all that.
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Basic Git Questions
From: Adam Kellas @ 2010-12-21 2:59 UTC (permalink / raw)
To: git
In-Reply-To: <20101220192152.4509.qmail@science.horizon.com>
On 12/20/2010 2:21 PM, George Spelvin wrote:
> 1) .gitignore. If the files are such that you never want git to pay
> attention to them, you can add them to the .gitignore file.
My own preferred pattern is to flip the default: I put a '*' in
.gitignore and use "add -f" when I want files tracked.
AK
^ permalink raw reply
* Re: [PATCH v2] completion: add missing configuration variables
From: Junio C Hamano @ 2010-12-21 1:22 UTC (permalink / raw)
To: Martin von Zweigbergk, Jeff King; +Cc: git
In-Reply-To: <20101220212018.GA18503@sigill.intra.peff.net>
Will queue with the Ack from peff; thanks, both.
^ permalink raw reply
* Re: [PATCH/RFC] ident: die on bogus date format
From: Junio C Hamano @ 2010-12-21 1:00 UTC (permalink / raw)
To: Jeff King; +Cc: Sergio, git
In-Reply-To: <7vei9ipusf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> After determine_author_info() returns to prepare_to_commit(), we have a
> call to git_committer_info() only to discard the outcome from....
> ... We can do this by
> adding a new parameter (strbuf) to prepare_to_commit(), I think.
Heh, I was an idiot, and mixed up author and committer in the above.
But I think it is worth trying to avoid asking the user to edit when
we know that a bad author ident will result in an error later.
How about doing it like this?
-- >8 --
Subject: commit: die before asking to edit the log message
When determine_author_info() returns to the calling prepare_to_commit(),
we already know the pieces of information necessary to determine what
author ident will be used in the final message, but deferred making a call
to fmt_ident() before the final commit_tree(). Most importantly, we would
open the editor to ask the user to compose the log message before it.
As one important side effect of fmt_ident() is to error out when the given
information is malformed, this resulted in us spawning the editor first
and then refusing to commit due to error, even though we had enough
information to detect the error before starting the editor, which was
annoying.
Move the fmt_ident() call to the end of determine_author_info() where we
have final determination of author info to rectify this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/commit.c | 54 ++++++++++++++++++++++++++++++++----------------------
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 66fdd22..3bcb4b7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -69,7 +69,6 @@ static enum {
static const char *logfile, *force_author;
static const char *template_file;
static char *edit_message, *use_message;
-static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int no_post_rewrite, allow_empty_message;
@@ -459,7 +458,7 @@ static int is_a_merge(const unsigned char *sha1)
static const char sign_off_header[] = "Signed-off-by: ";
-static void determine_author_info(void)
+static void determine_author_info(struct strbuf *author_ident)
{
char *name, *email, *date;
@@ -503,10 +502,8 @@ static void determine_author_info(void)
if (force_date)
date = force_date;
-
- author_name = name;
- author_email = email;
- author_date = date;
+ strbuf_addstr(author_ident, fmt_ident(name, email, date,
+ IDENT_ERROR_ON_NO_NAME));
}
static int ends_rfc2822_footer(struct strbuf *sb)
@@ -550,10 +547,21 @@ static int ends_rfc2822_footer(struct strbuf *sb)
return 1;
}
+static char *cut_ident_timestamp_part(char *string)
+{
+ char *ket = strrchr(string, '>');
+ if (!ket || ket[1] != ' ')
+ die("Malformed ident string: '%s'", string);
+ *++ket = '\0';
+ return ket;
+}
+
static int prepare_to_commit(const char *index_file, const char *prefix,
- struct wt_status *s)
+ struct wt_status *s,
+ struct strbuf *author_ident)
{
struct stat statbuf;
+ struct strbuf committer_ident = STRBUF_INIT;
int commitable, saved_color_setting;
struct strbuf sb = STRBUF_INIT;
char *buffer;
@@ -637,14 +645,13 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
strbuf_release(&sb);
- determine_author_info();
+ /* This checks and barfs if author is badly specified */
+ determine_author_info(author_ident);
/* This checks if committer ident is explicitly given */
- git_committer_info(0);
+ strbuf_addstr(&committer_ident, git_committer_info(0));
if (use_editor && include_status) {
- char *author_ident;
- const char *committer_ident;
-
+ char *ai_tmp, *ci_tmp;
if (in_merge)
fprintf(fp,
"#\n"
@@ -672,23 +679,21 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
- author_ident = xstrdup(fmt_name(author_name, author_email));
- committer_ident = fmt_name(getenv("GIT_COMMITTER_NAME"),
- getenv("GIT_COMMITTER_EMAIL"));
- if (strcmp(author_ident, committer_ident))
+ ai_tmp = cut_ident_timestamp_part(author_ident->buf);
+ ci_tmp = cut_ident_timestamp_part(committer_ident.buf);
+ if (strcmp(author_ident->buf, committer_ident.buf))
fprintf(fp,
"%s"
"# Author: %s\n",
ident_shown++ ? "" : "#\n",
- author_ident);
- free(author_ident);
+ author_ident->buf);
if (!user_ident_sufficiently_given())
fprintf(fp,
"%s"
"# Committer: %s\n",
ident_shown++ ? "" : "#\n",
- committer_ident);
+ committer_ident.buf);
if (ident_shown)
fprintf(fp, "#\n");
@@ -697,6 +702,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
s->use_color = 0;
commitable = run_status(fp, index_file, prefix, 1, s);
s->use_color = saved_color_setting;
+
+ *ai_tmp = ' ';
+ *ci_tmp = ' ';
} else {
unsigned char sha1[20];
const char *parent = "HEAD";
@@ -712,6 +720,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
else
commitable = index_differs_from(parent, 0);
}
+ strbuf_release(&committer_ident);
fclose(fp);
@@ -1246,6 +1255,7 @@ static int run_rewrite_hook(const unsigned char *oldsha1,
int cmd_commit(int argc, const char **argv, const char *prefix)
{
struct strbuf sb = STRBUF_INIT;
+ struct strbuf author_ident = STRBUF_INIT;
const char *index_file, *reflog_msg;
char *nl, *p;
unsigned char commit_sha1[20];
@@ -1273,7 +1283,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Set up everything for writing the commit object. This includes
running hooks, writing the trees, and interacting with the user. */
- if (!prepare_to_commit(index_file, prefix, &s)) {
+ if (!prepare_to_commit(index_file, prefix, &s, &author_ident)) {
rollback_index_files();
return 1;
}
@@ -1352,11 +1362,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
if (commit_tree(sb.buf, active_cache_tree->sha1, parents, commit_sha1,
- fmt_ident(author_name, author_email, author_date,
- IDENT_ERROR_ON_NO_NAME))) {
+ author_ident.buf)) {
rollback_index_files();
die("failed to write commit object");
}
+ strbuf_release(&author_ident);
ref_lock = lock_any_ref_for_update("HEAD",
initial_commit ? NULL : head_sha1,
^ permalink raw reply related
* Re: [PATCH] handle arbitrary ints in git_config_maybe_bool
From: Junio C Hamano @ 2010-12-21 0:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20101219033640.GA6889@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This function recently gained the ability to recognize the
> documented "0" and "1" values as false/true. However, unlike
> regular git_config_bool, it did not treat arbitrary numbers
> as true. While this is undocumented and probably ridiculous
> for somebody to rely on, it is safer to behave exactly as
> git_config_bool would. Because git_config_maybe_bool can be
> used to retrofit new non-bool values onto existing bool
> options, not behaving in exactly the same way is technically
> a regression.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This was posted earlier as part of the command-specific pager topic; you
> ended up splitting part of that out into jk/maint-decorate-01-bool. This
> should logically go on top of that (b2be2f6).
>
> It probably doesn't make a difference in the real world, but I think it
> is safer (as described above), and the code is a little cleaner. I
> should have just done it this way in the first place.
I'd reword "arbitrary numbers" to "arbitrary non-zero numbers".
Other than that, thanks for your attention to the details.
Will apply.
> config.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/config.c b/config.c
> index 32c0b2c..d73b090 100644
> --- a/config.c
> +++ b/config.c
> @@ -429,13 +429,11 @@ static int git_config_maybe_bool_text(const char *name, const char *value)
>
> int git_config_maybe_bool(const char *name, const char *value)
> {
> - int v = git_config_maybe_bool_text(name, value);
> + long v = git_config_maybe_bool_text(name, value);
> if (0 <= v)
> return v;
> - if (!strcmp(value, "0"))
> - return 0;
> - if (!strcmp(value, "1"))
> - return 1;
> + if (git_parse_long(value, &v))
> + return !!v;
> return -1;
> }
>
> --
> 1.7.3.4.761.g98ad5
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Junio C Hamano @ 2010-12-21 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <AANLkTinP4SArMkjvTXOEG=tf=8EcEdP9fPAB7F=iitSc@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I just noticed this, and I wonder if it has bitten me before without
> me noticing: "git am --abort" can be really dangerous.
>
> What happened today was that I had been doing a pull or two, and then
> applied an emailed patch with "git am" as usual. But as sometimes
> happens, I actually had a previous "git am" that had failed - in fact,
> it was the same patch that I applied today that had had an earlier
> version that no longer applied.
I never got into this as I use bash completion in my PS1 in the real life,
but I've seen this happen while playing around, and I can see myself
easily getting hurt by this behaviour without status in PS1.
> Maybe "git am" should actually save the last commit ID that it did,
> and only do the "reset" if the current HEAD matches the rebase-apply
> state and warns if it doesn't? Or maybe we could just introduce a new
> "git am --clean" that just flushes any old pending state (ie does that
> "clean_abort" thing, which is basically just the "rm -rf" I've done by
> hand). Or both?
I sometimes wanted "--clean" myself, so it is a no-brainer to decide that
it would be a good thing to add.
The last time I thought about this issue, I wasn't sure about "compare
with the last commit"---mostly because it wasn't clear what ramifications
it would have. When you get refusal from "am --abort", how would you
recover from it?
Back then my tentative conclusion was actually to get rid of "am --abort"
and give "am --clean", making the final "reset HEAD~$n" the responsiblity
of the user. But I forgot to pursue it.
^ permalink raw reply
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