* [PATCH (topgit) 0/2] tg-patch: fix pagination
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
Kirill Smelkov (2):
Implement setup_pager just like in git
tg-patch: fix pagination
tg-patch.sh | 3 +++
tg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH (topgit) 2/2] tg-patch: fix pagination
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
In-Reply-To: <cover.1231254832.git.kirr@landau.phys.spbu.ru>
Previously, when I was invoking `tg patch` the following used to happen:
1. .topmsg content was sent directly to _terminal_
2. for each file in the patch, its diff was generated with `git diff`
and sent to *PAGER*
3. trailing 'tg: ...' was sent to terminal again
So the problem is that while `tg patch >file` works as expected, plain
`tg patch` does not -- in pager there is only a part of the whole patch
(first file diff) and header and trailer are ommitted.
I've finally decided to fix this inconvenience, and the way it works is
like in git -- we just hook `setup_pager` function in commands which
need to be paginated.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg-patch.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tg-patch.sh b/tg-patch.sh
index a704375..dc699d2 100644
--- a/tg-patch.sh
+++ b/tg-patch.sh
@@ -24,6 +24,9 @@ done
base_rev="$(git rev-parse --short --verify "refs/top-bases/$name" 2>/dev/null)" ||
die "not a TopGit-controlled branch"
+
+setup_pager
+
git cat-file blob "$name:.topmsg"
echo
[ -n "$(git grep '^[-]--' "$name" -- ".topmsg")" ] || echo '---'
--
1.6.1.48.ge9b8
^ permalink raw reply related
* [PATCH (topgit) 1/2] Implement setup_pager just like in git
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
In-Reply-To: <cover.1231254832.git.kirr@landau.phys.spbu.ru>
setup_pager() spawns a pager process and redirect the rest of our output
to it.
This will be needed to fix `tg patch` output in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/tg.sh b/tg.sh
index 8c23d26..51a82af 100644
--- a/tg.sh
+++ b/tg.sh
@@ -243,6 +243,59 @@ do_help()
fi
}
+## Pager stuff
+
+# isatty FD
+isatty()
+{
+ tty -s 0<&$1 || return 1
+ return 0
+}
+
+# setup_pager
+# Spawn pager process and redirect the rest of our output to it
+setup_pager()
+{
+ isatty 1 || return 0
+
+ # TG_PAGER = GIT_PAGER | PAGER
+ # http://unix.derkeiler.com/Newsgroups/comp.unix.shell/2004-03/0792.html
+ case ${GIT_PAGER+XXX} in
+ '')
+ case ${PAGER+XXX} in
+ '')
+ # both GIT_PAGER & PAGER unset
+ TG_PAGER=''
+ ;;
+ *)
+ TG_PAGER="$PAGER"
+ ;;
+ esac
+ ;;
+ *)
+ TG_PAGER="$GIT_PAGER"
+ ;;
+ esac
+
+ [ -z "$TG_PAGER" -o "$TG_PAGER" = "cat" ] && return 0
+
+
+ # now spawn pager
+ export LESS=${LESS:-FRSX} # as in pager.c:pager_preexec()
+
+ _pager_fifo="$(mktemp -t tg-pager-fifo.XXXXXX)"
+ rm "$_pager_fifo" && mkfifo -m 600 "$_pager_fifo"
+
+ "$TG_PAGER" < "$_pager_fifo" &
+ exec > "$_pager_fifo" # dup2(pager_fifo.in, 1)
+
+ # this is needed so e.g. `git diff` will still colorize it's output if
+ # requested in ~/.gitconfig with color.diff=auto
+ export GIT_PAGER_IN_USE=1
+
+ # atexit(close(1); wait pager)
+ trap "exec >&-; rm $_pager_fifo; wait" EXIT
+}
## Startup
--
1.6.1.48.ge9b8
^ permalink raw reply related
* Re: BUG?? INSTALL MAKEFILE
From: Mike Ralphson @ 2009-01-06 15:22 UTC (permalink / raw)
To: Lars Sadau; +Cc: Matthieu Moy, git
In-Reply-To: <vpqiqosa3fc.fsf@bauges.imag.fr>
2009/1/6 Matthieu Moy <Matthieu.Moy@imag.fr>
> Lars Sadau <lars@sadau-online.de> writes:
> > i'm a brand-new git user. Just one minute ago I wanted to install git in
> > my home directory. The INSTALL file says type simply "make install", but
> > the makefile does a global installation.
>
> I was going to write:
>
> Either run ./configure --prefix=$HOME/wherever/you/want or edit the
> prefix variable in config.mak.
>
> but then realized that prefix is set to $(HOME) by default. Are you
> sure you didn't edit the Makefile or run any sort of ./configure
> before "make install" ?
Or run 'make' as root, as well as 'make install'?
Mike
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Sitaram Chamarty @ 2009-01-06 15:33 UTC (permalink / raw)
To: git
In-Reply-To: <488807870901060705m49419ec1he14aace5caaa3d89@mail.gmail.com>
On 2009-01-06, Johnny Lee <johnnylee194@gmail.com> wrote:
> On Tue, Jan 6, 2009 at 7:57 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> If you're not worried about the finer-grained access control
>> that acl(5) gives you, just do what "git init
>> --shared=group" does:
>>
>> git config core.sharedrepository 1 # as mentioned above
>> chmod g+ws .git
>>
>> Now set the group to something (I use "gitpushers" ;-)
>>
>> chgrp -R gitpushers .git
>>
>> amd make sure all your users are part of that group.
> We also plan to do it in this way, just a small wondering that it
> looks a kind of workaround instead of a more graceful solution.
I wouldn't consider it a workaround. It uses normal Unix
permissions the way they were designed to, including setgid
for directories.
Actually, I am yet to come up with a situation where I
actually needed ACLs, though they are more generalised, and
fine-grained.
And the maint is all eminently scriptable.
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 15:48 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901021405460.21567@asgard.lang.hm>
david@lang.hm writes:
> I have a need to setup a repository where I'm storing config files,
> and I need to be able to search the history of a particular line, not
> just when the last edit of the line was (which is what I see from git
> blame)
>
> I'm not seeing a obvious way to do this, am I missing something or
> does it need a non-obvious approach?
>
> for example, if I do
>
> git blame -L /SUBLEVEL/,+1 -M Makefile
>
> on the linux kernel it currently shows
>
> 57f8f7b6 (Linus Torvalds 2008-10-23 20:06:52 -0700 3) SUBLEVEL = 28
>
> what I would want it to show would be a list of the commits that have
> changed this line.
>
> It looks like I can write a script to do this
>
> git blame -L /SUBLEVEL/,+1 -M Makefile 57f8f7b6^
> 6e86841d (Linus Torvalds 2008-07-28 19:40:31 -0700 3) SUBLEVEL = 27
> git blame -L /SUBLEVEL/,+1 -M Makefile 6e86841d^
> 2ddcca36 (Linus Torvalds 2008-05-03 11:59:44 -0700 3) SUBLEVEL = 26
>
> etc.
>
> is there a better way to do this?
>
> David Lang
I think you need a script to do what you want. I think this works...
Save the following script in ~/bin/git-rblame.sh, make it executable,
and then create a global git alias for it as follows:
$ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
Then you can just use
$ git rblame -L /SUBLEVEL/,+1 -M Makefile
6e86841d (Linus Torvalds 2008-07-28 19:40:31 -0700 3) SUBLEVEL = 27
2ddcca36 (Linus Torvalds 2008-05-03 11:59:44 -0700 3) SUBLEVEL = 26
...
4c91aedb (Linus Torvalds 2005-06-28 22:57:29 -0700 3) SUBLEVEL = 13
^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 3) SUBLEVEL = 12
------cut here ------ !/bin/git-rblame.sh ---
#!/bin/sh
PARAMS="$*"
LINE=$(git blame $PARAMS)
while test $? == 0
do
echo $LINE
COMMIT="${LINE:0:8}^"
LINE=$(git blame $PARAMS $COMMIT 2>/dev/null)
done
------cut here ------------------------------
Cheers,
Bernt
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Miklos Vajna @ 2009-01-06 16:08 UTC (permalink / raw)
To: Bernt Hansen; +Cc: david, git
In-Reply-To: <87d4f01lmt.fsf@gollum.intra.norang.ca>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
> Save the following script in ~/bin/git-rblame.sh, make it executable,
> and then create a global git alias for it as follows:
>
> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
and you won't even have to define an alias on each machine. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Boyd Lynn Gerber @ 2009-01-06 16:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Scott Chacon, David Bryson, Mike Hommey, git
In-Reply-To: <20090106085448.GF21154@genesis.frugalware.org>
On Tue, 6 Jan 2009, Miklos Vajna wrote:
> On Mon, Jan 05, 2009 at 09:24:16PM -0700, Boyd Lynn Gerber
> <gerberb@zenez.com> wrote:
>> http://dir.gmane.org/gmane.comp.version-control.git
>>
>> On this page the following...
>>
>> Other mailing list archives for this list:
>>
>> 1. The Mail Archive
>>
>> http://www.mail-archive.com/git@vger.kernel.org/
>>
>> And this states this link
>>
>> http://www.mail-archive.com/git@vger.kernel.org/
>>
>> And the lastest is 2005 and earlier.
>
> I don't think you should blame Scott for this, it seem to be a gmane vs
> mail-archive issue, and gmane is mentioned already in MaintNotes.
I was not sure who/what/where to make a not of this. I think it would be
good if we could get a link to the various archives. During an update of
my system, a file was changed that cause email to me to be bounced. I did
not relealize it. I was trying to find archived. I thought I would start
with our new main page. I had to do google searches to finally find an
archive. The only problem is I have not figured out how to download all
303 articles, quickly/easily. You would think one of the majordomo
commands to get articles would work. They do not.
I thought I should remport my finding and see if anyone knew or could make
changes to make it easier for us to find the archives.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 16:21 UTC (permalink / raw)
To: Miklos Vajna; +Cc: david, git
In-Reply-To: <20090106160814.GI21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
>> Save the following script in ~/bin/git-rblame.sh, make it executable,
>> and then create a global git alias for it as follows:
>>
>> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
>
> Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
> and you won't even have to define an alias on each machine. ;-)
Yes but I don't want to use 'git-rblame' as the command since I've
broken my habit of using the dashed versions of commands. 'git rblame'
just feels better to me.
Now I probably should have named the script something that won't ever
clash with possible future git commands (like my-git-rblame.sh or
something) but since it's in my ~/bin I'll just deal with that if it
ever happens in the future :)
-Bernt
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Ted Pavlic @ 2009-01-06 16:26 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Lars Sadau, git
In-Reply-To: <vpqiqosa3fc.fsf@bauges.imag.fr>
> but then realized that prefix is set to $(HOME) by default. Are you
> sure you didn't edit the Makefile or run any sort of ./configure
> before "make install" ?
After doing a
git clean -f
in my local git repo, I notice that:
config.mak.autogen
still exists, and inside it:
prefix = /usr/local
That file is included in the Makefile *after* prefix is set, and so if
it's not updated, the Makefile will default to /usr/local.
According to the INSTALL doc, the default prefix should be ~. However,
this is certainly not the case. Either the INSTALL doc needs to be
updated or a new default config.mak.autogen needs to be checked in (or
perhaps config.mak.autogen needs to be omitted from the repo?).
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 16:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: david, git
In-Reply-To: <878wpo1k2p.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@norang.ca> writes:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
>>> Save the following script in ~/bin/git-rblame.sh, make it executable,
>>> and then create a global git alias for it as follows:
>>>
>>> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
>>
>> Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
>> and you won't even have to define an alias on each machine. ;-)
>
> Yes but I don't want to use 'git-rblame' as the command since I've
> broken my habit of using the dashed versions of commands. 'git rblame'
> just feels better to me.
>
> Now I probably should have named the script something that won't ever
> clash with possible future git commands (like my-git-rblame.sh or
> something) but since it's in my ~/bin I'll just deal with that if it
> ever happens in the future :)
Oops. That actually does do what I want. Thanks for pointing that out
Miklos!
(sorry for replying to my own post - next time I'll try it first before
I post :)
-Bernt
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Matthieu Moy @ 2009-01-06 17:17 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Lars Sadau, git
In-Reply-To: <49638625.3090109@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> According to the INSTALL doc, the default prefix should be ~.
I didn't read that in INSTALL. What I read is that if I only run "make
install", the prefix is $HOME, which is true. Now, ./configure uses a
default value which is not the one of the Makefile, but that's another
point.
--
Matthieu
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Daniel Barkalow @ 2009-01-06 17:24 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Matthieu Moy, Lars Sadau, git
In-Reply-To: <49638625.3090109@tedpavlic.com>
On Tue, 6 Jan 2009, Ted Pavlic wrote:
> > but then realized that prefix is set to $(HOME) by default. Are you
> > sure you didn't edit the Makefile or run any sort of ./configure
> > before "make install" ?
>
> After doing a
>
> git clean -f
You need a "git clean -fx"
> According to the INSTALL doc, the default prefix should be ~. However, this is
> certainly not the case. Either the INSTALL doc needs to be updated or a new
> default config.mak.autogen needs to be checked in (or perhaps
> config.mak.autogen needs to be omitted from the repo?).
It's omitted from the repo, but it's in .gitignore so "git clean" doesn't
remove it unless you tell it to remove ignored files.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] gitweb: don't use pathinfo for global actions
From: Jakub Narebski @ 2009-01-06 17:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Devin Doucette
In-Reply-To: <1230896080-22801-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:
> With PATH_INFO urls, actions for the projects list (e.g. opml,
> project_index) were being put in the URL right after the base. The
> resulting URL is not properly parsed by gitweb itself, since it expects
> a project name as first component of the URL.
Therefore it really needs to be in, as df63fb also by Giuseppe
(gitweb: use href() when generating URLs in OPML) is already in,
and I think gitweb would generate broken OPML and TXT links without
this patch.
>
> Accepting global actions in use_pathinfo is not a very robust solution
> due to possible present and future conflicts between project names and
> global actions, therefore we just refuse to create PATH_INFO URLs when
> the project is not defined.
I think it is quite robust solution and it makes sense; we use
shortcuts http://git.example.com for projects_list page, and
http://git.example.com/path/to/repo.git for overview 'summary'
action for a project, therefore pathinfo has to look like the
following: http://git.example.com/repo/action/hash with "action"
_after_ "project". And there is also matter of backward compatibility
of URL (URLs shouldn't break).
Anyway, we have $home_link for default project_list page, which
is path_info without project, and query without query string...
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 99f71b4..fa7d8ad 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -830,7 +830,7 @@ sub href (%) {
> }
>
> my $use_pathinfo = gitweb_check_feature('pathinfo');
> - if ($use_pathinfo) {
> + if ($use_pathinfo and defined $params{'project'}) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> @@ -845,7 +845,7 @@ sub href (%) {
> $href =~ s,/$,,;
>
> # Then add the project name, if present
> - $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> + $href .= "/".esc_url($params{'project'});
> delete $params{'project'};
>
> # since we destructively absorb parameters, we keep this
Nice.
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: JGit vs. Git
From: Shawn O. Pearce @ 2009-01-06 18:45 UTC (permalink / raw)
To: Vagmi Mudumbai; +Cc: git
In-Reply-To: <a55cfe9d0901052250k2be203dfvb0b437a523f2cecc@mail.gmail.com>
Vagmi Mudumbai <vagmi.mudumbai@gmail.com> wrote:
> 1) Is JGit a drop in replacement of Git? In sense, if I were to pack
> in an SCM with my app, Can I pack jgit instead of C Git?
As Robin said, its not a full drop-in replacement. That said, its
getting there. We're now only really missing patch application,
diff generation, merge support, and submodule support. Most of
the JGit core can handle submodules by skipping over them during
object traversal, but the part that talks to the filesystem to do
a checkout doesn't recognize them.
JGit is mostly a library, not a command line replacement. But it
does have commands like "jgit init", "jgit clone", "jgit fetch",
"jgit push", even some server side tools like "jgit daemon",
"jgit receive-pack" and "jgit upload-pack".
To be honest I don't think anyone actually uses the command line
pgm stuff to work with Git. Anyone using JGit is actually running
it embedded in some type of application like an IDE plugin or a
server like Gerrit.
> 2) I noticed that there are no 'add' and 'commit' commands (at least
> from the source) in the org.spearce.git.pgm project. I am looking at
> the repo.or.cz/egit.git repo. I had a brief look at the
> lib/GitIndex.java and lib/Repository.java. GitIndex has the add
> methods to add files/entries to the index. I am still stumped on how
> commits can be done with JGit. Any help is hugely appreciated.
As Robin said, look at the unit tests. Basically you want to use
the Commit class to populate out the data fields, then pass it off to
an ObjectWriter instance to store it into the tree. Finally you'll
need to use a RefUpdate (obtained from Repository's updateRef method)
to store the new ObjectId of that Commit into a ref like HEAD.
Unfortunately we have two commit representations in JGit. If you
are trying to read data from a Repository the RevCommit (obtained
from a RevWalk) is orders of magnitude faster than the Commit class.
> I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
> get worse, I guess.) . I planned on using grit via JRuby but grit uses
> fork which is not available on funny platforms like windows. And JRuby
> guys do not have any plan on supporting fork even on platforms on
> which for is supported. If JGit is a pure Java based implementation of
> Git with more or less the same functionality, then my work becomes a
> lot easier.
I plan on writing patch apply sometime this quarter I think. I have
most of what I need to rip a patch apart and inspect it prior to
application, now I just need to line it up onto the base object
and issue the output version.
Diff might also come in the next few months. Dscho has a nice
prototype working, but there's still some work to be done on it.
--
Shawn.
^ permalink raw reply
* Quick command to count commits
From: Henk @ 2009-01-06 18:51 UTC (permalink / raw)
To: git
Hi,
For GitExtensions (windows git ui) I need a command to count all commits. I
now use this command:
git.cmd rev-list --all --abbrev-commit | wc -l
This works perfect but its very slow in big repositories. Is there a faster
way to count the commits?
Henk
--
View this message in context: http://n2.nabble.com/Quick-command-to-count-commits-tp2118851p2118851.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] diff: accept -- when using --no-index
From: Thomas Rast @ 2009-01-06 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Accept -- as an "end of options" marker even when using --no-index.
Previously, the -- triggered a "normal" index/tree diff and
subsequently failed because of the unrecognized (in that mode)
--no-index.
Note that the second loop can treat '--' as a normal option, because
the preceding checks ensure it is the third-to-last argument.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
diff-no-index.c | 8 ++++++--
t/t4013-diff-various.sh | 1 +
.../diff.diff_--no-index_--name-status_--_dir2_dir | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index b60d345..d1e8e4b 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -173,8 +173,10 @@ void diff_no_index(struct rev_info *revs,
/* Were we asked to do --no-index explicitly? */
for (i = 1; i < argc; i++) {
- if (!strcmp(argv[i], "--"))
- return;
+ if (!strcmp(argv[i], "--")) {
+ i++;
+ break;
+ }
if (!strcmp(argv[i], "--no-index"))
no_index = 1;
if (argv[i][0] != '-')
@@ -214,6 +216,8 @@ void diff_no_index(struct rev_info *revs,
i++;
else if (!strcmp(argv[1], "-q"))
options |= DIFF_SILENT_ON_REMOVED;
+ else if (!strcmp(argv[i], "--"))
+ i++;
else {
j = diff_opt_parse(&revs->diffopt, argv + i, argc - i);
if (!j)
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index aeb5405..aba5320 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -261,6 +261,7 @@ diff --patch-with-stat -r initial..side
diff --patch-with-raw -r initial..side
diff --name-status dir2 dir
diff --no-index --name-status dir2 dir
+diff --no-index --name-status -- dir2 dir
diff master master^ side
EOF
diff --git a/t/t4013/diff.diff_--no-index_--name-status_--_dir2_dir b/t/t4013/diff.diff_--no-index_--name-status_--_dir2_dir
new file mode 100644
index 0000000..6756f8d
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--name-status_--_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --name-status -- dir2 dir
+A dir/sub
+$
--
tg: (e9b8523..) t/diff-no-index-invocation (depends on: origin/master)
^ permalink raw reply related
* Re: Quick command to count commits
From: Shawn O. Pearce @ 2009-01-06 18:55 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1231267896595-2118851.post@n2.nabble.com>
Henk <henk_westhuis@hotmail.com> wrote:
> For GitExtensions (windows git ui) I need a command to count all commits. I
> now use this command:
> git.cmd rev-list --all --abbrev-commit | wc -l
>
> This works perfect but its very slow in big repositories. Is there a faster
> way to count the commits?
No. But drop the --abbrev-commit flag, abbreviating the object ids
would take longer than just dumping the full 40 bytes to stdout.
It requires a scan of parts of the object database for every commit
to determine what is a unique abbreviation.
This isn't a very common operation. Its expensive to do, as you
can see. What's the reason for supplying it, and needing it so
quickly? Nobody really cares how many commits are in their history,
unless they are trying to produce stats to describe how big their
repository is. In which case the size of the .git/objects/pack
*.pack and *.idx files is much more relevant, especially the .idx
files as it gives a really quick estimate on the number of total
objects in the repository.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH] Improve the sideband progress scaper to be more accurate
From: Nicolas Pitre @ 2009-01-06 19:23 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901032312.53148.robin.rosenberg@dewire.com>
On Sat, 3 Jan 2009, Robin Rosenberg wrote:
> onsdag 31 december 2008 20:04:01 skrev Shawn O. Pearce:
> > By matching only whole lines we should be able to improve the
> > progress scaper so we avoid ugly output like we had been seeing:
> >
> > EGIT.contrib/jgit clone git://repo.or.cz/libgit2.git LIBGIT2
> > Initialized empty Git repository in /home/me/SW/LIBGIT2/.git
> > Counting objects: 547
> > Compressing objects: 100% (192/192)
> > ts: 100% (192/192)
> > Compressing objects: 100% (192/192)
> > ng objects: 100% (192/192)
> >
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > > Would it be hard to get the progress look better?
> >
> > Maybe this does the trick. Its hard to reproduce so its hard to
> > come up with the condition that was giving us the problem before.
> > I suspect its because we were getting line fragments on the sideband
> > channel, but I'm not sure that was really the case.
>
> Nasty. I couldn't reproduce it myself. I'll hold onto this one for a while and
> see if I'll get the opportunity to test it live with this problem.
There may indeed be line fragments sent over the sideband channel, as
well as the opposite which is multiple lines sent at once in a single
packet. If you look at sideband.c you'll find about all those cases.
In general, what you have to do is:
- for each packet:
- split into multiple chunks on line breaks ('\r' or '\n')
- for each chunk:
- if last chunk didn't end with a line break, or if current
chunk is empty or only contains a line break, then skip printing
the "remote:" prefix. Otherwise print it.
- print the current chunk up to any line break
- if current chunk contains a line break and other characters then
print a sequence to clear the remaining of the screen line
- print the line break if any
That should cover all cases. Note that the case where a previous chunk
didn't end with a line break is always seen when moving from one packet
to another, so that state cannot be local to the inner loop.
Nicolas
^ permalink raw reply
* Re: [JGIT PATCH] Improve the sideband progress scaper to be more accurate
From: Shawn O. Pearce @ 2009-01-06 19:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Robin Rosenberg, git
In-Reply-To: <alpine.LFD.2.00.0901061343000.26118@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> There may indeed be line fragments sent over the sideband channel, as
> well as the opposite which is multiple lines sent at once in a single
> packet. If you look at sideband.c you'll find about all those cases.
Thanks, that's what I thought...
> In general, what you have to do is:
>
> - for each packet:
> - split into multiple chunks on line breaks ('\r' or '\n')
> - for each chunk:
> - if last chunk didn't end with a line break, or if current
> chunk is empty or only contains a line break, then skip printing
> the "remote:" prefix. Otherwise print it.
> - print the current chunk up to any line break
> - if current chunk contains a line break and other characters then
> print a sequence to clear the remaining of the screen line
> - print the line break if any
Hmm. I should note that C Git still screws this up sometimes. I've
seen 1.6.1 git fetch mess up the output from repo.or.cz's sideband.
I'm sure Pasky isn't running JGit's daemon, its too damn fast. :-)
I don't have a spew of it handy, but late last week I saw it screw
up while doing a clone off repo.or.cz.
Robin, maybe we should apply this patch? Its along the lines
Nico is describing above, but because our progress code doesn't do
direct display its a little less complex, we don't have to worry
about clearing the current line. But I think I'm doing the chunk
splitting and filtering he's talking about.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fast-export: print usage when no options specified
From: Johannes Schindelin @ 2009-01-06 19:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, jidanni, git
In-Reply-To: <1230955152-23646-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Sat, 3 Jan 2009, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> I found that behaviour surprising as well when I saw it the first time.
> git rev-list outputs some usage info in that case, git log just logs
> HEAD. Given that unconditionally exporting HEAD with no arguments is
> probably not something most users want, here is a patch to make the
> behaviour like what git rev-list already has.
Maybe this should be part of the commit message?
-- snip --
Some people find it surprising that fast-export does not output a usage
when called without parameters, as rev-list does.
This assumes that a user usually does not want to export HEAD by default.
-- snap --
However, I have to say that I would find exporting HEAD a rather sensible
default.
But I am not _that_ strongly opposed to the patch. Just would like to
hear some opinions first.
Ciao,
Dscho
^ permalink raw reply
* Re: Quick command to count commits
From: Linus Torvalds @ 2009-01-06 19:30 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1231267896595-2118851.post@n2.nabble.com>
On Tue, 6 Jan 2009, Henk wrote:
>
> For GitExtensions (windows git ui) I need a command to count all commits. I
> now use this command:
> git.cmd rev-list --all --abbrev-commit | wc -l
>
> This works perfect but its very slow in big repositories. Is there a faster
> way to count the commits?
Nope. Possibly drop the --abbrev-commit part, but it's not going to hurt
_that_ much, and maybe avoiding piping the data can be a win in some
cases.
Basically, to get commit counts, you need to traverse the whole history,
or at least cache it. So the only way to speed things up is
- make sure your repository is well-packed. That will speed things up by
an absolutely huge amount, if they weren't well-packed before. Just a
single large pack-file, not lots of small packs, and not lots of loose
objects.
- you can certainly cache it. Just index by the sha1sum of all the heads,
and you have a great cache. Just keep a single entry. So _if_ the
repository seldom changes, and you do this a lot, you'll at least only
pay the price once.
IOW, do something like this:
#!/bin/sh
revs=$(git rev-parse --all)
index=$(echo "$revs" | sha1sum | cut -d' ' -f1)
cached=$(cat .git/commit_nr_cache)
cached_index=$(echo "$cached" | cut -d' ' -f1)
if [ "$index" == "$cached_index" ]; then
echo "$cached" | cut -d' ' -f2
exit
fi
nr=$(git rev-list $revs | wc -l)
echo "$index $nr" > .git/commit_nr_cache
echo $nr
and you now have a stupid single-entry cache.
Totally untested. You'll need to do _some_ work yourself ;)
Linus
^ permalink raw reply
* Re: [PATCH 2/3] unpack-trees: fix path search bug in verify_absent
From: Johannes Schindelin @ 2009-01-06 19:35 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, git
In-Reply-To: <20090104200133.GA2202@localhost>
Hi,
On Sun, 4 Jan 2009, Clemens Buchacher wrote:
> On Sun, Jan 04, 2009 at 02:01:14AM -0800, Junio C Hamano wrote:
> > The function's purpose is .... Before entering the loop to count
> > the number of entries to skip, this check to detect if we do not
> > even have to count appears. When this check triggers, we know we
> > do not want to skip anything, and returning constant 0 is much
> > clearer than returning a variable cnt that was initialized to 0
> > near the beginning of the function; we haven't even started using
> > it to count yet.
> >
> > But the point is, if that is the reason the author thinks it is an
> > improvement, that probably needs to be stated.
>
> If you want to check the validity of the patch you have to view it in
> context anyways.
Umm.
You can make reviewing your patch attractive and easy, and you can make it
unattractive and difficult.
If you explain in the commit message that you replaced "cnt" by "0"
because it is initialized to 0 at that point anyway, it is a _much bigger_
pleasure to review your patch.
Let alone a much bigger pleasure for you, 6 months from now, when somebody
says "why does this silly function return 0, when it should return cnt?"
BTW exactly for that reason, I'd like to leave it as "cnt". Because code
_will_ change, and it's quite possible that cnt will not be 0 at that
point in the future.
> Compared to understanding the change to the code, it takes much longer
> to parse and understand the above paragraph _plus_ verify its agreement
> with the code. I think you will agree that there is a limit to the
> amount of documentation that's still useful.
Just look at a concrete case: me. I saw that part of the patch, even
before coming to the real meat of it. And that head-scratching already
removed all the enthusiasm I had to look at unpack-trees.c again, so you
lost a reviewer.
> What's sad, however, is that we are now discussing style and commenting
> issues of a line of code, which, as by my analysis of [PATCH 3/3] never
> actually gets executed in the first place. I would have been much more
> curious about your comments on that.
Exactly,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Johannes Schindelin @ 2009-01-06 19:40 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, davidel, Francis Galiegue, Git ML
In-Reply-To: <20090106111712.GB30766@artemis.corp>
Hi,
On Tue, 6 Jan 2009, Pierre Habouzit wrote:
> On jeu, jan 01, 2009 at 04:38:09 +0000, Johannes Schindelin wrote:
> >
> > Nothing fancy, really, just a straight-forward implementation of the
> > heavily under-documented and under-analyzed paience diff algorithm.
>
> Btw, what is the status of this series ? I see it neither in pu nor in
> next. And I would gladly see it included in git.
AFAICT people wanted to be reasonably sure that it is worth the effort.
Although I would like to see it in once it is fleshed out -- even if it
does not meet our usefulness standard -- because people said Git is
inferior for not providing a patience diff. If we have --patience, we can
say "but we have it, it's just not useful, check for yourself".
> On jeu, jan 01, 2009 at 07:45:21 +0000, Linus Torvalds wrote:
> >
> > So could we have some actual real data on it?
>
> For example, look at the following (shamelessly stolen from the real
> life example http://glandium.org/blog/?p=120).
Due to the lines being much longer than 80 characters, this example was
not useful to me.
Ciao,
Dscho
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Ted Pavlic @ 2009-01-06 19:44 UTC (permalink / raw)
To: git
In-Reply-To: <49638625.3090109@tedpavlic.com>
> git clean -f
DOH. I meant to do
git clean -fx
(or just a git ls-files). That config.mak.autogen is certainly not
checked into the repo, and a quick test confirms that "make install"
certainly does set prefix to the home directory.
That being said, I'm sure that in the recent past I had to use configure
to install git into home directories.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
^ 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