* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Johannes Schindelin @ 2009-03-20 10:31 UTC (permalink / raw)
To: Michael J Gruber
Cc: git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher,
Junio C Hamano
In-Reply-To: <1237543471-27248-1-git-send-email-git@drmicha.warpmail.net>
Hi,
On Fri, 20 Mar 2009, Michael J Gruber wrote:
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
That is brutal. First shot, then cut.
> Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
> >
> > Often, it is quite interesting to inspect the branch tracked by a
> > given branch. This patch introduces a nice notation to get at the
> > tracked branch: 'BEL<branch>' can be used to access that tracked
> > branch.
> >
> > A special shortcut 'BEL' refers to the branch tracked by the current
> > branch.
> >
> > Suggested by Pasky and Shawn.
> >
> > This patch extends the function introduced to handle the nth-last
> > branch (via the {-<n>} notation); therefore that function name was
> > renamed to something more general.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> I guess you beat me to it then, which is fine.
I had it ready yesterday! But the real problem is not addressed by your
patch, either: '%<branch>' is a legal branch name.
I briefly considered <branch>^{tracked}, but
- the ^{} codepath does not try to substitute branch _names_, so we'd have
to duplicate that ^{} detection, and,
- it is really cumbersome to write.
> But haven't you seen my note about the failing test either? The code
> below tests with branches which track local branches. merge and remote
> is set for the branch in question ("tracking"), it's just that remote is
> ".". It seems that the remote.c code does not set up merge info for
> these branches.
I have seen it, it's just not my itch, and I am busy enough as it is.
> <Goes to figure out how to enter BEL...>
Ctrl-v Ctrl-g
Ciao,
Dscho
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Steve @ 2009-03-20 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <200903201103.59907.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch <at> intra2net.com> writes:
> Check the permissions of the files on the server, I once accidentally executed
> git commands as root user and the HTTP server was later
> unable to read/write the repository properly.
The perms are okay, yet the error message remains.
^ permalink raw reply
* Re: Git no longer reads attributes from the index properly
From: Junio C Hamano @ 2009-03-20 10:16 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Linus Torvalds, msysgit
In-Reply-To: <20090320084031.GD1037@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> However, that commit looks like it's solving a different problem
> entirely (supporting changing between two branches where .gitattributes
> exists in both cases) and happens to fix the no .gitattributes -> read
> from index regression at the same time. I don't know enough about the
> guts to tell, but does this also fix the core problem of the regression
> (I assume something about trying to read from the wrong index, given the
> commit that broke it), or does it just happen to work around it?
Actually the commit solves both.
Notice that the second hunk of the patch to unpack-trees passes o->result
to the new git_attr_set_direction() function to tell it to read from the
new index, instead of reading from the wrong one. In addition, by setting
the direction to CHECKOUT, it favors to read the attribute data from the
index over from the work tree.
Note that this is merely a "good enough" approximation and arguing that we
should only read from the in-index attributes during checkout (and read
only from work tree attributes during checkin) is futile. Look at other
thread with Kristian Amlie for details.
diff --git a/unpack-trees.c b/unpack-trees.c
index e547282..661218c 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -105,6 +106,7 @@ static int check_updates(struct unpack_trees_options *o)
cnt = 0;
}
+ git_attr_set_direction(GIT_ATTR_CHECKOUT, &o->result);
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
^ permalink raw reply related
* Re: git-push on packed refs via HTTP
From: Thomas Jarosch @ 2009-03-20 10:03 UTC (permalink / raw)
To: git; +Cc: Steve
In-Reply-To: <loom.20090320T094550-421@post.gmane.org>
Hi Steve,
On Friday, 20. March 2009 10:50:57 you wrote:
> Using HTTP as transport, I've noticed that after using git-gc on a git
> server, I can't push to that repo anymore: "No refs in common and none
> specified." Client and server are both 1.6.2. Is ths a bug or do I have to
> do something after executing git-gc on the server?
Check the permissions of the files on the server, I once accidentally executed
git commands as root user and the HTTP server was later
unable to read/write the repository properly.
Thomas
^ permalink raw reply
* [PATCH] Document and test the new % shotcut for the tracked branch
From: Michael J Gruber @ 2009-03-20 10:04 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201027450.10279@pacific.mpi-cbg.de>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
>
> Often, it is quite interesting to inspect the branch tracked by a given
> branch. This patch introduces a nice notation to get at the tracked
> branch: 'BEL<branch>' can be used to access that tracked branch.
>
> A special shortcut 'BEL' refers to the branch tracked by the current branch.
>
> Suggested by Pasky and Shawn.
>
> This patch extends the function introduced to handle the nth-last branch
> (via the {-<n>} notation); therefore that function name was renamed to
> something more general.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I guess you beat me to it then, which is fine.
But haven't you seen my note about the failing test either? The code below
tests with branches which track local branches. merge and remote is set
for the branch in question ("tracking"), it's just that remote is ".".
It seems that the remote.c code does not set up merge info for these
branches.
<Goes to figure out how to enter BEL...>
Documentation/git-rev-parse.txt | 3 ++
t/t1506-rev-parse-track.sh | 60 +++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 0 deletions(-)
create mode 100755 t/t1506-rev-parse-track.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..dafcfe8 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* A prefix '%', optionally followed by a branchname '<branch>', means the
+ branch tracked by '<branch>'. '<branch>' defaults to the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/t/t1506-rev-parse-track.sh b/t/t1506-rev-parse-track.sh
new file mode 100755
index 0000000..1ca1dd6
--- /dev/null
+++ b/t/t1506-rev-parse-track.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='test % syntax'
+
+. ./test-lib.sh
+
+
+make_commit () {
+ echo "$1" > "$1" &&
+ git add "$1" &&
+ git commit -m "$1"
+}
+
+
+test_expect_success 'setup' '
+
+ make_commit 1 &&
+ git branch tracked &&
+ make_commit 2 &&
+ git checkout tracked &&
+ make_commit 3 &&
+ git checkout --track -b tracking tracked
+ make_commit 4 &&
+ git checkout master
+
+'
+
+# tracking tracks tracked
+# master does not track anything
+# all three point at different commits
+
+test_rev_equivalent () {
+
+ git rev-parse "$1" > expect &&
+ git rev-parse "$2" > output &&
+ test_cmp expect output
+
+}
+
+test_expect_success '%trackingbranch works' '
+ test_rev_equivalent tracked %tracking
+'
+
+test_expect_success '% works in tracking branch' '
+ git checkout tracking &&
+ test_rev_equivalent tracked %
+'
+
+test_expect_success '%nontrackingbranch fails' '
+ test_must_fail git rev-parse %tracked
+'
+
+test_expect_success '% fails in non-tracking branch' '
+ git checkout tracked &&
+ test_must_fail git rev-parse %
+'
+
+test_done
+
+
--
1.6.2.149.g6462
^ permalink raw reply related
* Re: git-svn with multiple branch directories
From: Eric Wong @ 2009-03-20 10:04 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <alpine.LSU.2.01.0903200002390.29898@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> wrote:
> Hello,
>
> I am trying to create a git repo that tracks an SVN repo with multiple
> branch directories.
>
> Is there any way to get this done easily?
>
> It seems the 'git svn' command allows only to specify one 'trunk',
> 'branches' and 'tag' directory.
>
> The example usecase is the OpenOffice.org repo (it's just a private
> experiment). I got this svn-sync'ed within 4 evening sessions, the SVN
> size is about ~8 GB with ~270000 commits. Unfortunately their structure
> is
>
> branches/
> contrib/
> cws/
> dist/
> patches/
> tags/
> trunk/
>
> where 'cws' and 'branches' both hold branches.
>
> I have seen a web-based article telling one should
>
> git svn clone <URL>/trunk repo.git
>
> first, and then hack the repo.git/.git/config file manually to add
> entries like
>
> [svn-remote "b1"]
> url = $SVN_REPO_URL/branches/b1
> fetch = :refs/remotes/b1
> [svn-remote "b2"]
> url = $SVN_REPO_URL/branches/b2
> fetch = :refs/remotes/b2
> [svn-remote "c1"]
> url = $SVN_REPO_URL/cws/c1
> fetch = :refs/remotes/c1
> ...
>
> to later use
>
> git svn fetch <branchname>
>
> for each branch. But even if that worked, their seems to be no easy way
> to detect newly created branches etc. Additionally, I get two entries
> listed in 'git branch' for each, one of which with extension '@1' (seems
> to point ot the branch point). This doesn't seem to be the case for
> repo's with only one branch directory converted the normal way.
>
> Any ideas?
You should be able to do something like this:
[svn-remote "svn"]
url = $SVN_REPO_URL
branches = branches/*:refs/remotes/branches/*
tags = tags/*:refs/remotes/tags/*
fetch = cws/c1:refs/remotes/cws/c1
fetch = cws/c2:refs/remotes/cws/c2
fetch = cws/c3:refs/remotes/cws/c3
...
As for generating the individual fetch lines, I would just pipe
svn ls $SVN_REPO_URL/cws to awk/sed/perl...
--
Eric Wong (who just realized he programs in ASP :x)
^ permalink raw reply
* [PATCH] import-tars: separate author from committer
From: Giuseppe Bilotta @ 2009-03-20 9:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
The import-tars script is typically employed to (re)create the past
history of a project from stored tars. Although assigning authorship in
these cases can be a somewhat arbitrary process, it makes sense to set
the author to whoever created the tars in the first place (if it's
known), and (s)he can in general be different from the committer
(whoever is running the script).
Implement this by having separate author and committer data, making them
settable from the usual GIT_* environment variables.
---
Or should I have made the ENV access a separate patch?
contrib/fast-import/import-tars.perl | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 23aeb25..6309d14 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -14,13 +14,18 @@ die "usage: import-tars *.tar.{gz,bz2,Z}\n" unless @ARGV;
my $branch_name = 'import-tars';
my $branch_ref = "refs/heads/$branch_name";
-my $committer_name = 'T Ar Creator';
-my $committer_email = 'tar@example.com';
+my $author_name = $ENV{'GIT_AUTHOR_NAME'} || 'T Ar Creator';
+my $author_email = $ENV{'GIT_AUTHOR_EMAIL'} || 'tar@example.com';
+my $committer_name = $ENV{'GIT_COMMITTER_NAME'} || `git config --get user.name`;
+my $committer_email = $ENV{'GIT_COMMITTER_EMAIL'} || `git config --get user.email`;
+
+chomp($committer_name, $committer_email);
open(FI, '|-', 'git', 'fast-import', '--quiet')
or die "Unable to start git fast-import: $!\n";
foreach my $tar_file (@ARGV)
{
+ my $commit_time = time;
$tar_file =~ m,([^/]+)$,;
my $tar_name = $1;
@@ -39,7 +44,7 @@ foreach my $tar_file (@ARGV)
die "Unrecognized compression format: $tar_file\n";
}
- my $commit_time = 0;
+ my $author_time = 0;
my $next_mark = 1;
my $have_top_dir = 1;
my ($top_dir, %files);
@@ -92,7 +97,7 @@ foreach my $tar_file (@ARGV)
}
$files{$path} = [$next_mark++, $mode];
- $commit_time = $mtime if $mtime > $commit_time;
+ $author_time = $mtime if $mtime > $author_time;
$path =~ m,^([^/]+)/,;
$top_dir = $1 unless $top_dir;
$have_top_dir = 0 if $top_dir ne $1;
@@ -100,6 +105,7 @@ foreach my $tar_file (@ARGV)
print FI <<EOF;
commit $branch_ref
+author $author_name <$author_email> $author_time +0000
committer $committer_name <$committer_email> $commit_time +0000
data <<END_OF_COMMIT_MESSAGE
Imported from $tar_file.
@@ -119,7 +125,7 @@ EOF
print FI <<EOF;
tag $tar_name
from $branch_ref
-tagger $committer_name <$committer_email> $commit_time +0000
+tagger $author_name <$author_email> $author_time +0000
data <<END_OF_TAG_MESSAGE
Package $tar_name
END_OF_TAG_MESSAGE
--
1.6.2.254.g84bde
^ permalink raw reply related
* git-push on packed refs via HTTP
From: Steve @ 2009-03-20 9:50 UTC (permalink / raw)
To: git
Hi
Using HTTP as transport, I've noticed that after using git-gc on a git server, I
can't push to that repo anymore: "No refs in common and none specified." Client
and server are both 1.6.2. Is ths a bug or do I have to do something after
executing git-gc on the server?
Thanks! Steve
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 9:54 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher,
git
In-Reply-To: <3F6729A7-76FA-43F4-9538-D644B30576D7@wincent.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 771 bytes --]
Hi,
On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>
> >
> >Often, it is quite interesting to inspect the branch tracked by a given
> >branch. This patch introduces a nice notation to get at the tracked
> >branch: 'BEL<branch>' can be used to access that tracked branch.
> >
> >A special shortcut 'BEL' refers to the branch tracked by the current branch.
> >
> >Suggested by Pasky and Shawn.
>
> What does BEL actually stand for? I read Shawn's suggestion, but it's not
> immediately clear to me what "BEL" means.
It is the ASCII "bell" character, 007 (I always wanted to write that
magic identifier into a patch).
FWIW you could type it in a regular ANSI terminal using Control-v
Control-g.
Ciao,
Dscho
^ permalink raw reply
* Re: Git no longer reads attributes from the index properly
From: Michael J Gruber @ 2009-03-20 9:45 UTC (permalink / raw)
To: bdowning; +Cc: Junio C Hamano, git, Linus Torvalds, msysgit
In-Reply-To: <20090320084031.GD1037@lavos.net>
Brian Downing venit, vidit, dixit 20.03.2009 09:40:
>
> On Fri, Mar 20, 2009 at 01:27:31AM -0700, Junio C Hamano wrote:
>> bdowning@lavos.net (Brian Downing) writes:
>>> As of 34110cd4e394e3f92c01a4709689b384c34645d8, (2008-03-06, just over a
>>> year ago), Git no longer reads attributes from the index properly in all
>>> cases....
>>
>> Perhaps you would want to try it on 06f33c1 (Read attributes from the
>> index that is being checked out, 2009-03-13) that is part of 'pu'?
>
> I only tried it on next, groan. Yes, it works there, thanks.
>
> However, that commit looks like it's solving a different problem
> entirely (supporting changing between two branches where .gitattributes
> exists in both cases) and happens to fix the no .gitattributes -> read
> from index regression at the same time. I don't know enough about the
> guts to tell, but does this also fix the core problem of the regression
> (I assume something about trying to read from the wrong index, given the
> commit that broke it), or does it just happen to work around it?
>
> Specifically, it would be nice to have a fix for the regression that
> could land on maint relatively soon, as the initial checkout case is
> breaking a real repository I use, whereas the switching branches case is
> something I don't care about as much at the moment.
>
> Of course, I don't know how to fix it at the moment, and beggars can't
> be choosers. :)
You're testing whether a checkout without index and with empty work tree
works, right?
In that case, the checkout needs to make sure that .gitattributes is
checked out (or at least respected) before all other files, and that is
exactly what the patch in pu does. [If I remember right that great
simplification patch you bisected as bad played a role there, unless I'm
mixing up threads...]
Michael
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Wincent Colaiuta @ 2009-03-20 9:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher,
git
In-Reply-To: <alpine.DEB.1.00.0903201027450.10279@pacific.mpi-cbg.de>
El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>
> Often, it is quite interesting to inspect the branch tracked by a
> given
> branch. This patch introduces a nice notation to get at the tracked
> branch: 'BEL<branch>' can be used to access that tracked branch.
>
> A special shortcut 'BEL' refers to the branch tracked by the current
> branch.
>
> Suggested by Pasky and Shawn.
What does BEL actually stand for? I read Shawn's suggestion, but it's
not immediately clear to me what "BEL" means.
Cheers,
Wincent
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-20 9:35 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.10.0903191948050.4560@asgard.lang.hm>
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
> On Fri, 20 Mar 2009, Johannes Schindelin wrote:
>
> > I'd rather have more file types supported that are useful for the
> > average user, than a generic XML merge driver that is useful to only a
> > handful of people.
>
> we are both after the same thing,
Apparently not...
> the most use to the average user.
>
> you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
> seperate things that should have support developed seperatly.
No. I look at SVG, ODF text, ODF spreadsheet, etc as things with
completely different user interfaces.
And likewise, the merge _helper_, the very thing the user will get to see,
must have different user interfaces.
And I see much more potential for this project to fail in those different
user interfaces than something as _trivial_ (in relation) as XML merging.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add a test for checking whether gitattributes is honored by checkout.
From: Kristian Amlie @ 2009-03-20 9:32 UTC (permalink / raw)
To: git; +Cc: Kristian Amlie
In-Reply-To: <49C34FB1.4040100@nokia.com>
The original bug will not honor new entries in gitattributes if they
are changed in the same checkout as the files they affect.
It will also keep using .gitattributes, even if it is deleted in the
same commit as the files it affects.
---
t/t0020-crlf.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1be7446..4e72b53 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -429,6 +429,37 @@ test_expect_success 'in-tree .gitattributes (4)' '
}
'
+test_expect_success 'checkout with existing .gitattributes' '
+
+ git config core.autocrlf true &&
+ git config --unset core.safecrlf &&
+ echo ".file2 -crlfQ" | q_to_cr >> .gitattributes &&
+ git add .gitattributes &&
+ git commit -m initial &&
+ echo ".file -crlfQ" | q_to_cr >> .gitattributes &&
+ echo "contents" > .file &&
+ git add .gitattributes .file &&
+ git commit -m second &&
+
+ git checkout master~1 &&
+ git checkout master &&
+ test "$(git diff-files --raw)" = ""
+
+'
+
+test_expect_success 'checkout when deleting .gitattributes' '
+
+ git rm .gitattributes &&
+ echo "contentsQ" | q_to_cr > .file2 &&
+ git add .file2 &&
+ git commit -m third
+
+ git checkout master~1 &&
+ git checkout master &&
+ remove_cr .file2 >/dev/null
+
+'
+
test_expect_success 'invalid .gitattributes (must not crash)' '
echo "three +crlf" >>.gitattributes &&
--
1.6.2.1.222.g570cc.dirty
^ permalink raw reply related
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 9:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <7vprgc4r6h.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 19 Mar 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
> >
> >> So yea, you can create a branch named "foo@{1}".
> >
> > But you can't actually refer to it:
> >
> > $ git branch foo@{1}
> > $ git show foo@{1} --
> > fatal: bad revision 'foo@{1}'
> >
> > which implies that nobody is actually using it for anything.
>
> I think you are right. It is just "git branch" and perhaps "git
> update-ref" are too loose in enforcing what can be created.
"git branch" I agree with, but not "git update-ref". As plumbing, the
latter should be much more allowing, feeding rope aplenty (but also
allowing cool tricks we do not think about yet).
Ciao,
Dscho
^ permalink raw reply
* [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 9:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <20090320004450.GY23521@spearce.org>
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: 'BEL<branch>' can be used to access that tracked branch.
A special shortcut 'BEL' refers to the branch tracked by the current branch.
Suggested by Pasky and Shawn.
This patch extends the function introduced to handle the nth-last branch
(via the {-<n>} notation); therefore that function name was renamed to
something more general.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 19 Mar 2009, Shawn O. Pearce wrote:
> Use BEL for your %helloworld hack.
Here you are.
Documentation/git-rev-parse.txt | 3 ++
sha1_name.c | 21 ++++++++++++---
t/t1506-rev-parse-tracked.sh | 54 +++++++++++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+), 4 deletions(-)
create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..a4bcd5e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The prefix 'BEL' to a ref means the branch tracked by that ref. If no
+ ref was specified, it means the branch tracked by the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..cb4168d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -240,9 +241,10 @@ static int ambiguous_path(const char *path, int len)
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form BEL<branch>.
*/
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
{
struct strbuf buf = STRBUF_INIT;
int ret = interpret_nth_last_branch(*string, &buf);
@@ -254,12 +256,23 @@ static char *substitute_nth_last_branch(const char **string, int *len)
return (char *)*string;
}
+ if (**string == '\007') {
+ struct branch *tracking = branch_get((*string)[1] ?
+ (*string) + 1 : NULL);
+
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch(&str, &len);
const char **p, *r;
int refs_found = 0;
@@ -288,7 +301,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
{
- char *last_branch = substitute_nth_last_branch(&str, &len);
+ char *last_branch = substitute_branch(&str, &len);
const char **p;
int logs_found = 0;
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..359f648
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='test BEL<branch> syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success 'BEL resolves to correct full name' '
+
+ test refs/remotes/origin/master = "$(full_name "$(echo -e '\007')")"
+
+'
+
+test_expect_success 'BELmy-side resolves to correct full name' '
+
+ test refs/remotes/origin/side = "$(full_name "$(echo -e '\007')"my-side)"
+
+'
+
+test_expect_success 'BELmy-side resolves to correct commit' '
+
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject "$(echo -e '\007')"my-side)"
+
+'
+
+test_done
--
1.6.2.1.477.g74567
^ permalink raw reply related
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Johannes Schindelin @ 2009-03-20 9:17 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <81b0412b0903200130s594ce3beyae21eb0b5cc8fe0@mail.gmail.com>
Hi,
On Fri, 20 Mar 2009, Alex Riesen wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Now, we _do_ have msysGit, you _do_ have shown the capability to fix
> > issues when they arise, so I do _not_ see any obstacle why you should
> > not go msysGit, rather than staying with the pain of trying to stay
> > POSIX-compatible, but not quite all the time.
>
> I understand. It is not pure POSIX compatibility I seek. I just can't
> use MinGW port, because I absolutely must use the cygwin environment
> (for "hysterical" reasons) and they don't play well together (tried,
> yes. Conflicting libraries, but you already know that).
Maybe we can work on those conflicting libraries? After all, we do have a
"rebase.exe" tool now (for all those as puzzled by the naming as I was:
the rebase.exe tool can shift the memory range used by a .dll so that it
does not overlap with that one of another .dll).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: Reworded example text in git-bisect.txt.
From: Michael J Gruber @ 2009-03-20 8:59 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git
In-Reply-To: <1237520134-18044-1-git-send-email-dmellor@whistlingcat.com>
David J. Mellor venit, vidit, dixit 20.03.2009 04:35:
> Reworded to avoid splitting sentences across examples of command usage.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 44 ++++++++++++++++++++++-------------------
> 1 files changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 1a4a527..93d9fc0 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -50,28 +50,29 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
> ------------------------------------------------
>
> When you have specified at least one bad and one good version, the
> -command bisects the revision tree and outputs something similar to:
> +command bisects the revision tree and outputs something similar to
> +the following:
>
> ------------------------------------------------
> Bisecting: 675 revisions left to test after this
> ------------------------------------------------
>
> -and then checks out the state in the middle. You would now compile
> -that kernel and boot it. If the booted kernel works correctly, you
> -would then issue the following command:
> +The state in the middle of the set of revisions is then checked out.
> +You would now compile that kernel and boot it. If the booted kernel
> +works correctly, you would then issue the following command:
>
> ------------------------------------------------
> $ git bisect good # this one is good
> ------------------------------------------------
>
> -which would then output something similar to:
> +The output of this command would be something similar to the following:
>
> ------------------------------------------------
> Bisecting: 337 revisions left to test after this
> ------------------------------------------------
>
> -and you continue along, compiling that one, testing it, and depending
> -on whether it is good or bad issuing the command "git bisect good"
> +You keep repeating this process, compiling the tree, testing it, and
> +depending on whether it is good or bad issuing the command "git bisect good"
> or "git bisect bad" to ask for the next bisection.
>
> Eventually there will be no more revisions left to bisect, and you
> @@ -81,7 +82,7 @@ Bisect reset
> ~~~~~~~~~~~~
>
> To return to the original head after a bisect session, you issue the
> -command:
> +following command:
>
> ------------------------------------------------
> $ git bisect reset
> @@ -94,14 +95,14 @@ the bisection state).
> Bisect visualize
> ~~~~~~~~~~~~~~~~
>
> -During the bisection process, you issue the command:
> +To see the currently remaining suspects in 'gitk', the following command
> +is issued during the bisection process:
>
> ------------
> $ git bisect visualize
> ------------
>
> -to see the currently remaining suspects in 'gitk'. `view` may also
> -be used as a synonym for `visualize`.
> +`view` may also be used as a synonym for `visualize`.
>
> If the 'DISPLAY' environment variable is not set, 'git log' is used
> instead. You can also give command line options such as `-p` and
> @@ -114,16 +115,17 @@ $ git bisect view --stat
> Bisect log and bisect replay
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -After having marked revisions as good or bad, then:
> +After having marked revisions as good or bad, you issue the following
> +command to show what has been done so far:
>
> ------------
> $ git bisect log
> ------------
>
> -shows what you have done so far. If you discover that you made a mistake
> -in specifying the status of a revision, you can save the output of this
> -command to a file, edit it to remove the incorrect entries, and then issue
> -the following commands to return to a corrected state:
> +If you discover that you made a mistake in specifying the status of a
> +revision, you can save the output of this command to a file, edit it to
> +remove the incorrect entries, and then issue the following commands to
> +return to a corrected state:
>
> ------------
> $ git bisect reset
> @@ -173,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
> $ git bisect skip v2.5..v2.6
> ------------
>
> -would mean that no commit between `v2.5` excluded and `v2.6` included
> -can be tested.
> +The effect of this would be that no commit between `v2.5` excluded and
> +`v2.6` included could be tested.
>
> Note that if you also want to skip the first commit of the range you
> would issue the command:
> @@ -183,14 +185,16 @@ would issue the command:
> $ git bisect skip v2.5 v2.5..v2.6
> ------------
>
> -and the commit pointed to by `v2.5` would also be skipped.
> +This would cause the commits between `v2.5` included and `v2.6` included
> +to be skipped.
> +
>
> Cutting down bisection by giving more parameters to bisect start
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> You can further cut down the number of trials, if you know what part of
> the tree is involved in the problem you are tracking down, by specifying
> -path parameters when issuing the `bisect start` command, like this:
> +path parameters when issuing the `bisect start` command:
>
> ------------
> $ git bisect start -- arch/i386 include/asm-i386
Thanks :)
^ permalink raw reply
* Re: [PATCH 2/2] Allow http authentication via prompt for http push.
From: Michael J Gruber @ 2009-03-20 8:49 UTC (permalink / raw)
To: Amos King; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <d8c371a80903191202v6fb974f4t2321761d0cf21a70@mail.gmail.com>
Amos King venit, vidit, dixit 19.03.2009 20:02:
> The issue with calling it remote is that it conflicts with the remote
> struct that is need for http_init, and is used in the rest of the
> code. So do you want me to make this small impact change or a larger
> and more broad sweeping change by changing the name of the other
> remote. I don't believe fake is a better name. I would hope that at
> some point the 'repo' struct would go away and we can make http_push
> work like all the other remote commands.
>
> I also believe that 'out' is the correct word. It was not a typo, and
> I appreciate your suggestion of assuming that I can't spell just
> because I used a word that you didn't understand. I'm not building
> OUR authorization. I am building OUT authorization. Have you heard
> of building something out? Or even fleshing something out?
>
> I appreciated your first responses to my other patch. Even if your
> tone was that of a person with low self-esteem who needs to pick
> unimportant details apart in order to stroke their own ego. Instead
> of responding in the same tone I thought I would respond nicely and
> get your feedback. Responses like your first one don't cause people
> to want to continue to contribute to the community.
>
> I have a great idea. Why don't you try using the 'nice' tense in your
> next email instead of the high and mighty 'ass-hole' tense. Then I
> will gladly not use past tense in my commit messages, and others might
> respond more positively to your criticisms.
>
> Fiek Dich,
> Amos
We don't want these obscenities on this list, whether in plain English
or wrong German!
In fact, Dscho's criticism was not only constructive but nice, and not
only by his standards.
You managed to have at least 2 (3 by our count) typos in one line, and
Dscho pointed that out correctly and nicely.
Your second response (which I saw just before hitting send) doesn't show
much new insight regarding the latter two points. I'll consider the
first one dealt with by it.
Michael
> On Thu, Mar 19, 2009 at 11:59 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 19 Mar 2009, Amos King wrote:
>>
>>> There is now a faux remote created in order to
>>> be passed to http_init.
>>>
>>> Signed-off-by: Amos King <amos.l.king@gmail.com>
>>> ---
>>> http-push.c | 11 ++++++++++-
>>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/http-push.c b/http-push.c
>>> index 9ac2664..468d5af 100644
>>> --- a/http-push.c
>>> +++ b/http-push.c
>>> @@ -2195,7 +2195,16 @@ int main(int argc, char **argv)
>>>
>>> memset(remote_dir_exists, -1, 256);
>>>
>>> - http_init(NULL);
>>> + /*
>>> + * This is a faked remote so that http_init can
>>> + * get the correct data for builidng out athorization.
>>> + */
>>
>> You might want to pass this through aspell ;-) Altough it will not
>> suggest 'out ->our', I guess...
>>
>>> + struct remote *remote;
>>> + remote = xcalloc(sizeof(*remote), 1);
>>> + ALLOC_GROW(remote->url, remote->url_nr + 1, remote->url_alloc);
>>> + remote->url[remote->url_nr++] = repo->url;
>>> +
>>> + http_init(remote);
>>
>> Would 'fake' not be a more appropriate name than 'remote'?
>>
>> That would also make the patch 1/2 rather unnecessary (I also have to
>> admit that I do not find 'repo' a better name, as we have a repository
>> both locally and remotely, and this _is_ the remote repository, not the
>> local one).
>>
>> Ciao,
>> Dscho
>>
>>
>
>
>
^ permalink raw reply
* Re: Git no longer reads attributes from the index properly
From: Brian Downing @ 2009-03-20 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, msysgit
In-Reply-To: <7vab7gk39o.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 20, 2009 at 01:27:31AM -0700, Junio C Hamano wrote:
> bdowning@lavos.net (Brian Downing) writes:
> > As of 34110cd4e394e3f92c01a4709689b384c34645d8, (2008-03-06, just over a
> > year ago), Git no longer reads attributes from the index properly in all
> > cases....
>
> Perhaps you would want to try it on 06f33c1 (Read attributes from the
> index that is being checked out, 2009-03-13) that is part of 'pu'?
I only tried it on next, groan. Yes, it works there, thanks.
However, that commit looks like it's solving a different problem
entirely (supporting changing between two branches where .gitattributes
exists in both cases) and happens to fix the no .gitattributes -> read
from index regression at the same time. I don't know enough about the
guts to tell, but does this also fix the core problem of the regression
(I assume something about trying to read from the wrong index, given the
commit that broke it), or does it just happen to work around it?
Specifically, it would be nice to have a fix for the regression that
could land on maint relatively soon, as the initial checkout case is
breaking a real repository I use, whereas the switching branches case is
something I don't care about as much at the moment.
Of course, I don't know how to fix it at the moment, and beggars can't
be choosers. :)
-bcd
^ permalink raw reply
* Re: Gnome chose Git
From: Michael J Gruber @ 2009-03-20 8:33 UTC (permalink / raw)
To: Jeff King; +Cc: Pat Notz, Shawn O. Pearce, Git
In-Reply-To: <20090319201405.GD17028@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 19.03.2009 21:14:
> On Thu, Mar 19, 2009 at 09:50:39AM -0600, Pat Notz wrote:
>
>> On Thu, Mar 19, 2009 at 9:16 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>>
>>> Why are people reinventing the reflog, and core.logallrefupdates ?
>>>
>>
>> Hmmm, lack of awareness of core.logallrefupdates in my case. Thanks
>> for the pointer.
>
> But do note that reflogs expire eventually, so you will want to also
> look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> keep this as an activity log forever.
>
> -Peff
In any case, reflogs are local. I would assume that accountability
tracking should be public and transparent. Depends on the use case, of
course.
Michael
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-20 8:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903200025170.10279@pacific.mpi-cbg.de>
2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Thu, 19 Mar 2009, Alex Riesen wrote:
>> Johannes Schindelin, Thu, Mar 19, 2009 11:57:01 +0100:
>>
>> > I'd rather just disable WIN32_STAT for Cygwin, because otherwise, we
>> > will keep running into issues.
>>
>> I'd rather not. The thing is just so unbelievably slow and being stuck
>> on it I'm just trying my damnedest to squeeze every last bit of
>> performance out of it.
>
> If you are serious about performance, you will not stay with Cygwin -- for
> the purposes of Git.
I'm staying with Cygwin port not _for_ Git, but _because_ of Cygwin. If it
were for me, I'd gladly let the Cygwin port die (frankly, any Windows port).
I just use Linux everywhere possible. Sometimes it's not...
> Do not get me wrong: Cygwin is a wonderful thing if your goal is to spare
> yourself a lot of trouble with that seriously challenged win32 API.
I beg to differ: Cygwin is a piece of crap and performs dangerously hideous
in what it tries to do.
> But if your goal is to get the most out of the Win32 API in terms of
> speed, you _will_ have to go with MinGW (at least, as long as you are
> unwilling to shell out big bucks in the vague direction of Redmond, and
> add some time tax to that).
My goal in this environment is to make it bearable. I think that both
Cygwin and MinGW ports are dead-on-arrival, because the underlying
platform is so stupidly and hopelessly broken, and no amount of no bucks
can help it.
> Now, we _do_ have msysGit, you _do_ have shown the capability to fix
> issues when they arise, so I do _not_ see any obstacle why you should not
> go msysGit, rather than staying with the pain of trying to stay
> POSIX-compatible, but not quite all the time.
I understand. It is not pure POSIX compatibility I seek. I just can't use MinGW
port, because I absolutely must use the cygwin environment (for "hysterical"
reasons) and they don't play well together (tried, yes. Conflicting libraries,
but you already know that).
I don't have the Windows sickness anywhere else but at my work, and
sadly it is a good place in all respects, even if absolute crazy in this regard.
So I'm sorry, if I ever made an impression that I'm motivated to do any
Windows-related development. I'm _absolutely_ not. I just happen to have that
itch of Perforce (may it burn in hell for thousand years), have a know how, and
have a little time to spare (hopefully no one of management sees that).
^ permalink raw reply
* Re: Git no longer reads attributes from the index properly
From: Junio C Hamano @ 2009-03-20 8:27 UTC (permalink / raw)
To: bdowning; +Cc: git, Linus Torvalds, msysgit
In-Reply-To: <20090320073527.GC1037@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> As of 34110cd4e394e3f92c01a4709689b384c34645d8, (2008-03-06, just over a
> year ago), Git no longer reads attributes from the index properly in all
> cases....
Perhaps you would want to try it on 06f33c1 (Read attributes from the
index that is being checked out, 2009-03-13) that is part of 'pu'?
^ permalink raw reply
* Re: [PATCH 2/2] Make Git respect changes to .gitattributes during checkout.
From: Kristian Amlie @ 2009-03-20 8:11 UTC (permalink / raw)
To: ext Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7v8wn18bo2.fsf@gitster.siamese.dyndns.org>
ext Junio C Hamano wrote:
> Kristian Amlie <kristian.amlie@nokia.com> writes:
>
>> ext Junio C Hamano wrote:
>> ...
>>> For example, you may notice that, after making a clean checkout, one path
>>> has a wrong attribute assigned to it, and may try to correct it. But how?
>>>
>>> $ edit .gitattributes ;# mark foo.dat as binary
>>> $ rm foo.dat
>>> $ git checkout foo.dat ;# make sure the new settings is correct???
>> As far as I can see, this works without any modifications to the patch.
>> Is that maybe because git_attr_set_direction() is not called if you use
>> that form of checkout?
>
> But that in itself can be seen as a bug, right? In another use case,
> suppose you botched your .gitattributes in HEAD version and noticed that
> foo.dat is checked out with a wrong attribute. You try to fix it like
> this:
>
> $ git reset HEAD^ .gitattributes
> $ rm foo.dat
> $ git checkout foo.dat
>
> If you do not flip the direction, the one from the work tree is used which
> is not what you want. If you do, then you break the other use case.
Right, I didn't even think about that case. My idea of gitattributes was
that the working tree copy is always the master version, and takes
precedence. The only reason that the index takes precedence in the "git
checkout <branch>" case is that there is no other way to get it checked
out correctly, so I see this as an implementation detail. I'm sure some
people would disagree though.
But you're right, there is no way to make both cases correct. From my
standpoint I'd say that the behavior of your patch is the most intuitive.
I'll follow up with the test case.
--
Kristian
^ permalink raw reply
* AW: Re: [PATCH 00/11] Test on Windows - prequel
From: Johannes Sixt @ 2009-03-20 8:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano schrieb:
> Johannes Sixt <j6t@kdbg.org> writes:
>
> > On Mittwoch, 18. März 2009, Johannes Sixt wrote:
> >> git://repo.or.cz/git/mingw/j6t.git for-junio
> >>
> > I've updated the series. Would you please pick up it up from the URL
> > above?
>
> I think you have a typo in the "Use 'say'" one ("In on case").
Fixed and pushed.
-- Hannes
^ permalink raw reply
* [PATCH RESEND] git-gui: Fix merge conflict display error when filename contains spaces
From: Jens Lehmann @ 2009-03-20 7:52 UTC (permalink / raw)
To: git
When a merge conflict occurs in a file with spaces in the filename, git-gui showed wrongly "LOCAL: deleted".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Resending this patch, as i have not received any reply so far.
To reproduce the error with git 1.6.2.1.136.g8e24, i used the following commands:
mkdir spaces
cd spaces/
git init
echo "a" >file\ with\ spaces
git add file\ with\ spaces
git commit -m a .
git checkout -b b
echo "b" >file\ with\ spaces
git commit -m b .
git checkout master
echo "c" >file\ with\ spaces
git commit -m c .
git merge b
git gui
git gui doesn't show the conflict markers as it should, displaying "LOCAL: deleted" instead (but an older git-gui works as expected).
Jens
git-gui/lib/mergetool.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/mergetool.tcl b/git-gui/lib/mergetool.tcl
index eb2b4b5..3e1b42b 100644
--- a/git-gui/lib/mergetool.tcl
+++ b/git-gui/lib/mergetool.tcl
@@ -88,7 +88,7 @@ proc merge_load_stages {path cont} {
set merge_stages(3) {}
set merge_stages_buf {}
- set merge_stages_fd [eval git_read ls-files -u -z -- $path]
+ set merge_stages_fd [eval git_read ls-files -u -z -- {$path}]
fconfigure $merge_stages_fd -blocking 0 -translation binary -encoding binary
fileevent $merge_stages_fd readable [list read_merge_stages $merge_stages_fd $cont]
--
1.6.2.1.215.g5d16f
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox