* Re: Improved git-gui blame viewer
From: Matthijs Melchior @ 2007-06-02 10:44 UTC (permalink / raw)
To: git
In-Reply-To: <20070602041723.GD7044@spearce.org>
Shawn O. Pearce wrote:
> A long time ago Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Sun, 18 Mar 2007, Shawn O. Pearce wrote:
>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>> Of course, the git gui blame colorization is clearly done by somebody who
>>>> is still actively popping LSD with both fists and didn't realize that the
>>>> 60's are long done, but that's another issue.
>>> git-gui is open source. I'd be happy to take a patch. Or,
>>> since that is horribly messy Tcl/Tk code, just a better color
>>> suggestion. :-)
>> I would suggest:
>>
>> - some special color for "currently selected" (which defaults to being
>> the first one coming out of the blame thing, of course).
>>
>> I'd suggest "black text on pale green background", but that may be just
>> me.
>>
>> - some *stable* graduated color for the rest. I don't think it
>> necessarily needs to be "older" vs "newer", and in fact I'd suggest
>> just two slightly different shades of gray for the background - just
>> pick alternating shades for each blame entry that comes in (and leave
>> un-blamed lines white).
>
> I finally got the git-gui code to the point where cleaning up the
> user interface was possible without sending myself to the nut house.
>
> I tried out Linus' suggestions for coloring, and I like them. Enough
> that they are now sitting in my `pu` branch on repo.or.cz/git-gui.git.
>
> There's also a whole slew of other improvements to the blame viewer,
> like being able to dig through history by clicking on commit ids,
> and tooltips when you mouse over a region of the file.
>
> Behavior on Windows is actually quite good; its less so on Mac
> OS X. I'm fighting Tk there a little bit more than I should be.
> Untested on Linux, so I'd love to hear some feedback on it.
>
> git://repo.or.cz/git-gui.git pu
> http://repo.or.cz/r/git-gui.git pu
>
I have got this on Debian Etch and given the command 'make install'
in the pu branch while git-core 1.5.2 is installed.
About git-gui says:
git-gui version 0.7.2.39.ge6a1
git version 1.5.2
Tcl/Tk version 8.4.12
The colors look much better.
The behavior has some rough edges. I don't like the following:
When clicking on a link in the left column, the file as present in
that commit is loaded, positioned at the top. I would like for the
line where I clicked is to stay at the same position on the screen,
so I do not have to find it again.
Also, when returning I would like most lines on the screen stay the
same.
When clicking on a light gray line to become a green line, then
adjacent areas are not correctly colored. A few adjacent entries
become all same gray... [Look around git-gui.sh:340]
Something I want for the normal window, in the Staged and Unstaged
file lists, high-lite the last entry selected so it becomes easy to
click on the next one and I can see more clearly what is displayed
in the bottom area.
Thanks for your efforts!
Regards,
Matthijs Melchior.
^ permalink raw reply
* Re: [RFH] QGit: how to cram a patch in a crowded screen
From: Marco Costalba @ 2007-06-02 11:37 UTC (permalink / raw)
To: Jan Hudec; +Cc: Andy Parkins, git, Pavel Roskin
In-Reply-To: <20070531195633.GA3252@efreet.light.src>
On 5/31/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> I have to say that I like the gitk way better. There is the issue of
> over-scrolling. I often want to quickly scan through the diff, so I scroll
> pretty quickly and it switches over when I reach the end.
>
Ok. "Smart Browsing" ;-) patch series pushed to qgit4.
Refer to patches logs for a little documentation.
Please give feedback if this patch series it's not smart enough for you.
Thanks
Marco
^ permalink raw reply
* How to use git-svn to clone from a mirror?
From: David Kastrup @ 2007-06-02 12:54 UTC (permalink / raw)
To: git
Hi, I seem to be too stupid to get this right.
I have used something like
git-svn clone -T trunk -b branches -t tags file:///tmp/rsync-mirror
to clone an rsync mirror of an SVN repository. Now I want to have
fetch revert to pulling from the upstream repository in future.
However, if I change the respective line in .git/config to
svn://the.svn.link/whatever, git-rebase will fetch the right updates,
but then says that it can't work with the objects in the git
repository.
Changing the config back will make git-rebase -l work.
So what would be the right procedure to shift the SVN source from an
rsync mirror to the original, without git-svn breaking?
--
David Kastrup
^ permalink raw reply
* [PATCH] Add option -L to git-tag.
From: Matthijs Melchior @ 2007-06-02 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthijs Melchior
This will list the selected tags and include annotations, if any.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
---
Version 2 of the git-tag -L patch.
It implements better style,
a new --pretty=n option and
an interresting exit code.
-Matthijs
Documentation/git-tag.txt | 5 ++++-
git-tag.sh | 24 +++++++++++++++++-------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 4e3e027..441f361 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
-'git-tag' -l [<pattern>]
+'git-tag' [-l | -L] [<pattern>]
'git-tag' -v <name>
DESCRIPTION
@@ -41,6 +41,9 @@ GnuPG key for signing.
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
+`-L <pattern>` lists tags, including their annotations, that match
+the given pattern (or all if no pattern is given).
+
OPTIONS
-------
-a::
diff --git a/git-tag.sh b/git-tag.sh
index 6f0b7a7..45c4253 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
+USAGE='[-l | -L] [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -26,13 +26,23 @@ do
-f)
force=1
;;
- -l)
- case "$#" in
- 1)
- set x . ;;
- esac
+ -l|-L)
+ TAGSONLY=true
+ [ "$1" = -L ] && TAGSONLY=false
+ [ "$#" = 1 ] && set x .
shift
- git rev-parse --symbolic --tags | sort | grep "$@"
+ git rev-parse --symbolic --tags | grep "$@" |
+ while read TAG
+ do
+ echo "$TAG"
+ $TAGSONLY && continue
+ OBJTYPE=$(git cat-file -t "$TAG")
+ case $OBJTYPE in
+ tag) git cat-file $OBJTYPE "$TAG" |
+ sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
+ ;;
+ esac
+ done
exit $?
;;
-m)
--
1.5.2
>From f0123e2f1c4bd8a15e8d190dc1e0c2745db60278 Mon Sep 17 00:00:00 2001
From: Matthijs Melchior <mmelchior@xs4all.nl>
Date: Sat, 2 Jun 2007 15:04:46 +0200
Subject: [PATCH] git-tag -L, version 2
style. --pretty=n and exit code
---
git-tag.sh | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index 45c4253..dafa083 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -13,6 +13,7 @@ message=
username=
list=
verify=
+LINES=3
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -26,24 +27,33 @@ do
-f)
force=1
;;
+ --pretty=*)
+ LINES=$(expr "$1" : '--pretty=\(.*\)')
+ ;;
-l|-L)
TAGSONLY=true
[ "$1" = -L ] && TAGSONLY=false
[ "$#" = 1 ] && set x .
shift
- git rev-parse --symbolic --tags | grep "$@" |
+ [ "$LINES" -le 0 ] && LINES=999999
+ TAGLIST=$(git rev-parse --symbolic --tags | grep "$@")
+ RC=$? # from grep
+ printf "%s" "$TAGLIST" |
while read TAG
do
echo "$TAG"
$TAGSONLY && continue
OBJTYPE=$(git cat-file -t "$TAG")
case $OBJTYPE in
- tag) git cat-file $OBJTYPE "$TAG" |
- sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
- ;;
+ tag) git cat-file tag "$TAG" |
+ sed -e '1,/^$/d' \
+ -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \
+ -e 's/^/ /' |
+ sed -e "${LINES}q"
+ ;;
esac
done
- exit $?
+ exit $RC
;;
-m)
annotate=1
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add option -L to git-tag.
From: Matthijs Melchior @ 2007-06-02 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy5avf89.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Matthijs Melchior <mmelchior@xs4all.nl> writes:
>
>
>> This will list the selected tags and include annotations, if any.
>>
>> Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
>> ---
>>
>> This patch has been created to allow me to easily see the annotations with tags.
>> I have not found any other way to do this...
>>
>
> Hmmmm. This feature ought to belong to git-show, but that
> command already has its own interpretation of how a tag should
> be shown.
>
> Do we care about the "one line summary"? Perhaps...
>
> $ git tag --pretty=short -L v2.6.11-tree
> v2.6.11-tree
> This is the 2.6.11 tree object.
>
> $ git tag -L v2.6.11-tree
> v2.6.11-tree
> This is the 2.6.11 tree object.
>
> NOTE! There's no commit for this, since it happened...
>
> The answer to this question would really depend on why we would
> want to have this feature. "git-tag" started as a way to
> "create", and then it gained -l to "list" and -v to "verify". I
> think your -L is meant to be an extension to "list", but I
> suspect that while you are listing many things you would keep
> the annotation short-and-sweet, and you would want to view the
> full description when your interest is focused at a single one.
> Maybe we would want a separate "print" action for the full
> contents and use the short one for "list but more verbosely than
> usual"?
>
> I dunno; I've never been very good at the user interfaces.
>
Yes, since I have this command and have seen the tag annotations in the
git repository, I think we need this extra parameter.
I propose to give the number of lines you want to see, with 0 gives all.
So it will be --pretty=<max-number-lines> to limit the output and be
able to find interesting stuff before looking at the complete message.
In the project where I wanted this, the tag annotations are only a few
lines max...
I have used this to remember special status of of a commit, such as release
version and date. In order to quickly find such a thing I wanted to see
all the annotations.
>
>> - Sorting the tag names resulting from git-rev-parse is not nessecary since
>> the list of tags is already deliverd in sorted order.
>>
>
> This I am a bit reluctant about, as that sorting done by
> rev-parse is purely by accident (i.e. it is an implementation
> detail).
>
This accident can be repaired by documenting it.... :)
>
>> - Using git-cat-file -t on every tag is expensive, but there is no alternative
>>
>
> This is Ok, as we have somebody working on doing git-tag as a
> built-in, and once that happens, we do not have to pay the
> performance penalty. So I would think at this point we should
> concentrate on discussing the usefulness of this new feature and
> correctness of your implementation, as that would set the course
> for the future. On the other hand, "cat-file -t" performance
> issues will not stay with us forever.
>
>
>> @@ -26,13 +26,23 @@ do
>> -f)
>> force=1
>> ;;
>> - -l)
>> - case "$#" in
>> - 1)
>> - set x . ;;
>> - esac
>> + -l|-L)
>> + TAGSONLY=true
>> + [ "$1" = -L ] && TAGSONLY=false
>> + [ "$#" = 1 ] && set x .
>> shift
>> + git rev-parse --symbolic --tags | grep "$@" |
>> + while read TAG
>> + do
>> + echo "$TAG"
>> + $TAGSONLY && continue
>> + OBJTYPE=$(git cat-file -t "$TAG")
>> + case $OBJTYPE in
>> + tag) git cat-file $OBJTYPE "$TAG" |
>> + sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
>> + ;;
>> + esac
>>
>
> Micronit. If you already know it is a tag, you do not have to
> say "cat-file $OBJTYPE".
>
Yes, this was left over from an older prototype.....
> Style. Please indent the case arm to the same level as, not
> deeper than, case/esac.
> This is the same as C's switch() { case ...: } indentation rule.
>
> Please do not feed multiple expressions concatenated with
> semicolon to sed, as it is one of the often observed portability
> issues (not all the world is GNU yet). Write it like this
> instead:
>
> case "$OBJTYPE" in
> tag)
> git cat-file tag "$TAG" |
> sed -e '1,/^$/d' \
> -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \
> -e s/^/ /'
> ;;
> esac
>
>
>> + done
>> exit $?
>>
OK, I'll use this style.
> What does this command exit with now? It used to be that
>
> $ git tag -l no-such-tag-at-all ; echo $?
>
> said "1", I think, because grep did not match.
>
It will always exit 0, either from sed or git-cat.
I will send a new patch with better style, a --pretty=n option and
again exit code from grep.
(maybe the exit code is not worth the added complexity...).
Thanks.
--
Regards,
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
mmelchior@xs4all.nl Netherlands _\_v
---------------------------------------------------------------- ----
^ permalink raw reply
* Re: [PATCH] Add option -L to git-tag.
From: Frank Lichtenheld @ 2007-06-02 14:49 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: Junio C Hamano, git
In-Reply-To: <1180789848873-git-send-email-mmelchior@xs4all.nl>
On Sat, Jun 02, 2007 at 03:10:48PM +0200, Matthijs Melchior wrote:
> +`-L <pattern>` lists tags, including their annotations, that match
> +the given pattern (or all if no pattern is given).
>From the descriptions it is not clear to me if the pattern is applied to
the tag names, the annotations or both. Maybe one could reorder that
sentence to make it less confusing?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] always start looking up objects in the last used pack first
From: Dana How @ 2007-06-02 14:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <alpine.LFD.0.99.0705302152180.11491@xanadu.home>
On 5/30/07, Nicolas Pitre <nico@cam.org> wrote:
> Jon Smirl said:
> | Once an object reference hits a pack file it is very likely that
> | following references will hit the same pack file. So first place to
> | look for an object is the same place the previous object was found.
>
> This is indeed a good heuristic so here it is. The search always start
> with the pack where the last object lookup succeeded. If the wanted
> object is not available there then the search continues with the normal
> pack ordering.
Nice numbers for performance,
especially your later email showing this makes
split packs almost as quick as one pack.
> Note: the
> --max-pack-size to git-repack currently produces packs with old objects
> after those containing recent objects. The pack sort based on
> filesystem timestamp is therefore backward for those. This needs to be
> fixed of course, but at least it made me think about this variable for
> the test.
Yes, I was intending to submit a patch to builtin-pack-objects.c
to reverse the timestamps when split packs were created.
Haven't got around to it yet.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] always start looking up objects in the last used pack first
From: Dana How @ 2007-06-02 15:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Junio C Hamano, git, danahow
In-Reply-To: <alpine.LFD.0.99.0705311015410.11491@xanadu.home>
On 5/31/07, Nicolas Pitre <nico@cam.org> wrote:
> Which makes me wonder about a possible incremental improvement to my
> patch: on failure to find an object in the last used pack, the search
> should then start again from the pack containing the commit from which
> this object search is related to. In the split pack case all commit
> objects will be located in the first pack so nothing will change there.
> In the multiple-fetch case then the search will always reset to packs
> not younger than the commit triggering those object lookups. Question
> is how to implement that nicely...
My immediate reaction to this patch was that there should be
a last-used-pack per object type. Or perhaps one for commits,
and one for trees+blobs [since the latter are intermingled]?
Unfortunately the interface only specifies
the SHA-1, not the object type, and certainly not the "commit
this is related to". I think your related-commit idea could be
very useful, but it does require some extra info to be passed
around which currently is not.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH 1/3] Remove PDF version of manual from being build and installed
From: Jonas Fonseca @ 2007-06-02 16:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200706011824.08148.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote Fri, Jun 01, 2007:
> [...]
> On Thu, 31 May 2007, Jonas Fonseca wrote:
> > I will try to correct this together with the no-PDF doc-building.
>
> I hope we didn't end up duplicating our efforts.
Nope, it didn't. Again, thanks for doing this!
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 3/3] Refresh VERSION file when building distribution tarball in "make dist"
From: Jonas Fonseca @ 2007-06-02 16:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200706011834.28911.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote Fri, Jun 01, 2007:
> On Thu, 31 May 2007, Jonas Fonseca wrote:
>
> > Maybe you can test the newly released tig 0.7 tarball?
> >
> > Your patch was added as commit 8cdf56913e7e486bb3f527c24ee4a4d19f2a4f61,
> > with a few minor adjustments.
>
> One of those changes was using HEAD version of VERSION file in
> "make dist", instead of regenerating it and replacing it with the one
> containing _current_ version in the tar file.
>
> $ make rpm
> sed -e 's/@@VERSION@@/0.7.4.g1995120/g' < tig.spec.in > tig.spec
> git-archive --format=tar --prefix=tig-0.7.4.g1995120/ HEAD > tig-0.7.4.g1995120.tar
> tar rf tig-0.7.4.g1995120.tar tig-0.7.4.g1995120/tig.spec
> gzip -f -9 tig-0.7.4.g1995120.tar
> rpmbuild -ta tig-0.7.4.g1995120.tar.gz
> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.72336
> Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.72336
> make[1]: Entering directory `/home/local/builddir/BUILD/tig-0.7.4.g1995120'
> cc -Wall -O2 '-DVERSION="0.7.git"' tig.c -lcurses -o tig
> asciidoc -b docbook -d manpage -aversion=0.7.git tig.1.txt
> xmlto -m manpage.xsl man tig.1.xml
> [...]
>
> Note the mismatch in the versions: 0.7.4.g1995120 vs 0.7.git
> (by the way, shouldn't it be 0.7.tig?), even when building from live
> repo, and not from tarball.
Gah, somehow I didn't realize the problems of not updating the VERSION
file. Beautiful, so now it should actually work even for non-RPM builds
using the 'make dist' result. :)
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Linus Torvalds @ 2007-06-02 16:34 UTC (permalink / raw)
To: skimo; +Cc: Lars Hjemli, Junio C Hamano, git
In-Reply-To: <20070602074910.GB955MdfPADPa@greensroom.kotnet.org>
On Sat, 2 Jun 2007, Sven Verdoolaege wrote:
> On Fri, Jun 01, 2007 at 09:29:58AM -0700, Linus Torvalds wrote:
> > [module "infrastructure"]
> > submodule = lib
> > submodule = build
> >
> > [submodule "lib"]
> > url = git://xyzzy/lib-1.2.3
> >
> > [submodule "build"]
> > url = git://xyzzy/build-0.61
> >
> >
> > IOW, in the above case, we have *three* modules:
> >
> > - module "infrastructure", that is the union of submodules/paths "lib"
> > and "build"
> > - module "lib" (== submodule/path "lib")
> > - module "build" (== submodule/path "build")
>
> If there are three modules, then why is one in the "module" section
> and the other two in the "submodule" section?
Because there are:
- *two* actual submodules (== path), namely "lib" and "build".
- each submodule always is *implicitly* a module too
- we have a *named* (aka explicit) module "infrastructure" that is a
higher-level name for one or more submodules (in this case two).
So the implicit modules could have been written out:
[module "lib"]
submodule = "lib" # aka 'path = "lib"'
[module "build"]
submodule = "build" # aka 'path = "build"'
but my suggestion was that if the module name and the path name are the
same, you don't need to say it.
(And quite frankly, I think it reads better as "submodule" than as "path",
but maybe that threw you).
> Why not allow a module to both contain smaller modules and be contained
> in a bigger module?
Because the "module" definition is _different_ from the "submodule"
definition.
The "module" definition is just a level of indirection. It is what allows
you to call your module "kernel" regardless of where in the tree it is
(and regardless of whether it's actually built up on *one* directory or
many). It allows what CVS users have long used the "alias" thing for (or
whatever it's called in CVSROOT/modules. But it also allows you to name
single modules *without* having to specify exactly where in the tree they
are.
In contrast, the "submodule" thing actually would declare where the
submodule can be found from an URL standpoint.
And maybe you want to allow the CVS "alias" kind of thing separately, but
I think it's very common (exactly because quite often you want to cluster
a few submodules together as "src" or "docs" or something, even if they
might be technically more than one actual subproject).
Linus
^ permalink raw reply
* Re: [PATCH] Create a new manpage for the gitignore format, and reference it elsewhere
From: Josh Triplett @ 2007-06-02 16:54 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Junio C Hamano
In-Reply-To: <20070602105648.GX3242@planck.djpig.de>
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
Frank Lichtenheld wrote:
> On Fri, Jun 01, 2007 at 05:52:53PM -0700, Josh Triplett wrote:
>> Frank Lichtenheld wrote:
>>> On Fri, Jun 01, 2007 at 03:20:52PM -0700, Josh Triplett wrote:
>>>> + - Otherwise, git treats the pattern as a shell glob suitable
>>>> + for consumption by fnmatch(3) with the FNM_PATHNAME flag: any
>>>> + slash in the pattern must match a slash in the pathname. For
>>>> + example, "Documentation/\*.html" matches
>>>> + "Documentation/git.html" but not "ppc/ppc.html". A leading
>>>> + slash matches the beginning of the pathname; for example,
>>>> + "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".
>>> I realise this is copy&paste but shouldn't that read:
>>> "Documentation/\*.html" matches "Documentation/git.html"
>>> but not "Documentation/ppc/ppc.html"
>>> ?
>> I don't know. Neither file seems to exist in current Git.
>
> The point I was trying to make is that "Documentation/*.html" _of
> course_ doesn't match ppc/ppc.html. What we try to tell the user here
> is that * doesn't match /
> So I think it should definetly read Documentation/ppc/ppc.html
Ah, I understand your point now.
> FWIW, I find the sentence
> "any slash in the pattern must match a slash in the pathname"
> very confusing too. The sentence in fnmatch(3) is much more precise:
> "match a slash in string only with a slash in pattern and not by an
> asterisk (*) or a question mark (?) metacharacter, nor by a bracket
> expression ([]) containing a slash"
I like that better as well.
> Anyway, if you prefer (and if it is okay with Junio) I can send a
> patch of my own for this single issue to not hinder the commit of
> your big patch as the issue is equally present in the old and the
> new text.
Now that I understand the issue you raised, I can easily fix it and
send a revised patch. Expect one momentarily.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] Create a new manpage for the gitignore format, and reference it elsewhere
From: Josh Triplett @ 2007-06-02 17:08 UTC (permalink / raw)
To: git, Junio C Hamano, Frank Lichtenheld, 427078
[-- Attachment #1: Type: text/plain, Size: 14957 bytes --]
Only git-ls-files(1) describes the gitignore format in detail, and it does so
with reference to git-ls-files options. Most users don't use the plumbing
command git-ls-files directly, and shouldn't have to look in its manpage for
information on the gitignore format.
Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor
out the gitignore documentation into that file, changing it to refer to
.gitignore and $GIT_DIR/info/exclude as used by porcelain commands. Reference
gitignore(5) from other relevant manpages and documentation. Remove
now-redundant information on exclude patterns from git-ls-files(1), leaving
only information on how git-ls-files options specify exclude patterns and what
precedence they have.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
In this new version, I've modified the explanation and example for patterns
containing a slash based on additional comments by Frank Lichtenheld.
I also updated the first example in gitignore(5) to use git-status rather than
git-ls-files.
Documentation/Makefile | 2 +-
Documentation/config.txt | 3 +-
Documentation/git-ls-files.txt | 99 ++++-------------------------
Documentation/git-read-tree.txt | 3 +-
Documentation/git-status.txt | 8 +--
Documentation/gitignore.txt | 116 +++++++++++++++++++++++++++++++++++
Documentation/repository-layout.txt | 3 +-
Documentation/user-manual.txt | 12 ++--
8 files changed, 145 insertions(+), 101 deletions(-)
create mode 100644 Documentation/gitignore.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3f92783..ef4425c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -2,7 +2,7 @@ MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
gitk.txt
-MAN5_TXT=gitattributes.txt
+MAN5_TXT=gitattributes.txt gitignore.txt
MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3d8f03d..bb4d6e0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -259,7 +259,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludeFile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
- of files which are not meant to be tracked.
+ of files which are not meant to be tracked. See
+ gitlink:gitignore[5].
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 43e0d22..a78a9ff 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -139,46 +139,24 @@ Exclude Patterns
'git-ls-files' can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
-flags --others or --ignored are specified.
+flags --others or --ignored are specified. gitlink:gitignore[5]
+specifies the format of exclude patterns.
-These exclude patterns come from these places:
+These exclude patterns come from these places, in order:
- 1. command line flag --exclude=<pattern> specifies a single
- pattern.
+ 1. The command line flag --exclude=<pattern> specifies a
+ single pattern. Patterns are ordered in the same order
+ they appear in the command line.
- 2. command line flag --exclude-from=<file> specifies a list of
- patterns stored in a file.
+ 2. The command line flag --exclude-from=<file> specifies a
+ file containing a list of patterns. Patterns are ordered
+ in the same order they appear in the file.
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.
-
-An exclude pattern file used by (2) and (3) contains one pattern
-per line. A line that starts with a '#' can be used as comment
-for readability.
-
-There are three lists of patterns that are in effect at a given
-time. They are built and ordered in the following way:
-
- * --exclude=<pattern> from the command line; patterns are
- ordered in the same order as they appear on the command line.
-
- * lines read from --exclude-from=<file>; patterns are ordered
- in the same order as they appear in the file.
-
- * When --exclude-per-directory=<name> is specified, upon
- entering a directory that has such a file, its contents are
- appended at the end of the current "list of patterns". They
- are popped off when leaving the directory.
-
-Each pattern in the pattern list specifies "a match pattern" and
-optionally the fate; either a file that matches the pattern is
-considered excluded or included. A filename is matched against
-the patterns in the three lists; the --exclude-from list is
-checked first, then the --exclude-per-directory list, and then
-finally the --exclude list. The last match determines its fate.
-If there is no match in the three lists, the fate is "included".
+ examines, normally `.gitignore`. Files in deeper
+ directories take precedence. Patterns are ordered in the
+ same order they appear in the files.
A pattern specified on the command line with --exclude or read
from the file specified with --exclude-from is relative to the
@@ -186,58 +164,9 @@ top of the directory tree. A pattern read from a file specified
by --exclude-per-directory is relative to the directory that the
pattern file appears in.
-An exclude pattern is of the following format:
-
- - an optional prefix '!' which means that the fate this pattern
- specifies is "include", not the usual "exclude"; the
- remainder of the pattern string is interpreted according to
- the following rules.
-
- - if it does not contain a slash '/', it is a shell glob
- pattern and used to match against the filename without
- leading directories.
-
- - 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
- not "ppc/ppc.html". As a natural exception, "/*.c" matches
- "cat-file.c" but not "mozilla-sha1/sha1.c".
-
-An example:
-
---------------------------------------------------------------
- $ cat .git/info/exclude
- # ignore objects and archives, anywhere in the tree.
- *.[oa]
- $ cat Documentation/.gitignore
- # ignore generated html files,
- *.html
- # except foo.html which is maintained by hand
- !foo.html
- $ git-ls-files --ignored \
- --exclude='Documentation/*.[0-9]' \
- --exclude-from=.git/info/exclude \
- --exclude-per-directory=.gitignore
---------------------------------------------------------------
-
-Another example:
-
---------------------------------------------------------------
- $ cat .gitignore
- vmlinux*
- $ ls arch/foo/kernel/vm*
- arch/foo/kernel/vmlinux.lds.S
- $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
---------------------------------------------------------------
-
-The second .gitignore keeps `arch/foo/kernel/vmlinux.lds.S` file
-from getting ignored.
-
-
See Also
--------
-gitlink:git-read-tree[1]
+gitlink:git-read-tree[1], gitlink:gitignore[5]
Author
@@ -246,7 +175,7 @@ Written by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list <git@vger.kernel.org>.
GIT
---
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 019c8be..acb5744 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -341,7 +341,8 @@ have finished your work-in-progress), attempt the merge again.
See Also
--------
-gitlink:git-write-tree[1]; gitlink:git-ls-files[1]
+gitlink:git-write-tree[1]; gitlink:git-ls-files[1];
+gitlink:gitignore[5]
Author
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index d701538..1fd1af1 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -42,11 +42,9 @@ mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
-As for gitlink:git-add[1], the configuration variable
-'core.excludesfile' can indicate a path to a file containing patterns
-of file names to exclude, in addition to patterns given in
-'info/exclude' and '.gitignore'.
-
+See Also
+--------
+gitlink:gitignore[5]
Author
------
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
new file mode 100644
index 0000000..ea79d74
--- /dev/null
+++ b/Documentation/gitignore.txt
@@ -0,0 +1,116 @@
+gitignore(5)
+============
+
+NAME
+----
+gitignore - Specifies intentionally untracked files to ignore
+
+SYNOPSIS
+--------
+$GIT_DIR/info/exclude, .gitignore
+
+DESCRIPTION
+-----------
+
+A `gitignore` file specifies intentionally untracked files that
+git should ignore. Each line in a `gitignore` file specifies a
+pattern.
+
+When deciding whether to ignore a path, git normally checks
+`gitignore` patterns from multiple sources, with the following
+order of precedence:
+
+ * Patterns read from the file specified by the configuration
+ variable 'core.excludesfile'.
+
+ * Patterns read from `$GIT_DIR/info/exclude`.
+
+ * Patterns read from a `.gitignore` file in the same directory
+ as the path, or in any parent directory, ordered from the
+ deepest such file to a file in the root of the repository.
+ These patterns match relative to the location of the
+ `.gitignore` file. A project normally includes such
+ `.gitignore` files in its repository, containing patterns for
+ files generated as part of the project build.
+
+The underlying git plumbing tools, such as
+gitlink:git-ls-files[1] and gitlink:git-read-tree[1], read
+`gitignore` patterns specified by command-line options, or from
+files specified by command-line options. Higher-level git
+tools, such as gitlink:git-status[1] and gitlink:git-add[1],
+use patterns from the sources specified above.
+
+Patterns have the following format:
+
+ - A blank line matches no files, so it can serve as a separator
+ for readability.
+
+ - A line starting with # serves as a comment.
+
+ - An optional prefix '!' which negates the pattern; any
+ matching file excluded by a previous pattern will become
+ included again.
+
+ - If the pattern does not contain a slash '/', git treats it as
+ a shell glob pattern and checks for a match against the
+ pathname without leading directories.
+
+ - Otherwise, git treats the pattern as a shell glob suitable
+ for consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/\*.html" matches
+ "Documentation/git.html" but not
+ "Documentation/ppc/ppc.html". A leading slash matches the
+ beginning of the pathname; for example, "/*.c" matches
+ "cat-file.c" but not "mozilla-sha1/sha1.c".
+
+An example:
+
+--------------------------------------------------------------
+ $ git-status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ # Documentation/gitignore.html
+ # file.o
+ # lib.a
+ # src/internal.o
+ [...]
+ $ cat .git/info/exclude
+ # ignore objects and archives, anywhere in the tree.
+ *.[oa]
+ $ cat Documentation/.gitignore
+ # ignore generated html files,
+ *.html
+ # except foo.html which is maintained by hand
+ !foo.html
+ $ git-status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ [...]
+--------------------------------------------------------------
+
+Another example:
+
+--------------------------------------------------------------
+ $ cat .gitignore
+ vmlinux*
+ $ ls arch/foo/kernel/vm*
+ arch/foo/kernel/vmlinux.lds.S
+ $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
+--------------------------------------------------------------
+
+The second .gitignore prevents git from ignoring
+`arch/foo/kernel/vmlinux.lds.S`.
+
+Documentation
+-------------
+Documentation by David Greaves, Junio C Hamano, Josh Triplett,
+Frank Lichtenheld, and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
index 0459bd9..15221b5 100644
--- a/Documentation/repository-layout.txt
+++ b/Documentation/repository-layout.txt
@@ -155,8 +155,7 @@ info/exclude::
exclude pattern list. `.gitignore` is the per-directory
ignore file. `git status`, `git add`, `git rm` and `git
clean` look at it but the core git commands do not look
- at it. See also: gitlink:git-ls-files[1] `--exclude-from`
- and `--exclude-per-directory`.
+ at it. See also: gitlink:gitignore[5].
remotes::
Stores shorthands to be used to give URL and default
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 4fabb8e..7eaafa8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1103,12 +1103,12 @@ showing up in the output of "`git status`", etc.
Git therefore provides "exclude patterns" for telling git which files to
actively ignore. Exclude patterns are thoroughly explained in the
-"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
-but the heart of the concept is simply a list of files which git should
-ignore. Entries in the list may contain globs to specify multiple files,
-or may be prefixed by "`!`" to explicitly include (un-ignore) a previously
-excluded (ignored) file (i.e. later exclude patterns override earlier ones).
-The following example should illustrate such patterns:
+gitlink:gitignore[5] manual page, but the heart of the concept is simply
+a list of files which git should ignore. Entries in the list may contain
+globs to specify multiple files, or may be prefixed by "`!`" to
+explicitly include (un-ignore) a previously excluded (ignored) file
+(i.e. later exclude patterns override earlier ones). The following
+example should illustrate such patterns:
-------------------------------------------------
# Lines starting with '#' are considered comments.
--
1.5.2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply related
* [PATCH] Allow CFLAGS to be overridden while preserving VERSION
From: James Bowes @ 2007-06-02 17:14 UTC (permalink / raw)
To: fonseca, git
If someone defined their own CFLAGS, they would have to include a -DVERSION=
as well (or else get unknown-version as the version).
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 61fc86b..91cb097 100644
--- a/Makefile
+++ b/Makefile
@@ -20,7 +20,7 @@ endif
RPM_VERSION = $(subst -,.,$(VERSION))
LDLIBS = -lcurses
-CFLAGS = -Wall -O2 '-DVERSION="$(VERSION)"'
+CFLAGS = -Wall -O2
DFLAGS = -g -DDEBUG -Werror
PROGS = tig
MANDOC = tig.1 tigrc.5
@@ -28,6 +28,8 @@ HTMLDOC = tig.1.html tigrc.5.html manual.html README.html
ALLDOC = $(MANDOC) $(HTMLDOC) manual.html-chunked manual.pdf
TARNAME = tig-$(RPM_VERSION)
+override CFLAGS += '-DVERSION="$(VERSION)"'
+
all: $(PROGS)
all-debug: $(PROGS)
all-debug: CFLAGS += $(DFLAGS)
--
1.5.2.888.g96a5e
^ permalink raw reply related
* Re: [PATCH] Let .git/config specify the url for submodules
From: Sven Verdoolaege @ 2007-06-02 17:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Lars Hjemli, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0706020923170.23741@woody.linux-foundation.org>
On Sat, Jun 02, 2007 at 09:34:26AM -0700, Linus Torvalds wrote:
> On Sat, 2 Jun 2007, Sven Verdoolaege wrote:
> > On Fri, Jun 01, 2007 at 09:29:58AM -0700, Linus Torvalds wrote:
> > > [module "infrastructure"]
> > > submodule = lib
> > > submodule = build
> > >
> > > [submodule "lib"]
> > > url = git://xyzzy/lib-1.2.3
> > >
> > > [submodule "build"]
> > > url = git://xyzzy/build-0.61
> > >
> > >
> > > IOW, in the above case, we have *three* modules:
> > >
> > > - module "infrastructure", that is the union of submodules/paths "lib"
> > > and "build"
> > > - module "lib" (== submodule/path "lib")
> > > - module "build" (== submodule/path "build")
> >
> > If there are three modules, then why is one in the "module" section
> > and the other two in the "submodule" section?
>
> Because there are:
>
> - *two* actual submodules (== path), namely "lib" and "build".
>
> - each submodule always is *implicitly* a module too
>
> - we have a *named* (aka explicit) module "infrastructure" that is a
> higher-level name for one or more submodules (in this case two).
>
> So the implicit modules could have been written out:
>
> [module "lib"]
> submodule = "lib" # aka 'path = "lib"'
>
> [module "build"]
> submodule = "build" # aka 'path = "build"'
>
> but my suggestion was that if the module name and the path name are the
> same, you don't need to say it.
>
> (And quite frankly, I think it reads better as "submodule" than as "path",
> but maybe that threw you).
I did indeed glance over the "submodule == path" in your mail (and it
seems Junio did so too).
I thought it was more or less agreed that the URL should be associated
to the logical module rather than the path (which you call "submodule"
here). See http://article.gmane.org/gmane.comp.version-control.git/47567 .
Personally, I find your section names confusing.
Both your "submodule"s and "module"s are submodules from the point
of view of the project containing the .gitmodules.
And anything in the "submodule" section is only a (proper) submodule
of some other module if there happens to be a "module" containing it.
What's wrong with the following?
[module "infrastructure"]
submodule = lib
submodule = build
[module "lib"]
url = git://xyzzy/lib-1.2.3
[module "build"]
url = git://xyzzy/build-0.61
A module with a "url" attribute can be cloned from that url.
A module with one or more "submodule" attributes requires
these modules as well.
> > Why not allow a module to both contain smaller modules and be contained
> > in a bigger module?
>
> Because the "module" definition is _different_ from the "submodule"
> definition.
>From the point of view of the user, they are the same.
They can both be used as an argument to
git submodule checkout
> The "module" definition is just a level of indirection.
But why limit yourself to _one_ level of indirection?
If you call everything a "module" (or everything a "submodule")
then you get multiple levels of indirection for free.
skimo
^ permalink raw reply
* [PATCH] Fix git-am(1) synopsis formatting
From: Jonas Fonseca @ 2007-06-02 17:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-am.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 7658fbd..f3387f5 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,6 @@ SYNOPSIS
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
<mbox>|<Maildir>...
-
'git-am' [--skip | --resolved]
DESCRIPTION
--
1.5.2.816.gc5560-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] git-rebase: suggest to use git-add instead of git-update-index
From: Jonas Fonseca @ 2007-06-02 17:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The command is part of the main porcelain making git-add more
appropriate.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
git-rebase.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
I don't know if this is good or not, maybe it is a matter of taste, but
as a new git user I prefer to use git add.
diff --git a/git-rebase.sh b/git-rebase.sh
index 61770b5..2aa3a01 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -55,7 +55,7 @@ continue_merge () {
if test -n "$unmerged"
then
echo "You still have unmerged paths in your index"
- echo "did you forget update-index?"
+ echo "did you forget to use git add?"
die "$RESOLVEMSG"
fi
@@ -126,7 +126,7 @@ do
--continue)
git-diff-files --quiet || {
echo "You must edit all merge conflicts and then"
- echo "mark them as resolved using git update-index"
+ echo "mark them as resolved using git add"
exit 1
}
if test -d "$dotest"
--
1.5.2.816.gc5560-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Add option -L to git-tag.
From: Junio C Hamano @ 2007-06-02 18:22 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: git
In-Reply-To: <46616C19.4020800@xs4all.nl>
Matthijs Melchior <mmelchior@xs4all.nl> writes:
> Junio C Hamano wrote:
> ...
>> I dunno; I've never been very good at the user interfaces.
>>
> Yes, since I have this command and have seen the tag annotations in the
> git repository, I think we need this extra parameter.
> I propose to give the number of lines you want to see, with 0 gives all.
> So it will be --pretty=<max-number-lines> to limit the output and be
> able to find interesting stuff before looking at the complete message.
Please do not use the same word used elsewhere ('pretty') and
make it mean something different (they are 'short', 'oneline', etc.
in other places).
Regardless of how we might do a single-liner output, I suspect that
Instead of showing them like this (your patch):
$ git tag -L v2.6.1* | head -n 6
v2.6.11
This is the 2.6.11 tree object.
v2.6.11-tree
This is the 2.6.11 tree object.
v2.6.12
This is the final 2.6.12 release
showing them in this way might be more pleasant:
$ git tag -L v2.6.1* | head -n 3
v2.6.11 This is the 2.6.11 tree object.
v2.6.11-tree This is the 2.6.11 tree object.
v2.6.12 This is the final 2.6.12 release
This matches the way "git branch -v" without other arguments,
which I think is the moral equivalent for branches to your "git
tag -L", shows a bit more information than the usual (we could
even say "git tag -l -v" but -v is already taken -- we could
still do "git tag --list --verbose" and leave the short '-v' to
mean 'verify' but I dunno).
This is a slightly related tangent, but I've been wanting to
extend the "the first line is special 'one-line summary',
separated by a blank line from the rest of the more descriptive
message" convention used in the commit log message formatter.
When somebody asks for --pretty=oneline, instead of showing the
"first line", we would give the first paragraph, with LFs
replaced with SPs to make it a single line. This would not
affect commit log messages that follow the above convention.
If your tags have a few lines to describe what the commits are
about, it might make it easier to get the overview by applying
the same "first paragraph squashed down to a single line" logic,
grab the first paragraph, present it as a one-liner" in the
format shown above.
>>> - Sorting the tag names resulting from git-rev-parse is not nessecary since
>>> the list of tags is already deliverd in sorted order.
>>
>> This I am a bit reluctant about, as that sorting done by
>> rev-parse is purely by accident (i.e. it is an implementation
>> detail).
>>
> This accident can be repaired by documenting it.... :)
That would cast the implementation in stone, avoidance of which
was the point of my comment.
>> What does this command exit with now? It used to be that
>>
>> $ git tag -l no-such-tag-at-all ; echo $?
>>
>> said "1", I think, because grep did not match.
>>
> It will always exit 0, either from sed or git-cat.
>
> ...
>
> (maybe the exit code is not worth the added complexity...).
That's 40% satisfactory answer.
I do not speak for others, but when I comment on a patch, saying
"This might be better done this other way", or "This change
might be bad", I do not necessarily expect/want you to agree
with me on all counts. I would very much be happier to get a
counter argument back -- that's how we both learn things and
make progress.
Unlike Linus, I am not always right ;-)
But more seriously, I sometimes deliberately make suggestions
that I know are not optimal, because I want to involve other
people (not necessarily the author of the patch, but others on
the list) in the process of making improvements.
The "40%" satisfactory part comes from that you correctly
answered that your version now always exits zero while the
original diagnosed the "no such tag whatsoever" situation with
non-zero exit, with a slight hint that you think it might be
better not to differenciate the "no match" case.
What I would prefer to see is to make that "slight hint" more
explicit. As you say, "is not worth the added complexity" is a
possible justification, but in this particular case, I think we
could (and probably should) even argue that the current exit
code is not so useful. It might go like this...
Although "git tag -l <pattern>" currently signals non-match
with its exit code, "git tag -l do-i-have-this-tag" is not
the right way to ask that question to begin with, because
the tagname parameter is always taken as a pattern. For
that, "git show-ref --verify refs/tags/do-i-have-this-tag"
is much better. I do not think the current exit status from
"git-tag -l <pattern>" is useful, and we should change it to
exit with 0 unless we see other errors (e.g. "not a git
repository"), regardless of the addition of -L option.
and you would have got the remaining 60% ;-).
I care about documenting the change in behaviour and justifying
why we changed the behavikour in the commit log.
^ permalink raw reply
* Re: [PATCH] Create a new manpage for the gitignore format, and reference it elsewhere
From: Junio C Hamano @ 2007-06-02 18:24 UTC (permalink / raw)
To: Josh Triplett; +Cc: Frank Lichtenheld, git
In-Reply-To: <4661A0BC.2060201@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> Now that I understand the issue you raised, I can easily fix it and
> send a revised patch. Expect one momentarily.
Thanks both. Yes the original description showed my
incompetence in wording.
^ permalink raw reply
* [RFC PATCH] Add git quick reference
From: Jonas Fonseca @ 2007-06-02 18:24 UTC (permalink / raw)
To: git
It attempts to list some of the most commonly used commands, which should
give new users an idea of how to get started.
Available both as a manpage (generated via a script) and HTML page.
---
Documentation/Makefile | 8 ++-
Documentation/asciidoc.conf | 2 +
Documentation/git-quick-ref.sh | 67 ++++++++++++++++++++++
Documentation/quick-reference.txt | 112 +++++++++++++++++++++++++++++++++++++
4 files changed, 187 insertions(+), 2 deletions(-)
create mode 100755 Documentation/git-quick-ref.sh
create mode 100644 Documentation/quick-reference.txt
This is "ported" from the Cogito quick reference that I made (inspired
by svn-ref) to serve as something to hand out for new users--a kinda
cheat sheet. I don't know if git even needs another document in this
category. However, contrary to some of the others, this document tries
to be very brief, which might help impatient users. ;)
Also, I am, myself, quite new to the git porcelain so any feedback on
which commands should be included would be very much appreciated! I'd
like to keep the format to 2 pages max, so there is still room for a
few additions.
See the end result at:
http://jonas.nitro.dk/git/quick-reference.{html,pdf}
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3f92783..9dcabaf 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -3,7 +3,7 @@ MAN1_TXT= \
$(wildcard git-*.txt)) \
gitk.txt
MAN5_TXT=gitattributes.txt
-MAN7_TXT=git.txt
+MAN7_TXT=git.txt git-quick-ref.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
@@ -18,6 +18,7 @@ ARTICLES += hooks
ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += glossary
+ARTICLES += quick-reference
# with their own formatting rules.
SP_ARTICLES = howto/revert-branch-rebase user-manual
@@ -107,7 +108,7 @@ git.7 git.html: git.txt core-intro.txt
clean:
rm -f *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
- rm -f $(cmds_txt) *.made
+ rm -f $(cmds_txt) *.made git-quick-ref.txt
%.html : %.txt
rm -f $@+ $@
@@ -129,6 +130,9 @@ clean:
user-manual.xml: user-manual.txt user-manual.conf
$(ASCIIDOC) -b docbook -d book $<
+git-quick-ref.txt: quick-reference.txt
+ ./git-quick-ref.sh $< > $@
+
XSLT = http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index fa7dc94..546a074 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -12,6 +12,8 @@ caret=^
startsb=[
endsb=]
tilde=~
+# Five non breaking spaces used for option indentation in the quick reference
+qrefopt=     
ifdef::backend-docbook[]
[gitlink-inlinemacro]
diff --git a/Documentation/git-quick-ref.sh b/Documentation/git-quick-ref.sh
new file mode 100755
index 0000000..65b02b3
--- /dev/null
+++ b/Documentation/git-quick-ref.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+#
+# Generate asciidoc manpage markup from Git quick reference file.
+# Copyright (c) Jonas Fonseca, 2007
+#
+# Takes the path to the reference file. Prints the manpage to stdout.
+
+reffile="$1"
+
+cat <<__END__
+git-quick-ref(7)
+================
+
+NAME
+----
+git-quick-ref - Git quick reference
+
+SYNOPSIS
+--------
+A list of frequently used commands grouped with related commands.
+
+DESCRIPTION
+-----------
+
+__END__
+
+sed '
+ 0,/^$/d
+ /^`---/d
+ /frame="none"/,1d
+ s/\\$//
+ s/[*]\([^*]*\)[*]/\1/g
+ s/[`]\([^`]*\)[`]/\1/g
+ s/['\'']\([^'\'']*\)['\'']/\1/g
+' < "$reffile" | \
+while read line; do
+ col1=$(echo "$line" | cut -f 1)
+ case "$line" in
+ *":")
+ echo "$line"
+ echo "$line" | sed "s/[^~]/~/g"
+ echo
+ echo "[verse]"
+ continue
+ ;;
+ "-----"*|"")
+ echo "$line" | sed 's/-/./g'
+ continue
+ ;;
+ "{qrefopt}"*)
+ col1=$(echo "$col1" | sed 's/.*qrefopt}/ /')
+ ;;
+ esac
+ col2=$(echo "$line" | sed 's/.*[ ]\+//')
+ printf "%-30s %s\n" "$col1" "$col2"
+done
+
+cat << __END__
+
+DOCUMENTATION
+-------------
+Documentation by Jonas Fonseca and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+__END__
diff --git a/Documentation/quick-reference.txt b/Documentation/quick-reference.txt
new file mode 100644
index 0000000..4ab8620
--- /dev/null
+++ b/Documentation/quick-reference.txt
@@ -0,0 +1,112 @@
+Git Quick Reference
+===================
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Getting help:
+------------------------------------------------------------------------------
+*git help* 'command' or
+*git* 'command' \--help Show help for a command
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Repository creation:
+------------------------------------------------------------------------------
+*git init* Create a repository in the current directory
+*git clone* 'url' Clone a remote repository into a subdirectory
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+File operations:
+------------------------------------------------------------------------------
+*git add* 'path' Add file or files in directory recursively
+*git rm* 'path' Remove file or directory from the working tree
+{qrefopt} -f Force deletion of file(s) from disk
+*git mv* 'path' 'destination' Move file or directory to new location
+{qrefopt} -f Overwrite existing destination files
+*git checkout* '[rev]' 'file' Restore file from current branch or revision
+{qrefopt} -f Overwrite uncommitted local changes
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Working tree:
+------------------------------------------------------------------------------
+*git status* Show status of the working tree
+*git diff* '[path]' Show diff of changes in the working tree
+*git diff* HEAD 'path' Show diff of stages and unstaged changes
+*git add* 'path' Stage file for commit
+*git reset* HEAD 'path' Unstage file for commit
+*git commit* Commit files that has been staged (with git-add)
+{qrefopt} -a Automatically stage all modified files
+*git reset* \--soft HEAD^ Undo commit & keep changes in the working tree
+*git reset* \--hard HEAD^ Reset the working tree to the last commit
+*git clean* Clean unknown files from the working tree
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Examining History:
+------------------------------------------------------------------------------
+*git log* '[path]' View commit log, optionally for specific path
+*git log* '[from[..to]]' View commit log for a given revision range
+{qrefopt} \--stat List diffstat for each revision
+{qrefopt} -S'pattern' Search history for changes matching pattern
+*git blame* '[file]' Show file annotated with line modifications
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Remote repositories - 'remotes':
+------------------------------------------------------------------------------
+*git fetch* '[remote]' Fetch changes from a remote repository
+*git pull* '[remote]' Fetch and merge changes from a remote repository
+*git push* '[remote]' Push changes to a remote repository
+*git remote* List remote repositories
+*git remote add* 'remote' 'url' Add remote to list of tracked repositories
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Branches:
+------------------------------------------------------------------------------
+*git checkout* 'branch' Switch working tree to branch
+{qrefopt} -b 'branch' Create branch before switching to it
+*git branch* List local branches
+*git branch* -f 'branch' 'rev' Overwrite existing branch, start from revision
+*git merge* 'branch' Merge changes from branch
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Exporting and importing:
+------------------------------------------------------------------------------
+*git apply* - < 'file' Apply patch from stdin
+*git format-patch* 'from[..to]' Format a patch with log message and diffstat
+*git archive* 'rev' > 'file' Export snapshot of revision to file
+{qrefopt} \--prefix='dir'/ Nest all files in the snapshot in directory
+{qrefopt} \--format='[tar|zip]' Specify archive format to use: 'tar' or 'zip'
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Tags:
+------------------------------------------------------------------------------
+*git tag* 'name' '[revision]' Create tag for a given revision
+{qrefopt} -s Sign tag with your private key using GPG
+{qrefopt} -l '[pattern]' List tags, optionally matching pattern
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+File status flags:
+------------------------------------------------------------------------------
+`M` modified File has been modified
+`C` copy-edit File has been copied and modified
+`R` rename-edit File has been renamed and modified
+`A` added File has been added
+`D` deleted File has been deleted
+`U` unmerged File has conflicts after a merge
+------------------------------------------------------------------------------
--
1.5.2.816.gc5560-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Allow CFLAGS to be overridden while preserving VERSION
From: Jonas Fonseca @ 2007-06-02 18:35 UTC (permalink / raw)
To: James Bowes; +Cc: git
In-Reply-To: <118080449045-git-send-email-jbowes@dangerouslyinc.com>
James Bowes <jbowes@dangerouslyinc.com> wrote Sat, Jun 02, 2007:
> If someone defined their own CFLAGS, they would have to include a -DVERSION=
> as well (or else get unknown-version as the version).
Thank you, applied and pushed out.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Use =20 when rfc2047 encoding spaces.
From: Junio C Hamano @ 2007-06-02 18:51 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11807320922292-git-send-email-hoegsberg@gmail.com>
Kristian Høgsberg <hoegsberg@gmail.com> writes:
> Encode ' ' using '=20' even though rfc2047 allows using '_' for
> readability..
Thanks.
Your message was marked as iso-8859-1 even though it was utf-8
(your signed-off-by line), so I'll fix it up with your From:
header.
^ permalink raw reply
* Re: [PATCH] Use =20 when rfc2047 encoding spaces.
From: Junio C Hamano @ 2007-06-02 18:58 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <7vd50eqjef.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Kristian Høgsberg <hoegsberg@gmail.com> writes:
>
>> Encode ' ' using '=20' even though rfc2047 allows using '_' for
>> readability..
>
> Thanks.
>
> Your message was marked as iso-8859-1 even though it was utf-8
> (your signed-off-by line), so I'll fix it up with your From:
> header.
Oh, another thing. Before you submit a patch, make sure the
whole testsuite in t/ passes by running "make test".
^ permalink raw reply
* Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Yann Dirson @ 2007-06-02 19:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070506142233.GA20017@diana.vm.bytemark.co.uk>
On Sun, May 06, 2007 at 04:22:33PM +0200, Karl Hasselström wrote:
> On 2007-05-06 15:39:09 +0200, Yann Dirson wrote:
>
> > Well, this case clearly falls in the category of "actions outside
> > stgit that make it possible to rebase without a loss". But then it
> > is also clear that the action of tagging makes the committed patch
> > reachable, and thus the rebase loss-less.
> >
> > The safety check could be possibly be rewritten as "check if current
> > base is reachable without using any refs from current series".
>
> Yes, I like that idea _much_ better. That's what we _should_ be
> testing for, given that the objective is to keep all commits
> reachable.
>
> So, how can we do that? gitk displays, when you view a commit, the
> heads through which that commit is reachable. How does it compute
> that? Hmm, it seems like this type of construct works for selecting
> only those commits that are only reachable through a given ref:
>
> gitk origin/pu --not $(git show-ref | grep -v refs/remotes/origin/pu| cut -f 1 -d ' ')
>
> Of course, one could use git log instead of gitk if it turns out to be
> too hard to write an x-windows parser for stgit. :-)
Indeed, gitk calls git-rev-list with those arguments, so the check can
be easily rewritten :)
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH] git-rebase: suggest to use git-add instead of git-update-index
From: Junio C Hamano @ 2007-06-02 19:07 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20070602175949.GB19952@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> The command is part of the main porcelain making git-add more
> appropriate.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> git-rebase.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> I don't know if this is good or not, maybe it is a matter of taste, but
> as a new git user I prefer to use git add.
I like it. Thanks.
^ 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