* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-09 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809091631250.3117@nehalem.linux-foundation.org>
Linus Torvalds wrote:
> On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> Jakub Narebski wrote:
>>>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>>>> The definition of the origin field reads as follows:
>>
>>>> - There can be an arbitrary number of origin fields per commit.
>>>> Typically there is going to be at most one origin field per commit.
>>
>>> I understand that multiple origin fields occur if you do a squash
>>> merge, or if you cherry-pick multiple commits into single commit.
>>> For example:
>>> $ git cherry-pick -n <a1>
>>> $ git cherry-pick <a2>
>>> $ git commit --amend #; to correct commit message
>>
>> Correct.
>
> Quite frankly, recording the origins for _any_ of the above sounds like a
> horribly mistake.
Actually the above is _not_ a good example for using 'origin', and why
using 'origin'; just a bit convoluted example of multiple 'origin'
headers.
> All those operations are commonly used (along with "git rebase -i") to
> clean up history in order to show a nicer version.
>
> The whole point of "origin" seems to be to _destroy_ that.
If I understand correctly the point is to record those 'origin' headers
for git-revert (when 'origin'-ed commit is somewhere in the history),
and for git-cherry-pick from other long lived branch and thus require
additional option to git-cherry-pick to record 'origin' (denoting that
you this is "true" cherry-pick, and not reordering of commits and
cleaning up a history, better done with interactive rebase).
/me is playing advocatus diaboli here, 'cause I'm not that convinced
to necessity of this feature.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-09 23:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809091631250.3117@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> Jakub Narebski wrote:
>> >I understand that multiple origin fields occur if you do a squash
>> >merge, or if you cherry-pick multiple commits into single commit.
>> >For example:
>> > $ git cherry-pick -n <a1>
>> > $ git cherry-pick <a2>
>> > $ git commit --amend #; to correct commit message
>> Correct.
>All those operations are commonly used (along with "git rebase -i") to
>clean up history in order to show a nicer version.
Actually, I'd suggest that cherry-pick takes an -o flag which turns on
the origin link. This needs to be a concious decision because one deems
the history relevant. This typically is a Good Thing when the
development has several long-term-stable branches which never get merged
with each other, yet they receive frequent backports (using cherry-pick)
between them.
>The whole point of "origin" seems to be to _destroy_ that.
Only in the case where the committer thinks the history is of interest,
and even then, since the origin link is in the header, displaying it or
not suddenly is under the control of git.
Had it been in the free-form textarea, there'd be no way suppress the
display of it.
>I would refuse to ever touch anything that had an "origin" pointer, so if
>git were to add that feature, it would be a huge disappointment to me. I'd
>have to have a version that makes sure that anything it pulls hasn't been
>crapped on by somebody who added a stupid link to some dirty history that
>I'm not at all interested in seeing.
As you might have noticed, the actual process of pulling/fetching
explicitly does *not* pull in the objects being pointed to.
That, in turn, will cause the origin link output to be automatically
suppressed. I.e. you'll never know the difference.
OTOH, if someone adds a free-form link to the commit message, you
essentially cannot hide that and are just suffering the clutter without
having any use for it.
>IOW, I'm seeing a _lot_ of downsides, and not any actual upsides. What are
>the upsides again?
The upsides are:
- If your repository contains the proper branches, it will show a richer
content.
- If your repository lacks the proper branches, it will show a *reduced*
clutter content (because actual free-text references in the commit
messages will decrease).
I see a lot of upsides, what were the downsides again?
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: [PATCH] t7501: always use test_cmp instead of diff
From: Jeff King @ 2008-09-09 23:54 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1221003666-17115-1-git-send-email-vmiklos@frugalware.org>
On Wed, Sep 10, 2008 at 01:41:06AM +0200, Miklos Vajna wrote:
> test_expect_success \
> 'validate git-rev-list output.' \
> - 'diff current expected'
> + 'test_cmp current expected'
We seem to use the convention of
test_cmp <expected> <actual>
elsewhere, rather than
test_cmp <actual> <expected>
as you have here. Most noticeably, that means the diff will show
deviations from expected, rather "what should be done to make this as
expected". But it is also possible that in the future test_cmp could be
enhanced to do something more interesting.
I don't think it is worth it to go fix all such instances, but while you
are here...
-Peff
^ permalink raw reply
* Re: [PATCH] t7501: always use test_cmp instead of diff
From: Miklos Vajna @ 2008-09-09 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1221003666-17115-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Wed, Sep 10, 2008 at 01:41:06AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> This should make the output more readable (by default using diff -u)
> when some tests fail.
Sorry for the duplication, I didn't want to send it twice. I also just
realised after sending that I forgot to rebase it again current master,
where git-rev-list is replaced by git rev-list, but I guess git am -3
handles it. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] t7501: always use test_cmp instead of diff
From: Miklos Vajna @ 2008-09-09 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This should make the output more readable (by default using diff -u)
when some tests fail.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7501-commit.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0edd9dd..6f8c038 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -141,7 +141,7 @@ EOF
test_expect_success \
'validate git-rev-list output.' \
- 'diff current expected'
+ 'test_cmp current expected'
test_expect_success 'partial commit that involves removal (1)' '
@@ -151,7 +151,7 @@ test_expect_success 'partial commit that involves removal (1)' '
git commit -m "Partial: add elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "A elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -160,7 +160,7 @@ test_expect_success 'partial commit that involves removal (2)' '
git commit -m "Partial: remove file" file &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "D file" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -171,7 +171,7 @@ test_expect_success 'partial commit that involves removal (3)' '
git commit -m "Partial: modify elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "M elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -187,7 +187,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
@@ -256,7 +256,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
--
1.6.0.1
^ permalink raw reply related
* [PATCH] t7501: always use test_cmp instead of diff
From: Miklos Vajna @ 2008-09-09 23:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This should make the output more readable (by default using diff -u)
when some tests fail.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7501-commit.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 0edd9dd..6f8c038 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -141,7 +141,7 @@ EOF
test_expect_success \
'validate git-rev-list output.' \
- 'diff current expected'
+ 'test_cmp current expected'
test_expect_success 'partial commit that involves removal (1)' '
@@ -151,7 +151,7 @@ test_expect_success 'partial commit that involves removal (1)' '
git commit -m "Partial: add elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "A elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -160,7 +160,7 @@ test_expect_success 'partial commit that involves removal (2)' '
git commit -m "Partial: remove file" file &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "D file" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -171,7 +171,7 @@ test_expect_success 'partial commit that involves removal (3)' '
git commit -m "Partial: modify elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "M elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -187,7 +187,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
@@ -256,7 +256,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
--
1.6.0.1
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-09 23:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20080909210917.GA3715@coredump.intra.peff.net>
Jeff King wrote:
>On Tue, Sep 09, 2008 at 02:05:28PM -0700, Junio C Hamano wrote:
>> To be consistent, when you are at HEAD and are merging side branch B,
>> because that merge is to incorporate what happened on the side branch
>> while you are looking the other way, we should say "by the way, the
>> difference between state $(git merge-base HEAD B) and state B was used to
>> make this commit." in the resulting merge commit, shouldn't we?
>I suppose you could, though in that case you can obviously calculate the
>merge base yourself from the parents of the merge. The difference with
>cherry-picking (or rebasing) is that you might not otherwise know about
>the "by the way" commits.
Quite. The origin link is primarily intended for cherry-picks/reverts
which are otherwise difficult to find. Anything that can use the normal
parent mechanism has no business using the origin links.
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-09 23:35 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, git
In-Reply-To: <20080909194354.GA13634@cuci.nl>
On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
> Jakub Narebski wrote:
> >"Stephen R. van den Berg" <srb@cuci.nl> writes:
> >> The definition of the origin field reads as follows:
>
> >> - There can be an arbitrary number of origin fields per commit.
> >> Typically there is going to be at most one origin field per commit.
>
> >I understand that multiple origin fields occur if you do a squash
> >merge, or if you cherry-pick multiple commits into single commit.
> >For example:
> > $ git cherry-pick -n <a1>
> > $ git cherry-pick <a2>
> > $ git commit --amend #; to correct commit message
>
> Correct.
Quite frankly, recording the origins for _any_ of the above sounds like a
horribly mistake.
All those operations are commonly used (along with "git rebase -i") to
clean up history in order to show a nicer version.
The whole point of "origin" seems to be to _destroy_ that.
I would refuse to ever touch anything that had an "origin" pointer, so if
git were to add that feature, it would be a huge disappointment to me. I'd
have to have a version that makes sure that anything it pulls hasn't been
crapped on by somebody who added a stupid link to some dirty history that
I'm not at all interested in seeing.
IOW, I'm seeing a _lot_ of downsides, and not any actual upsides. What are
the upsides again?
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-09 23:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080909230525.GC10360@machine.or.cz>
Petr Baudis wrote:
>On Wed, Sep 10, 2008 at 12:56:03AM +0200, Stephen R. van den Berg wrote:
>In other way, I think this is purely a porcelain matter and recording
>this information in the free-form area is more than enough.
>> I'd prefer to formalise the (weak) relationship of an origin link, instead of
>> relying on vague assumptions when parsing the free-form commit message
>> and then guessing what the mentioned hash might mean.
>Why?
Using special references in the free-form area of a commit is akin to
using X-... headerfields in E-mail with all the assorted mess:
- No strict definition of what it means.
- Diverging porcelain implementations making use of the field in ever so
slightly changing ways over the years.
- You cannot rely on the field being always available.
- Automated "renumbering" becomes difficult at best.
What we want are concise and unambiguous definitions which allow us to
build tools that operate predictably on them now, and will operate
predictably on them in the future.
>> >Having history browsers draw fancy lines is fine but I see nothing wrong
>> It's not just that. If I make a change to an area that was cherrypicked
>> from another branch, then I find it rather important to check if any
>> changes to this area need to be backported/forwardported to the branches
>> the origin links are pointing to.
>> I.e. the origin link allows me to improve my efficiency as a programmer.
>And why are the notes created by git cherry-pick -x insufficient for that?
Things like rebase/filter-branch/stgit mess that up because they don't
know if the hash in the free-form should be altered.
Also, there is no automated way to actually fetch missing branches we
cherry-picked from this way.
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: gitignore patterns
From: Randy.Dunlap @ 2008-09-09 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randy.Dunlap, git
In-Reply-To: <7vprnc3nr7.fsf@gitster.siamese.dyndns.org>
On Tue, 9 Sep 2008, Junio C Hamano wrote:
> "Randy.Dunlap" <rdunlap@xenotime.net> writes:
>
> > In the kernel tree, I see 2 .gitignore files that use "+pattern":
> >
> > ./arch/blackfin/include/asm/.gitignore:+mach
> > ./arch/blackfin/boot/.gitignore:+vmImage
> >
> > However, I can't find anything about '+' on the gitignore(5) man page
> > at http://www.kernel.org/pub/software/scm/git/docs/gitignore.html .
> >
> > Does the '+' mean something special or is it just a character in the
> > filename/dir pattern?
>
> AFAIR, this should be just a shell glob fnmatch(3) understands, so perhaps
> their build procedure leaves temporary droppings in a file whose filename
> is prefixed with './+'?
OK, I'll ask the blackfin developers/maintainers about it.
Thanks.
--
~Randy
^ permalink raw reply
* Re: gitignore patterns
From: Junio C Hamano @ 2008-09-09 23:25 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0809091521120.15561@shark.he.net>
"Randy.Dunlap" <rdunlap@xenotime.net> writes:
> In the kernel tree, I see 2 .gitignore files that use "+pattern":
>
> ./arch/blackfin/include/asm/.gitignore:+mach
> ./arch/blackfin/boot/.gitignore:+vmImage
>
> However, I can't find anything about '+' on the gitignore(5) man page
> at http://www.kernel.org/pub/software/scm/git/docs/gitignore.html .
>
> Does the '+' mean something special or is it just a character in the
> filename/dir pattern?
AFAIR, this should be just a shell glob fnmatch(3) understands, so perhaps
their build procedure leaves temporary droppings in a file whose filename
is prefixed with './+'?
^ permalink raw reply
* [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-09 23:10 UTC (permalink / raw)
To: git
Hi!
After awfully long delay, here comes v0.3 of TopGit - we hopefully
begin to approach some kind of practical usability by now.
TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
and others, of course in an attempt to Get It Right this time around.
TopGit is absolutely minimal porcelain layer that will manage your
patch queue for you using topic branches, one patch per branch,
never rewriting the history in order to enable fully distributed
workflow. You can get TopGit at
http://repo.or.cz/w/topgit.git
and read up on its design, usage and implementation at:
http://repo.or.cz/w/topgit.git?a=blob;f=README
Aside of few minor changes, the major point of this release is remotes
handling; you can elevate any remote to a TopGit-tracked status using
'tg remote', then git fetch / push will haul around the TopGit bases
as well, and 'tg update' can update your local branches based on
the remote ones. Each repository has one "default" TopGit remote and
the local branches are supposed to reflect this one; that is the remote
'tg update' and all the other commands consider by default. Normally,
this remote is the last one you called 'tg remote --populate' on, but
you can change it in .git/config or switch it for a particular tg call
using the 'tg -r REMOTE command' parameter.
The other major improvement is new 'tg import' command by Aneesh Kumar
that lets you transform a series of commits to a topic branch sequence.
I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
this release yet, since it will probably take me a bit of time yet to
fully understand his approach; so far, I have an uneasy feel about it.
Note that this release, as usual, received only very light testing -
please come back with any bugs you find. If someone would feel like
adding at least a simple testsuite, that would be really nice.
Aneesh Kumar K.V (1):
topgit: Implement tg-import
Bert Wesarg (1):
Makefile: Use $(wildcard) for commands_in
David Brown (1):
Force adding the .topmsg and .topdep files.
Jan Nieuwenhuizen (1):
TOPGIT: [PATCH] Use standard prefix and DESTDIR rather than explain
Jonathan Nieder (2):
supply template argument to mktemp
tg-info: fix sed typo
Petr Baudis (35):
tg-export: Ensure we don't overwrite a branch by git update-ref
tg create: Set up refs/top-bases/ after conflict resolution
README: Sketch of my current ideas on remotes handling
tg summary: Fix confusing variable name
tg remote: New command
tg-update.sh: Better explain base update
Factor out rev-parse --verify calls to new ref_exists() function
tg.sh: Set $base_remote to topgit.remote config value
recurse_deps+branch_needs_update(): Deal with remote branches
tg update: Support updating from remote branches
has_remote(): Introduce to check if branch has remote counterpart
tg info: Show information about remote branches
tg info: Asterisk-prefix 'out-of-band' warnings
tg summary: Show info about remote mates
tg summary: 'L' denotes that push will update remote mate
tg info: Note if local head is ahead of remote mate
tg summary: Mark current branch with '>'
tg -r REMOTE: Support for switching base remote
tg summary: Fix spurious errors on tg-inconsistent remotes
Fix recursive tg calls: Pass tg parameters through properly
Account for direct-tg arguments in Usage strings
tg import: Better description
tg import: Standard script header
tg import: Standard options parsing
tg import: Remove tg_ prefixes from functions
tg import: Change default prefix from tp/ to t/
README: Add synopsis for working with remotes
tg create -r BRANCH: Create branch based on a remote one
tg import -p PREFIX: Custom prefix instead of t/
tg import: Fix up process_commit() progress reporting
branch_contains(): More explicit call to git rev-list
tg import: Make the progress reporting stand out more
Merge branch 'tg-import'
README: Remove stale TODO
TopGit-0.3
martin f. krafft (2):
Add tg-export to gitignore
Add various todos/wishlists
Have fun,
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-09 23:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809092254.30668.jnareb@gmail.com>
Jakub Narebski wrote:
>On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> On the contrary, my current proposal only needs to verify the validity
>> of a single commit, changing it like this will require the system to
>> verify the validity of two commits. Given the rareness of the origin
>> links this will hardly present a problem, but it *does* increase
>> the overhead in checking a bit.
>Errr... wasn't you proposing to keep/protect against pruning <cousin>
>AND <cousin>^<mainline>? You want to have _diff_ (changeset) protected,
>not a single tree state.
Actually, making sure that the commit we reference in the origin link
exists, we implicitly prove that all the parents of that commit exist as
well. Then again, this point is moot since I already conceded (in a
different thread) that storing two hashes is better.
>>>> - git rev-list --topo-order will take origin links into account to
>>>> ensure proper ordering.
>Hmmm... while I think it might be a good idea, I'm not sure about its
>overhead. Should be much, I guess.
Actually, I have already programmed this part, and the overhead is close
to zero.
>>>> - git blame will follow and use the origin link if the object exists.
>>> Hmmmm... I'm not sure about that.
>> Care to explain your doubts?
>> The reason I want this behaviour, is because it's all about tracking
>> content, and that part of the content happens to come from somewhere
>> else, and therefore blame should look there to "dig deeper" into it.
>But blame is all about what commit brought some line to currents version.
>So the cherry-pick itself, or revert of a commit itself would be blamed,
>and should be blamed, not its parents, nor commit which got cherry-picked,
>or commit which got reversed.
Well, it depends, I guess.
If you'd go for a "committer" based display, then following origin links
is bad.
If you'd go for an "author" based display, then following origin links
should be the default (IMHO).
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-09 23:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Stephen R. van den Berg, git
In-Reply-To: <200809100035.23166.jnareb@gmail.com>
Jakub Narebski wrote:
> On Tue, 9 Sep 2008, Jeff King wrote:
> > On Tue, Sep 09, 2008 at 01:42:52PM -0700, Junio C Hamano wrote:
> > Now, that being said:
> >
> > > After reading the discussion so far, I am still not convinced if this is a
> > > good idea, nor this time around it is that much different from what the
> > > previous "prior" link discussion tried to do.
> >
> > For the record, I am not convinced it is a good idea either; I was
> > hoping to steer it in a direction where somebody could say "and now this
> > is the useful thing we can do now that we could not do before." If the
> > ultimate goal is to put links to other commits into history viewers,
> > then the commit message is a reasonable place to do so. The only thing I
> > see improving with a header is that it makes more sense for pruning and
> > object transfer.
>
> I'm also not all convinced that 'cousin'/'origin'/'changeset'/'cset'
> header is a good idea. I only tried to steer discussion in good
> direction if it is somewhat a good idea.
By the way, beside graphical history viewers it would also help rebase
(and git-cherry) notice when patch was already applied better.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Petr Baudis @ 2008-09-09 23:05 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080909225603.GA7459@cuci.nl>
On Wed, Sep 10, 2008 at 12:56:03AM +0200, Stephen R. van den Berg wrote:
> The only way to perform the backports is by using cherry-pick.
> The history of each backport *is* important though.
> Since all the developers who care about the multiple release branches
> have all the relevant branches in their repository, the presence of
> a origin object is by no means random, it's a certainty.
Recording cherry-picks in your workflow certainly makes sense, but I'm
not talking about workflow-level issues here. You are adding an extra
header to the commit object. I'm talking about the object database and
low-level Git model implications this has.
In other way, I think this is purely a porcelain matter and recording
this information in the free-form area is more than enough.
> >Why do you actually *follow* the origin link at all anyway? Without its
> >parents, the associated tree etc., the object is essentially useless for
> >you; the authorship information and commit message should've been
> >preserved by a proper cherry-pick anyway. You're cluttering the object
> >store with invalid objects, which also breaks quite some fundamental
> >logic within Git (which assumes that if an object exists, all its
> >references are valid - give or take few special cases like shallow
> >repositories, but this would have very different characteristics).
>
> I'd prefer to formalise the (weak) relationship of an origin link, instead of
> relying on vague assumptions when parsing the free-form commit message
> and then guessing what the mentioned hash might mean.
Why?
> >Having history browsers draw fancy lines is fine but I see nothing wrong
> >with them extracting this from the free-form part of the commit message.
> >For informative purposes, we don't shy away from heuristics anyway, c.f.
> >our renames detection (heck, we are even brave enough to use that for
> >merges).
>
> It's not just that. If I make a change to an area that was cherrypicked
> from another branch, then I find it rather important to check if any
> changes to this area need to be backported/forwardported to the branches
> the origin links are pointing to.
> I.e. the origin link allows me to improve my efficiency as a programmer.
And why are the notes created by git cherry-pick -x insufficient for that?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]
From: Elijah Newren @ 2008-09-09 23:02 UTC (permalink / raw)
To: Steven Walter; +Cc: Govind Salinas, Jakub Narebski, git
In-Reply-To: <e06498070809091450y3bb7ba1cs8b86ea31b4e37bd8@mail.gmail.com>
On Tue, Sep 9, 2008 at 3:50 PM, Steven Walter <stevenrwalter@gmail.com> wrote:
> On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren <newren@gmail.com> wrote:
>> it), but it's fairly straightforward to say any of:
>>
>> eg revert --since HEAD~3 # Undo all changes since HEAD~3
>> eg revert --in HEAD~8 # much like git revert HEAD~8, but no
>> commit by default
>> eg revert --since HEAD foo.py # Undo changes to foo.py since last commit
>> eg revert foo.py # Same as above
>> eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]
> [...]
>> Are these kinds of "reverting data" really so different that there
>> should need to be different commands, or that some of these operations
>> shouldn't be supported by the simple revert command? Sure, most users
>> most of the time will probably use the "eg revert FILE1 FILE2..."
>> form, but I didn't see the harm in supporting the extra capabilities.
>
> The harm I see in trying to support every possible use case is that it
> makes it exponentially more difficult to fully understand the tool.
> Using yap as an example, I think it should be easy enough for a user
> to read the help blurb for every command and understand what it does
> and when to use it (this is easy for me to say as the author, but I
> think it would hold true for a "typical SCM user.") Having a mode
> the seems to act like another SCM (revert --since) seems great at
> first blush. The user will see that and think, "Wonderful, this will
> work just like svn and I don't have to think about it." As I mention
> in another email, that's all well and good until the user runs "git
> diff" and makes a liar of you. In svn, there would be no diff,
> because the files all match their respective upstream versions. In
> git, you would see changes because the file no longer matches the last
> commit. Now your user is confused because his mental model was
> violated.
Um, no, git diff won't make a liar of me -- it'll come up empty as
expected. :-) My suggestion for revert does make it a logical
extension of svn's, and includes git revert's behavior (with two minor
tweaks). See my follow up post to Junio's elsewhere in this thread.
> Obviously, there is a trade-off here between power and usability. As
> shown by the Hole Hawg[1], there is a limit to the amount of power it
> is useful for the average user to have. The git community has already
> admitted this by dividing the git command set into two classes:
> plumbing, and porcelain. "The plumbing," you say, "is very powerful,
> but you shouldn't have to use it." My contention is that there is a
> class of users that is not well served by the current definition of
> porcelain. It is that class of users that I have tried to target with
> yap.
Fair enough. I too had to make decisions on what to focus on as well
in Easy Git. Since my goal was more along the lines of "make it easy
to learn how to use git, and particularly easy to transition to and
from git and eg" that gives me a much different frame of reference
than interoperating with svn (which I essentially ignored). I thought
that this particular case didn't add much complexity (and potentially
even removed it elsewhere), but that may just be my frame of
reference.
yap looks pretty cool; I'll have to take a look sometime.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-09 22:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080909211355.GB10544@machine.or.cz>
Petr Baudis wrote:
>On Tue, Sep 09, 2008 at 03:22:12PM +0200, Stephen R. van den Berg wrote:
>> - During fetch/push/pull the full commit including the origin fields is
>> transmitted, however, the objects the origin links are referring to
>> are not (unless they are being transmitted because of other reasons).
>> - When fetching/pulling it is optionally possible to tell git to
>> actually transmit objects referred to by origin links even if it would
>> otherwise not have done so.
>I think this is misguided. In general case, cherrypicks can be from
>completely unrelated histories, and if you are doing the cherry pick,
>you are saying that actually, the history *does not matter*. In that
That is a false assumption in general, I'd say.
>case, this kind of link tries to impose a meaning where there is none,
>and in an ill-defined way when whether the commit is actually around
>anywhere is essentially random.
The purpose I'd use the origin links for is to manage software projects
that consist of 7 main branches which have branched in (on average) two
year intervals, which never get merged anymore. The only thing that
happens is that there are backports amongst the branches about two per
week.
The only way to perform the backports is by using cherry-pick.
The history of each backport *is* important though.
Since all the developers who care about the multiple release branches
have all the relevant branches in their repository, the presence of
a origin object is by no means random, it's a certainty.
>Why do you actually *follow* the origin link at all anyway? Without its
>parents, the associated tree etc., the object is essentially useless for
>you; the authorship information and commit message should've been
>preserved by a proper cherry-pick anyway. You're cluttering the object
>store with invalid objects, which also breaks quite some fundamental
>logic within Git (which assumes that if an object exists, all its
>references are valid - give or take few special cases like shallow
>repositories, but this would have very different characteristics).
I'd prefer to formalise the (weak) relationship of an origin link, instead of
relying on vague assumptions when parsing the free-form commit message
and then guessing what the mentioned hash might mean.
>Having history browsers draw fancy lines is fine but I see nothing wrong
>with them extracting this from the free-form part of the commit message.
>For informative purposes, we don't shy away from heuristics anyway, c.f.
>our renames detection (heck, we are even brave enough to use that for
>merges).
It's not just that. If I make a change to an area that was cherrypicked
from another branch, then I find it rather important to check if any
changes to this area need to be backported/forwardported to the branches
the origin links are pointing to.
I.e. the origin link allows me to improve my efficiency as a programmer.
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: Revert behavior
From: Elijah Newren @ 2008-09-09 22:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steven Walter, Petr Baudis, Jakub Narebski, Govind Salinas, git
In-Reply-To: <7v63p53r93.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 9, 2008 at 4:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If you implement "eg svn-like-revert" to checkout the given paths out of
> the last commit, instead of the index, shouldn't that be sufficient?
No, that would leave staged changes unreverted -- a particular case of
which means that revert wouldn't be able to undo an add operation.
For svn-like-revert, the default should be for both staged and
unstaged changes to be undone, unless the user specifically requested
that only part of the changes be reverted (e.g. with --staged or
--unstaged flags). Making revert work prior to the initial commit for
new adds is another case that needs a command with behavior different
than git's checkout of paths.
>> It it a delicate balance to have the user interface match both the
>> mental model of the user and the storage model of the tool.
>
> I do not think it is that simple.
>
> You could match the user experience to the mental model of the other tool,
> by hiding the differences and insisting that people use only your tool.
>
> The real issue is that you may need to castrate the underlying tool in
> certain places if its world model is richer than the model the tool you
> are trying to emulate. Ignoring the index by making "svn-like-revert"
> work on both index and the working tree file at the same time is a good
> example of that.
Why? If the command _by default_ works on both the index and working
tree file, is that necessarily bad ('git checkout BRANCH' operates on
both)? If the tool can only operate on both at once, then sure, I
agree, but that at least isn't the case with eg and wasn't my
suggestion for git.
Not all alternate porcelains try to hide or destroy the index. Some
of us really do love it.
Elijah
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-09 22:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Stephen R. van den Berg, git
In-Reply-To: <20080909205003.GA3397@coredump.intra.peff.net>
On Tue, 9 Sep 2008, Jeff King wrote:
> On Tue, Sep 09, 2008 at 01:42:52PM -0700, Junio C Hamano wrote:
>
> > As for "by the way ... was used to make this commit": this is git. So how
> > you arrived at the tree state you record in a commit *does not matter*.
>
> But it _does_ matter, which is why we have commit messages to explain
> how you arrived at this tree state.
Well, that is why I was carefull to say that "origin <rev1> <rev2>"
(or 'changeset', or 'cset') means that tree state for given commit
is created out of parent commit (or parent commits in the case of merge)
and of (<rev2> - <rev1>) patch. This is a bit of enhancement to
"parent <rev>" meaning that tree state for current commit is derived
from tree state of <rev>.
This is nice generalization...
> Now, that being said:
>
> > After reading the discussion so far, I am still not convinced if this is a
> > good idea, nor this time around it is that much different from what the
> > previous "prior" link discussion tried to do.
>
> For the record, I am not convinced it is a good idea either; I was
> hoping to steer it in a direction where somebody could say "and now this
> is the useful thing we can do now that we could not do before." If the
> ultimate goal is to put links to other commits into history viewers,
> then the commit message is a reasonable place to do so. The only thing I
> see improving with a header is that it makes more sense for pruning and
> object transfer.
I'm also not all convinced that 'cousin'/'origin'/'changeset'/'cset'
header is a good idea. I only tried to steer discussion in good
direction if it is somewhat a good idea.
First, if the only goal would be to add extra links (extra edges) to
[graphical] history viewer, then full sha-1 of a commit which can be
recorded in commit message for cherry-picks and reverts should be
enough. It does mean parsing commit message, and all possibilities
for mistake which are connected to using conventions in free-form part
of commit object; on the other hand it is not _that_ critical.
If however 'origin' links are more (perhaps only a tiny bit more),
for example discussed "weak" links... then I'm not sure if
the tradeoffs are worth it. First, if it is full connectivity like
in 'parent' header case, then a) why not use 'parent' anyway,
b) it pins the history indefinitely long. Second, if it is "weak"
link, i.e. local protect it on prune, then a) there are problems
with transferring the data, and protecting links on transfer,
as somewhere in the middle or at the end there might be repository
which uses older git (backwards compatibility strikes again),
b) git in many, many places assumes that object is valid if it passes,
and all objects linked to from object are valid; we would have either
use some kind of separate 'not strictly checked' packfile/storage,
or have grafts-like thingy.
So I'm not sure if 'origin' links are worth the trouble.
About much, much earlier "prior" link discussion: I think the discussion
about "prior" header link was done before reflogs, or at least before
reflogs got turned on by default.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Revert behavior
From: Steven Walter @ 2008-09-09 22:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, Jakub Narebski, Elijah Newren, Govind Salinas, git
In-Reply-To: <7v63p53r93.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 9, 2008 at 6:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If you implement "eg svn-like-revert" to checkout the given paths out of
> the last commit, instead of the index, shouldn't that be sufficient?
eg's "revert --since <commit> <path>" command is actually most similar
to "svn update -rXXX path." In this case, except for the special case
where commit is HEAD, it is not sufficient; checking the path out of
the last commit would not be what the user wanted.
>> It it a delicate balance to have the user interface match both the
>> mental model of the user and the storage model of the tool.
>
> I do not think it is that simple.
>
> You could match the user experience to the mental model of the other tool,
> by hiding the differences and insisting that people use only your tool.
>
> The real issue is that you may need to castrate the underlying tool in
> certain places if its world model is richer than the model the tool you
> are trying to emulate. Ignoring the index by making "svn-like-revert"
> work on both index and the working tree file at the same time is a good
> example of that.
>
> If the castrated feature is truly too exotic and rarely useful for mere
> mortals, that strategy works very well. A simpler world model that lets
> you do the same job equally well is a much better UI than the needlessly
> complex one. But if that is not the case, your users would eventually
> graduate out of the training wheel and would want to use that feature you
> hid away from them, and at that point they need to unlearn parts of the
> simpler world model and shift their world view somewhat. If you try to
> support both classes of users, that become hard.
Indeed so. Hiding the index is not a design goal of yap. However,
neither is it absolutely necessary to understand the distinction
between "staged" and "unstaged" changes to use yap. If a use never
runs the "stage" command, everything would work as he expects.
Achieving this is as simple as making "yap commit," in the presence of
only unstaged changes, do the equivalent of "git commit -a." If it
turns out that _wasn't_ what the user wanted, salvation is only a "yap
uncommit" away.
In your position as an integrator, what is a necessary tool for you
may indeed be an exotic command for another user. For example, users
who primarily interact with svn repositories (a target demographic for
yap), "merge" is not terribly useful given the information loss when a
commit is eventually "pushed" to subversion. I do not hide merge
functionality, but neither is it emphasized as a standard part of the
workflow (there is no "pull" command).
> I have to admit that I used to have my own Porcelain when git was very
> young, not because I did not like existing UI git had, but there was no UI
> back then. "My own" Porcelain is relatively easy -- I have to only cater
> to my own needs and need to expose only the limited subset of the features
> the underlying tool (in this case, the storage model and history view of
> git) I understand, and nobody complains that he cannot access the parts I
> do not expose to him. Growing it to satisfy wider audience is the hard
> part.
No argument that supporting an audience greater than 1 is considerably
more difficult. Indeed I intend and hope to support users other than
myself with yap, else I would not have gone to the trouble of
announcing it. However, without concrete discussion on where yap
hides too much or "castrates" a feature in a way that hinders learning
of the lower-level tools, there's only so much one can do.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* gitignore patterns
From: Randy.Dunlap @ 2008-09-09 22:23 UTC (permalink / raw)
To: git
Hi,
In the kernel tree, I see 2 .gitignore files that use "+pattern":
./arch/blackfin/include/asm/.gitignore:+mach
./arch/blackfin/boot/.gitignore:+vmImage
However, I can't find anything about '+' on the gitignore(5) man page
at http://www.kernel.org/pub/software/scm/git/docs/gitignore.html .
Does the '+' mean something special or is it just a character in the
filename/dir pattern?
Thanks,
--
~Randy
^ permalink raw reply
* Re: Revert behavior
From: Junio C Hamano @ 2008-09-09 22:10 UTC (permalink / raw)
To: Steven Walter
Cc: Petr Baudis, Jakub Narebski, Elijah Newren, Govind Salinas, git
In-Reply-To: <e06498070809091439q1c543807pd6e74b7ada32434@mail.gmail.com>
"Steven Walter" <stevenrwalter@gmail.com> writes:
> I agree with this. That's part of the problem I have with schemes to
> make commands work similarly to other SCMs. If you give, for example,
> eg a mode to act like "svn revert;" that all well and good until the
> user runs "git diff" and you're made a liar. In svn, there would be
> no diff, because the files all match their respective upstream
> versions. In git, you would see changes because the file no longer
> matches the last commit.
If you implement "eg svn-like-revert" to checkout the given paths out of
the last commit, instead of the index, shouldn't that be sufficient?
> It it a delicate balance to have the user interface match both the
> mental model of the user and the storage model of the tool.
I do not think it is that simple.
You could match the user experience to the mental model of the other tool,
by hiding the differences and insisting that people use only your tool.
The real issue is that you may need to castrate the underlying tool in
certain places if its world model is richer than the model the tool you
are trying to emulate. Ignoring the index by making "svn-like-revert"
work on both index and the working tree file at the same time is a good
example of that.
If the castrated feature is truly too exotic and rarely useful for mere
mortals, that strategy works very well. A simpler world model that lets
you do the same job equally well is a much better UI than the needlessly
complex one. But if that is not the case, your users would eventually
graduate out of the training wheel and would want to use that feature you
hid away from them, and at that point they need to unlearn parts of the
simpler world model and shift their world view somewhat. If you try to
support both classes of users, that become hard.
I have to admit that I used to have my own Porcelain when git was very
young, not because I did not like existing UI git had, but there was no UI
back then. "My own" Porcelain is relatively easy -- I have to only cater
to my own needs and need to expose only the limited subset of the features
the underlying tool (in this case, the storage model and history view of
git) I understand, and nobody complains that he cannot access the parts I
do not expose to him. Growing it to satisfy wider audience is the hard
part.
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Jeff King @ 2008-09-09 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vljy13sq0.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 09, 2008 at 02:38:31PM -0700, Junio C Hamano wrote:
> My eyes are getting dry after looking at these s/git-/git / patches, so
> please do not get offended if I leave these in my Inbox unread for a few
> days.
I did the same "look for conversion that should _not_ have occurred"
check for these patches, and all look sane with two exceptions:
- the cvsserver stuff that you mentioned
- patch 4/6 changes the commit log message in a few cases for some "git
svn" tests; presumably nothing is caring about the commit id's
generated here, but I don't actually have svn installed to run the
tests to be sure
> So why don't we do this (not just for test but for documentation as well)?
>
> * We do not use "git foo" form when refering to the "server side
> programs". Make it official;
>
> * We move "server side programs" in git(7) documentation into its
> separate subsection; and
>
> * We always install "server side programs" in $(bindir).
>
> I think git-cvsserver is the last one we missed from the set of server
> side programs (git-cvsserver, git-daemon, git-receive-pack,
> git-upload-archive, git-upload-pack).
That makes perfect sense to me.
-Peff
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Nanako Shiraishi @ 2008-09-09 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Quoting Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> The environment variable CVS_SERVER is still set to "git-cvsserver",
>> because tests fail with CVS_SERVER='git cvsserver' (or double quotes).
>
> My eyes are getting dry after looking at these s/git-/git / patches, so
> please do not get offended if I leave these in my Inbox unread for a few
> days.
No problem.
> So why don't we do this (not just for test but for documentation as well)?
>
> * We do not use "git foo" form when refering to the "server side
> programs". Make it official;
>
> * We move "server side programs" in git(7) documentation into its
> separate subsection; and
>
> * We always install "server side programs" in $(bindir).
>
> I think git-cvsserver is the last one we missed from the set of server
> side programs (git-cvsserver, git-daemon, git-receive-pack,
> git-upload-archive, git-upload-pack).
Thanks for your comments; it makes sense to me. I have to leave for work now, so please expect no progress nor response from me until evening.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]
From: Steven Walter @ 2008-09-09 21:50 UTC (permalink / raw)
To: Elijah Newren; +Cc: Govind Salinas, Jakub Narebski, git
In-Reply-To: <51419b2c0809091319j2f29b6e1n752cba305c7c1cf6@mail.gmail.com>
On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren <newren@gmail.com> wrote:
>> I tend to dislike "DWIM" in interfaces, because the computer cannot
>> read your mind, and can therefore never know with certainty what I
>> mean. Especially in cases where the computer thinks I intend to
>> perform an irreversible operation, I want the computer to ask first.
>> Not only that, but I think having one command that does 10 different
>> things is as confusing as 10 commands that each do one thing. My
>
> How are these things really different, though? People occasionally
> want to "revert changes". Now, this may be the changes between 32 and
> 29 revisions ago, it might be all changes since the last commit, it
> could be the changes since 3 commits ago, or it could be just one
> specific commit. The user may want to subset such reversions to just
> specific files, but it all boils down to "reverting changes" in the
> end. Now, eg can't yet handle a range like between 32 and 29
> revisions ago (because I wasn't sure what syntax I'd want to use for
> it), but it's fairly straightforward to say any of:
>
> eg revert --since HEAD~3 # Undo all changes since HEAD~3
> eg revert --in HEAD~8 # much like git revert HEAD~8, but no
> commit by default
> eg revert --since HEAD foo.py # Undo changes to foo.py since last commit
> eg revert foo.py # Same as above
> eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]
[...]
> Are these kinds of "reverting data" really so different that there
> should need to be different commands, or that some of these operations
> shouldn't be supported by the simple revert command? Sure, most users
> most of the time will probably use the "eg revert FILE1 FILE2..."
> form, but I didn't see the harm in supporting the extra capabilities.
The harm I see in trying to support every possible use case is that it
makes it exponentially more difficult to fully understand the tool.
Using yap as an example, I think it should be easy enough for a user
to read the help blurb for every command and understand what it does
and when to use it (this is easy for me to say as the author, but I
think it would hold true for a "typical SCM user.") Having a mode
the seems to act like another SCM (revert --since) seems great at
first blush. The user will see that and think, "Wonderful, this will
work just like svn and I don't have to think about it." As I mention
in another email, that's all well and good until the user runs "git
diff" and makes a liar of you. In svn, there would be no diff,
because the files all match their respective upstream versions. In
git, you would see changes because the file no longer matches the last
commit. Now your user is confused because his mental model was
violated.
Obviously, there is a trade-off here between power and usability. As
shown by the Hole Hawg[1], there is a limit to the amount of power it
is useful for the average user to have. The git community has already
admitted this by dividing the git command set into two classes:
plumbing, and porcelain. "The plumbing," you say, "is very powerful,
but you shouldn't have to use it." My contention is that there is a
class of users that is not well served by the current definition of
porcelain. It is that class of users that I have tried to target with
yap.
[1] http://www.cryptonomicon.com/beginning.html
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ 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