* Re: grafts not appearing in manual pages
From: J. Bruce Fields @ 2007-09-26 21:01 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070926202441.GA31848@glandium.org>
On Wed, Sep 26, 2007 at 10:24:41PM +0200, Mike Hommey wrote:
> Hi,
>
> The only occurrence of grafts in the manual pages is in the
> git-filter-branch one. I somehow feel this is wrong not to see it
> described more "formally" in the manual pages.
>
> I wouldn't mind writing a small something, except I have no idea what
> would be the most appropriate place to talk about it... Does anyone have
> such an idea ?
It could go in Documentation/user-manual.txt, but I don't know where.
Maybe at the end of the git-concepts chapter? Patches welcomed. I
guess what's needed (and currently missing) is an overview explaining
what they're actually for, plus some basic setup instructions.
And/or maybe a section 5 manual page documenting the format of the
"grafts" file? Maybe that's overkill. There's a paragraph in
Documentation/repository-layout.txt. Maybe we need to make it easier to
find that file.
--b.
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: J. Bruce Fields @ 2007-09-26 20:37 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20070926182204.GB14959@genesis.frugalware.org>
On Wed, Sep 26, 2007 at 08:22:04PM +0200, Miklos Vajna wrote:
> On Wed, Sep 26, 2007 at 02:14:51PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > Neat-o, I'd missed (or forgotten about) import-tars.perl.
> >
> > But I'd prefer to keep this first explanation of how to initialize and
> > commit to a new project pretty streamlined, and I don't think this is
> > really necessary here. So let's save this up until we have enough
> > material for a separate chapter or section on interacting with other
> > scm's.
>
> okay, now it's saved by gmane :)
Also in my git tree--I took yours and Johannes' suggestions, put them in
a blender, and added a brief skeleton of a new chapter at:
git://linux-nfs.org/~bfields/git.git docwork-foreign-scms
--b.
^ permalink raw reply
* grafts not appearing in manual pages
From: Mike Hommey @ 2007-09-26 20:24 UTC (permalink / raw)
To: git
Hi,
The only occurrence of grafts in the manual pages is in the
git-filter-branch one. I somehow feel this is wrong not to see it
described more "formally" in the manual pages.
I wouldn't mind writing a small something, except I have no idea what
would be the most appropriate place to talk about it... Does anyone have
such an idea ?
Cheers,
Mike
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-09-26 20:05 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
+ diffcore-rename: cache file deltas
Parked in 'next' for now but is 'master' material.
* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
+ Don't use "<unknown>" for placeholders and suppress printing of
empty user formats.
Parked in 'next'; I was already burned by it not passing one of
the test cases, and I am not absolutely certain what else this
subtly breaks. Hopefully minor.
* jb/remote-rm (Sun Sep 23 22:29:12 2007 -0700) 3 commits
+ git-remote rm: add tests and minor fix-ups
+ remote: document the 'rm' subcommand
+ remote: add 'rm' subcommand
Should be Ok to push out to 'master'.
* ml/submodule (Sun Sep 23 22:19:42 2007 -0400) 1 commit
+ git-submodule - allow a relative path as the subproject url
Should be Ok to push out to 'master'.
* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
+ git-merge: add --ff and --no-ff options
+ git-merge: add support for --commit and --no-squash
+ git-merge: add support for branch.<name>.mergeoptions
+ git-merge: refactor option parsing
+ git-merge: fix faulty SQUASH_MSG
+ Add test-script for git-merge porcelain
Comments? I personally never felt need for --no-ff but the
series is reasonably clean so I do not see strong objection
against this series either.
* sv/svn (Fri Sep 21 15:27:01 2007 +1200) 3 commits
+ git-svn: handle changed svn command-line syntax
+ git-svn: fix test for trunk svn (transaction out of date)
+ git-svn: fix test for trunk svn (commit message not needed)
Will merge to 'master' this weekend.
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commit
+ rebase -i: work on a detached HEAD
Waiting for autogc change as this textually interacts with it,
and the additional convenience can wait.
* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
+ git-gc --auto: run "repack -A -d -l" as necessary.
+ git-gc --auto: restructure the way "repack" command line is built.
+ git-gc --auto: protect ourselves from accumulated cruft
+ git-gc --auto: add documentation.
+ git-gc --auto: move threshold check to need_to_gc() function.
+ repack -A -d: use --keep-unreachable when repacking
+ pack-objects --keep-unreachable
+ Export matches_pack_name() and fix its return value
+ Invoke "git gc --auto" from commit, merge, am and rebase.
+ Implement git gc --auto
I think the only remaining thing left with this thing is to
prevent more than one instances of it from running at the same
time. Any takers?
* ph/strbuf (Tue Sep 25 10:22:44 2007 +0200) 37 commits
+ Small cache_tree_write refactor.
+ Make builtin-rerere use of strbuf nicer and more efficient.
+ Add strbuf_cmp.
+ strbuf_setlen(): do not barf on setting length of an empty buffer
to 0
+ sq_quote_argv and add_to_string rework with strbuf's.
+ Full rework of quote_c_style and write_name_quoted.
+ ...
I had to make a small fix-up to strbuf_setlen() last night to
this series; this should be ready for 'master'.
And it is better to push this out early, as the series touches
everywhere and conflicts with peoples' patches.
* db/fetch-pack (Tue Sep 25 00:13:25 2007 -0400) 45 commits
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
+ Cleanup style nit of 'x == NULL' in remote.c
+ Fix memory leaks when disconnecting transport instances
+ Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
+ ...
Two issues known to me are:
- "rsync" transport is not supported yet;
- regresses "git pull <name>" using .git/remotes/<name>; does
not merge the first refspec when branch.<name>.merge is not
set.
There may be others but some people apparently use this in
production (including me) and I do not expect major breakages in
the really essential part.
* ss/svnimport (Mon Sep 24 12:57:40 2007 +0200) 1 commit
+ Fix pool handling in git-svnimport to avoid memory leaks.
This is meant to eventually go to 'maint' as well but with
diminishing user base of svnimport it is getting harder to get
good "tested successfully, seen improvements" reports.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
I think "stash create" is going in a good direction, but I do
not think rebase should unstash unconditionally on the resulting
work tree. A good compromise might be not to unstash if the
user asked to switch branches first and to unstash if he didn't.
* kh/commit (Mon Sep 17 20:06:48 2007 -0400) 7 commits
- Implement git commit as a builtin command.
- Export rerere() and launch_editor().
- Add strbuf_read_file().
- Clean up stripspace a bit, use strbuf even more.
- Introduce entry point for launching add--interactive.
- Enable wt-status to run against non-standard index file.
- Enable wt-status output to a given FILE pointer.
There were a few updates/replacements to the list I missed;
* gr/smtp (Tue Sep 25 17:27:54 2007 -0700) 2 commits
- [TO BE SQUASHED] Fix-up after review
- Add ability to specify SMTP server port when using git-send-email.
Will be in 'next'.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-09-26 20:05 UTC (permalink / raw)
To: git
In-Reply-To: <7v3axhd0lr.fsf@gitster.siamese.dyndns.org>
Nothing earth-shattering in 'maint', except:
- if you are on FreeBSD and use its default shell, git scripts
might work better for you;
- comes with updated user-manual;
- send-email would not incorrectly issue duplicated message IDs
even if you fire many messages within one second;
- "git rm this-file && git commit this-file" should work
better;
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Benoit Sigoure (1):
Add test to check recent fix to "git add -u"
David Brown (1):
Detect exec bit in more cases.
David Kastrup (1):
Supplant the "while case ... break ;; esac" idiom
Eric Wong (2):
Documentation/git-svn: updated design philosophy notes
git-svn: don't attempt to spawn pager if we don't want one
Gerrit Pape (1):
git-gui: lib/index.tcl: handle files with % in the filename
properly
Glenn Rempe (1):
Fixed minor typo in t/t9001-send-email.sh test command line.
J. Bruce Fields (14):
user-manual: adjust section levels in "git internals"
user-manual: move object format details to hacking-git chapter
user-manual: rename "git internals" to "git concepts"
user-manual: create new "low-level git operations" chapter
user-manual: rewrite index discussion
user-manual: reorder commit, blob, tree discussion
user-manual: rewrite object database discussion
user-manual: move packfile and dangling object discussion
user-manual: fix introduction to packfiles
user-manual: todo updates and cleanup
documentation: replace Discussion section by link to user-manual
chapter
core-tutorial: minor cleanup
git-apply: fix whitespace stripping
user-manual: don't assume refs are stored under .git/refs
Jakub Narebski (2):
gitweb: Remove parse_from_to_diffinfo code from git_patchset_body
gitweb: No difftree output for trivial merge
Jari Aalto (1):
Documentation/git-archive.txt: a couple of clarifications.
Jeff King (1):
git-push: documentation and tests for pushing only branches
Jim Meyering (2):
unexpected Make output (e.g. from --debug) causes build failure
Do not over-quote the -f envelopesender value.
Johannes Schindelin (2):
revision walker: --cherry-pick is a limited operation
apply --index-info: fall back to current index for mode changes
Johannes Sixt (2):
gitattributes.txt: Remove a duplicated paragraph about 'ident' and
'crlf' interaction.
gitattributes.txt: Be more to the point in the filter driver
description.
Junio C Hamano (11):
diff --no-index: do not forget to run diff_setup_done()
Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot
Split grep arguments in a way that does not requires to add
/dev/null.
git-sh-setup: typofix in comments
send-email: make message-id generation a bit more robust
git-commit: Allow partial commit of file removal.
git-commit: partial commit of paths only removed from the index
Document ls-files --with-tree=<tree-ish>
t/t4014: test "am -3" with mode-only change.
GIT 1.5.3.2
Documentation/git-lost-found.txt: drop unnecessarily duplicated
name.
Linus Torvalds (1):
Fix the rename detection limit checking
Matt Kraai (2):
Move the paragraph specifying where the .idx and .pack files should
be
Conjugate "search" correctly in the git-prune-packed man page.
Matthias Urlichs (1):
git-svnimport: Use separate arguments in the pipe for git-rev-parse
Michael Smith (1):
user-manual: Explain what submodules are good for.
Michele Ballabio (2):
git-gui: show unstaged symlinks in diff viewer
git-gui: handle "deleted symlink" diff marker
Miklos Vajna (1):
User Manual: add a chapter for submodules
Pierre Habouzit (1):
Fix lapsus in builtin-apply.c
Randy Dunlap (1):
core-tutorial: correct URL
Shawn Bohrer (1):
Fix spelling of overridden in documentation
Shawn O. Pearce (13):
git-gui: Correct starting of git-remote to handle -w option
git-gui: Fix detaching current branch during checkout
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Disable Tk send in all git-gui sessions
git-gui: Avoid use of libdir in Makefile
git-gui: Assume untracked directories are Git submodules
git-gui: Trim trailing slashes from untracked submodule names
git-gui: Don't delete send on Windows as it doesn't exist
git-gui: Make backporting changes from i18n version easier
git-gui: Font chooser to handle a large number of font families
git-gui: Provide 'uninstall' Makefile target to undo an
installation
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Disable native platform text selection in "lists"
Väinö Järvelä (1):
Fixed update-hook example allow-users format.
* The 'master' branch has these since the last announcement
in addition to the above.
Carlos Rica (3):
Add tests for documented features of "git reset".
Move make_cache_entry() from merge-recursive.c into read-cache.c
Make "git reset" a builtin.
Christian Couder (4):
rev-list --bisect: Move finding bisection into do_find_bisection.
rev-list --bisect: Move some bisection code into best_bisection.
rev-list --bisect: Bisection "distance" clean up.
rev-list --bisect: Fix best == NULL case.
David Kastrup (3):
diff-delta.c: pack the index structure
diff-delta.c: Rationalize culling of hash buckets
git-commit.sh: Shell script cleanup
Dmitry Potapov (1):
preserve executable bits in zip archives
Jeff King (1):
contrib/fast-import: add perl version of simple example
Johannes Schindelin (7):
Teach "git remote" a mirror mode
verify-tag: also grok CR/LFs in the tag signature
apply: get rid of --index-info in favor of --build-fake-ancestor
rebase -i: commit when continuing after "edit"
rebase -i: style fixes and minor cleanups
rebase -i: Fix numbers in progress report
rebase -i: avoid exporting GIT_AUTHOR_* variables
Josh England (2):
Add post-merge hook, related documentation, and tests.
Added example hook script to save/restore permissions/ownership.
Junio C Hamano (8):
Keep last used delta base in the delta window
git-commit: Allow partial commit of file removal.
An additional test for "git-reset -- path"
Simplify cache API
git-commit: partial commit of paths only removed from the index
Document ls-files --with-tree=<tree-ish>
builtin-pack-objects.c: avoid bogus gcc warnings
Start RelNotes for 1.5.4
Lars Hjemli (3):
git-svn: add support for --first-parent
git-svn: always use --first-parent
Make merge-recursive honor diff.renamelimit
Matt Kraai (2):
Move convert-objects to contrib.
rebase -i: create .dotest-merge after validating options.
Nguyễn Thái Ngọc Duy (1):
contrib/fast-import: add simple shell example
Nicolas Pitre (10):
straighten the list of objects to deltify
localize window memory usage accounting
rearrange delta search progress reporting
basic threaded delta search
threaded delta search: refine work allocation
threaded delta search: better chunck split point
threaded delta search: specify number of threads at run time
fix threaded delta search locking
threaded delta search: add pack.threads config variable
threaded delta search: proper locking for cache accounting
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: Johannes Schindelin @ 2007-09-26 19:58 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <20070926181451.GA20976@fieldses.org>
Hi,
On Wed, 26 Sep 2007, J. Bruce Fields wrote:
> On Wed, Sep 26, 2007 at 12:37:04AM +0200, Miklos Vajna wrote:
> > Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> > ---
> >
> > On Tue, Sep 25, 2007 at 04:13:06PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > One exception--the "series of tarballs" thing--I think it's cool that
> > > you can just unpack a bunch of tarballs and string them together into a
> > > git history. It gives a good sense of how git works, and I don't think
> > > it's documented explicitly anywhere. I think that might be kinda fun to
> > > write up. But I haven't tried.
> >
> > something like this?
>
> Neat-o, I'd missed (or forgotten about) import-tars.perl.
You should also mention
$ mkdir my-new-repo
$ cd my-new-repo
$ git init
$ for z in /blub/*.zip
do
rm -rf * 2> /dev/null &&
unzip "$z" &&
git add . &&
git commit -m "$z" ||
break
done
import-tars.pl is much faster than this, of course, when it comes to tars,
but it has no clue about other archive formats.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Schindelin @ 2007-09-26 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Johannes Sixt, git
In-Reply-To: <7vd4w51csv.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 26 Sep 2007, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
> > Johannes Schindelin schrieb:
> >> The reason why I insist on not putting this into --amend is that I
> >> think this is not really an amend, but actively a rewrite of the
> >> merge commit.
> >
> > You have a point here. I'm convinced. Scrap the patch.
>
> I am slow today. Since when --amend is not about "a rewrite of commit"?
Technically, you are right, of course. Commit objects are immutable. But
from a _porcelain_ view I maintain that "amending" is about changes _to_ a
commit. It is not about redefining the (a) parent.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-26 19:23 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git
In-Reply-To: <20070926145229.GA15300@potapov>
On Wed, 2007-09-26 at 18:52 +0400, Dmitry Potapov wrote:
> On Mon, Sep 24, 2007 at 02:07:36PM -0700, Junio C Hamano wrote:
> > "Josh England" <jjengla@sandia.gov> writes:
> >
> > > ... Granted, the
> > > branch (and HEAD) does not change for this operation, but that shouldn't
> > > matter. It is somewhat in line with the principle of 'least-surprise':
> > > if the hook runs for 'git checkout otherbranch', but not 'git checkout
> > > otherbranch path.c', this could cause confusion and distress to the
> > > user. IMO, it is a 'checkout' so the post-checkout hook should run.
> > > Why is that so insane?
> >
> > Because I find it would be surprising if the following commands
> > behave differently:
> >
> > $ git cat-file blob otherbranch:path.c >path.c
> > $ git show otherbranch:path.c >path.c
> > $ git diff -R otherbranch path.c | git apply
> > $ git checkout otherbranch path.c
>
> Actually, they already act differently even without any hook.
> If path.c is a symbol link then 1 and 2 will give a different
> result than commands 3 and 4.
Moroever, with respect to permissions, the first 2 retain the
permissions of the file if it already exists in the worktree, whereas
the other variations actually recreate the file with a default umask and
wipe out existing permissions.
> On the other hand, while the difference in above commands
> understandable (in case 1 and 2, the shell creates path.c; and
> in 3 and 4, git creates it), I really dislike the idea of
> "checkout is magical." I believe that command 3 and 4 should
> always give the same result or Git is broken.
>
> Another reason, why I dislike the post-checkout hook is that it
> is prone to abuse like as not so smart user trying to put some
> content modification here.
Content modification is not among the intended uses for this hook. Any
and all hooks can be abused/misused in this way. I just want to give
the user a tool -- if he wants to hit himself in the face with it that's
his prerogative.
> Moreover, it appears to be excessive
> to me, because if you want to run something after git-checkout,
> you can write a simple shell script for that that first runs
> git-checkout with the given arguments and then run whatever you
> want. I don't see why we should modify Git for that.
The same could be said for pre-commit and other hooks. The whole
reason for the hook system is to provide a useful interface so that
users are *not* required to write their own wrapper scripts to get the
job done. In this case, providing the hook is by far the *more*
consistent way of doing things.
> Perhaps, it would be better to have a hook on modification,
> which is invoked every time when Git wants to try to change
> anything in the working directory. The hook could receives on
> the input something that looks like 'git-diff --name-status'
> output and can do any work on creation files, etc. It is much
> more flexible, because you can do additional stuff here like
> creating one directory in the path as a symbol link somewhere
> else or something like that. But what is much more important
> is that everything work _consistently_ and you get the same
> results whether you type:
> git diff -R otherbranch path.c | git apply
> or
> git checkout otherbranch path.c
>
> If you start with one "magical interface" then eventually you
> will end up with everything being so magical that no one can
> make sense of it. Please, stay consistent.
I don't know why you think this is so magical. git-checkout can run a
post-checkout hook, if enabled. Plain and simple. No magic here. As
for the universal 'worktree-updated' hook, I look forward to seeing a
sane implementation, but in the meantime post-merge and post-checkout
suit my needs just fine.
-JE
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Junio C Hamano @ 2007-09-26 18:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Johannes Sixt, gitster, git
In-Reply-To: <46FA6CD7.1020709@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
>> The reason why I insist on not putting this into --amend is that I
>> think this is not really an amend, but actively a rewrite of the
>> merge commit.
>
> You have a point here. I'm convinced. Scrap the patch.
I am slow today. Since when --amend is not about "a rewrite of
commit"?
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: Miklos Vajna @ 2007-09-26 18:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070926181451.GA20976@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
On Wed, Sep 26, 2007 at 02:14:51PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> Neat-o, I'd missed (or forgotten about) import-tars.perl.
>
> But I'd prefer to keep this first explanation of how to initialize and
> commit to a new project pretty streamlined, and I don't think this is
> really necessary here. So let's save this up until we have enough
> material for a separate chapter or section on interacting with other
> scm's.
okay, now it's saved by gmane :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] User Manual: document import-tars.perl
From: J. Bruce Fields @ 2007-09-26 18:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1190759824-18896-1-git-send-email-vmiklos@frugalware.org>
On Wed, Sep 26, 2007 at 12:37:04AM +0200, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Tue, Sep 25, 2007 at 04:13:06PM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > One exception--the "series of tarballs" thing--I think it's cool that
> > you can just unpack a bunch of tarballs and string them together into a
> > git history. It gives a good sense of how git works, and I don't think
> > it's documented explicitly anywhere. I think that might be kinda fun to
> > write up. But I haven't tried.
>
> something like this?
Neat-o, I'd missed (or forgotten about) import-tars.perl.
But I'd prefer to keep this first explanation of how to initialize and
commit to a new project pretty streamlined, and I don't think this is
really necessary here. So let's save this up until we have enough
material for a separate chapter or section on interacting with other
scm's.
--b.
>
> VMiklos
>
> Documentation/user-manual.txt | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a085ca1..f722932 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -978,6 +978,19 @@ $ git add . # include everything below ./ in the first commit:
> $ git commit
> -------------------------------------------------
>
> +If you already have a series of tarballs (typically previous releases without
> +using a version control system):
> +
> +-------------------------------------------------
> +$ mkdir project
> +$ cd project
> +$ git init
> +$ perl import-tars.perl /path/to/tarballs/*.tar.bz2
> +$ git checkout import-tars
> +-------------------------------------------------
> +
> +You can find `import-tars.perl` in the `contrib/fast-import/` directory.
> +
> [[how-to-make-a-commit]]
> How to make a commit
> --------------------
> --
> 1.5.3.2.80.g077d6f-dirty
>
^ permalink raw reply
* Re: [PATCH] post-checkout hooks and related tests
From: Josh England @ 2007-09-26 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve9y2v39.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-09-25 at 16:17 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > diff --git a/git-checkout.sh b/git-checkout.sh
> > index 17f4392..78355eb 100755
> > --- a/git-checkout.sh
> > +++ b/git-checkout.sh
> > @@ -137,6 +137,13 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
> > git ls-files --error-unmatch -- "$@" >/dev/null || exit
> > git ls-files -- "$@" |
> > git checkout-index -f -u --stdin
> > +
> > + # Run a post-checkout hook -- the HEAD does not change so the
> > + # current HEAD is passed in for both args
> > + if test -x "$GIT_DIR"/hooks/post-checkout; then
>
> It is usually a good idea to view your patch in your MUA before
> sending them out.
>
> You will spot HT vs SP indentation inconsistencies right away.
Dang. It looked ok in emacs. :(
> HEAD did not change but don't you want to differenciate if the
> checkout was from the index or from the HEAD? If not why not?
Hmmmm. It wouldn't hurt to add another arg though I guess in case
someone might use it. I'm just trying to figure out how to word this
nicely in the Documentation.
-JE
^ permalink raw reply
* Re: History over-simplification
From: Shawn O. Pearce @ 2007-09-26 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4phi4b9t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I don't really like the patch to revision.c because it winds up
> > showing trivial merges too. What I really want is to have the
> > "--full-history" option include a merge if either of the following
> > is true:
> >
> > a) The resulting path does not match _any_ of the parents. We
> > already handle this case correctly in revision.c and correctly
> > show the "evil" merge.
> >
> > b) The resulting path matches one of the parents but not one of
> > the others. In such a case the merge should still be output if
> > a 3-way read-tree would not have chosen this result by default.
>
> I am not sure (b) is useful in general. Merging two branches
> that fix the same issue but in different ways (think: 'maint'
> and 'master' have different infrastructure and a fix initially
> made on 'master' was backported to 'maint', and then later
> 'maint' needed to be merged to 'master' to carry forward other
> fixes) is a norm, and in such cases taking the version from the
> merged-to branch is almost always what happens.
(b) is useful, even in the case you just described. Try doing the
above backport today. Run `git log maint -- foo.c` and find the
backported commit B. Now try to see if that commit is in master in
foo.c with `git log master -- foo.c`. B won't appear as the merge
of maint into master chose master's revision and maint's history
is pruned away.
Now if the backported change was logically the same but was rewritten
considerably it might take you a while to figure out why a merge
discarded the change B. The merge commit might actually describe
why in its message, but you can't find that particular merge commit
today, even with --full-history. Not without my one-line patch.
Unfortunately my one-line patch causes all of the merges that the
path is involved in to be output. That can be quite a lot of them.
> Also it sounds to me by "if read-tree would not have chosen this
> result by default" you mean this feature would not just need to
> run merge-base but also recursive merge-base synthesis, and also
> recreate the structural merge (aka "rename detection") there as
> well. Even if (b) is useful, it sounds like a very expensive
> option, and the current merge-recursive code is structured in
> such a way to be easily reused for this purpose.
I think you meant here that it is *not* structured in a way to be
easily reused for this purpose. That code relies heavily on the
index to allow it to create that synthetic merge base. Making it
callable from within the revision walker would not be a small change.
But as you say, running merge-recursive here would be a very
expensive option. Which is why I was saying the 3-way read-tree
result as that is cheaper to compute. However the read-tree result
can be different from the merge-recursive result (think renames)
and yet both are still "trivial" resolutions that the user was
never involved in.
Of course other kinds of trivial merges (where changes from the
two branches are in the same file but far enough part it can be
easily merged as a 3-way file merge) appear to the path limiter
as though they were an evil merge, and such merges are output.
So maybe having --full-history output all merges that affected
that path really is the right choice.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Dmitry Potapov @ 2007-09-26 14:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh England, git
In-Reply-To: <7vejgnai1z.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 24, 2007 at 02:07:36PM -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > ... Granted, the
> > branch (and HEAD) does not change for this operation, but that shouldn't
> > matter. It is somewhat in line with the principle of 'least-surprise':
> > if the hook runs for 'git checkout otherbranch', but not 'git checkout
> > otherbranch path.c', this could cause confusion and distress to the
> > user. IMO, it is a 'checkout' so the post-checkout hook should run.
> > Why is that so insane?
>
> Because I find it would be surprising if the following commands
> behave differently:
>
> $ git cat-file blob otherbranch:path.c >path.c
> $ git show otherbranch:path.c >path.c
> $ git diff -R otherbranch path.c | git apply
> $ git checkout otherbranch path.c
Actually, they already act differently even without any hook.
If path.c is a symbol link then 1 and 2 will give a different
result than commands 3 and 4.
On the other hand, while the difference in above commands
understandable (in case 1 and 2, the shell creates path.c; and
in 3 and 4, git creates it), I really dislike the idea of
"checkout is magical." I believe that command 3 and 4 should
always give the same result or Git is broken.
Another reason, why I dislike the post-checkout hook is that it
is prone to abuse like as not so smart user trying to put some
content modification here. Moreover, it appears to be excessive
to me, because if you want to run something after git-checkout,
you can write a simple shell script for that that first runs
git-checkout with the given arguments and then run whatever you
want. I don't see why we should modify Git for that.
Perhaps, it would be better to have a hook on modification,
which is invoked every time when Git wants to try to change
anything in the working directory. The hook could receives on
the input something that looks like 'git-diff --name-status'
output and can do any work on creation files, etc. It is much
more flexible, because you can do additional stuff here like
creating one directory in the path as a symbol link somewhere
else or something like that. But what is much more important
is that everything work _consistently_ and you get the same
results whether you type:
git diff -R otherbranch path.c | git apply
or
git checkout otherbranch path.c
If you start with one "magical interface" then eventually you
will end up with everything being so magical that no one can
make sense of it. Please, stay consistent.
Dmitry Potapov
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709261501190.28395@racer.site>
Johannes Schindelin schrieb:
> The reason why I insist on not putting this into --amend is that I think
> this is not really an amend, but actively a rewrite of the merge commit.
You have a point here. I'm convinced. Scrap the patch.
-- Hannes
^ permalink raw reply
* [PATCH 2/2] git-add--interactive: Improve behavior on bogus input
From: Jean-Luc Herren @ 2007-09-26 14:05 UTC (permalink / raw)
To: git; +Cc: gitster
1) Previously, any menu would cause a perl error when entered '0',
which is never a valid option.
2) Entering a bogus choice (like 998 or 4-2) surprisingly caused
the same behavior as if the user had just hit 'enter', which
means to carry out the selected action on the selected items.
Entering such bogus input is now a no-op and the sub-menu
doesn't exit.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
git-add--interactive.perl | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index f9e9f02..be68814 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -219,7 +219,7 @@ sub list_and_choose {
last;
}
chomp $line;
- my $donesomething = 0;
+ last if $line eq '';
for my $choice (split(/[\s,]+/, $line)) {
my $choose = 1;
my ($bottom, $top);
@@ -251,12 +251,11 @@ sub list_and_choose {
next TOPLOOP;
}
for ($i = $bottom-1; $i <= $top-1; $i++) {
- next if (@stuff <= $i);
+ next if (@stuff <= $i || $i < 0);
$chosen[$i] = $choose;
- $donesomething++;
}
}
- last if (!$donesomething || $opts->{IMMEDIATE});
+ last if ($opts->{IMMEDIATE});
}
for ($i = 0; $i < @stuff; $i++) {
if ($chosen[$i]) {
--
1.5.3
^ permalink raw reply related
* [PATCH 1/2] git-add--interactive: Allow Ctrl-D to exit
From: Jean-Luc Herren @ 2007-09-26 13:56 UTC (permalink / raw)
To: git; +Cc: gitster
Hitting Ctrl-D (EOF) is a common way to exit shell-like tools.
When in a sub-menu it will still behave as if an empty line had
been entered, carrying out the action on the selected items and
returning to the previous menu.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
git-add--interactive.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 7921cde..f9e9f02 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -213,7 +213,11 @@ sub list_and_choose {
print ">> ";
}
my $line = <STDIN>;
- last if (!$line);
+ if (!$line) {
+ print "\n";
+ $opts->{ON_EOF}->() if $opts->{ON_EOF};
+ last;
+ }
chomp $line;
my $donesomething = 0;
for my $choice (split(/[\s,]+/, $line)) {
@@ -791,6 +795,7 @@ sub main_loop {
SINGLETON => 1,
LIST_FLAT => 4,
HEADER => '*** Commands ***',
+ ON_EOF => \&quit_cmd,
IMMEDIATE => 1 }, @cmd);
if ($it) {
eval {
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Schindelin @ 2007-09-26 14:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <46FA5604.101@viscovery.net>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Wed, 26 Sep 2007, Johannes Sixt wrote:
> >
> > > This allows a poor-mans-filter-branch of the top-most commit.
> > >
> > > Specifically, I had this history:
> > >
> > > --o--o--A' <-- amended version of A
> > > \
> > > A
> > > \
> > > --o--B--M
> > >
> > > I now wanted to "amend" M to pull in A' instead of A as its second
> > > parent. For various reasons I didn't want to redo the merge M again,
> > > in particular, it already contained the changes that were amended
> > > into A'. So I figured I would just install a graft that lists B and
> > > A' as parents of M and then do a simple git commit --amend. Alas,
> > > git commit looks at the real parents instead of the grafted ones, so
> > > the amended M' would still have A as its second parent. Here is the
> > > fix that picks the grafted parents instead.
> >
> > I do not think that this is a "fix".
> >
> > I'd really suggest that you fix it up (before the amend!) by
> > installing the graft, and running git-filter-branch -1 <branch>.
> > (Note: I did not test this, but it _should_ work. If it does not,
> > please let me know.)
>
> The problem with filter-branch is that it leaves a committer date in M
> that is before A', and for this reason is not the right tool for this
> task. So I do think that this fix is necessary.
But that's easily fixed with "--env-filter 'export
GIT_COMMITTER_DATE=$(date +%s)'" or something similar.
The reason why I insist on not putting this into --amend is that I think
this is not really an amend, but actively a rewrite of the merge commit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a --dateformat= option to git-for-each-ref
From: Jeff King @ 2007-09-26 12:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200709261009.18777.andyparkins@gmail.com>
On Wed, Sep 26, 2007 at 10:09:18AM +0100, Andy Parkins wrote:
> For example (I'm in BST, +0100 at present):
>
> $ git-for-each-ref --dateformat=normal --format='%(taggerdate)' refs/tags/v1.5.2
> Sun May 20 00:30:42 2007 -0700
> $ git-for-each-ref --dateformat=relative --format='%(taggerdate)' refs/tags/v1.5.2
> 4 months ago
What if you want a format that contains two dates in different formats?
Something like:
$ git-for-each-ref --format='%(committerdate:relative) %(authordate:normal)'
would be more flexible. Although perhaps that is a bit too unlikely to
be concerned with implementing, giving options to substitutions seems
like a sane way to implement these sorts of things (e.g.,
"%(objectsize:human)", "%(parent:1)", etc).
> + if (!prefixcmp(arg, "--dateformat=")) {
> + arg += 13;
> + if (!prefixcmp(arg,"relative")) {
> + date_mode = DATE_RELATIVE;
> + } else if (!prefixcmp(arg,"short")) {
> + date_mode = DATE_SHORT;
> + } else if (!prefixcmp(arg,"local")) {
> + date_mode = DATE_LOCAL;
> + } else if (!prefixcmp(arg,"iso8601")) {
> + date_mode = DATE_ISO8601;
> + } else if (!prefixcmp(arg,"rfc2822")) {
> + date_mode = DATE_RFC2822;
> + }
> + continue;
> + }
Surely this same code exists elsewhere, and could be easily factored out
into a parse_date_type function.
-Peff
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 12:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709261322150.28395@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 26 Sep 2007, Johannes Sixt wrote:
>
>> This allows a poor-mans-filter-branch of the top-most commit.
>>
>> Specifically, I had this history:
>>
>> --o--o--A' <-- amended version of A
>> \
>> A
>> \
>> --o--B--M
>>
>> I now wanted to "amend" M to pull in A' instead of A as its second
>> parent. For various reasons I didn't want to redo the merge M again, in
>> particular, it already contained the changes that were amended into A'.
>> So I figured I would just install a graft that lists B and A' as parents
>> of M and then do a simple git commit --amend. Alas, git commit looks at
>> the real parents instead of the grafted ones, so the amended M' would
>> still have A as its second parent. Here is the fix that picks the
>> grafted parents instead.
>
> I do not think that this is a "fix".
>
> I'd really suggest that you fix it up (before the amend!) by installing
> the graft, and running git-filter-branch -1 <branch>. (Note: I did not
> test this, but it _should_ work. If it does not, please let me know.)
The problem with filter-branch is that it leaves a committer date in M that
is before A', and for this reason is not the right tool for this task. So I
do think that this fix is necessary.
-- Hannes
^ permalink raw reply
* Re: Workflow question
From: Jeff King @ 2007-09-26 12:42 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F9CA2A.7000107@gmail.com>
On Tue, Sep 25, 2007 at 09:55:38PM -0500, Russ Brown wrote:
> Yes, this is very helpful indeed: thank you for that. /me bookmarks. I
> hadn't actually realised that rebase creates new commits and replaces
> your old ones: I'd thought they just got 'moved' (dunno how I thought it
> worked though!)
It's a necessity, since the commits are named by hash, and the hash
encompasses _all_ of the history. So the same change at a different
location in history will be a different commit.
And that is why rebases can make merging harder. Git can very quickly
compare two commits by hash and say "these are the same commit", or look
at them and say "one side has these changes, the other side has these
other changes, and here is where they meet." Rebasing ruins that, since
the same changes occur in two places with different names.
> I'm just wondering at this point why git lets you checkout remote
> tracking branches if it's something you really shouldn't do. Unless it's
> something you want to be able to do in edge cases to fix screwups maybe?
Junio explained in much more detail, but I use it largely for read-only
access ("oh, let me speed-test my branch against the upstream 'master'";
git-checkout master; test test test; git-checkout mybranch).
> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.
I agree. That sort of information is sprinkled throughout the mailing
list, but it might be nice on a wiki. I have thought of it as a sort of
"git cookbook" where you say "here is a recipe for accomplishing X". The
user manual comes close to this for smaller tasks.
-Peff
^ permalink raw reply
* Re: [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Schindelin @ 2007-09-26 12:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <11908086961933-git-send-email-johannes.sixt@telecom.at>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> This allows a poor-mans-filter-branch of the top-most commit.
>
> Specifically, I had this history:
>
> --o--o--A' <-- amended version of A
> \
> A
> \
> --o--B--M
>
> I now wanted to "amend" M to pull in A' instead of A as its second
> parent. For various reasons I didn't want to redo the merge M again, in
> particular, it already contained the changes that were amended into A'.
> So I figured I would just install a graft that lists B and A' as parents
> of M and then do a simple git commit --amend. Alas, git commit looks at
> the real parents instead of the grafted ones, so the amended M' would
> still have A as its second parent. Here is the fix that picks the
> grafted parents instead.
I do not think that this is a "fix".
I'd really suggest that you fix it up (before the amend!) by installing
the graft, and running git-filter-branch -1 <branch>. (Note: I did not
test this, but it _should_ work. If it does not, please let me know.)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-commit --amend: respect grafted parents.
From: Johannes Sixt @ 2007-09-26 12:11 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
This allows a poor-mans-filter-branch of the top-most commit.
Specifically, I had this history:
--o--o--A' <-- amended version of A
\
A
\
--o--B--M
I now wanted to "amend" M to pull in A' instead of A as its second parent.
For various reasons I didn't want to redo the merge M again, in particular,
it already contained the changes that were amended into A'. So I figured
I would just install a graft that lists B and A' as parents of M and then
do a simple git commit --amend. Alas, git commit looks at the real parents
instead of the grafted ones, so the amended M' would still have A as its
second parent. Here is the fix that picks the grafted parents instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I know that git-commit is becoming a builtin. At the least, here is
a test that makes sure that the behavior is remains.
-- Hannes
git-commit.sh | 4 ++--
t/t7501-commit.sh | 9 +++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
mode change 100644 => 100755 t/t7501-commit.sh
diff --git a/git-commit.sh b/git-commit.sh
index 7a7a2cb..33e7503 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -529,8 +529,8 @@ then
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
elif test -n "$amend"; then
rloga='commit (amend)'
- PARENTS=$(git cat-file commit HEAD |
- sed -n -e '/^$/q' -e 's/^parent /-p /p')
+ PARENTS=$(git rev-list --parents -1 HEAD |
+ sed -e 's/^[^ ]*//' -e 's/ / -p /g')
fi
current="$(git rev-parse --verify HEAD)"
else
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
old mode 100644
new mode 100755
index b151b51..09c0d98
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -163,4 +163,13 @@ test_expect_success 'partial commit that involves removal (3)' '
'
+test_expect_success '--amend respects grafts' '
+
+ grandparent=$(git rev-parse HEAD~2) &&
+ echo $(git rev-parse HEAD) $grandparent > .git/info/grafts &&
+ git commit --amend -C HEAD &&
+ test "parent $grandparent" = "$(git cat-file commit HEAD | grep "^parent")"
+
+'
+
test_done
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Sixt @ 2007-09-26 11:18 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <86zlz9smqr.fsf@lola.quinscape.zz>
David Kastrup schrieb:
> If $USE_OUTPUT can be either shell function or executable or shell
> function plus args, however...
UTSL: $USE_OUTPUT is either 'output' (ie. a shell function) or empty.
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] rebase -i: avoid exporting GIT_AUTHOR_* variables
From: Johannes Schindelin @ 2007-09-26 10:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <46FA358E.40500@viscovery.net>
Hi,
On Wed, 26 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 445a299..e3e89dd 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -174,7 +174,11 @@ pick_one_preserving_merges () {
> > eval "$author_script"
> > msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
> > # NEEDSWORK: give rerere a chance
> > - if ! output git merge $STRATEGY -m "$msg"
> > $new_parents
> > + if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > + output git merge $STRATEGY -m "$msg" \
> > + $new_parents
> > then
> > printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
> > die Error redoing merge $sha1
> > @@ -281,7 +285,9 @@ do_next () {
> > f)
> > # This is like --amend, but with a different message
> > eval "$author_script"
> > - export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> > GIT_AUTHOR_DATE
> > + GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > + GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > + GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > ;;
> > t)
>
> According to Herbert Xu's recent post
> (http://article.gmane.org/gmane.comp.version-control.git/59219) this won't
> export the variables in all shells since 'output' is a shell function. :-(
Argh.
You know, I am _so_ close to just scrap it and rewrite it in C.
Ciao,
Dscho
^ 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