* [ANNOUNCE] Git 1.7.7.6
From: Junio C Hamano @ 2012-01-19 1:14 UTC (permalink / raw)
To: git
An maintenance release Git 1.7.7.6 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
483dc95de0e26f0154fb23444589266b59848cfe git-1.7.7.6.tar.gz
8bcbd0a53fd3b937a9991aa096220a1a0eb2f771 git-htmldocs-1.7.7.6.tar.gz
0fd7452c88d0b3ccb08d9b2b91b552680b0209e0 git-manpages-1.7.7.6.tar.gz
Also the following public repositories all have a copy of the v1.7.7.6
tag and the maint-1.7.7 branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.7.6 Release Notes
==========================
Fixes since v1.7.7.5
--------------------
* The code to look up attributes for paths reused entries from a wrong
directory when two paths in question are in adjacent directories and
the name of the one directory is a prefix of the other.
* A wildcard that matches deeper hierarchy given to the "diff-index" command,
e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
matching files even when there is no change.
* When producing a "thin pack" (primarily used in bundles and smart
HTTP transfers) out of a fully packed repository, we unnecessarily
avoided sending recent objects as a delta against objects we know
the other side has.
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.7.5 are as follows:
Clemens Buchacher (1):
Documentation: read-tree --prefix works with existing subtrees
Jack Nagel (1):
Add MYMETA.json to perl/.gitignore
Jeff King (4):
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Jens Lehmann (1):
docs: describe behavior of relative submodule URLs
Junio C Hamano (8):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Git 1.7.7.6
Nguyễn Thái Ngọc Duy (2):
t2203: fix wrong commit command
diff-index: enable recursive pathspec matching in unpack_trees
Thomas Rast (1):
Documentation: rerere.enabled is the primary way to configure rerere
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-19 1:00 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Neal Kreitzinger, git
In-Reply-To: <4F1764B9.90907@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
>> Have you checked where in the filesystem hierarchy that script is run
>> (hint: pwd)?
>>
> echo pwd in post-update echoes /path/WORKTREE/.git in git-push stdout.
> ...
> 'git-checkout -f' works manually, but in post-update hook...
Stronger hint. Did you run "git checkout -f" in /path/WORKTREE/.git to
back that "works manually" claim?
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-19 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vwr8oljq7.fsf@alter.siamese.dyndns.org>
On 1/18/2012 4:38 PM, Junio C Hamano wrote:
> Neal Kreitzinger<nkreitzinger@gmail.com> writes:
>
>> hooks/post-update is:
>>
>> git stash save
>> echo "worktree+index of non-bare remote current branch stashed for safety"
>> git reset --hard
>> echo "git-reset --hard on current remote branch to ensure clean state"
>>
>> message is echoed, but git-reset --hard does not appear to have really
>> worked. (git 1.7.1)
>
> Have you checked where in the filesystem hierarchy that script is run
> (hint: pwd)?
>
echo pwd in post-update echoes /path/WORKTREE/.git in git-push stdout.
> Also it is unclear why you keep saying "stash". What kind of changes are
> you expecting to be saved to the stash? Will they be changes that are not
> source controlled that you would rather not to see? In other words, after
> running "stash" every time somebody pushes and having accumulated many
> stash entries, when do you plan to pop these stashed changes?
>
good point. rejection of dirty worktree is a cleaner safety.
> I would have expect that such a repository to reject a push if the working
> tree is dirty, and run checkout in post-update, though.
>
'git-checkout -f' works manually, but in post-update hook it leaves
behind dirty worktree, ie. index and HEAD match, but worktree still
matches HEAD@{1}. This is the same undesired result git-stash and
git-reset --hard leave behind when executed in post-update hook.
v/r,
neal
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: Jonathan Nieder @ 2012-01-19 0:29 UTC (permalink / raw)
To: Pete Harlan
Cc: Git Mailing List, Nguyễn Thái Ngọc Duy,
Shawn Bohrer
In-Reply-To: <4F1384AE.1050209@pcharlan.com>
(+cc: Duy, Shawn)
Hi,
Pete Harlan wrote:
> When a directory contains nothing but an ignored subdirectory, that
> subdirectory does not get removed by "git clean -Xdf".
>
> For example, in a new directory:
>
> # git init
> Initialized empty Git repository in /tmp/foo/.git/
> # echo a/ >.gitignore
> # git add .gitignore
> # git commit -m "Initial commit"
> [master (root-commit) c3af24c] Initial commit
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 .gitignore
> # mkdir -p foo/a
> # touch foo/a/junk.o
> # git status
> # On branch master
> nothing to commit (working directory clean)
> # git clean -Xdn # <--- DOES NOT MENTION foo/a
> # touch foo/x.c
> # git clean -Xdn # <--- DITTO WITH UNTRACKED IN foo
> # git add foo/x.c
> # git clean -Xdn # <--- WITH TRACKED IN foo, WILL REMOVE a/
> Would remove foo/a/
> #
>
> Is this intentional? It's interfering with my using "git clean" to
> remove built objects, which happen to be in a dedicated temporary
> subdirectory.
Sounds like a bug. Duy, Shawn, any hints?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-19 0:17 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
> ...
>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>> whether it works, or not.
>
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
You are right.
In the current approach we take for shell scripts, we cannot have "No i18n
whatsoever and messages are emit with printf and echo". We always have to
go through gettext/eval_gettext even though they may be an implementation
that does not do i18n at all.
> Now I haven't done exhaustive tests but this is the sort of slowdown
> we might be looking at on Linux for output,...
I think we judged that it is OK not to worry about the performance of
message generation, back when we decided to take the current approach.
> Anyway speed is the least of the issues here, it's not like we're very
> constrained by spewing out gettext output.
>
> I just think we should consider portability more carefully than "it
> doesn't work on one obscure setup, let's change it everywhere", when
> actually it's working just fine in most places.
> ...
> But in summary: We shouldn't be *always* using fallback functions
> whether they're the C stuff in compat/* or the gettext fallbacks in
> git-sh-i18n.sh just because there's some version out there of the
> system-supplied functions that's broken.
>
> It makes sense to prefer the system functions by default in both
> cases, but when the OS one can be broken or lacking we can just add
> probes or Makefile options like we do for fnmatch() with the
> NO_FNMATCH_CASEFOLD switch.
So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
that correct?
If that is the case, should we do something like
LANG=C LC_ALL=C
export LANG LC_ALL
in our shell scripts, when building for NO_GETTEXT target?
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Jonathan Nieder @ 2012-01-19 0:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Alex Riesen, Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
>
> This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
> and you want to change *everywhere* because you have some completely
> broken Cygwin install.
I thought NO_GETTEXT meant either "I'm aware that there is this new
translation feature, and it may or may not be useful to me some day,
but no thanks for now, since I cannot tolerate the possibility of
regressions" (i.e., opting out of a new feature) or "my platform does
not have suitable gettext infrastructure so please do not use it"
(i.e., reducing build-time dependencies by making some optional).
"I don't want localized messages" is spelled as "LC_MESSAGES=C; export
LC_MESSAGES", not as "make NO_GETTEXT=YesPlease".
I guess I am wondering, does the approach in Alex's patch have the
potential to cause actual problems? If it doesn't, I don't see what
there is to complain about.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Jonathan Nieder @ 2012-01-19 0:12 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20120118195438.GA18892@blimp.dmz>
Hi,
Alex Riesen wrote:
> [Subject: i18n: disable i18n for shell scripts if NO_GETTEXT define]
>
> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
> It is very unexpected.
Sounds like a good idea. Quick comments:
[...]
> --- a/git-sh-i18n.sh
> +++ b/git-sh-i18n.sh
> @@ -16,61 +16,44 @@ else
> fi
> export TEXTDOMAINDIR
>
> -if test -z "$GIT_GETTEXT_POISON"
> +GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
> +if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
> +then
> + : no probing necessary
> +elif test -n "$GIT_GETTEXT_POISON"
> then
> - if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
> - then
> +elif test -n type gettext.sh >/dev/null 2>&1
> +then
I like the unindenting. Alas, I get
1: test: type: unexpected operator
I suspect this should just say "elif type gettext.sh >/dev/null 2>&1".
The rest looks good. Thanks for writing it.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Ævar Arnfjörð Bjarmason @ 2012-01-18 23:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CALxABCadHdvR02Br9e6STy0w+EPoycUKr62RiSUSP_EPF-TH3g@mail.gmail.com>
On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Wed, Jan 18, 2012 at 16:22, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> On Tue, Jan 17, 2012 at 14:42, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
>>> It is very unexpected.
>>
>> So the reason it's like that is that I was assuming that gettext.sh
>> wouldn't be FUBAR anywhere, but the translations shouldn't kick in
>> since we haven't installed them during "make install".
>>
>> But I wonder if this negatively affects some systems, now we now:
>>
>> * Don't use gettext.sh, which means that we're using our fallback
>> shell function instead of the binary gettext(1), which is probably
>> faster.
>>
>> * Use our own eval_gettext() instead of using the system one, which
>> uses the GNU binary which is more likely to be in the FS cache
>> already since other programs are probably using it.
>>
>> Which is why I didn't do something like this to begin with.
>
> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
> whether it works, or not.
That's not what NO_GETTEXT means, and not what it *should* mean. It
means that your output won't be translated, but we might still make
use of a locally installed library to provide the gettext() and
eval_gettext() functions.
This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
and you want to change *everywhere* because you have some completely
broken Cygwin install.
How did you even get that install? Is it a known issue? Some ancient
now-fixed bug? What version of Cygwin / gettext etc.
Now I'm not saying that we shouldn't fix this, I just don't think that
this is the right way to go about it.
Now I haven't done exhaustive tests but this is the sort of slowdown
we might be looking at on Linux for output, both with warm cache:
$ cat our-eval_gettext.sh
#!/bin/bash
eval_gettext () {
printf "%s" "$1" | (
export PATH $(git sh-i18n--envsubst --variables "$1");
git sh-i18n--envsubst "$1"
)
}
for i in {1..1000}
do
some_variable="for speed"
eval_gettext "benchmark this \$some_variable"
done
$ time bash our-eval_gettext.sh >/dev/null
real 0m3.336s
user 0m0.052s
sys 0m0.128s
Compared to using the system eval_gettext, which for me is much
faster:
$ cat system-eval_gettext.sh
#!/bin/bash
. gettext.sh
for i in {1..1000}
do
some_variable="for speed"
eval_gettext "benchmark this \$some_variable"
done
$ time bash system-eval_gettext.sh >/dev/null
real 0m1.671s
user 0m0.048s
sys 0m0.140s
And then we have the gettext() function itself:
$ cat our-gettext.sh
#!/bin/bash
gettext () {
printf "%s" "$1"
}
for i in {1..1000}
do
gettext "benchmark this"
done
$ cat system-gettext.sh
#!/bin/bash
for i in {1..1000}
do
gettext "benchmark this"
done
Where our fallback is faster, because printf() is a bash built-in:
$ time bash system-gettext.sh >/dev/null
real 0m0.534s
user 0m0.016s
sys 0m0.084s
$ time bash our-gettext.sh >/dev/null
real 0m0.018s
user 0m0.016s
sys 0m0.000s
Anyway speed is the least of the issues here, it's not like we're very
constrained by spewing out gettext output.
I just think we should consider portability more carefully than "it
doesn't work on one obscure setup, let's change it everywhere", when
actually it's working just fine in most places.
I think a better fix would be to add probes for whether the system
functions actually work in the autoconf script.
I'd also love to be able to use C macros in the git-*.sh scripts, it
would make the code in git-sh-i18n.sh much nicer since we can
determine what functions we want at compile time.
Another option would be to pipe our shellscripts through some
pre-processor that would completely remove the gettext and
eval_gettext calls. Then we'd be doing the same thing we're doing on
the C-Level, and we wouldn't have the previously cited command-call
overhead or Win32.
But in summary: We shouldn't be *always* using fallback functions
whether they're the C stuff in compat/* or the gettext fallbacks in
git-sh-i18n.sh just because there's some version out there of the
system-supplied functions that's broken.
It makes sense to prefer the system functions by default in both
cases, but when the OS one can be broken or lacking we can just add
probes or Makefile options like we do for fnmatch() with the
NO_FNMATCH_CASEFOLD switch.
^ permalink raw reply
* Re: Checking out orphans with -f
From: Junio C Hamano @ 2012-01-18 23:12 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201201181550.23792.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> Actually, no I can't. I can check out some other branch
> (assuming I have one), but I cannot then delete a, it
> appears to already be deleted by virtue of checking out
> another branch. I like that since I never checked it in,
> better to clean up the garbage.
Good.
> ...but why can't I then
> checkout another orphan to do the same thing?
I am not surprised if the original contributor who wanted to add --orphan
did not address corner cases. It is very plausible that we did not try as
hard to nitpick the code for complete support of such corner cases as I
and other contributors usually do for more important features.
So... Patches welcome ;-)
Having said that, there are many things to consider to fill the corner
case you seem to be interested to add support for.
The "orphaned" state is like immediately after "git init". Because you do
not have any current commit, you cannot create an orphan branch based the
state immediately after "git init", either. You are nominally on your
'master' branch, but it does not have anything yet; you are expected to
turn it into a real branch by creating a commit soon, but until you do so,
you are kind of in-limbo. It is understandable that there will be many
operations that will not make any sense until you first get out of this
in-limbo state. For example, you cannot (and do not have to) delete the
branch and if you have a commit (e.g. you can fetch one from another
place) you can check it out and the 'master' will be gone, because you
never created it in the first place.
^ permalink raw reply
* Interesting behavior in git mergetool with no BASE revision
From: Jason Wenger @ 2012-01-18 23:05 UTC (permalink / raw)
To: git
Doing a git merge on 1.7.4.3, on a case where both branches have a
file created, and the base does not. Per git-mergetool:
"the configured command line will be invoked with $BASE set to the
name of a temporary file containing the common base for the merge, if
available;"
So testing in this case, I set my mergetool cmd as "echo $MERGED
$LOCAL $REMOTE $BASE", and I get the following:
cio/.cproject ./cio/.cproject.LOCAL.9029.cproject
./cio/.cproject.REMOTE.9029.cproject
./cio/.cproject.BASE.9029.cproject
ls -a cio shows the following files:
.cproject
.cproject.LOCAL.9325.cproject
.cproject.BACKUP.9325.cproject
.cproject.REMOTE.9325.cproject
So the lack of base file makes sense -- There is no base to start
from. However, $BASE evaluates to ./cio/.cproject.BASE.9029.cproject,
which is a nonexistent file. This makes my actual mergetool upset to
no end. Intuitively from documents, I would expect $BASE to evaluate
to an empty string in this case.
Is this intended behavior?
--Jason C. Wenger
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-18 22:56 UTC (permalink / raw)
To: Dieter Plaetinck; +Cc: git
In-Reply-To: <1326923544-8287-1-git-send-email-dieter@plaetinck.be>
Dieter Plaetinck <dieter@plaetinck.be> writes:
> There is no need to restrict use of --ignore-missing to dry runs,
> it can be useful to ignore missing files during normal operation as
> well.
>
> Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
Sorry, but for this kind of change, we would want to see a justification
that is much better than that. The default around here is not to change an
established behaviour without a good reason.
Have you dug into the list archive to see _why_ we decided not to allow
this option in the real run in the first place? You would need to find "By
letting the command ignore missing paths, the user can get into X and Y
situations and we would want to avoid it. We however need to give users a
way to see if there is something missing, hence we add it when we are
under dry-run option." and refute that previous justification, arguing why
X and Y is something we should _not_ be worrying about, to make a good
case for this change.
In this particular case, my gut feeling is that this might a change in the
good direction (but I strongly suspect that I am not recalling the real
reason why we didn't allow it when we introduced this option).
If somebody is writing a script using "git add" (which is not recommended
to begin with), it is tempting to say 'git add $list_of_possible_files' in
such a script when the script _knows_ that the list it is giving to "git
add" may contain a path that does not exist, and wants to ignore missing
ones.
But then the script could easily filter what does not exist before
compiling such a list, so that is not a very strong reason to advocate
it.
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > I am trying to write some scripts which do various
> > things to a git repo and I have run into a issue where
> > I think that git behavior with respect to orphan
> > branches is potentially
> >
> > undesirable. If I type:
> > git checkout --orphan a
> >
> > I cannot easily abandon this state
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
Actually, no I can't. I can check out some other branch
(assuming I have one), but I cannot then delete a, it
appears to already be deleted by virtue of checking out
another branch. I like that since I never checked it in,
better to clean up the garbage, but why can't I then
checkout another orphan to do the same thing?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: found some code...
From: Holger Hellmuth @ 2012-01-18 22:45 UTC (permalink / raw)
To: Ron Eggler; +Cc: Andrew Ardill, git
In-Reply-To: <CAHxBh_QiZzJP2jS6rMpC1c=P8uXSbFWumbcnHj3ArkQB4sXyPQ@mail.gmail.com>
Mmh, your reply here didn't make it to the mailing list, maybe because
it was multipart with html(??) or it just got lost.
Am 18.01.2012 18:57, schrieb Ron Eggler:
> Try "git update-index --refresh", more info in this recent thread
> "http://comments.gmane.org/__gmane.comp.version-control.__git/188291
> <http://comments.gmane.org/gmane.comp.version-control.git/188291>"
>
>
> I got this outputand nothing really changed(generally using TortoiseGit
> on Windows but did this in the provided bash shell):
> $ git update-index --refresh
> MCU2.COF.txt: needs update
> MCU2.bak: needs update
> MCU2.c: needs update
> MCU2.esym: needs update
> MCU2.h: needs update
> MCU2.hex: needs update
> MCU2.lst: needs update
> MCU2.mcp: needs update
[...]
Ok, "needs update" seems to be the non-porcelain version of 'M' (why 'M'
is more porcelain than "needs update" is a mystery to me ;-) respective
"Changes not staged for commit" in git status.
Well, what does it say when you do "git diff MCU2.h" ? There are 2
possibilities:
1) You see code differences. In that case you should be able to
recognize where and when these changes were comitted or not.
2) You see no difference or every line is listed as different even
though they seem to be equal. Possible reason is a mixup of line endings
as git on windows has to convert \r\n line endings to \n line endings
when it checks data in. This is controlled by config variables, and
maybe your config is slightly wrong.
In that case I would create a new repo with git init in bash (not
tortoise git!), and look at .git/config. Compare that with .git/config
of your mixed up repo. Also compare with .git/config of the repo on your
usb stick. As far as I know you should have core.autocrlf set to true on
Windows.
Alternatively or for a complete picture you could do "git config -l"
which gives you also global and system configuration variables if they
exist.
Another possible reason would be file names with same name but different
case. I mention this because there is a parallel thread on this mailing
list with a problem with tortoise git and windows. See
http://git.661346.n2.nabble.com/Bug-Git-checkout-fails-with-a-wrong-error-message-td7181244.html.
As suggested in that thread you should have the option core.ignorecase set.
> Ok ,let's see:
> I "found" the piece of code on my thumbdrive and it ultimately is copied
> from my "old" working directory from the computer i don't have
> anymore... "get create new local folders" means that I actually created
> a new folder on my new machine and cloned the repo from git into it so
> this would be my new working directory... now i have the code that
> should be in there seperatetely in the directory from the thumb drive....
> Does that make any more ssense?
>
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > I am trying to write some scripts which do various
> > things to a git repo and I have run into a issue where
> > I think that git behavior with respect to orphan
> > branches is potentially
> >
> > undesirable. If I type:
> > git checkout --orphan a
> >
> > I cannot easily abandon this state
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
By abandon, I simply mean to check out another branch, which
as you point, I can almost do. I just can't do it by
checking out another orphaned branch! Why not, this seems
inconsistent? In both cases I loose what the original
orphaned branch (a) is, so why prevent me from doing it in
the one case and not the other?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Checking out orphans with -f
From: Junio C Hamano @ 2012-01-18 22:40 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201201181207.05967.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> I am trying to write some scripts which do various things to
> a git repo and I have run into a issue where I think that
> git behavior with respect to orphan branches is potentially
> undesirable. If I type:
>
> git checkout --orphan a
>
> I cannot easily abandon this state
What do you mean by "abandon"?
If you want to remove a branch "a" because you do not need it, you can
check out some other branch and say "git branch -D a", no?
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-18 22:38 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Neal Kreitzinger, git
In-Reply-To: <4F1714AD.4090706@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> hooks/post-update is:
>
> git stash save
> echo "worktree+index of non-bare remote current branch stashed for safety"
> git reset --hard
> echo "git-reset --hard on current remote branch to ensure clean state"
>
> message is echoed, but git-reset --hard does not appear to have really
> worked. (git 1.7.1)
Have you checked where in the filesystem hierarchy that script is run
(hint: pwd)?
Also it is unclear why you keep saying "stash". What kind of changes are
you expecting to be saved to the stash? Will they be changes that are not
source controlled that you would rather not to see? In other words, after
running "stash" every time somebody pushes and having accumulated many
stash entries, when do you plan to pop these stashed changes?
I would have expect that such a repository to reject a push if the working
tree is dirty, and run checkout in post-update, though.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uqwmyt6.fsf@alter.siamese.dyndns.org>
On 12-01-18 05:27 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> It might be better to just move the footnote to the end of the next sentence.
>
> Ok. How does this version look? The highlights are:
>
> * remove footnotes and spell them out inline, like "Note that..."
>
> * "a single liner" -> "a one-liner"
IMO "one-liner" should be "one-line", but toMAYto toMAHto...
The rest looks good.
M.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Junio C Hamano @ 2012-01-18 22:27 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Junio C Hamano, git
In-Reply-To: <4F173C5D.7000802@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> It might be better to just move the footnote to the end of the next sentence.
Ok. How does this version look? The highlights are:
* remove footnotes and spell them out inline, like "Note that..."
* "a single liner" -> "a one-liner"
* "publishing repository" -> "public repository". I often use the former
when I want to differenciate a repository used to publish the work by a
single owner from a shared public repository, so technically the wording
could stay as-is, but I think it is clear that we mean publishing one
not a shared one from the context of this document.
* Drop the attempt to say "you would see these 'Good signature from...'
if and only if the signature verifies OK" altogether. It is clear from
the example that the signature was good.
* Replace the paragraph that explains there is no need to keep and
transfer signed tags for auditors with your version.
Thanks.
.../howto/using-signed-tag-in-pull-request.txt | 60 +++++++++----------
1 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
index efac088..a1351c5 100644
--- a/Documentation/howto/using-signed-tag-in-pull-request.txt
+++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
@@ -58,7 +58,7 @@ A contributor or a lieutenant
-----------------------------
After preparing her work to be pulled, the contributor uses `git tag -s`
-to create a signed tag [*1*]:
+to create a signed tag:
------------
$ git checkout work
@@ -66,14 +66,27 @@ to create a signed tag [*1*]:
$ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
------------
-and pushes the tag out to her publishing repository [*2*]. There is no
-need to push the `work` branch or anything else:
+Note that this example uses the `-m` option to create a signed tag with
+just a one-liner message, but this is for illustration purposes only. It
+is advisable to compose a well-written explanation of what the topic does
+to justify why it is worthwhile for the integrator to pull it, as this
+message will eventually become part of the final history after the
+integrator responds to the pull request (as we will see later).
+
+Then she pushes the tag out to her public repository:
------------
$ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
------------
-Then the contributor prepares a message to request a "pull":
+There is no need to push the `work` branch or anything else.
+
+Note that the above command line used a plus sign at the beginning of
+`+frotz-for-xyzzy` to allow forcing the update of a tag, as the same
+contributor may want to reuse a signed tag with the same name after the
+previous pull request has already been responded to.
+
+The contributor then prepares a message to request a "pull":
------------
$ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
@@ -148,22 +161,21 @@ In the editor, the integrator will see something like this:
# gpg: Good signature from "Con Tributor <nitfol@example.com>"
------------
-provided if the signature in the signed tag verifies correctly. Notice
-that the message recorded in the signed tag "Completed frotz feature"
-appears here, and again that is why it is important for the contributor
-to explain her work well when creating the signed tag.
+Notice that the message recorded in the signed tag "Completed frotz
+feature" appears here, and again that is why it is important for the
+contributor to explain her work well when creating the signed tag.
As usual, the lines commented with `#` are stripped out. The resulting
commit records the signed tag used for this validation in a hidden field
so that it can later be used by others to audit the history. There is no
need for the integrator to keep a separate copy of the tag in his
-repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
-example), and there is no need to publish the tag to his public
+repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the
+above example), and there is no need to publish the tag to his public
repository, either.
After the integrator responds to the pull request and her work becomes
-part of the permanent history, the contributor can remove the tag from the
-publishing repository, if she chooses, in order to keep the tag namespace
+part of the permanent history, the contributor can remove the tag from
+her public repository, if she chooses, in order to keep the tag namespace
of her public repository clean, with:
------------
@@ -199,23 +211,7 @@ A typical output from `git show --show-signature` may look like this:
...
------------
-There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
-that is used for frequent "pull" exchange in the long term just for such
-auditing purposes, as the signature is recorded as part of the merge
-commit.
-
-
-Footnotes
----------
-
-*1* This example uses the `-m` option to create a signed tag with just a
-single liner message, but this is for illustration purposes only. It is
-advisable to compose a well-written explanation of what the topic does to
-justify why it is worthwhile for the integrator to pull it, as this
-message will eventually become part of the final history after the
-integrator responds to the pull request.
-
-*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
-forcing the update of a tag, as the same contributor may want to reuse a
-signed tag with the same name after the previous pull request has already
-been responded to.
+There is no need for the auditor to explicitly fetch the contributor's
+signature, or to even be aware of what tag(s) the contributor and integrator
+used to communicate the signature. All the required information is recorded
+as part of the merge commit.
^ permalink raw reply related
* [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Dieter Plaetinck @ 2012-01-18 21:52 UTC (permalink / raw)
To: git; +Cc: Dieter Plaetinck
There is no need to restrict use of --ignore-missing to dry runs,
it can be useful to ignore missing files during normal operation as
well.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
---
Documentation/git-add.txt | 9 +++++----
builtin/add.c | 4 +---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 9c1d395..c6fae9f 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -138,10 +138,11 @@ subdirectories.
true to make this the default behaviour.
--ignore-missing::
- This option can only be used together with --dry-run. By using
- this option the user can check if any of the given files would
- be ignored, no matter if they are already present in the work
- tree or not.
+ If some files could not be added because they are missing,
+ do not raise any error but continue adding the others.
+ By using this option with --dry-run the user can check if
+ any of the given files would be ignored,
+ no matter if they are already present in the work tree or not.
\--::
This option can be used to separate command-line options from
diff --git a/builtin/add.c b/builtin/add.c
index 1c42900..e702714 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -326,7 +326,7 @@ static struct option builtin_add_options[] = {
OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
- OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "check if - even missing - files are ignored in dry run"),
+ OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "just skip files which do not exist"),
OPT_END(),
};
@@ -388,8 +388,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die(_("-A and -u are mutually incompatible"));
- if (!show_only && ignore_missing)
- die(_("Option --ignore-missing can only be used together with --dry-run"));
if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
--
1.7.8.3
^ permalink raw reply related
* Re: modifying the commits before push
From: Andreas Schwab @ 2012-01-18 22:01 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: git
In-Reply-To: <87sjjc3cpj.fsf@gnu.org>
Sam Steingold <sds@gnu.org> writes:
> alas, I could not push because the remote tree was modified in the
> meantime, I pulled and now:
>
> # On branch master
> # Your branch is ahead of 'origin/master' by 23 commits.
What exactly did you do to get the additional 19 commits?
> is there a way for me to get back my original 4 patches, reset my tree
> (maybe by rm-rf+clone) and then re-apply them?
You can find them in the reflog (git log -g).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: modifying the commits before push
From: Sam Steingold @ 2012-01-18 21:47 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: git
In-Reply-To: <4F17291A.8020600@dirk.my1.cc>
Hi Dirk,
> * Dirk Süsserott <arjfyrggre@qvex.zl1.pp> [2012-01-18 21:18:34 +0100]:
> Am 18.01.2012 18:49 schrieb Sam Steingold:
>
> to modify the last 4 commits you can use git filter-branch (see the
> manpage):
>
> $ git checkout master
> $ git filter-branch --env-filter \
> 'GIT_COMMITTER_EMAIL="sds@gnu.org" \
> GIT_COMMITTER_NAME="Sam Steingold"' \
> HEAD~4..HEAD
>
> It should tell you that it rewrites 4 commits.
I did this; I got a few messages which scrolled very quickly.
status code was 0, apparently, I was successful.
> The original tree is saved under original/refs/heads/master.
where is that?
> If sth. went wrong, reset your master to that point (easiest with
> gitk, it's steel blue). If it worked, you can delete the
> original/refs/heads/master like so:
>
> $ git for-each-ref --format="%(refname)" \
> refs/original/ | xargs -n 1 git update-ref -d
>
> Note: Whether it worked or not, remove the original refs afterwards,
> because a second run of git filter-branch will fail if there's already
> an "original" tree.
alas, I could not push because the remote tree was modified in the
meantime, I pulled and now:
# On branch master
# Your branch is ahead of 'origin/master' by 23 commits.
#
nothing to commit (working directory clean)
so, what do I do now?
is there a way for me to get back my original 4 patches, reset my tree
(maybe by rm-rf+clone) and then re-apply them?
thanks!
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://jihadwatch.org http://memri.org http://thereligionofpeace.com
http://www.PetitionOnline.com/tap12009/ http://palestinefacts.org
I don't have an attitude problem. You have a perception problem.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62g8n1tq.fsf@alter.siamese.dyndns.org>
On 12-01-18 04:22 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>>> +
>>> +------------
>>> + $ git checkout work
>>> + $ ... "git pull" from sublieutenants, "git commit" your own work ...
>>> + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
>>> +------------
>>> +
>>> +and pushes the tag out to her publishing repository [*2*]. There is no
>>
>> This footnote speaks of the example using a +, but the example does no such
>> thing.
>>
>>> +need to push the `work` branch or anything else:
>>> +
>>> +------------
>>> + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
>>> +------------
>
> Do you not see the plus in front of +'frotz-for-xyzzy' above, or am I
> missing something?
Oops, I was tripped up because the footnote is attached to a sentence that my
addled mind associates with the previous "git tag" example.
It might be better to just move the footnote to the end of the next sentence.
M.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Junio C Hamano @ 2012-01-18 21:22 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <4F16E228.5050203@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
>> +A contributor or a lieutenant
>> +-----------------------------
>> +
>> +After preparing her work to be pulled, the contributor uses `git tag -s`
>> +to create a signed tag [*1*]:
>
> Given that the rest of the text refers to the gist of this footnote, I think
> it'd be better to put the note's text here instead of as a footnote.
Hmm, I'll try to see how well it reads after moving the text here. Thanks.
>> +
>> +------------
>> + $ git checkout work
>> + $ ... "git pull" from sublieutenants, "git commit" your own work ...
>> + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
>> +------------
>> +
>> +and pushes the tag out to her publishing repository [*2*]. There is no
>
> This footnote speaks of the example using a +, but the example does no such
> thing.
>
>> +need to push the `work` branch or anything else:
>> +
>> +------------
>> + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
>> +------------
Do you not see the plus in front of +'frotz-for-xyzzy' above, or am I
missing something?
>> +In the editor, the integrator will see something like this:
>> +
>> +------------
>> + Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
>> +
>> + Completed frotz feature
>> + # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
>> + # gpg: Good signature from "Con Tributor <nitfol@example.com>"
>> +------------
>> +
>> +provided if the signature in the signed tag verifies correctly. Notice
>
> s/if //
Noted.
>> +repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
>
> s/list/list the/
Noted.
>> +There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
>> +that is used for frequent "pull" exchange in the long term just for such
>> +auditing purposes, as the signature is recorded as part of the merge
>> +commit.
>
> I had trouble parsing this sentence. I think part of the problem is that
> it's comparing the actual implementation to an earlier proposed design that
> was rejected. So it's trying to sell the reader on a feature of the
> implemented design, but the reader doesn't care.
>
> How about this instead:
>
> There is no need for the auditor to explicitly fetch the contributor's
> signature, or to even be aware of what tag(s) the contributor and integrator
> used to communicate the signature. All the required information is recorded
> as part of the merge commit.
Ok, that is much easier to read.
>> +
>> +
>> +Footnotes
>> +---------
>> +
>> +*1* This example uses the `-m` option to create a signed tag with just a
>> +single liner message, but this is for illustration purposes only. It is
>
> s/single liner/single-line/
Noted.
Thanks.
^ permalink raw reply
* Re: Interactive rebase with submodules
From: Jens Lehmann @ 2012-01-18 20:38 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <4F16AB2E.30706@metanate.com>
Am 18.01.2012 12:21, schrieb John Keeping:
> On 17/01/12 21:29, Jens Lehmann wrote:
>> Am 17.01.2012 19:47, schrieb John Keeping:
>>> This appears to be because the git-rebase--interactive script inspects whether there is anything to commit when `rebase --continue` is invoked by running:
>>>
>>> git diff-index --cached --quiet --ignore-submodules HEAD --
>>
>>> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
>>
>> Yes, removing it will help your use case but break others. The reason
>> for that is that because submodules are not updated during a rebase
>> it doesn't make sense to compare their HEAD to what is recorded in
>> the superproject, as that might have been changed by an earlier
>> commit. And as the submodules HEAD hasn't been updated back then,
>> it is stale and will always show up as modified (even if it wasn't).
>
> Is this worse than the current behaviour?
If we break established behavior that would be worse unless we have
a *very* good reason to do so. But please see below ...
> If I perform a rebase where there is a (non-submodule) conflict in a commit where a submodule changes I can see something like:
>
> # Changes to be committed:
> # modified: path/to/submodule
> #
> # Unmerged paths:
> # both modified: path/to/file
> #
> # Changes not staged for commit:
> # modified: path/to/submodule (new commits)
>
> This occurs if a later commit in the rebase will modify the submodule. In this case, `rebase --continue` correctly recreates the commit once I have resolved the conflict in the file, ignoring the unstaged submodule changes.
Yeah, as rebase doesn't touch the submodules, that is expected.
>>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>>
>> The irony is that you would have to update submodules (or at least
>> their HEAD and use "--ignore-submodules=dirty") while running rebase
>> to make that work in all cases ;-)
>
> I don't this this is the case, since diff-tree is being invoked with --cached won't it ignore changes in the work tree anyway?
Right, thanks for nudging me with the clue bat ...
I missed the "--cached" option and did not question if the code does
what the commit message of 6848d58c6 (where the --ignore-submodules
option was introduced) said:
Ignore dirty submodule states during rebase and stash
When rebasing or stashing, chances are that you do not care about
dirty submodules, since they are not updated by those actions anyway.
So ignore the submodules' states.
Note: the submodule states -- as committed in the superproject --
will still be stashed and rebased, it is _just_ the state of the
submodule in the working tree which is ignored.
I think this logic misses the case when only submodule changes are left
in a commit.
>> But just updating the HEAD would be dangerous as you would have to be
>> very careful to restore the submodules HEAD after the rebase, or the
>> submodule's work tree will be out of sync.
>
> Just updating HEAD in the submodule without touching its work tree doesn't seem like a good idea. I think it will cause a lot more confusion when running `git status` which will show unexpected modified content for the submodule.
Yes, we agree here.
> Since I did not expect rebase to perform a submodule update, I was not surprised to see unstaged submodule changes when rebasing, but I did expect rebase to commit anything I had added to the index.
Right.
I'll have to add some tests for that case, but I doubt I'll manage that
today. Until I can provide a complete patch, this diff should fix your
problem (no, I did not test if that change is enough to fix the problem,
but at least it does not break the test suite ;-):
---------------8<--------------
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 5812222..4546749 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -672,7 +672,7 @@ rearrange_squash () {
case "$action" in
continue)
# do we have anything to commit?
- if git diff-index --cached --quiet --ignore-submodules HEAD --
+ if git diff-index --cached --quiet HEAD --
then
: Nothing to commit -- skip this
else
^ permalink raw reply related
* Re: modifying the commits before push
From: Dirk Süsserott @ 2012-01-18 20:18 UTC (permalink / raw)
To: git, sds
In-Reply-To: <87wr8o3nq0.fsf@gnu.org>
Am 18.01.2012 18:49 schrieb Sam Steingold:
> Hi,
> I am trying to push:
> $ git status
> # On branch master
> # Your branch is ahead of 'origin/master' by 4 commits.
> #
> nothing to commit (working directory clean)
> $
> but `git push` fails with this:
>
> remote: ERROR: Rejecting update because this commit email is not from ZZZ
>
> What I need to do is
> - modify the 4 commits with a different e-mail and do `git push` again
> - make sure that all my commits in this repo are done with the correct e-mail
>
> how do I do this?
>
> thanks!
>
Hi Sam,
to modify the last 4 commits you can use git filter-branch (see the
manpage):
$ git checkout master
$ git filter-branch --env-filter \
'GIT_COMMITTER_EMAIL="sds@gnu.org" \
GIT_COMMITTER_NAME="Sam Steingold"' \
HEAD~4..HEAD
It should tell you that it rewrites 4 commits. The original tree is
saved under original/refs/heads/master. If sth. went wrong, reset your
master to that point (easiest with gitk, it's steel blue). If it worked,
you can delete the original/refs/heads/master like so:
$ git for-each-ref --format="%(refname)" \
refs/original/ | xargs -n 1 git update-ref -d
Note: Whether it worked or not, remove the original refs afterwards,
because a second run of git filter-branch will fail if there's already
an "original" tree.
To change your address for future commits configure it in .gitconfig in
your $HOME (--global) or on a per repo basis in .git/config (--local):
$ git config --global user.email "sds@gnu.org"
$ git config --global user.name "Sam Steingold"
Or use git gui for this step (Edit -> Options).
HTH
Dirk
^ 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