* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-03 21:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510031522590.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Are these all before 1.0, or are some of them supposed to happen
> eventually but later?
The latter.
>> * Libification. There are many places "run once" mentality is
>> ingrained in the management of basic data structures, which
>> need to be fixed.
>
> I think this should be a post-1.0 thing; I think after 1.0, we should
> rearrange a lot of the code to make more sense from a programmer
> perspective.
I agree.
>> * Look at libified GNU diff CVS seems to use, or libxdiff.
>
> I've almost got a suffix-tree-based diff that works reasonably well,
> that's built as a library, and outputs unified diff. I need to merge it
> with git, hook up input from trees and blobs, and test it on a wider set
> of data.
Sounds like fun.
> I'd also like to add:
>
> * Accept patches to fetch multiple objects by HTTP in parallel.
>
> I think this may be necessary to get good performance without rsync for
> repositories hosted without specific git support.
Surely. I'd love to see you work with Nick Hengeveld on this
one, perhaps even before 1.0. Looking out the fetch.c code, I
think you already have set up a reasonable "work queue" during
the last round, with a lot of simplification thanks to Sergey,
and parallel fetching would be a very nice addition.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Matthias Urlichs @ 2005-10-03 20:48 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> * Libification. There are many places "run once" mentality is
> ingrained in the management of basic data structures, which need to be
> fixed.
I have started work on doing this "the right way"
(as per earlier discussion).
Current status: There's a toplevel "struct git_env", an associated "struct
git_objdb", and (thread-safe and globals-free) library code to read
sha1-identified object (meta)data, including packs and all.
http://netz.smurf.noris.de/git/git.git#libize
Next on my TODO list: introduce a "struct git_obj" which represents
exactly one sha1 and the metadata associated with it, rename the
accessor functions to be more consistent, add SWIG interface code and
Python testcases, submit to everybody's scrutinity.
After that, the task can hopefully be parallelized.
Definitely a post-1.0 job; the job is too big, and shipping 1.0 with a
partial library that doesn't do much that's useful does not make sense.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
We've sent a man to the moon, and that's 29,000 miles away. The center
of the Earth is only 4,000 miles away. You could drive that in a week,
but for some reason nobody's ever done it.
-- Andy Rooney
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-03 20:12 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051003200233.GC15593@reactrix.com>
On Mon, 3 Oct 2005, Nick Hengeveld wrote:
> On Mon, Oct 03, 2005 at 03:43:02PM -0400, Daniel Barkalow wrote:
>
> > * Accept patches to fetch multiple objects by HTTP in parallel.
> >
> > I think this may be necessary to get good performance without rsync for
> > repositories hosted without specific git support.
>
> I have a version of this almost working, but it's a nontrivial patch
> that feels more like a post-1.0 thing to me.
I'd be interested to see it anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Nick Hengeveld @ 2005-10-03 20:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510031522590.23242@iabervon.org>
On Mon, Oct 03, 2005 at 03:43:02PM -0400, Daniel Barkalow wrote:
> * Accept patches to fetch multiple objects by HTTP in parallel.
>
> I think this may be necessary to get good performance without rsync for
> repositories hosted without specific git support.
I have a version of this almost working, but it's a nontrivial patch
that feels more like a post-1.0 thing to me.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Martin Coxall @ 2005-10-03 19:55 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0510031522590.23242@iabervon.org>
> I'd also like to add:
>
> * Accept patches to fetch multiple objects by HTTP in parallel.
>
Indeed. As a humble user of git for our inhouse development, I can
vouch that HTTP pulling on unpacked repositories (i.e. all of them, it
seems) is appalling. Ship a 1.0 without addressing this, then I imagine
the Mercurial devs will haemorrage with their Pythonesque mocking. ;p
Martin
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Alan Chandler @ 2005-10-03 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
On Monday 03 Oct 2005 01:14, Junio C Hamano wrote:
...
>
> Technical (heavier)
> -------------------
...
> * Look at libified GNU diff CVS seems to use, or libxdiff.
>
I did wonder today in response to a discussion at work about version control
of documentation, whether git could in some way understand OpenDocument
format and allow some form of merging of concurrent changes to the same
document. I am not sure if just unzipping the files and applying standard
merge strategies the resultant xml would be good enough.
Sadly just a thought at the moment.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-03 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Oct 2005, Junio C Hamano wrote:
> What to expect after 0.99.8
> ===========================
>
> This is written in a form of to-do list for me, so if I say
> "accept patch", it means I do not currently plan to do that
> myself. People interested in seeing it materialize please take
> a hint.
Are these all before 1.0, or are some of them supposed to happen
eventually but later?
> Technical (heavier)
> -------------------
>
> * Libification. There are many places "run once" mentality is
> ingrained in the management of basic data structures, which
> need to be fixed.
I think this should be a post-1.0 thing; I think after 1.0, we should
rearrange a lot of the code to make more sense from a programmer
perspective.
> * 'git split-projects'? This requires updated 'git-rev-list' to
> skip irrelevant commits.
> Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
I thought about this some more, and realized that the operation to get
additions to the gitk history out of a git repository is going to be slow,
because you don't know the correct hashes for parents until you go all the
way back. Still worth doing, but less exciting than I'd hoped.
> * Look at libified GNU diff CVS seems to use, or libxdiff.
I've almost got a suffix-tree-based diff that works reasonably well,
that's built as a library, and outputs unified diff. I need to merge it
with git, hook up input from trees and blobs, and test it on a wider set
of data.
I'd also like to add:
* Accept patches to fetch multiple objects by HTTP in parallel.
I think this may be necessary to get good performance without rsync for
repositories hosted without specific git support.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: StGit command completions - and Git ones?
From: Blaisorblade @ 2005-10-03 17:57 UTC (permalink / raw)
To: Horst von Brand; +Cc: Catalin Marinas, git
In-Reply-To: <200510021737.j92HbjkK015752@inti.inf.utfsm.cl>
On Sunday 02 October 2005 19:37, Horst von Brand wrote:
> Blaisorblade <blaisorblade@yahoo.it> wrote:
> > I noticed in your TODO you talk about adding command line completions.
> > I've been doing it for my needs, and the thing is still very incomplete,
> > even if it's not a "XXX hack hack hack", and I wanted to send this first
> > draft.
> Why don't just lay this at the bash-completion people's feet?
Catalin put this in his TODO, and many projects install their additional bash
completions on their own, at least from the Gentoo user point of view.
In any case, I guess I'd rather contact them only when the work is at least
complete.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: H. Peter Anvin @ 2005-10-03 18:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510031113500.31407@g5.osdl.org>
Linus Torvalds wrote:
>
> Is it? The only place umask is mentioned in the man-page is
>
> --no-same-permissions
> apply user?s umask when extracting files instead of recorded
> permissions
>
> but if tar really does honor umask, then hey, that 0777/0666 is fine.
>
> (Ahh, googling a bit more, it appears that "-p" is default for root, which
> explains why you'd need the "anti-flag").
>
Yeah, that assymetry is rather unfortunate.
-hpa
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: Linus Torvalds @ 2005-10-03 18:18 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <434172FD.7020302@zytor.com>
On Mon, 3 Oct 2005, H. Peter Anvin wrote:
>
> Linus Torvalds wrote:
> >
> > As to tar: I think the current
> >
> > if (S_ISDIR(mode) || S_ISREG(mode))
> > mode |= (mode & 0100) ? 0777 : 0666;
> >
> > is wrong. It makes things world-writable by default, and that's just
> > dangerous.
>
> That's standard in the Unix world, though; of course, the user's umask
> shouldn't be set to zero unless things are in very special circumstances. In
> the case of tar, the umask is applied on extraction unless the user explicitly
> specifies -p.
Is it? The only place umask is mentioned in the man-page is
--no-same-permissions
apply user?s umask when extracting files instead of recorded
permissions
but if tar really does honor umask, then hey, that 0777/0666 is fine.
(Ahh, googling a bit more, it appears that "-p" is default for root, which
explains why you'd need the "anti-flag").
Linus
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: H. Peter Anvin @ 2005-10-03 18:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510031028370.31407@g5.osdl.org>
Linus Torvalds wrote:
>
> As to tar: I think the current
>
> if (S_ISDIR(mode) || S_ISREG(mode))
> mode |= (mode & 0100) ? 0777 : 0666;
>
> is wrong. It makes things world-writable by default, and that's just
> dangerous.
That's standard in the Unix world, though; of course, the user's umask
shouldn't be set to zero unless things are in very special
circumstances. In the case of tar, the umask is applied on extraction
unless the user explicitly specifies -p.
-hpa
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: Linus Torvalds @ 2005-10-03 17:45 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <43415C9A.1090502@zytor.com>
On Mon, 3 Oct 2005, H. Peter Anvin wrote:
>
> If the old-format (with random write bits) is out of circulation -- which I
> can't tell for sure they it is, but Linus' kernel tree doesn't seem to have
> any of these objects
Oh, it does.
Run "git-fsck-cache --full --strict", and you'll get several trees that
the strict checker marks as bad. I think it's mostly all one entry, namely
arch/i386/kernel/vsyscall-note.S being marked 0664.
Git itself has even more of them - the kernel actually has fewer, because
most work was done with a consistent umask of 022 (ie mostly mine), and by
the time others started using git actively, we'd already changed the git
rules.
However, there's nothing that says that we couldn't use one more bit in
the "mode" flag to just say "this is an _exact_ mode, please preserve it".
A kind of "sticky mode" for git. We've got _bits_ plenty: it's an ASCII
text-mode representation in the trees (infinite bits), and even in the
index it's a 32-bit thing that we only use 12 bits of (9 bits for
permissions, 3 bits for the sparsely represented directory/symlink/regular
file)
We'd have to be a bit careful to preserve that bit when doing an index
refresh, but it's really not very hard. The hardest part is actually doing
so for directories, since we don't keep the directories in the index at
_all_.
But the fact is, it wouldn't solve the git-tar-tree thing. We can
_represent_ exact masks, but we don't _want_ to, because normally it just
leads to horrible problems with different people having different umasks.
So in order to avoid having mode change merges, we'd _still_ have to make
the current "0666/0777 + umask" be the normal one, and you'd use this
"exact mode" thing only for very special cases (ie for backing up your
home directory or similar, _not: for a distributed SCM).
As to tar: I think the current
if (S_ISDIR(mode) || S_ISREG(mode))
mode |= (mode & 0100) ? 0777 : 0666;
is wrong. It makes things world-writable by default, and that's just
dangerous. "tar" normally won't apply umask when untarring (there's a flag
for it, but I have never ever used it myself, and I doubt anybody else
really does either - it's called "--no-same-permissions" in GNU tar).
I think a "0775" or "0664" might be acceptable (an umask of 002 is at
least _normal_), but I suspect 0755/0644 is really better. Doing a simple
chmod -R +w
afterwards is better (and takes umask into account) than a "chmod -R o-w",
since the latter leaves the tree writable for a while.
Ie default permissions are better off being too strict than too lax. Basic
security.
Of course, if we were to add the "exact mode" bit, then git-tar-tree
should obviously honor that for any files that have that bit set.
Linus
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: H. Peter Anvin @ 2005-10-03 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xxasenp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> For in-cache permission mode bits, we would probably need
> something like this:
>
> * git-update-index will pick up the filesystem bits with the
> current semantics (i.e. look only at (mode & 0100) and
> force 0644 or 0755) by default; --full-perm-bits option
> would bypass this bits munging.
>
> Once a file is added with --full-perm-bits, it might be
> nice if index file remembers to pick up the full bits next
> time git-update-index is run on the path. This could be
> achieved by saying that anything stored in the cache with
> non 100644, 100755 nor 120000 bits are such paths without
> having to change the index file format.
>
One could also say that since oddball permissions are an exception, not
the rule, that one should use a "git-chmod" command to enter the
permissions in the cache. The correct answer is probably *both* that
and --full-permissions (or whatever) since they both probably apply to
different workflows.
-hpa
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: Junio C Hamano @ 2005-10-03 17:18 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43415C9A.1090502@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> As you stated above, we currently use this field in a very inefficient
> manner, because of old mistakes. There are several ways to recover from
> here, some of which are more complex than others.
Solution for in-tree permission mode bits you outlined looked
fine (I'll have to re-read the part about "mode xor (mode &
022)..." part later, though).
For in-cache permission mode bits, we would probably need
something like this:
* git-update-index will pick up the filesystem bits with the
current semantics (i.e. look only at (mode & 0100) and
force 0644 or 0755) by default; --full-perm-bits option
would bypass this bits munging.
Once a file is added with --full-perm-bits, it might be
nice if index file remembers to pick up the full bits next
time git-update-index is run on the path. This could be
achieved by saying that anything stored in the cache with
non 100644, 100755 nor 120000 bits are such paths without
having to change the index file format.
* there are bunch of codes that assume 0644 and 0755 are the
norm but also know that there are ancient trees that have
0664 and 0775 and try to treat them equivalently. They need
to be selectively neutered; this applies to in-tree
permission bits as well.
git-read-tree will read permission mode bits from tree
object as-is. I.e. you will get 0644 and 0755 in cache from
the existing tree objects. When you check things out with
002 umask, you will get 0664 and 0775 on the filesystem. We
do not want to consider this "mode changed by the user".
git-update-index --refresh code should not be mode neutered
to prevent this. The same thing goes for diff. These
currently canonicalize mode bits by looking at (mode &
0100), but should be changed to do so only when index has
already the canonical mode bits, or something like that.
* git-write-tree and git-fsck-objects probably has code to
reject and correct abnormal mode bits. They need to be
neutered.
^ permalink raw reply
* [PATCH] Random documentation fixes
From: Jonas Fonseca @ 2005-10-03 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sun, Oct 02, 2005:
> Documentation
> -------------
> * Accept patches to make formatted tables in asciidoc to work
> well in both html and man pages (see git-diff(1)).
I went through the docs and have attached a patch fixing some
formattings that was causing bad rendering. Note, I have mostly
concentrated on getting the HTML better.
In order to fix the manpages we probably have add our own docbook hooks
to convert everything to verbatim form instead of tables, which
apparently cannot be handled well by xmlto. I haven't tried it though,
just an idea.
Another thing, a lot of the manpages have long synopsis lines spanning
multiple lines. In both the man and HTML pages they are turned into one
long line. I found that wrapping them in something like:
SYNOPSIS
--------
+[verse]
+.........................................................................
'git-cvsimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
[ -C <GIT_repository> ] [ -i ] [ -k ]
[ -s <subst> ] [ -m ] [ -M regex ] [ <CVS_module> ]
+.........................................................................
will make it look like intended. I don't know if sacrificing readability
of the *.txt files for improved generated docs is acceptable. If not the
patch below should probably also be filtered a bit.
Another thing (sorry for putting it all in one mail), what about also
documenting all Makefile configuration variables, such as:
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -29,6 +29,8 @@
#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
#
+# Define WITH_SEND_EMAIL if you have the Perl Sendmail module installed
+#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
---
The fixes focuses on improving the HTML output. Most noteworthy:
- Fix the Makefile to also make various *.html files depend on
included files.
- Consistently use 'NOTE: ...' instead of '[ ... ]' for additional
info.
- Fix ending '::' for description lists in OPTION section etc.
- Fix paragraphs in description lists ending up as preformated text.
- Always use listingblocks (preformatted text wrapped in lines with -----)
for examples that span empty lines, so they are put in only one HTML
block.
- Use '1.' instead of '(1)' for numbered lists.
- Fix linking to other GIT docs.
- git-rev-list.txt: put option descriptions in an OPTION section.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 3 +
Documentation/cvs-migration.txt | 8 +-
Documentation/diffcore.txt | 12 ++-
Documentation/git-applypatch.txt | 2 -
Documentation/git-bisect.txt | 2 -
Documentation/git-cherry-pick.txt | 6 +-
Documentation/git-commit-tree.txt | 6 +-
Documentation/git-cvsimport.txt | 10 +--
Documentation/git-diff-index.txt | 8 +-
Documentation/git-diff-tree.txt | 22 +++---
Documentation/git-fetch.txt | 2 -
Documentation/git-fsck-objects.txt | 8 +-
Documentation/git-ls-files.txt | 20 +++--
Documentation/git-pack-objects.txt | 3 +
Documentation/git-prune-packed.txt | 3 +
Documentation/git-read-tree.txt | 4 +
Documentation/git-repack.txt | 3 +
Documentation/git-rev-list.txt | 72 ++++++++++---------
Documentation/git-revert.txt | 6 +-
Documentation/git-send-email.txt | 16 ++--
Documentation/git-send-pack.txt | 8 +-
Documentation/git-sh-setup.txt | 9 +-
Documentation/git-update-index.txt | 2 -
Documentation/git-var.txt | 14 ++--
Documentation/git-verify-pack.txt | 14 ++--
Documentation/pull-fetch-param.txt | 138 +++++++++++++++++-------------------
27 files changed, 211 insertions(+), 192 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -53,6 +53,9 @@ install: man
$(patsubst %.txt,%.1,$(wildcard git-diff-*.txt)): \
diff-format.txt diff-options.txt
$(patsubst %,%.1,git-fetch git-pull git-push): pull-fetch-param.txt
+$(patsubst %.txt,%.html,$(wildcard git-diff-*.txt)): \
+ diff-format.txt diff-options.txt
+$(patsubst %,%.html,git-fetch git-pull git-push): pull-fetch-param.txt
git.7: ../README
clean:
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -229,10 +229,10 @@ does rename or copy would not show in th
"o-file.c", it would find the commit that changed the statement
when it was in "o-file.c".
-[ BTW, the current versions of "git-diff-tree -C" is not eager
+NOTE: The current versions of "git-diff-tree -C" is not eager
enough to find copies, and it will miss the fact that a-file.c
was created by copying o-file.c unless o-file.c was somehow
- changed in the same commit.]
+ changed in the same commit.
You can use the --pickaxe-all flag in addition to the -S flag.
This causes the differences from all the files contained in
@@ -243,6 +243,6 @@ that contain this changed "if" statement
nitfol();
}' --pickaxe-all
-[ Side note. This option is called "--pickaxe-all" because -S
+NOTE: This option is called "--pickaxe-all" because -S
option is internally called "pickaxe", a tool for software
- archaeologists.]
+ archaeologists.
diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt
--- a/Documentation/diffcore.txt
+++ b/Documentation/diffcore.txt
@@ -254,11 +254,11 @@ As an example, typical orderfile for the
would look like this:
------------------------------------------------
- README
- Makefile
- Documentation
- *.h
- *.c
- t
+README
+Makefile
+Documentation
+*.h
+*.c
+t
------------------------------------------------
diff --git a/Documentation/git-applypatch.txt b/Documentation/git-applypatch.txt
--- a/Documentation/git-applypatch.txt
+++ b/Documentation/git-applypatch.txt
@@ -30,7 +30,7 @@ OPTIONS
<patch>::
The patch to apply.
-<info>:
+<info>::
Author and subject information extracted from e-mail,
used on "author" line and as the first line of the
commit log message.
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -91,7 +91,7 @@ Author
Written by Linus Torvalds <torvalds@osdl.org>
Documentation
---------------
+-------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -38,9 +38,9 @@ OPTIONS
option is used, your working tree does not have to match
the HEAD commit. The cherry-pick is done against the
beginning state of your working tree.
-
- This is useful when cherry-picking more than one commits'
- effect to your working tree in a row.
++
+This is useful when cherry-picking more than one commits'
+effect to your working tree in a row.
Author
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -58,11 +58,11 @@ following environment variables.
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
-(nb <,> and '\n's are stripped)
+(nb "<", ">" and "\n"s are stripped)
A commit comment is read from stdin (max 999 chars). If a changelog
-entry is not provided via '<' redirection, "git-commit-tree" will just wait
-for one to be entered and terminated with ^D
+entry is not provided via "<" redirection, "git-commit-tree" will just wait
+for one to be entered and terminated with ^D.
Diagnostics
-----------
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -51,15 +51,15 @@ OPTIONS
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
Use this option if you want to import into a different branch.
-
- Use '-o master' for continuing an import that was initially done by
- the old cvs2git tool.
++
+Use '-o master' for continuing an import that was initially done by
+the old cvs2git tool.
-p <options-for-cvsps>::
Additional options for cvsps.
The options '-u' and '-A' are implicit and should not be used here.
-
- If you need to pass multiple options, separate them with a comma.
++
+If you need to pass multiple options, separate them with a comma.
-m::
Attempt to detect merges based on the commit message. This option
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -86,8 +86,8 @@ the more useful of the two in that what
a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
The non-cached version asks the question:
- show me the differences between HEAD and the currently checked out
- tree - index contents _and_ files that aren't up-to-date
+ show me the differences between HEAD and the currently checked out
+ tree - index contents _and_ files that aren't up-to-date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the "git-diff-tree -r"
@@ -107,13 +107,13 @@ not up-to-date and may contain new stuff
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
-NOTE! As with other commands of this type, "git-diff-index" does not
+NOTE: As with other commands of this type, "git-diff-index" does not
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
"git-upate-cache" it to make the cache be in sync.
-NOTE 2! You can have a mixture of files show up as "has been updated"
+NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
tell which file is in which state, since the "has been updated" ones
show a valid sha1, and the "not in sync with the index" ones will
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -101,16 +101,18 @@ An example of normal usage is:
which tells you that the last commit changed just one file (it's from
this one:
- commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
- tree 5319e4d609cdd282069cc4dce33c1db559539b03
- parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
- author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
- committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
-
- Make "git-fsck-objects" print out all the root commits it finds.
-
- Once I do the reference tracking, I'll also make it print out all the
- HEAD commits it finds, which is even more interesting.
+-----------------------------------------------------------------------------
+commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
+tree 5319e4d609cdd282069cc4dce33c1db559539b03
+parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
+author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+
+Make "git-fsck-objects" print out all the root commits it finds.
+
+Once I do the reference tracking, I'll also make it print out all the
+HEAD commits it finds, which is even more interesting.
+-----------------------------------------------------------------------------
in case you care).
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -39,7 +39,7 @@ Written by Linus Torvalds <torvalds@osdl
Junio C Hamano <junkio@cox.net>
Documentation
---------------
+-------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -19,9 +19,9 @@ OPTIONS
-------
<object>::
An object to treat as the head of an unreachability trace.
-
- If no objects are given, git-fsck-objects defaults to using the
- index file and all SHA1 references in .git/refs/* as heads.
++
+If no objects are given, git-fsck-objects defaults to using the
+index file and all SHA1 references in .git/refs/* as heads.
--unreachable::
Print out objects that exist but that aren't readable from any
@@ -128,7 +128,7 @@ GIT_OBJECT_DIRECTORY::
GIT_INDEX_FILE::
used to specify the index file of the cache
-GIT_ALTERNATE_OBJECT_DIRECTORIES:
+GIT_ALTERNATE_OBJECT_DIRECTORIES::
used to specify additional object database roots (usually unset)
Author
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -70,11 +70,11 @@ OPTIONS
-t::
Identify the file status with the following tags (followed by
a space) at the start of each line:
- H cached
- M unmerged
- R removed/deleted
- C modifed/changed
- K to be killed
+ H:: cached
+ M:: unmerged
+ R:: removed/deleted
+ C:: modifed/changed
+ K:: to be killed
? other
--::
@@ -110,13 +110,13 @@ flags --others or --ignored are specifie
These exclude patterns come from these places:
- (1) command line flag --exclude=<pattern> specifies a single
+ 1. command line flag --exclude=<pattern> specifies a single
pattern.
- (2) command line flag --exclude-from=<file> specifies a list of
+ 2. command line flag --exclude-from=<file> specifies a list of
patterns stored in a file.
- (3) command line flag --exclude-per-directory=<name> specifies
+ 3. command line flag --exclude-per-directory=<name> specifies
a name of the file in each directory 'git-ls-files'
examines, and if exists, its contents are used as an
additional list of patterns.
@@ -168,12 +168,13 @@ An exclude pattern is of the following f
- otherwise, it is a shell glob pattern, suitable for
consumption by fnmatch(3) with FNM_PATHNAME flag. I.e. a
slash in the pattern must match a slash in the pathname.
- "Documentation/*.html" matches "Documentation/git.html" but
+ "Documentation/\*.html" matches "Documentation/git.html" but
not "ppc/ppc.html". As a natural exception, "/*.c" matches
"cat-file.c" but not "mozilla-sha1/sha1.c".
An example:
+--------------------------------------------------------------
$ cat .git/ignore
# ignore objects and archives, anywhere in the tree.
*.[oa]
@@ -186,6 +187,7 @@ An example:
--exclude='Documentation/*.[0-9]' \
--exclude-from=.git/ignore \
--exclude-per-directory=.gitignore
+--------------------------------------------------------------
See Also
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -76,7 +76,8 @@ Documentation by Junio C Hamano
See-Also
--------
-git-repack(1) git-prune-packed(1)
+gitlink:git-repack[1]
+gitlink:git-prune-packed[1]
GIT
---
diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt
--- a/Documentation/git-prune-packed.txt
+++ b/Documentation/git-prune-packed.txt
@@ -34,7 +34,8 @@ Documentation by Ryan Anderson <ryan@mic
See-Also
--------
-git-pack-objects(1) git-repack(1)
+gitlink:git-pack-objects[1]
+gitlink:git-repack[1]
GIT
---
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -84,10 +84,10 @@ fast forward situation).
When two trees are specified, the user is telling git-read-tree
the following:
- (1) The current index and work tree is derived from $H, but
+ 1. The current index and work tree is derived from $H, but
the user may have local changes in them since $H;
- (2) The user wants to fast-forward to $M.
+ 2. The user wants to fast-forward to $M.
In this case, the "git-read-tree -m $H $M" command makes sure
that no local change is lost as the result of this "merge".
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -51,7 +51,8 @@ Documentation by Ryan Anderson <ryan@mic
See-Also
--------
-git-pack-objects(1) git-prune-packed(1)
+gitlink:git-pack-objects[1]
+gitlink:git-prune-packed[1]
GIT
---
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -22,65 +22,69 @@ that point. Their parents are implied. "
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".
-If *--pretty* is specified, print the contents of the commit changesets
-in human-readable form.
-
-The *--objects* flag causes 'git-rev-list' to print the object IDs of
-any object referenced by the listed commits. 'git-rev-list --objects foo
-^bar' thus means "send me all object IDs which I need to download if
-I have the commit object 'bar', but not 'foo'".
-
-The *--bisect* flag limits output to the one commit object which is
-roughly halfway between the included and excluded commits. Thus,
-if 'git-rev-list --bisect foo ^bar
-^baz' outputs 'midpoint', the output
-of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
-^bar
-^baz'
-would be of roughly the same length. Finding the change which introduces
-a regression is thus reduced to a binary search: repeatedly generate and
-test new 'midpoint's until the commit chain is of length one.
-
-If *--merge-order* is specified, the commit history is decomposed into a
-unique sequence of minimal, non-linear epochs and maximal, linear epochs.
-Non-linear epochs are then linearised by sorting them into merge order, which
-is described below.
-
+OPTIONS
+-------
+--pretty::
+ Print the contents of the commit changesets in human-readable form.
+
+--objects::
+ Print the object IDs of any object referenced by the listed commits.
+ 'git-rev-list --objects foo ^bar' thus means "send me all object IDs
+ which I need to download if I have the commit object 'bar', but
+ not 'foo'".
+
+--bisect::
+ Limit output to the one commit object which is roughly halfway
+ between the included and excluded commits. Thus, if 'git-rev-list
+ --bisect foo ^bar ^baz' outputs 'midpoint', the output
+ of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
+ ^bar ^baz' would be of roughly the same length. Finding the change
+ which introduces a regression is thus reduced to a binary search:
+ repeatedly generate and test new 'midpoint's until the commit chain
+ is of length one.
+
+--merge-order::
+ When specified the commit history is decomposed into a unique
+ sequence of minimal, non-linear epochs and maximal, linear epochs.
+ Non-linear epochs are then linearised by sorting them into merge
+ order, which is described below.
++
Maximal, linear epochs correspond to periods of sequential development.
Minimal, non-linear epochs correspond to periods of divergent development
followed by a converging merge. The theory of epochs is described in more
detail at
link:http://blackcubes.dyndns.org/epoch/[http://blackcubes.dyndns.org/epoch/].
-
++
The merge order for a non-linear epoch is defined as a linearisation for which
the following invariants are true:
-
++
1. if a commit P is reachable from commit N, commit P sorts after commit N
in the linearised list.
2. if Pi and Pj are any two parents of a merge M (with i < j), then any
commit N, such that N is reachable from Pj but not reachable from Pi,
sorts before all commits reachable from Pi.
-
++
Invariant 1 states that later commits appear before earlier commits they are
derived from.
-
++
Invariant 2 states that commits unique to "later" parents in a merge, appear
before all commits from "earlier" parents of a merge.
-If *--show-breaks* is specified, each item of the list is output with a
-2-character prefix consisting of one of: (|), (^), (=) followed by a space.
-
+--show-breaks::
+ Each item of the list is output with a 2-character prefix consisting
+ of one of: (|), (^), (=) followed by a space.
++
Commits marked with (=) represent the boundaries of minimal, non-linear epochs
and correspond either to the start of a period of divergent development or to
the end of such a period.
-
++
Commits marked with (|) are direct parents of commits immediately preceding
the marked commit in the list.
-
++
Commits marked with (^) are not parents of the immediately preceding commit.
These "breaks" represent necessary discontinuities implied by trying to
represent an arbtirary DAG in a linear form.
-
++
*--show-breaks* is only valid if *--merge-order* is also specified.
Author
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -29,9 +29,9 @@ OPTIONS
working tree does not have to match the HEAD commit.
The revert is done against the beginning state of your
working tree.
-
- This is useful when reverting more than one commits'
- effect to your working tree in a row.
++
+This is useful when reverting more than one commits'
+effect to your working tree in a row.
Author
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -21,35 +21,37 @@ The header of the email is configurable
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
+OPTIONS
+-------
The options available are:
- --to
+--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
project involved.
- --from
+--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
The user will still be prompted to confirm this entry.
- --compose
+--compose::
Use \$EDITOR to edit an introductory message for the
patch series.
- --subject
+--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
- --in-reply-to
+--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
instead of this if --chain-reply-to is set (the default)
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
- --chain-reply-to, --no-chain-reply-to
+--chain-reply-to, --no-chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
@@ -57,7 +59,7 @@ The options available are:
entire patch series.
Default is --chain-reply-to
- --smtp-server
+--smtp-server::
If set, specifies the outgoing SMTP server to use. Defaults to
localhost.
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -61,9 +61,9 @@ this flag.
Without '--all' and without any '<ref>', the refs that exist
both on the local side and on the remote side are updated.
-When '<ref>'s are specified explicitly, it can be either a
+When one or more '<ref>' are specified explicitly, it can be either a
single pattern, or a pair of such pattern separated by a colon
-':' (this means that a ref name cannot have a colon in it). A
+":" (this means that a ref name cannot have a colon in it). A
single pattern '<name>' is just a shorthand for '<name>:<name>'.
Each pattern pair consists of the source side (before the colon)
@@ -79,10 +79,10 @@ destination side.
- If <dst> does not match any remote ref, either
- - it has to start with "refs/"; <dst> is used as the
+ * it has to start with "refs/"; <dst> is used as the
destination literally in this case.
- - <src> == <dst> and the ref that matched the <src> must not
+ * <src> == <dst> and the ref that matched the <src> must not
exist in the set of remote refs; the ref matched <src>
locally is used as the name of the destination.
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -14,11 +14,12 @@ DESCRIPTION
Sets up the normal git environment variables and a few helper functions
(currently just "die()"), and returns ok if it all looks like a git archive.
-So use it something like
+So, to make the rest of the git scripts more careful and readable,
+use it as follows:
- . git-sh-setup || die "Not a git archive"
-
-to make the rest of the git scripts more careful and readable.
+-------------------------------------------------
+. git-sh-setup || die "Not a git archive"
+-------------------------------------------------
Author
------
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -101,7 +101,7 @@ Using --cacheinfo or --info-only
current working directory. This is useful for minimum-checkout
merging.
- To pretend you have a file with mode and sha1 at path, say:
+To pretend you have a file with mode and sha1 at path, say:
$ git-update-index --cacheinfo mode sha1 path
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -15,21 +15,23 @@ DESCRIPTION
-----------
Prints a git logical variable.
--l causes the logical variables to be listed.
+OPTIONS
+-------
+-l::
+ Cause the logical variables to be listed.
EXAMPLE
--------
-$git-var GIT_AUTHOR_IDENT
-
-Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+ $ git-var GIT_AUTHOR_IDENT
+ Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
VARIABLES
----------
-GIT_AUTHOR_IDENT
+GIT_AUTHOR_IDENT::
The author of a piece of code.
-GIT_COMMITTER_IDENT
+GIT_COMMITTER_IDENT::
The person who put a piece of code into git.
Diagnostics
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
--- a/Documentation/git-verify-pack.txt
+++ b/Documentation/git-verify-pack.txt
@@ -25,15 +25,19 @@ OPTIONS
-v::
After verifying the pack, show list of objects contained
- in the pack. The format used is:
+ in the pack.
- SHA1 type size offset-in-packfile
+OUTPUT FORMAT
+-------------
+When specifying the -v option the format used is:
- for objects that are not deltified in the pack, and
+ SHA1 type size offset-in-packfile
- SHA1 type size offset-in-packfile depth base-SHA1
+for objects that are not deltified in the pack, and
- for objects that are deltified.
+ SHA1 type size offset-in-packfile depth base-SHA1
+
+for objects that are deltified.
Author
------
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -2,84 +2,78 @@
The "remote" repository to pull from. One of the
following notations can be used to name the repository
to pull from:
-
- Rsync URL
- rsync://remote.machine/path/to/repo.git/
-
- HTTP(s) URL
- http://remote.machine/path/to/repo.git/
-
- GIT URL
- git://remote.machine/path/to/repo.git/
- remote.machine:/path/to/repo.git/
-
- Local directory
- /path/to/repo.git/
-
- In addition to the above, as a short-hand, the name of a
- file in $GIT_DIR/remotes directory can be given; the
- named file should be in the following format:
-
- URL: one of the above URL format
- Push: <refspec>...
- Pull: <refspec>...
-
- When such a short-hand is specified in place of
- <repository> without <refspec> parameters on the command
- line, <refspec>... specified on Push lines or Pull lines
- are used for "git push" and "git fetch/pull",
- respectively.
-
- The name of a file in $GIT_DIR/branches directory can be
- specified as an older notation short-hand; the named
- file should contain a single line, a URL in one of the
- above formats, optionally followed by a hash '#' and the
- name of remote head (URL fragment notation).
- $GIT_DIR/branches/<remote> file that stores a <url>
- without the fragment is equivalent to have this in the
- corresponding file in the $GIT_DIR/remotes/ directory
-
- URL: <url>
- Pull: refs/heads/master:<remote>
-
- while having <url>#<head> is equivalent to
-
- URL: <url>
- Pull: refs/heads/<head>:<remote>
++
+===============================================================
+- Rsync URL: rsync://remote.machine/path/to/repo.git/
+- HTTP(s) URL: http://remote.machine/path/to/repo.git/
+- GIT URL: git://remote.machine/path/to/repo.git/
+ or remote.machine:/path/to/repo.git/
+- Local directory: /path/to/repo.git/
+===============================================================
++
+In addition to the above, as a short-hand, the name of a
+file in $GIT_DIR/remotes directory can be given; the
+named file should be in the following format:
++
+ URL: one of the above URL format
+ Push: <refspec>...
+ Pull: <refspec>...
++
+When such a short-hand is specified in place of
+<repository> without <refspec> parameters on the command
+line, <refspec>... specified on Push lines or Pull lines
+are used for "git push" and "git fetch/pull",
+respectively.
++
+The name of a file in $GIT_DIR/branches directory can be
+specified as an older notation short-hand; the named
+file should contain a single line, a URL in one of the
+above formats, optionally followed by a hash '#' and the
+name of remote head (URL fragment notation).
+$GIT_DIR/branches/<remote> file that stores a <url>
+without the fragment is equivalent to have this in the
+corresponding file in the $GIT_DIR/remotes/ directory
++
+ URL: <url>
+ Pull: refs/heads/master:<remote>
++
+while having <url>#<head> is equivalent to
++
+ URL: <url>
+ Pull: refs/heads/<head>:<remote>
<refspec>::
The canonical format of a <refspec> parameter is
'+?<src>:<dst>'; that is, an optional plus '+', followed
by the source ref, followed by a colon ':', followed by
the destination ref.
-
- When used in "git push", the <src> side can be an
- arbitrary "SHA1 expression" that can be used as an
- argument to "git-cat-file -t". E.g. "master~4" (push
- four parents before the current master head).
-
- For "git push", the local ref that matches <src> is used
- to fast forward the remote ref that matches <dst>. If
- the optional plus '+' is used, the remote ref is updated
- even if it does not result in a fast forward update.
-
- For "git fetch/pull", the remote ref that matches <src>
- is fetched, and if <dst> is not empty string, the local
- ref that matches it is fast forwarded using <src>.
- Again, if the optional plus '+' is used, the local ref
- is updated even if it does not result in a fast forward
- update.
-
- Some short-cut notations are also supported.
-
- * For backward compatibility, "tag" is almost ignored;
- it just makes the following parameter <tag> to mean a
- refspec "refs/tags/<tag>:refs/tags/<tag>".
-
- * A parameter <ref> without a colon is equivalent to
- <ref>: when pulling/fetching, and <ref>:<ref> when
- pushing. That is, do not store it locally if
- fetching, and update the same name if pushing.
++
+When used in "git push", the <src> side can be an
+arbitrary "SHA1 expression" that can be used as an
+argument to "git-cat-file -t". E.g. "master~4" (push
+four parents before the current master head).
++
+For "git push", the local ref that matches <src> is used
+to fast forward the remote ref that matches <dst>. If
+the optional plus '+' is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+For "git fetch/pull", the remote ref that matches <src>
+is fetched, and if <dst> is not empty string, the local
+ref that matches it is fast forwarded using <src>.
+Again, if the optional plus '+' is used, the local ref
+is updated even if it does not result in a fast forward
+update.
++
+Some short-cut notations are also supported.
++
+* For backward compatibility, "tag" is almost ignored;
+ it just makes the following parameter <tag> to mean a
+ refspec "refs/tags/<tag>:refs/tags/<tag>".
+* A parameter <ref> without a colon is equivalent to
+ <ref>: when pulling/fetching, and <ref>:<ref> when
+ pushing. That is, do not store it locally if
+ fetching, and update the same name if pushing.
-a, \--append::
Append ref names and object names of fetched refs to the
--
Jonas Fonseca
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: H. Peter Anvin @ 2005-10-03 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virwfuqwv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>My point is that I believe it should. It has the bitfield for it, it
>>just doesn't use it at the moment.
>
>
> It is a bit more complicated than that.
>
> Long time ago, we used to store the full permission bits and
> ended up storing files in 0644 and 0664 modes, depending on who
> is writing the tree object. People with umask 022 checked out
> from a tree that recorded blobs with 0664 bits and ended up
> getting "mode changed" diff all the time, which was unacceptable
> from the SCM point of view. We _could_ have really changed the
> mode bits representation in the tree objects back then to have
> type + executable bit, but to preserve backward compatibility,
> we chose to keep the bitfield layout and changed the code to
> treat 1006xx and 1007yy in older trees to be equivalent to
> 100644 and 100755. These days, for newly written tree objects,
> above xx and yy 6-bit fields are "Must Be 4" and "Must Be 5"
> fields, respectively, not bitfields to store arbitrary group and
> other permission information. git-fsck-objects even complains
> about them.
>
> So in that sense, it does _not_ have the bitfield for it, and
> obviously we cannot use what we do not have.
>
Welcome to the wonderful world of evolving file formats.
As you stated above, we currently use this field in a very inefficient
manner, because of old mistakes. There are several ways to recover from
here, some of which are more complex than others.
In the case of git, there isn't just the requirement to maintain old
formats indefinitely (due to the cryptographic chain), but also that new
objects that are compatible with old format should be written in the old
format to maintain the aliasing properties. These are obstacles that
are perfectly possible to overcome, although it takes a bit of legwork.
If the old-format (with random write bits) is out of circulation --
which I can't tell for sure they it is, but Linus' kernel tree doesn't
seem to have any of these objects -- then the answer is very simple:
redefine this field _a posteori_ to be the mode ^ 022 (or perhaps more
sanely,
mode ^ (mode & 0200 ? 022 : 0)). Compatibility and contents is fully
preserved. No problem.
If there are still old-format trees in circulation and compatibility
with these very old trees need to be maintained, then it's a bit more
complicated, but literally just a bit. This data is already stored in
text form in the object store, so there aren't any funnies with
expanding it. For example, encode a leading + on the octal value if
this is a value with "I really mean it" permissions (and *only* those
values.) This is even readable by older versions of git, since they
will just blindly ignore the + sign.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Horst von Brand @ 2005-10-03 15:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vfyrjw8qb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
> > If you were to publish the ToDo to the mailing list once a week it might
> > encourage more of those patches you want to accept.
>
> Hmph. I tend to dislike periodical posting that is more often
> than once a month.
>
> >> * Accept patches to finish missing docs.
> >
> > A list of missing, incomplete, and/or wrong docs in the ToDo file would
> > help focus effort when people (like me) have space cycles.
> Well, the thing is, I am not good at documentation, especially
> when I have other interests, and once I start writing a list of
> missing or incomplete docs, my interests _will_ shift to fill in
> those gaps and I will end up doing them myself, which means I
> would not have a chance to place the list in the TODO file.
Then put the following on the TODO list:
* Accept patches to the TODO list for missing/incomplete/... documentation
;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [ANNOUNCE] Stacked GIT 0.7
From: Catalin Marinas @ 2005-10-03 14:44 UTC (permalink / raw)
To: Ingo Molnar; +Cc: GIT
In-Reply-To: <b0943d9e0510030656l4535bec7u@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> After some tests, it looks like 'git-diff-tree -p ... | git-apply
> --index' is about 3 times faster than 'git-read-tree -m' (in the best
> case for git-read-tree with minor modifications of the base). It now
> takes ~0.5s to push a single patch (compared to ~1.5s).
And that's the patch for whoever wants to try. I will also add it to
the repository tonight:
Optimise 'push' to use git-apply instead of git-read-tree
With this patch, 'push' will use 'git-diff-tree | git-apply' first. If this
operation fails, it will fall back to the three-way merge with
git-read-tree.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/git.py | 9 +++++++++
stgit/stack.py | 19 +++++++++++--------
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -355,6 +355,15 @@ def commit(message, files = [], parents
return commit_id
+def apply_diff(rev1, rev2):
+ """Apply the diff between rev1 and rev2 onto the current
+ index. This function doesn't need to raise an exception since it
+ is only used for fast-pushing a patch. If this operation fails,
+ the pushing would fall back to the three-way merge.
+ """
+ return os.system('git-diff-tree -p %s %s | git-apply --index 2> /dev/null'
+ % (rev1, rev2)) == 0
+
def merge(base, head1, head2):
"""Perform a 3-way merge between base, head1 and head2 into the
local tree
diff --git a/stgit/stack.py b/stgit/stack.py
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -598,14 +598,17 @@ class Series:
# The current patch is empty after merge.
patch.set_bottom(head, backup = True)
patch.set_top(head, backup = True)
- # merge/refresh can fail but the patch needs to be pushed
- try:
- git.merge(bottom, head, top)
- except git.GitException, ex:
- print >> sys.stderr, \
- 'The merge failed during "push". ' \
- 'Use "refresh" after fixing the conflicts'
- pass
+
+ # Try the fast applying first. If this fails, fall back to the
+ # three-way merge
+ if not git.apply_diff(bottom, top):
+ # merge can fail but the patch needs to be pushed
+ try:
+ git.merge(bottom, head, top)
+ except git.GitException, ex:
+ print >> sys.stderr, \
+ 'The merge failed during "push". ' \
+ 'Use "refresh" after fixing the conflicts'
append_string(self.__applied_file, name)
--
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] Stacked GIT 0.7
From: Catalin Marinas @ 2005-10-03 13:56 UTC (permalink / raw)
To: Ingo Molnar; +Cc: GIT
In-Reply-To: <b0943d9e0510021233n39daa5bao@mail.gmail.com>
On 02/10/05, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> An optimisation would be to keep the patches in diff format and apply
> them but this would mean losing the advantages of the three-way
> merging.
After some tests, it looks like 'git-diff-tree -p ... | git-apply
--index' is about 3 times faster than 'git-read-tree -m' (in the best
case for git-read-tree with minor modifications of the base). It now
takes ~0.5s to push a single patch (compared to ~1.5s).
Since most of the patches, for routine updates of the base, don't
generate conflicts, git-apply should work fine. I'll modify StGIT to
use this method by default and fall back to the three-way merge in
case it fails. This will also solve the problem with complex
modifications of the base of the stack (i.e. file removals/additions)
when there won't be any need to call the external index merger if
git-apply succeeds.
--
Catalin
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Josef Weidendorfer @ 2005-10-03 12:55 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
On Monday 03 October 2005 02:14, Junio C Hamano wrote:
> * Perhaps accept patches to introduce the concept of "patch flow
> expressed as ref mappings" Josef has been advocating about.
This was about a central place to store local/remote ref mappings.
I proposed the Pull/Push lines in remote/ files changing to hold
these mappings, and putting the defaults into Pull-Default and
Push-Default.
I changed my mind: IMHO for simplicity, porcelain commands should
mostly deal with refspecs (default: current head), and thus,
above mappings should be stored per ref/head, not per remote repository.
I.e. I won't provide a patch for this.
But why did we choose to make git-pull/git-push
to accept a remote repository as first argument, and not a head/refspec
in the first place? [Of course, this needs the remote repository be
retrievable by head name: see branches/ files. And currently missing here is
the distinction between fetch and push direction].
In the current state, it would be better to get rid of branches/
parsing in GIT at all: By keeping it in, we force Cogito to keep the current
format.
[BTW: the git-push man page is wrong about branches/: the name of the file
in branches/ corresponds to a local refspec, and not to a remote name]
Josef
^ permalink raw reply
* [PATCH] Enable and fix support for base less merges.
From: Fredrik Kuivinen @ 2005-10-03 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vfyrjw8qb.fsf@assigned-by-dhcp.cox.net>
Let the merge strategies handle the base less case if they are able to
do it. It also fixes git-resolve.sh to die if no common ancestors
exists, instead of doing the wrong thing. Furthermore, it contains a
small independent fix for git-merge.sh and a fix for a base less code
path in gitMergeCommon.py.
With this it's possible to use
git merge -s recursive 'merge message' A B
to do a base less merge of A and B.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-resolve.sh | 6 ++++++
git-merge.sh | 4 ++--
gitMergeCommon.py | 2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
d298deec60a0fac7a16f43135f390c285251f613
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
--- a/git-merge-resolve.sh
+++ b/git-merge-resolve.sh
@@ -31,6 +31,12 @@ case "$remotes" in
exit 2 ;;
esac
+# Give up if this is a baseless merge.
+if test '' == "$bases"
+then
+ exit 2
+fi
+
git-update-index --refresh 2>/dev/null
git-read-tree -u -m $bases $head $remotes || exit 2
echo "Trying simple merge."
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -26,7 +26,7 @@ dropsave() {
savestate() {
# Stash away any local modifications.
git-diff-index -r -z --name-only $head |
- cpio -0 -o >"$GIR_DIR/MERGE_SAVE"
+ cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
}
restorestate() {
@@ -103,7 +103,7 @@ echo "$head" >"$GIT_DIR/ORIG_HEAD"
case "$#,$common" in
*,'')
- die "Unable to find common commit between $head_arg and $*"
+ # No common ancestors found. We need a real merge.
;;
1,"$1")
# If head can reach all the merge then we are up to date.
diff --git a/gitMergeCommon.py b/gitMergeCommon.py
--- a/gitMergeCommon.py
+++ b/gitMergeCommon.py
@@ -213,7 +213,7 @@ def buildGraph(heads):
# Write the empty tree to the object database and return its SHA1
def writeEmptyTree():
- tmpIndex = os.environ['GIT_DIR'] + '/merge-tmp-index'
+ tmpIndex = os.environ.get('GIT_DIR', '.git') + '/merge-tmp-index'
def delTmpIndex():
try:
os.unlink(tmpIndex)
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: Junio C Hamano @ 2005-10-03 5:10 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4340B73B.1090409@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> My point is that I believe it should. It has the bitfield for it, it
> just doesn't use it at the moment.
It is a bit more complicated than that.
Long time ago, we used to store the full permission bits and
ended up storing files in 0644 and 0664 modes, depending on who
is writing the tree object. People with umask 022 checked out
from a tree that recorded blobs with 0664 bits and ended up
getting "mode changed" diff all the time, which was unacceptable
from the SCM point of view. We _could_ have really changed the
mode bits representation in the tree objects back then to have
type + executable bit, but to preserve backward compatibility,
we chose to keep the bitfield layout and changed the code to
treat 1006xx and 1007yy in older trees to be equivalent to
100644 and 100755. These days, for newly written tree objects,
above xx and yy 6-bit fields are "Must Be 4" and "Must Be 5"
fields, respectively, not bitfields to store arbitrary group and
other permission information. git-fsck-objects even complains
about them.
So in that sense, it does _not_ have the bitfield for it, and
obviously we cannot use what we do not have.
^ permalink raw reply
* Re: Honor extractor's umask in git-tar-tree.
From: H. Peter Anvin @ 2005-10-03 4:44 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.02.09.55.52.564046@smurf.noris.de>
Matthias Urlichs wrote:
> Hi, H. Peter Anvin wrote:
>
>>I've thought that it would be nice if the files/directories were written
>>into the archive with 0666/0777 permissions by default, and then
>>extracted with the umask honoured.
>
> The git archive oesn't *have* permissions, just one "execute" bit.
>
My point is that I believe it should. It has the bitfield for it, it
just doesn't use it at the moment.
>> A special option then could be used
>>to add files with special permissions, like files in .ssh, which *have*
>>to be g-w or sshd will reject them.
>
> I'd include a script in the archive which you'd run afterwards to fix
> problems like this. IMHO, in most situations you'll need it anyway
> (for instance, to re-start services).
That is true in some cases, but I highly disagree with the statement "most".
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-03 4:00 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <4340A01F.7040901@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> If you were to publish the ToDo to the mailing list once a week it might
> encourage more of those patches you want to accept.
Hmph. I tend to dislike periodical posting that is more often
than once a month.
>> * Accept patches to finish missing docs.
>
> A list of missing, incomplete, and/or wrong docs in the ToDo file would
> help focus effort when people (like me) have space cycles.
Well, the thing is, I am not good at documentation, especially
when I have other interests, and once I start writing a list of
missing or incomplete docs, my interests _will_ shift to fill in
those gaps and I will end up doing them myself, which means I
would not have a chance to place the list in the TODO file.
>> Technical (heavier)
>> -------------------
> ...
>> * Maybe a pack optimizer.
>
> Huh?
Given a set of objects and a set of refs (probably a handful
branch heads and point release tags), find a set of packs to
allow reasonably minimum download for all of these classes of
people: (1) somebody cloning the repository from scratch, (2)
somebody who tends to follow the master branch head reasonably
closely, (3) somebody who tends to follow only the point
releases.
>> * Internally split the project into non-doc and doc parts; add
>> an extra root for the doc part and merge from it; move the
>> internal doc source to a separate repository, like the +Meta
>> repository; experiment if this results in a reasonable
>> workflow, and document it in howto form if it does.
>
> I think this is a bad idea. The docs should be part of the project
> (repository and head) as the code. Otherwise, they'll become even more
> out-of-sync.
The point was to make it possible to fork that part off to
somebody else; then I do not have to maintain Documentation
directory myself anymore, just like I simply slurp the latest
gitk from Paul and not worry about it ;-).
>> Technical (trivial)
>> -------------------
>>
> ...
>> * 'git merge-projects'?
>
> Huh?
Subject: Re: Merges without bases
References: <1125004228.4110.20.camel@localhost.localdomain>
Date: Thu, 25 Aug 2005 15:26:36 -0700
Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>
^ permalink raw reply
* Re: What to expect after 0.99.8
From: A Large Angry SCM @ 2005-10-03 3:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> As I mentioned in teh 0.99.8 announcement, let's start aiming
> for 1.0, really this time. From now on, brown paper bags,
> bugfixes, portability fixes, usability enhancements including
> documentation updates take precedence over any new features.
> One exception area is probably merge strategy modules -- they
> are like adding new device drivers or adding new filesystem, and
> can come in anytime as long as they do not touch the coreish.
>
>
> The GIT To-Do File
> ==================
>
> The latest copy of this document is found at
>
> http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
If you were to publish the ToDo to the mailing list once a week it might
encourage more of those patches you want to accept.
>
...
>
> * Maybe update tutorial with a toy project that involves two or
> three developers..
This is *important* to have for 1.0.
>
> * Update tutorial to cover setting up repository hooks to do
> common tasks.
This is nice to have for 1.0.
>
> * Accept patches to finish missing docs.
A list of missing, incomplete, and/or wrong docs in the ToDo file would
help focus effort when people (like me) have space cycles.
>
> * Accept patches to talk about "Whoops, it broke. What's
> next?".
This is *important* to have for 1.0.
>
> * Accept patches to make formatted tables in asciidoc to work
> well in both html and man pages (see git-diff(1)).
A Git documentation asciidoc style guide and howto would be _very_
useful. The current Git documentation is not all that consistent. (and I
accept the blame for the docs I wrote)
>
>
> Technical (heavier)
> -------------------
...
>
> * Maybe a pack optimizer.
Huh?
...
>
> * Internally split the project into non-doc and doc parts; add
> an extra root for the doc part and merge from it; move the
> internal doc source to a separate repository, like the +Meta
> repository; experiment if this results in a reasonable
> workflow, and document it in howto form if it does.
I think this is a bad idea. The docs should be part of the project
(repository and head) as the code. Otherwise, they'll become even more
out-of-sync.
>
...
>
> Technical (trivial)
> -------------------
>
...
>
> * 'git merge-projects'?
Huh?
>
> * 'git lost-and-found'? Link dangling commits found by
> fsck-objects under $GIT_DIR/refs/lost-found/. Then
> show-branch or gitk can be used to find any lost commit. [A
> feeler patch sent out. Very underwhelming response X-<.]
The response may have been underwhelming but it's still a good idea.
>
> Do not name it /lost+found/; that would probably confuse
> things that mistake it a mount point (not our code but
> somebody else's).
I the this concern is overblown.
>
...
^ 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