* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Shawn Pearce @ 2006-09-18 17:55 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20060918083114.GQ20913@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
> Hi,
>
> > This is a set of bash completion routines for many of the
> > popular core Git tools. I wrote these routines from scratch
> > after reading the git-compl and git-compl-lib routines available
> > from the gitcompletion package at http://gitweb.hawaga.org.uk/
> > and found those to be lacking in functionality for some commands.
>
> Did you talk to Ben Clifford (the maintainer of these scripts) before?
No. I found his scripts yesterday, played around with them for
about 15 minutes and found them to be missing some features.
In particular they don't actually list all branch names as they
only list only those contained directly in refs/heads. This is
certainly very annoying when your topic branch policy uses "sp/",
"jh/", "lt/" as branch name prefixes. It also won't work with Linus'
new packed ref format...
Ben's scripts also don't always complete tags at points where Git
accepts a tag, nor can they complete through a path with git diff
or git cat-file to yank a file out of another branch which doesn't
exist in the current working directory. They also can't complete
branch names in a remote repository when you are fetching or pushing.
So I set out to write my own, finished it in less than an hour,
used it for 4 hours while doing some merging, and sent an email to
put the script into contrib. :-)
> His scripts seem to be in pretty wide-spread use already, so it might
> make sense to join efforts and improve his scripts (and get them
> into git-core).
Agreed. There may be a few things my script is lacking but I
think the one I sent yesterday is already more powerful than Ben's.
But I'd like to see it be smarter about completion context and do
even more. But right now I'm happy as it can complete my topic
branch names and tag names.
I'd like to see core Git at least carry the completion for core Git.
I know Ben has support for StGit and Cogito as well; two packages
that my script doesn't support. In my humble opnion the completion
scripts should migrate into the packages they support. I don't
think its unreasonable to expect bash completion support to be part
of a popular package which is heavily dependent on the shell for
its user interface[*1*].
> > Consequently there may be some similarities but many differences.
>
> Do you know of any (incompatible) differences?
None that I can think of. I believe that my script will complete
anything Ben's does with the exception of a stray single character
option here or there.
You can't load both into your shell at the same time as bash will
only accept one completion function for any given command and both
packages use the same function names to implement the completion
logic.
[*1*] So long as there is someone to maintain it anyway. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Shawn Pearce @ 2006-09-18 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virjlr3am.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > +_git_log ()
> > +{
> > +...
> > +}
> > +...
> > +_git_whatchanged ()
> > +{
> > +...
> > +}
>
> These two look the same. Probably not very easy to maintain in
> the long run.
They are the same.
> It would be nice to have git-show as well but it usually does
> not take ranges unlike these two. It is more like "git branch"
> from completion purposes.
Like this? :-)
-- >8 --
Consolidated git_log and git_whatchanged; added git_show.
Minor requests from Junio: Consolidate the identical implementations of
git_log and git_whatchanged, especially since these two commands take
pretty much identical arguments. This should make the completion package
a little easier to maintain.
Also added branch name completion for git-show. I tried to implement
--pretty=oneline (etc.) but am apparently missing something as bash did
not want to complete it through the registered completion routine, so that's
still unsupported.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/bash-git-completion.sh | 21 +++++++--------------
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/contrib/bash-git-completion.sh b/contrib/bash-git-completion.sh
index 4800185..e8cf6bb 100644
--- a/contrib/bash-git-completion.sh
+++ b/contrib/bash-git-completion.sh
@@ -254,19 +254,10 @@ _git_push ()
esac
}
-_git_whatchanged ()
+_git_show ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- case "$cur" in
- *..*)
- local pfx=$(echo "$cur" | sed 's/\.\..*$/../')
- cur=$(echo "$cur" | sed 's/^.*\.\.//')
- COMPREPLY=($(compgen -P "$pfx" -W "$(__git_refs .)" -- "$cur"))
- ;;
- *)
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
- ;;
- esac
+ COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
}
_git ()
@@ -288,7 +279,8 @@ _git ()
ls-tree) _git_ls_tree ;;
pull) _git_pull ;;
push) _git_push ;;
- whatchanged) _git_whatchanged ;;
+ show) _git_show ;;
+ whatchanged) _git_log ;;
*) COMPREPLY=() ;;
esac
fi
@@ -314,7 +306,8 @@ complete -o default -o nospace -F _git_l
complete -o default -F _git_merge_base git-merge-base
complete -o default -o nospace -F _git_pull git-pull
complete -o default -o nospace -F _git_push git-push
-complete -o default -o nospace -F _git_whatchanged git-whatchanged
+complete -o default -F _git_show git-show
+complete -o default -o nospace -F _git_log git-whatchanged
# The following are necessary only for Cygwin, and only are needed
# when the user has tab-completed the executable name and consequently
@@ -327,4 +320,4 @@ complete -o default -o nospace -F _git_l
complete -o default -o nospace -F _git_ls_tree git-ls-tree.exe
complete -o default -F _git_merge_base git-merge-base.exe
complete -o default -o nospace -F _git_push git-push.exe
-complete -o default -o nospace -F _git_whatchanged git-whatchanged.exe
+complete -o default -o nospace -F _git_log git-whatchanged.exe
--
1.4.2.1.ga817
^ permalink raw reply related
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Shawn Pearce @ 2006-09-18 17:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609181012180.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> the only gripe I have with it: whenever some options are added, or
> removed, or renamed, you have to adapt the completion script. That is why
> I started (ages ago) to auto-generate the completion script from the
> documentation (of course, this means that the options have to be described
> consistently in the documentation, which is good in its own).
>
> Unfortunately, I never got around to finish it, but a preliminary version
> is in the mailing list archives.
I was torn about putting options into the completion list. Right now
"-l -b -f" are available for 'git checkout' but I think that was
a bad idea. There's little point in offering completion for an
option which is a single character. But that's my opinion and I'm
sure someone else might actually find it useful.
Longer options however such as "--since" or "--pretty=" with its
associated format options, or the merge strategy argument to "-s"
would all be nice to have completion support for. However I did
not implement these.
> However, since your script works well, and I do not have a working script,
> you clearly won! So, unless some kind soul actually implements my
> proposal, I am happy with your script.
I was mainly getting tired of copying and pasting or retyping
branch names and remote names. So that's what I implemented.
(And remote names aren't quite right as they don't tab complete
the ones available in .git/config.)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] revision traversal: --author, --committer, and --grep.
From: Linus Torvalds @ 2006-09-18 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Kai Blin
In-Reply-To: <7vslipsm4x.fsf@assigned-by-dhcp.cox.net>
On Sun, 17 Sep 2006, Junio C Hamano wrote:
>
> I wanted to default it to left anchored, so this was somewhat
> deliberate, but this is probably subject to taste.
I know that I'd prefer a rule where
"--author=^Junio"
would result in the grep-pattern being "^author Junio", but without the
initial '^' it would be "^author .*Junio".
So something like this, perhaps? It allows the regular left anchoring
syntax ('^' at the start of a pattern), but defaults to the default grep
behaviour ("anywhere in the line").
Linus
---
diff --git a/revision.c b/revision.c
index 26dd418..bca1229 100644
--- a/revision.c
+++ b/revision.c
@@ -677,6 +677,7 @@ int handle_revision_arg(const char *arg,
static void add_header_grep(struct rev_info *revs, const char *field, const char *pattern)
{
char *pat;
+ const char *prefix;
int patlen, fldlen;
if (!revs->header_filter) {
@@ -689,8 +690,13 @@ static void add_header_grep(struct rev_i
fldlen = strlen(field);
patlen = strlen(pattern);
- pat = xmalloc(patlen + fldlen + 3);
- sprintf(pat, "^%s %s", field, pattern);
+ pat = xmalloc(patlen + fldlen + 10);
+ prefix = ".*";
+ if (*pattern == '^') {
+ prefix = "";
+ pattern++;
+ }
+ sprintf(pat, "^%s %s%s", field, prefix, pattern);
append_grep_pattern(revs->header_filter, pat,
"command line", 0, GREP_PATTERN);
}
^ permalink raw reply related
* Re: [RFC] git-pack-refs --prune
From: Linus Torvalds @ 2006-09-18 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7shr5zw.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 18 Sep 2006, Junio C Hamano wrote:
>
> I am not sure I got the locking right, hence this RFC.
It looks correct (the important part to check is that the SHA1 of the ref
you remove still matches the SHA1 of the object you packed).
That said, we should fix it up a bit, notably
- we should _not_ prune refs that are indirect.
Right now, if we have a symbolic link, we _incorrectly_ pack it as
unlinked. The packed format doesn't have any "link" format.
This isn't a problem in practice, because the only link we ever use is
the HEAD link, but it's incorrect. As long as we don't prune, it wasn't
an issue - a unpacked head will always override a packed one, so
packing the thing didn't really matter.
- we should probably avoid even trying to prune stuff that was already
packed.
The way to fix both these problems at once would be to add a flag to the
"for_each_ref()", which says whether it followed a link, or whether it was
already packed, so that we wouldn't pack symlinks at all, and we wouldn't
add already-packed refs to the "keeprefs" list.
But that requires a sligh semantic extension to "do_for_each_ref()" (and
"struct ref_list" needs a flag to say whether it was looked up through a
symlink).
I was thinking that the easy way to solve it is to just _pack_ everything
(the way we do now - incorrectly for symrefs), but never prune a symref.
Linus
^ permalink raw reply
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Linus Torvalds @ 2006-09-18 16:31 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20060918065429.6f4de06e.chriscool@tuxfamily.org>
On Mon, 18 Sep 2006, Christian Couder wrote:
>
> With the new packed ref file format from Linus, this should be
> the new way to remove a branch.
Well, it's not really sufficient.
Somebody should add this test-case
git branch test
git branch -d test
git branch test/first
which should work.
It's entirely possible that the proper way to do branch deletion with
packed branches is to simply re-pack without the old branch, rather than
the negative branch model. I couldn't really decide.
However: this part is definitely correct, considering that we allow the
null sha1 in other places.
> "refs.c" is fixed so that a null sha1 for a deleted branch does
> not result in "refs/head/deleted does not point to a valid
> commit object!" messages.
And this last part is conceptually ok, but I think the implementaion is
wrong:
> "t/t3200-branch.sh" is fixed so that it uses git-show-ref
> instead of checking that the ref does not exist when a branch
> is deleted.
I think you should change the
! git-show-ref --verify --quiet -- "refs/heads/d/e/f" &&
into
git-show-ref --verify --quiet -- "refs/heads/d/e/f" ||
instead, no?
Linus
^ permalink raw reply
* Re: What's in git.git
From: Franck Bui-Huu @ 2006-09-18 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu035u4c3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> - Franck Bui-Huu and Rene Scharfe added 'git-archive' command,
> that will eventually supersede 'git-tar-tree' and
> 'git-zip-tree'.
>
I still have one issue, but haven't found out the solution yet.
Actually I even don't know if its related to 'archive/upload-archive'
commands. Could someone give it a try to tell me if he can at least
reproduce it ?
Here is the scenario (git-daemon and git-archive are executed on the
same machine):
git-daemon is started with the following command:
$ git daemon --verbose --syslog --export-all \
--enable=upload-archive --base-path=/home/fbuihuu/tmp/ --reuseaddr
git-archive is run to archive a small repo located in ~/tmp/test-git.
This is done in an endless loop:
$ while true; do
> git archive --format=tar --remote=git://localhost/test-git HEAD | tar tf -
> done
a
b
a
b
a
b
a
b
a
b
a
b
a
b # stuck !!!
So after a couple of loops, git-archive is stuck waiting for git-daemon but
daemon seems to be stuck somewhere.
Syslog shows something interesting here:
[...]
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Connection from 127.0.0.1:30373
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Extended attributes (16 bytes) exist <host=localhost>
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Request upload-archive for '/test-git2'
Sep 18 16:11:42 25-fbuihuu git-upload-archive: finished
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Disconnected
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Connection from 127.0.0.1:30629
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Extended attributes (16 bytes) exist <host=localhost>
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Request upload-archive for '/test-git2'
Sep 18 16:11:42 25-fbuihuu git-upload-archive: finished
[END]
It looks like git-daemon never receives the SIGCHLD signal that is
normally sent by upload-archive once it has finished its job.
Franck
^ permalink raw reply
* Re: git and Solaris 8
From: Paul Jakma @ 2006-09-18 14:05 UTC (permalink / raw)
To: skimo; +Cc: Peter Eriksen, Junio C Hamano, Uwe Zeisberger, git
In-Reply-To: <20060918134100.GL1221MdfPADPa@greensroom.kotnet.org>
On Mon, 18 Sep 2006, Sven Verdoolaege wrote:
> All I know is that I have a Solaris *8* machine here and that I
> _don't_ need NEEDS_LIBICONV. There is no -liconv on this machine.
> (I'm CC'ing Uwe, because he apparently also has access to a Solaris
> 8 machine).
I tested on S10, SNV (probably somewhere around SNV_14, can't quite
remember) and S9 (whichever the latest update was). None need
-liconv, it's a build error on S10 (which was the one I cared about).
I can dig into the Iconv situation further later in the week, or
next. I am away from home at moment.
> So is the current setting correct on some versions of Solaris 8 and
> if so, is there some way to change this setting from the command
> line ?
I couldn't find an S8 machine to test on, so I left S8 alone -
existing behaviour, I had no basis to judge it incorrect. S8 is
/really/ old now btw. ;)
> Btw, like Uwe, I also don't have a "gtar" and "ginstall" on this machine.
S10, maybe S9 too (not sure), install these to /usr/sfw/bin, if you
installed everything.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Interference from lunar radiation
^ permalink raw reply
* git and Solaris 8
From: Sven Verdoolaege @ 2006-09-18 13:41 UTC (permalink / raw)
To: Peter Eriksen, Paul Jakma, Junio C Hamano; +Cc: Uwe Zeisberger, git
Commits 2fd955cc0b49de9e64b2f073ce76033975f0be24 and
e15f545155bb4b2cad4475a25cad8fb576d37dee seem to contradict each other.
The first claims that NEEDS_LIBICONV is needed on Solaris 10,
while the second claims that it is not needed on Solaris 9 and up.
All I know is that I have a Solaris *8* machine here and that I _don't_
need NEEDS_LIBICONV. There is no -liconv on this machine.
(I'm CC'ing Uwe, because he apparently also has access to a Solaris 8
machine).
So is the current setting correct on some versions of Solaris 8
and if so, is there some way to change this setting from the command
line ?
Btw, like Uwe, I also don't have a "gtar" and "ginstall" on this machine.
SunOS billie 5.8 Generic_117350-39 sun4u sparc
skimo
^ permalink raw reply
* [PATCH] Add man page for git-show-ref
From: Jonas Fonseca @ 2006-09-18 12:32 UTC (permalink / raw)
To: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-show-ref.txt | 136 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 136 insertions(+), 0 deletions(-)
Mostly paraphrasing Linus' commit message ...
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
new file mode 100644
index 0000000..529ea17
--- /dev/null
+++ b/Documentation/git-show-ref.txt
@@ -0,0 +1,136 @@
+git-show-ref(1)
+===============
+
+NAME
+----
+git-show-ref - List references in a local repository
+
+SYNOPSIS
+--------
+[verse]
+'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+ [--tags] [--heads] [--] <pattern>...
+
+DESCRIPTION
+-----------
+
+Displays references available in a local repository along with the associated
+commit IDs. Results can be filtered using a pattern and tags can be
+dereferenced into object IDs. Additionally, it can be used to test whether a
+particular ref exists.
+
+Use of this utility is encouraged in favor of directly accessing files under
+in the `.git` directory.
+
+OPTIONS
+-------
+
+-h, --head::
+
+ Show the HEAD reference.
+
+--tags, --heads::
+
+ Limit to only "refs/heads" and "refs/tags", respectively. These
+ options are not mutually exclusive; when given both, references stored
+ in "refs/heads" and "refs/tags" are displayed.
+
+-d, --dereference::
+
+ Dereference tags into object IDs. They will be shown with "^{}"
+ appended.
+
+--verify::
+
+ Enable stricter reference checking by requiring an exact ref path.
+ Aside from returning an error code of 1, it will also print an error
+ message if '--quiet' was not specified.
+
+-q, --quiet::
+
+ Do not print any results to stdout. When combined with '--verify' this
+ can be used to silently check if a reference exists.
+
+<pattern>::
+
+ Show references matching one or more patterns.
+
+OUTPUT
+------
+
+The output is in the format: '<SHA-1 ID>' '<space>' '<reference name>'.
+
+-----------------------------------------------------------------------------
+$ git show-ref --head --dereference
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
+3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
+6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
+055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
+423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
+...
+-----------------------------------------------------------------------------
+
+EXAMPLE
+-------
+
+To show all references called "master", whether tags or heads or anything
+else, and regardless of how deep in the reference naming hierarchy they are,
+use:
+
+-----------------------------------------------------------------------------
+ git show-ref master
+-----------------------------------------------------------------------------
+
+This will show "refs/heads/master" but also "refs/remote/other-repo/master",
+if such references exists.
+
+When using the '--verify' flag, the command requires an exact path:
+
+-----------------------------------------------------------------------------
+ git show-ref --verify refs/heads/master
+-----------------------------------------------------------------------------
+
+will only match the exact branch called "master".
+
+If nothing matches, gitlink:git-show-ref[1] will return an error code of 1,
+and in the case of verification, it will show an error message.
+
+For scripting, you can ask it to be quiet with the "--quiet" flag, which
+allows you to do things like
+
+-----------------------------------------------------------------------------
+ git-show-ref --quiet --verify -- "refs/heads/$headname" ||
+ echo "$headname is not a valid branch"
+-----------------------------------------------------------------------------
+
+to check whether a particular branch exists or not (notice how we don't
+actually want to show any results, and we want to use the full refname for it
+in order to not trigger the problem with ambiguous partial matches).
+
+To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
+respectively (using both means that it shows tags and heads, but not other
+random references under the refs/ subdirectory).
+
+To do automatic tag object dereferencing, use the "-d" or "--dereference"
+flag, so you can do
+
+-----------------------------------------------------------------------------
+ git show-ref --tags --dereference
+-----------------------------------------------------------------------------
+
+to get a listing of all tags together with what they dereference.
+
+SEE ALSO
+--------
+gitlink:git-ls-remote[1], gitlink:git-peek-remote[1]
+
+AUTHORS
+-------
+Written by Linus Torvalds <torvalds@osdl.org>.
+Man page by Jonas Fonseca <fonseca@diku.dk>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.4.2.1.gca4e
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Sebastian Harl @ 2006-09-18 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060918004831.GA19851@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
Hi,
> This is a set of bash completion routines for many of the
> popular core Git tools. I wrote these routines from scratch
> after reading the git-compl and git-compl-lib routines available
> from the gitcompletion package at http://gitweb.hawaga.org.uk/
> and found those to be lacking in functionality for some commands.
Did you talk to Ben Clifford (the maintainer of these scripts) before? His
scripts seem to be in pretty wide-spread use already, so it might make sense
to join efforts and improve his scripts (and get them into git-core).
> Consequently there may be some similarities but many differences.
Do you know of any (incompatible) differences?
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Junio C Hamano @ 2006-09-18 8:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060918004831.GA19851@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> +_git_log ()
> +{
> +...
> +}
> +...
> +_git_whatchanged ()
> +{
> +...
> +}
These two look the same. Probably not very easy to maintain in
the long run.
It would be nice to have git-show as well but it usually does
not take ranges unlike these two. It is more like "git branch"
from completion purposes.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-09-18 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609181010500.19042@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > That's not a good excuse, though. It means you cannot propose
>> > new core-side support that only gitweb would benefit from
>> > initially, since we will not add new stuff to the core that does
>> > not have real users, and new stuff in the core must be cooked in
>> > "next" before it is proven to be useful and correct.
>>
>> But this also means that if I were for example to use git-for-each-ref
>> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
>> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
>> of git.
>
> Why not set up a testing directory, where you use both gitweb _and_ git
> from next? It is easy...
That's Ok; it means that he just cannot work on certain things.
It's not like we take gitweb patch only from Jakub, so it is not
the end of the world either ;-).
Also it is handy to have somebody who sticks to things that are
available in master to catch breakage we might accidentally
cause by Porcelainish commands jumping the gun before core-side
change hits the master branch.
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Johannes Schindelin @ 2006-09-18 8:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060918004831.GA19851@spearce.org>
Hi,
the only gripe I have with it: whenever some options are added, or
removed, or renamed, you have to adapt the completion script. That is why
I started (ages ago) to auto-generate the completion script from the
documentation (of course, this means that the options have to be described
consistently in the documentation, which is good in its own).
Unfortunately, I never got around to finish it, but a preliminary version
is in the mailing list archives.
However, since your script works well, and I do not have a working script,
you clearly won! So, unless some kind soul actually implements my
proposal, I am happy with your script.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-09-18 8:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeld1a$830$2@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1250 bytes --]
Hi,
On Mon, 18 Sep 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >> Junio C Hamano wrote:
> >>
> >>> - An experimental git-for-each-ref command to help language
> >>> bindings to get information on many refs at once. Hopefully
> >>> Jakub can teach gitweb to use it to speed things up.
> >>
> >> I use 'origin' (or 'next') version of gitweb, while using _released_
> >> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now
> >> I wouldn't be able to _test_ the git-for-each-ref.
> >
> > That's not a good excuse, though. It means you cannot propose
> > new core-side support that only gitweb would benefit from
> > initially, since we will not add new stuff to the core that does
> > not have real users, and new stuff in the core must be cooked in
> > "next" before it is proven to be useful and correct.
>
> But this also means that if I were for example to use git-for-each-ref
> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
> of git.
Why not set up a testing directory, where you use both gitweb _and_ git
from next? It is easy...
Ciao,
Dscho
^ permalink raw reply
* [RFC] git-pack-refs --prune
From: Junio C Hamano @ 2006-09-18 7:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609111632050.27779@g5.osdl.org>
"git pack-refs --prune", after successfully packing the existing
refs, removes the loose ref files. It tries to protect against
race by doing the usual lock_ref_sha1() which makes sure the
contents of the ref has not changed since we last looked at.
I am not sure I got the locking right, hence this RFC.
We would probably need to perform some sort of 'sync' after
closing and renaming the lockfile to its final location before
pruning. Is there a way cheaper than sync(2) to make sure the
effect of rename(2) hits the disk platter?
---
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index 0f5d827..2b3a483 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -3,6 +3,15 @@ #include "refs.h"
static FILE *refs_file;
static const char *result_path, *lock_path;
+static const char builtin_pack_refs_usage[] =
+"git-pack-refs [--prune]";
+
+static int prune;
+struct keepref {
+ struct keepref *next;
+ unsigned char sha1[20];
+ char name[FLEX_ARRAY];
+} *keepref;
static void remove_lock_file(void)
{
@@ -13,12 +22,50 @@ static void remove_lock_file(void)
static int handle_one_ref(const char *path, const unsigned char *sha1)
{
fprintf(refs_file, "%s %s\n", sha1_to_hex(sha1), path);
+ if (prune) {
+ int namelen = strlen(path) + 1;
+ struct keepref *n = xcalloc(1, sizeof(*n) + namelen);
+ hashcpy(n->sha1, sha1);
+ strcpy(n->name, path);
+ n->next = keepref;
+ keepref = n;
+ }
return 0;
}
+/* make sure nobody touched the ref, and unlink */
+static void prune_ref(struct keepref *r)
+{
+ struct ref_lock *lock = lock_ref_sha1(r->name + 5, r->sha1, 1);
+
+ if (lock) {
+ unlink(git_path(r->name));
+ unlock_ref(lock);
+ }
+}
+
+static void prune_refs(void)
+{
+ struct keepref *r;
+ for (r = keepref; r; r = r->next)
+ prune_ref(r);
+}
+
int cmd_pack_refs(int argc, const char **argv, const char *prefix)
{
- int fd;
+ int fd, i;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--prune")) {
+ prune = 1;
+ continue;
+ }
+ /* perhaps other parameters later... */
+ break;
+ }
+ if (i != argc)
+ usage(builtin_pack_refs_usage);
result_path = xstrdup(git_path("packed-refs"));
lock_path = xstrdup(mkpath("%s.lock", result_path));
@@ -37,5 +84,7 @@ int cmd_pack_refs(int argc, const char *
if (rename(lock_path, result_path) < 0)
die("unable to overwrite old ref-pack file (%s)", strerror(errno));
lock_path = NULL;
+ if (prune)
+ prune_refs();
return 0;
}
^ permalink raw reply related
* [PATCH] rev-list: fix segfault with --{author,committer,grep}
From: Jeff King @ 2006-09-18 6:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pv6yphp.fsf@assigned-by-dhcp.cox.net>
We need to save the commit buffer if we're going to match against it.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-rev-list.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 1f3333d..dbfee75 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -269,7 +269,9 @@ int cmd_rev_list(int argc, const char **
revs.diff)
usage(rev_list_usage);
- save_commit_buffer = revs.verbose_header;
+ save_commit_buffer = revs.verbose_header ||
+ revs.header_filter ||
+ revs.message_filter;
track_object_refs = 0;
if (bisect_list)
revs.limited = 1;
--
1.4.2.1.g9f1c-dirty
^ permalink raw reply related
* Re: [PATCH 3/3] revision traversal: --author, --committer, and --grep.
From: Junio C Hamano @ 2006-09-18 6:51 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, git, Kai Blin
In-Reply-To: <20060918060552.GA2833@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>The important difference is that your approach means that the user's
>regex is implicitly anchored at the beginning of the field. Thus,
>searching by email address does not work with --author=junkio, but
>rather requires --author='.*junkio'.
I wanted to default it to left anchored, so this was somewhat
deliberate, but this is probably subject to taste.
I actually wanted to do only --grep-header and --grep-message
internally with --author and --committer as simple shorthands,
and that is why --author=<pattern> is just an internal synonym
for "author <pattern>". I even considered doing without
distinction between header and body (meaning, a line in the
commit log message that happens to begin with "author " would
match --author string), which is technically incorrect but would
be more efficient. I do not think occasional false hits would
matter much in practice.
Not making the match case insensitive was probably a mistake.
Looking for "--author=linus" would be easier to type.
One thing that I know is broken is the match at the tail; I am
actually thinking of doing something like this:
sprintf(pat, "^%s %s [0-9][0-9]* [+-][0-9][0-9][0-9][0-9]$",
field, pattern);
to avoid matching the timestamps.
> A few other thoughts:
> 1. Case sensitivity?
I do not think much is lost if we make the match always case
insensitive for this application. It might be reasonable to to
default to case insensitive match but if there is a pattern that
has an uppercase use case sensitive match.
> 2. Is there any use to exposing the "header_grep" functionality with
> --grep-header?
I considered it but did not think of any. We obviously would
need to revisit this if we do "note " header in the future, but
not for now. On the other hand, it might be useful to allow
--grep-header='^\(author\|committer\) Junio'
> 3. An alias (--who=foo?) for --author=foo --committer=foo. I believe
> this doesn't require boolean magic, since we default to OR.
This should be trivial to implement (two calls to
add_header_grep instead of one), but would it be useful? I
dunno.
^ permalink raw reply
* Re: git-repack: Outof memory
From: Shawn Pearce @ 2006-09-18 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dongsheng Song
In-Reply-To: <7v64flyjpe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > ... I fear that
> > you are going to bump up against address space limitations soon
> > on 32 bit systems. Then you will bump up against the 4 GiB pack
> > file size limit. Which means you will need to use several packs
> > and avoid the '-a' flag when calling git-repack.
>
> I presume that you are hinting that we would need to update
> git-repack so that it is still useful without --all.
Yes. :-)
Apparently the Porcelain level is still open for debate. Someone
just needs to post a reasonable implementation to get discussion
(or lack there of) going. I'm too tired right now to try to roll
something up right, even though it looks to be rather simple.
As it is I'm having a difficult time navigating in vi to write this
email and normally vi navigation is as easy as breathing for me...
> I think pack-objects --unpacked=active-pack is ready, so I'll
> push it out.
Thanks; I noticed that in your "What's in git.git" announcement.
--
Shawn.
^ permalink raw reply
* Re: git pull a subtree, embedded trees
From: Shawn Pearce @ 2006-09-18 6:47 UTC (permalink / raw)
To: Timothy Shimmin; +Cc: Jakub Narebski, git
In-Reply-To: <20060918064255.GA20660@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Timothy Shimmin <tes@sgi.com> wrote:
> > So I added this to a script which walks over the objects directory,
> > to work out what all the object ids are so I can apply git-cat-file
> > to all the objects on my test directory.
> > I guess this will fall down if the objects are stored in a pack :)
> > I'll have to look and see how to extract all the object ids using
> > some command.
>
> Try this:
>
> git-rev-list --all
Sorry, that should have been:
git-rev-list --objects --all
damn brain. I guess its tired and wants some sleep. :-)
--
Shawn.
^ permalink raw reply
* Re: git pull a subtree, embedded trees
From: Shawn Pearce @ 2006-09-18 6:42 UTC (permalink / raw)
To: Timothy Shimmin; +Cc: Jakub Narebski, git
In-Reply-To: <450E3399.5070601@sgi.com>
Timothy Shimmin <tes@sgi.com> wrote:
> Jakub Narebski wrote:
> >Tim Shimmin wrote:
> >
> >>I'm new to git and have a couple of novice questions.
> >>
> >>* Is it possible to only pull in a subtree from
> >>a repository.
> >
> >I assume that by pull you mean checkout...
> >
> >I think it is possible (try git-read-tree with --prefix option,
> >and select subtree by giving either it's sha1, or e.g.
> >HEAD:<path> form), but not easy to do. Git revisions are
> >snapshots of the whole project (the revisions are states of
> >the whole project).
> >
> I'm not sure if that was what I was wanting.
>
> I'm just starting to understand git better (I think:).
> It seems like it is about having object snapshots.
> We have snapshots of files (blobs) and snapshots of a directory,
> tree objects which reference other trees and blob snapshots,
> and then we link the snapshots in time using commit objects.
> So every time we do a "git-update-index file" we create a new blob
> in the object directory and every time we do a "git-write-tree" we
> create tree objects in the database (.git/object/xx/xxxx....).
Right, but only if the object didn't previously exist. Git assumes
that the SHA1 hash of the given file content or tree content is
unique and uses that to decide if it already has a copy of the
object, or needs to save a copy into .git/objects/xx/xxx...
> So at these snapshot points, do we just keep adding more and
> more objects?
Yes, assuming we don't have the object already.
> I'm used to rcs and sccs, where we just keep diffs for file history,
> we don't do that here do we?; we keep the whole snapshot but in compressed
> form. (And then we have a packed form too.)
Git does diffs, but they are delayed. What happens is the
compressed (but complete) content is written to a loose object in
the .git/objects directory during git-update-index, git-write-tree
and git-commit-tree. Later during git-repack these loose objects
are bundled up into a new pack file. Within the pack file objects
can be deltafied against one another. Consequently what you find
is that revisions of the same file are "diff'd" against one another
once those objects are all combined up into the same pack.
Git is very good at this compression; the Mozilla CVS repository
went from ~3 GiB in CVS to ~430 MiB in Git. That's 10 years of
history on 120k files.
> So trying to understand your suggestion and the command:
> Given a tree object in our object database, we can update our
> index with the tree objects but they will be stored in the index
> with entry names which have prepended to them the given "prefix/".
Yes. But according to the git-read-tree documentation there must be
no existing entries in the index under "prefix/". This makes merging
very difficult. And merging is a core feature of a distributed SCM.
> We can then use git-checkout-index to populate our workarea
> with the prefix/ files and dirs.
Well, yes. Assuming you were able to hammer the index into
reflecting the structure you'd like to have your working directory
take on.
> So how do I get the foreign tree objects into the database;
> just copy them in?
Uh, yes, but don't do that. Use `git fetch` instead to copy the
commit(s) in question and all tree and blob objects they reference.
For one thing it should be faster; for another it will correctly
walk into pack files and extract only the objects needed.
> And this works with prefix/ dir not already existing in workarea.
> Hmmmmm....
Only with it not existing in the working directory. If prefix/
already was there you would likely encounter problems with the
git-checkout-index invocation complaining about those files already
existing and not wanting to overwrite them. Same thing happens
with a merge git-read-tree invocation, which happens a lot in Git
to update the working directory.
> >>Moreover, is it possible to have a subtree based on another
> >>repository.
> >
> >It is possible. For example, make empty directory <subproject>
> >somewhere, add this directory, or just all the files in it
> >either to .gitignore or .git/info/excludes file, then clone
> >the other project (subproject) to this place. You would have
> >the following directory structure
> >
> > /
> > dir1
> > dir2
> > dir2/subdir
> > subproject
> > subproject/.git
> > subproject/subprojectsubdir
> > ...
> >
> This could be handy.
> Looks like by using .gitignore, I can check the file in.
> (So the ingore/excludes are used by git scripts which call
> git-ls-files --others.)
Right. By convention .gitignore is read out of each directory to
find all ignore patterns for that directory and all subdirectories
contined within it. As such you can check it into the project
to share it across all users.
> >>* Are there any tools for dumping out the contents of the
> >>git objects in the .git/objects directory.
> >>By dumping out, I mean an ascii representation of the data
> >>fields for the commit and tree objects in particular.
> >>I've written a simple small program to dump out the index
> >>entries (cache entries).
> >
> >git-cat-file -p
> >
> Excellent, thanks. (looks like the option is undocumented - secret option:)
Hmm; it's documented in ed90cbf5 by Jeff King; this is 68 commits
before v1.4.0 so I'd say its definately in v1.4.0 and later.
> So I added this to a script which walks over the objects directory,
> to work out what all the object ids are so I can apply git-cat-file
> to all the objects on my test directory.
> I guess this will fall down if the objects are stored in a pack :)
> I'll have to look and see how to extract all the object ids using
> some command.
Try this:
git-rev-list --all
this will scan every ref and tag listed in .git/refs and proceed to
print the entire DAG they represent, including all commits, trees
and blobs. Git uses this internal to form the list of objects which
should be included into a pack file. It will include everything
that is also packed.
But I'd have to say say its sort of strange to walk over every
object in a repository and dump it to text with git-cat-file -p.
> What I have is an existing full tree with a subproject directory.
> And then I have a separate tree just for the subproject.
> The development happens in the subproject tree.
> At certain points we want to update the existing full tree's subproject
> directory with the work we have done in the subproject tree.
> At these points I'd like to effectively copy over the new tree objects
> and blobs to the full tree, but I guess I'd need new commits
> (which are based on the new commits of the subproject tree which would
> include their commit messages)
> which refer to new higher level tree objects (which refer down
> to my subproject tree objects).
> This presupposes that no other outside changes happened to subproject
> in the full tree - since I'm just copying over objects.
> Probably should be merging, just in case.
> Does this sound too confusing and awkward? :)
Yes. :)
But this may be able to be done in a somewhat sane (or perhaps
insane) fashion using current tooling. Lets say you want a
structure of:
full/
Makefile
subA/
Makefile
a.c
subB/
Makefile
b.c
with "full/" being the full repository that's updated at specific
points to specific revisions of smaller repositories "subA/" and
"subB/", each of which are developed on their own independently.
Then make all 3 their own Git repositories. Except in the "subA/"
repository layout your files within the "my-subA" repository within
a single "subA" top level directory:
my-subA/
subA/
Makefile
a.c
and do the same for subB. This will help when it comes time to
merge subA and subB into full.
subA and subB are completely isolated and can develop at will.
Now to upgrade full's subA to some branch or tag X of subA we can do:
cd full
git fetch ../path/to/my-subA X:refs/heads/tmp-subA
that just copied everything for commit X from ../path/to/my-subA
into full and stored it locally as branch tmp-subA but it hasn't
merged it yet.
git pull . tmp-subA
will merge the tmp-subA branch into the current branch. Now this
will cause a complete merge of the "subA/" directory content to
occur but it will avoid all other directories. This happens because
the tmp-subA branch *ONLY* has a "subA/" directory and no other
top level files or directories, and because the current branch in
full also has a "subA/" directory which is a lot like the "subA/"
directory in tmp-subA. (This is why the individual subprojects
have only one top level directory in them and why that directory
matches with its name within full.)
Later on to upgrade again the merge should pretty much go the
same way. Except the last merge between full and subA will be
automatically used as the merge base, which is exactly what you want.
The standard merge driver (git-merge-recursive or git-merge-recur)
will freak out and take a *very* long time to execute the "git pull"
portion of the merge process if there are a lot of files in full/
which are not in subA/. In this case you may wish to use a more
direct merge approach if the directory was not changed in full.
So a faster (but more complex) approach to merging in tmp-subA
during an update is:
cd full
git fetch ../my-subA X:refs/heads/tmp-subA
base=$(git merge-base HEAD tmp-subA)
if [ $(git rev-parse --verify $base:subA) \
= $(git rev-parse --verify HEAD:subA)
then
t=$(git ls-tree HEAD | ## replace ID of subA ## | git mk-tree)
c=$(echo "Updated subA"|git-commit-tree $t -p HEAD -p tmp-subA)
git update-ref HEAD $c
else
echo panic: full changed subA, full manual merge required
git pull . tmp-subA
fi
I've glossed over the '## replace ID of subA ##' part but the idea
here is that you can list an existing tree with ls-tree and if you
edit the output of that and feed it back into git mk-tree you can
produce a different tree with whatever content you want it to have.
The general concept here is that if the subA subdirectory hasn't
changed IDs between the last time full and subA were merged together
than that means that full hasn't changed subA. Consequently we
can just wholesale replace the subA directory with the new one
we got from subA. We do that by editing the tree with a simple
search/replace then generate a merge commit which merges the two
branches together.
Assuming full never modifies a subrepository the mk-tree hack above
should be *very* fast (few milliseconds on nearly all hardware)
no matter how many files are in full or the individual subrepository.
Either method (`git pull` or the mk-tree hack above) will preserve
the full development lineage on every subdirectory within the larger
full repository yet allow the individual subdirectory repositories
to be worked on in isolation. Either method will also record as
part of full's history who merged in the updated subrepository, when
they did it, and what version of the subrepository got merged in.
However due to the "overlay" structure being applied here there
is some planning involved with regards to directory naming, as
well as some difficulty in forming a temporary working area of just
subdirectory repositories that layout the same way as they would when
merged into a full repository. Its also basically impossible to take
changes from full and move them back to the relevant subrepository
(though git-cherry-pick may help there).
[*1*] I totally did not expect $(git rev-parse --verify HEAD:subA) to
return the ID of subtree subA within branch HEAD. Yet it does.
Talk about an unexpected bonus from Junio's quick cat-file
sha1 file path expression hack!
--
Shawn.
^ permalink raw reply
* [PATCH] gitignore: add git-show-ref and git-pack-refs
From: Jeff King @ 2006-09-18 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jeff King <peff@peff.net>
---
.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index bdeedb6..0ffe14a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ git-name-rev
git-mv
git-pack-redundant
git-pack-objects
+git-pack-refs
git-parse-remote
git-patch-id
git-peek-remote
@@ -105,6 +106,7 @@ git-shortlog
git-show
git-show-branch
git-show-index
+git-show-ref
git-ssh-fetch
git-ssh-pull
git-ssh-push
--
1.4.2.1.g01ff
^ permalink raw reply related
* Re: What's in git.git
From: Jakub Narebski @ 2006-09-18 6:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkohu3j1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>
>>> - An experimental git-for-each-ref command to help language
>>> bindings to get information on many refs at once. Hopefully
>>> Jakub can teach gitweb to use it to speed things up.
>>
>> I use 'origin' (or 'next') version of gitweb, while using _released_
>> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now
>> I wouldn't be able to _test_ the git-for-each-ref.
>
> That's not a good excuse, though. It means you cannot propose
> new core-side support that only gitweb would benefit from
> initially, since we will not add new stuff to the core that does
> not have real users, and new stuff in the core must be cooked in
> "next" before it is proven to be useful and correct.
But this also means that if I were for example to use git-for-each-ref
in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
of git.
On the other side as you said the true test for new core stuff is to use
it. Perhaps someone who runs 'master' or 'next' version of git...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] revision traversal: --author, --committer, and --grep.
From: Jeff King @ 2006-09-18 6:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Kai Blin
In-Reply-To: <7v4pv6yphp.fsf@assigned-by-dhcp.cox.net>
On Sun, Sep 17, 2006 at 05:42:26PM -0700, Junio C Hamano wrote:
> This adds three options to setup_revisions(), which lets you
> filter resulting commits by the author name, the committer name
> and the log message with regexp.
First of all, thanks for implementing this; I tried to use it the other
day (remembering the discussion and patches a few weeks ago) and was
disappointed to find it absent.
That being said, I find the matching style completely unintuitive. :)
To find --author=foo, your strategy is to stringify the header and grep
for "^author foo". As a user, my expectation was that you would
stringify the author field and grep for "foo".
The important difference is that your approach means that the user's
regex is implicitly anchored at the beginning of the field. Thus,
searching by email address does not work with --author=junkio, but
rather requires --author='.*junkio'.
Possible fixes:
1. Match against "^<field>.*<regex>" (I haven't looked closely at the
builtin grep implementation, but presumably '.' as usual does not
include newline).
2. Find <field>, and then feed grep_buffer only the contents of that
line.
The second is what I feel that users will expect (at least what I
expected!), but is probably slightly less efficient (two greps instead
of one, but I doubt the difference would be significant). However, I
don't think there is a way with the first approach to explicitly request
a beginning-of-string anchor (i.e., "^Junio" in the second approach).
A few other thoughts:
1. Case sensitivity? For convenience sake, it seems reasonable to
match these fields without case sensitivity (what was the
capitalization of A Large Angry SCM again? von Brand or Von Brand?
etc). Should it be optional, and if so, how to specify it (a global
command line option is probably not desired, as you might want
case-sensitive --grep but case-insensitive --author). So we either
need a "-i means the rest of the arguments are insensitive, +i
means they are sensitive" option, or some syntax to specify it in
the regex (perl uses (?i)).
2. Is there any use to exposing the "header_grep" functionality with
--grep-header? Is there anything worth grepping for besides
author/committer? The general consensus on non-core headers in
commit objects seemed to be "don't do it".
3. An alias (--who=foo?) for --author=foo --committer=foo. I believe
this doesn't require boolean magic, since we default to OR.
I'm happy to work on implementing any of the above if there's interest.
-Peff
^ permalink raw reply
* Re: git pull a subtree, embedded trees
From: Jakub Narebski @ 2006-09-18 5:58 UTC (permalink / raw)
To: git
In-Reply-To: <450E3399.5070601@sgi.com>
Timothy Shimmin wrote:
>>> * Are there any tools for dumping out the contents of the
>>> git objects in the .git/objects directory.
>>> By dumping out, I mean an ascii representation of the data
>>> fields for the commit and tree objects in particular.
>>> I've written a simple small program to dump out the index
>>> entries (cache entries).
>>
>> git-cat-file -p
>>
> Excellent, thanks. (looks like the option is undocumented - secret option:)
It looks not:
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
-p Pretty-print the contents of <object> based on its type.
> So I added this to a script which walks over the objects directory,
> to work out what all the object ids are so I can apply git-cat-file
> to all the objects on my test directory.
> I guess this will fall down if the objects are stored in a pack :)
> I'll have to look and see how to extract all the object ids using
> some command.
git-rev-parse and/or git-rev-list (the latter with --objects option) is your
friend. And there is git-ls-tree command which list sha1 of blobs (files)
and trees (subdirectories) for specific revision (specified tree).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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