* Re: Make "git clone" less of a deathly quiet experience
From: Linus Torvalds @ 2006-02-11 4:37 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0602102018250.3691@g5.osdl.org>
On Fri, 10 Feb 2006, Linus Torvalds wrote:
>
> Instead, it at least prints out how much data it's gotten, and what the
> packign speed is. Which makes the user realize that it's actually doing
> something useful instead of sitting there silently (and if the recipient
> knows how large the final result is, he can at least make a guess about
> when it migt be done).
Btw, we should print out the other "stages" too - the checkout in
particular can be a big part of the overhead, and it would probably make
sense to tell people about the fact that "hey, now we're checking the
result out, we're not actually trying to destroy your disk".
Quite often, the way to make users happy is not by being impossibly fast
or beautiful or otherwise wonderful, but by just _managing_ their
expectations, so that they don't say "that's some slow crud", but instead
say "Ok, it's a nice program, and it's doing a lot of hard work for me".
It takes me 15 minutes to clone a kernel repo over the network. Once I can
see that most of that is getting a 106MB pack-file at 146 kB/s, I say "ok,
that's fairly reasonable".
Linus
^ permalink raw reply
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-11 4:43 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <7v1wyasfam.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> git-sh-setup one is easy to fix. We could say something equally
> silly like this instead:
BTW, the reason I initially did this one and git-pull with
git-var was there was no way to extract values from the config
file easily from the command line back then. git-repo-config was
initially called git-config-set and was about setting values.
IMHO the configuration mechanism, and git-var in particular, is
quite broken, and nobody bothered to fix it.
(1) git-var -l can show all defined variables in the config
file, but you cannot ask about specific variable it does
not know about. You have to use git-repo-config for that:
$ git var -l | head -n 4
core.filemode=true
core.gitproxy=none for kernel.org
pull.twohead=resolve
pull.octopus=octopus
$ git var core.filemode ;# it does not know
usage: git-var [-l | <variable>]
$ git repo-config core.filemode
true
(2) git-repo-config does not have a way to list all the
configuration items like "git-var -l".
(3) neither of these commands know list of all the possible
configuration items, nor types of them, so core.filename
can be spelled as "1" or "true" to mean the same thing to
our C code, but repo-config faithfully returns how the
value is literally spelled in the configuration file. The
following two means the same thing to the C layer, so the
calling script needs to further interpret the output from
git-repo-config:
$ git repo-config core.filemode ;# [core] filemode=1
1
$ git repo-config core.filemode ;# [core] filemode=true
true
(4) worse, boolean 'true' can be specified by just having the
configuration item in the file, but repo-config dumps core
on that:
$ git repo-config core.filemode ;# [core] filemode
segmentation fault
Above problems are not the only problems with git-var and
git-repo-config, but these are not entirely these programs'
faults. They come from the way the configuration file mechanism
works. To allow different classes of configuration items to be
defined by commands that know about them, there is no central
registry of all the supported configuration items in the code.
For example, "diff.*" configuration items can be interpreted only
by C level programs that call git_config(git_diff_config).
With the current structure, it is very hard for these commands
to sensibly list all the configuration values (e.g. lack of
"[core] filemode" in the configuration file ought to mean that
the executable bit is unreliable i.e. core.filemode=false, but
they cannot report it), or report the values taking into account
their types. I do not think they even attempt to do so.
^ permalink raw reply
* Re: [PATCH] Don't send copies to the From: address
From: Greg KH @ 2006-02-11 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Biesinger, git, Ryan Anderson
In-Reply-To: <7vk6c2sg66.fsf@assigned-by-dhcp.cox.net>
On Fri, Feb 10, 2006 at 07:55:13PM -0800, Junio C Hamano wrote:
> Christian Biesinger <cbiesinger@web.de> writes:
>
> > Sending copies to the from address is pointless.
>
> Ryan, care to defend this part of the code? This behaviour
> might have been inherited from Greg's original version.
>
> I cannot speak for Ryan or Greg, but I think the script
> deliberately does this to support this workflow:
>
> (1) The original author sends in a patch to a subsystem
> maintainer;
>
> (2) The subsystem maintainer applies the patch to her tree,
> perhaps with her own sign-off and sign-offs by other people
> collected from the list. She examines it and says this
> patch is good;
>
> (3) The commit is formatted and sent to higher level of the
> foodchain. The message is CC'ed to interested parties in
> order to notify that the patch progressed in the
> foodchain.
>
> Me, personally I do not like CC: to people on the signed-off-by
> list, but dropping a note to From: person makes perfect sense to
> me, if it is to notify the progress of the patch.
Yes, they specifically should be notified of the progress of their
patch. And I like the fact that everyone else on the signed-off-by
chain also get's cc: too. It keeps everyone in the loop so they know
what is going on.
> What you are after _might_ be not CC'ing it if it was your own
> patch. Maybe something like this would help, but even if that
> is the case I suspect many people want to CC herself so it needs
> to be an optional feature.
Heh, getting a patch sent back to yourself this way is not a real big
deal at all :)
So, I really do not like this proposed patch at all.
thanks,
greg k-h
^ permalink raw reply
* Re: Resetting paths
From: Junio C Hamano @ 2006-02-11 5:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43EC7CB0.5040804@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> How about "git update-index --undo path...", possibly with "git reset
> path..." as a shorthand.
While "git reset path..." may make sense, "update-index --undo"
does not make any sense from the core point of view. That
command is about interaction between index and working tree file
and does not know anything about "the last commit", "the current
head commit", nor tree objects in general, so it does not know
where to get the undo information from.
I'll find time to code a prototype for "git reset path..." up
unless somebody beats me to it.
^ permalink raw reply
* Re: [PATCH] Munge ChangeLog-style commit messages, and grab author name and email.
From: Junio C Hamano @ 2006-02-11 5:39 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87slqqvgj2.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> The cairo project has been using ChangeLog-style commit messages, such as:
>
> 2006-01-18 Carl Worth <cworth@cworth.org>
>
> * src/cairo-pdf-surface.c: (cairo_pdf_surface_create_for_stream),
> (cairo_pdf_surface_create): Fix compilation-breaking typo.
>
> This patch recognizes that style and munges it up into:
>
> Fix compilation-breaking typo.
>
> which results in a much more useful headline within git.
I welcome discussion on this patch, but as its in current shape,
it looks a bit too specific to one particular style.
I think the one you quoted above is the GNU official style which
is used in many projects. I suspect your patch would help
people converting other projects as well. Having said that, as
you said it yourself, it would make more sense to make a more
generalized log munging interface.
Even though there might be many different schools of style,
hopefully each project consistently sticks to one style. Log
messages out of SVN repository tend to have their own styles.
We could define a common command line option, say --log-filter,
that are available across importers. E.g.
git-cvsimport --log-filter=gnu-log-style
git-svnimport --log-filter=gnu-log-style
'gnu-log-style' would be the massager you have hardcoded in the
patch, but made into a traditional UNIXy filter. We could
create contrib/commit-filters directory in git.git repository
and ship collections of such log massagers.
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Junio C Hamano @ 2006-02-11 5:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0602102018250.3691@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Anyway, _something_ like this is definitely needed. It could certainly be
> better (if it showed the same kind of thing that git-unpack-objects did,
> that would be much nicer, but would require parsing the object stream as
> it comes in). But this is big step forward, I think.
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> Comments? Hate-mail? Improvements?
It probably should default to quiet if (!isatty(1)).
The real improvement, independent of this client-side patch,
would be to reuse recently generated packs, but that needs
writable cache directory on the server side. Another thing that
I stumbled upon last time I tried it was that it did not look
totally trivial to modify the csum-file interface so that I can
splice the output from it into two different destinations (one
to cachefile, the other to the consumer).
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Junio C Hamano @ 2006-02-11 5:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0602102032410.3691@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, we should print out the other "stages" too - the checkout in
> particular can be a big part of the overhead, and it would probably make
> sense to tell people about the fact that "hey, now we're checking the
> result out, we're not actually trying to destroy your disk".
Would you suggest doing that with "checkout-index -v", that
shows "1 path1\r2 path2\r3 path3\r...\rDone.\n"?
^ permalink raw reply
* Re: [PATCH 1/3] Call extended-semantics commands through variables.
From: Junio C Hamano @ 2006-02-11 6:25 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1091.1139614506@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> The variables are just XARGS, FIND, and CPIO. No GIT_
> was appended so a user can set those once for all scripts
> that may use them (e.g. configure). A follow-on patch
> will modify the Makefile to allow installation-specific
> defaults.
The use of FIND or CPIO in git clone does not need -0 (and the
code does not use -0, nor your patch adds -0), so you should not
have to override them this way. Except refnames, the file names
are not something under arbitrary user control and usual LF
termination would work fine. Even refnames cannot contain LF in
them. Same thing for FIND in ls-remote and git-push.
FIND in count-objects only lists .git/objects/?? so filenames
there are already well-behaved and you do not need -0 there for
FIND nor XARGS. Same thing for XARGS in git-prune.sh and FIND
in repack (BTW, you got count-objects one wrong; there is a
leftover GIT_FIND there).
Although most of what your patch does seems to be unnecessary,
reviewing this patch gave me an opportunity to see if we fail to
use -0 where we should, and I am grateful for it.
I did not see any place we did not use -0 when we should, except
one. The places we _do_ use -0 currently should be converted
with something like your patch to use -0 capable version of the
tool.
The exception is where finding refnames from rsync'ed copy of a
remote (the remote may have screwed-up refnames just to be
hostile), but nobody should be using rsync transfer anyway,
so...
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Craig Schlenter @ 2006-02-11 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vwtg2o37c.fsf@assigned-by-dhcp.cox.net>
On 11 Feb 2006, at 7:48 AM, Junio C Hamano wrote:
[snip]
> The real improvement, independent of this client-side patch,
> would be to reuse recently generated packs, but that needs
> writable cache directory on the server side.
Speaking of improvements, I've noticed that my attempts to track
the 2.6 kernel via the git protocol result in inefficiencies from time
to time when the connection hangs or is terminated when my
flakey wireless link goes down. When I restart the pull, the data
that has already been downloaded is lost and things start from
scratch which is painful if it's a big update.
It would be nice if the "partial pack" or whatever that has been
downloaded at the time of the breakage could be re-used and
things could start "from that point onwards" or the bits that were
already received could be unpacked. Comments?
Thank you,
--Craig
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Radoslaw Szkodzinski @ 2006-02-11 8:44 UTC (permalink / raw)
To: Craig Schlenter; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <5C03F8F8-656F-48B0-825C-DE55C837F996@codefountain.com>
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
Craig Schlenter wrote:
> On 11 Feb 2006, at 7:48 AM, Junio C Hamano wrote:
> It would be nice if the "partial pack" or whatever that has been
> downloaded at the time of the breakage could be re-used and
> things could start "from that point onwards" or the bits that were
> already received could be unpacked. Comments?
It even already works on plain http repos with git fetch.
(e.g. WineHQ repository)
Why git protocol doesn't support it?
+10
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Marco Costalba @ 2006-02-11 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3bis88y9.fsf@assigned-by-dhcp.cox.net>
On 2/9/06, Junio C Hamano <junkio@cox.net> wrote:
>
> Does it matter? I presume that a Porcelain that cares would
> rather use the traditional "diff-tree -m -r" to look at diff
> with each parent. I dunno.
>
Yes, please preserve this behaviour.
I pulled today the diff-tree -c semantic change and now I see, in git archive:
$ git-diff-tree -r ca182053c7710a286d72102f4576cf32e0dafcfb
ca182053c7710a286d72102f4576cf32e0dafcfb
::100644 100644 100644 538d21d808b7ccc287e7bdd947f1583eadcda28b
30479b4a19805132a16facf6342b1438427486b7
59042d1bc9ee65063455b50a0968efb0b8182577 MM Makefile
$ git-diff-tree -r -m ca182053c7710a286d72102f4576cf32e0dafcfb
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 538d21d808b7ccc287e7bdd947f1583eadcda28b
59042d1bc9ee65063455b50a0968efb0b8182577 M Makefile
:100644 100644 410b758aab7efc6d777f0344500f97b1cbc52946
6c47c3a3e1acb8badaadad42dfe3d0bd7a06cac3 M entry.c
ca182053c7710a286d72102f4576cf32e0dafcfb
:100644 100644 30479b4a19805132a16facf6342b1438427486b7
59042d1bc9ee65063455b50a0968efb0b8182577 M Makefile
Please _do not_ change this behaviour to make -m a no-op as stated in
"diff-tree -c raw output" patch message
(ee63802422af14e43eccce3c6dc4150a27ceb1a3).
qgit has the possibility to switch from "see all merge files" to "see
interesting only", so
we really need that difference between 'git-diff-tree -r' and
'git-diff-tree -r -m'
Anyhow I am very happy with this change because it broke qgit ;-) but when fixed
it will have a lot of code removed and will be faster too.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.
From: Ryan Anderson @ 2006-02-10 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkwlo788.fsf@assigned-by-dhcp.cox.net>
On Wed, Feb 08, 2006 at 01:45:11PM -0800, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> >> It's been a while since I looked at it the last time so it may
> >> not even work with the current git, but here it is..
> >
> > I'll take a look through this in greater detail later, hopefully your
> > approach can be applied. Diff-analyzing is apparently tricky.
>
> Reading diff is tricky but I was lazy to match up the lines by
> hand, which is also a real work ;-).
Reading a diff is tricky, yes, but if you're willing to just throw RAM
at the problem, it might not be quite as bad as I was trying at first.
My current thought on how to get it more correct is this:
foreach $rev (@revqueue) {
foreach $parent (@{$revs{$rev}{parents}}) {
my @templines = @{$revs{$rev}{lines}};
$revs{$parent}{lines} = apply_diff(\@templlines);
}
}
The @lines arrays that get built will be entirely made up of hash or
array references, so they just get reused for each successive file.
When apply_diff() deletes a line from the new copy, it should mark that
line as "claimed" by the current rev.
I'm thinking that each element of @lines will look like this:
{
text => $text,
in_original => [0 | 1],
claimed_by => $rev,
}
at least to start.
This method can sanity check itself by calling git cat-file and actually
reading in each version of the file, and comparing it against the
generated copy, aborting if we get the two out of sync.
I'll see about implementing something along these lines this weekend,
time permitting.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Kent Engstrom @ 2006-02-10 19:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> *1* Often I find myself doing that while rewriting messy
> development history. For example, I start doing some
> work without knowing exactly where it leads, and end up with a
> history like this:
Perhaps this discussion could be added under Documentation/howto?
/ Kent Engström, Lysator
^ permalink raw reply
* [PATCH] allow double click on current HEAD id after git-pull
From: Olaf Hering @ 2006-02-11 11:26 UTC (permalink / raw)
To: git
Double click on to current HEAD commit id is not possible,
the dot has to go.
olaf@pomegranate:~/kernel/git/linux-2.6> git-pull
Unpacking 194 objects
100% (194/194) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Updating from 5bc159e6cb7ca8d173195919ee935885c129011e to 25bf368b3d98668c5d5f38e2201d8bca16e52680.
Fast forward
...
olaf@pomegranate:~/kernel/git/linux-2.6> git-whatchanged 5bc159e6cb7ca8d173195919ee935885c129011e..25bf368b3d98668c5d5f38e2201d8bca16e52680.
olaf@pomegranate:~/kernel/git/linux-2.6> git-whatchanged 5bc159e6cb7ca8d173195919ee935885c129011e..25bf368b3d98668c5d5f38e2201d8bca16e52680
<stuff>
Index: git-1.1.3/git-merge.sh
===================================================================
--- git-1.1.3.orig/git-merge.sh
+++ git-1.1.3/git-merge.sh
@@ -127,7 +127,7 @@ case "$#,$common,$no_commit" in
;;
1,"$head",*)
# Again the most common case of merging one remote.
- echo "Updating from $head to $1."
+ echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -m $head "$new_head" &&
Index: git-1.1.3/git-resolve.sh
===================================================================
--- git-1.1.3.orig/git-resolve.sh
+++ git-1.1.3/git-resolve.sh
@@ -41,7 +41,7 @@ case "$common" in
exit 0
;;
"$head")
- echo "Updating from $head to $merge."
+ echo "Updating from $head to $merge"
git-read-tree -u -m $head $merge || exit 1
git-update-ref HEAD "$merge" "$head"
git-diff-tree -p $head $merge | git-apply --stat
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] Teach repo-config the -l and --get-regexp options
From: Johannes Schindelin @ 2006-02-11 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtg2pkt2.fsf@assigned-by-dhcp.cox.net>
Now you can say "git-repo-config -l" and it will output the same as
"git-var -l", except that the keys are separated from the values by
a space instead of an equal sign.
If you want to match only "core" lines, just do
git-repo-config --get-regexp ^core
and if you want to be more specific, you can say
git-repo-config --get-regexp "^core.*mode"
to match any keys in section [core] which end in "mode".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Fri, 10 Feb 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > git-sh-setup one is easy to fix. We could say something equally
> > silly like this instead:
>
> BTW, the reason I initially did this one and git-pull with
> git-var was there was no way to extract values from the config
> file easily from the command line back then. git-repo-config was
> initially called git-config-set and was about setting values.
Happier?
Documentation/git-repo-config.txt | 10 ++++-
repo-config.c | 77 ++++++++++++++++++++++++++++---------
2 files changed, 68 insertions(+), 19 deletions(-)
aef2834ec6dfbdcca79879b4b749bbe9d3c2b63f
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 3069464..b7e0c23 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -8,10 +8,12 @@ git-repo-config - Get and set options in
SYNOPSIS
--------
+'git-repo-config' -l
'git-repo-config' name [value [value_regex]]
'git-repo-config' --replace-all name [value [value_regex]]
'git-repo-config' --get name [value_regex]
'git-repo-config' --get-all name [value_regex]
+'git-repo-config' --get-regexp name
'git-repo-config' --unset name [value_regex]
'git-repo-config' --unset-all name [value_regex]
@@ -39,9 +41,12 @@ This command will fail if
OPTIONS
-------
+-l::
+ List all key/value pairs.
+
--replace-all::
Default behaviour is to replace at most one line. This replaces
- all lines matching the key (and optionally the value_regex)
+ all lines matching the key (and optionally the value_regex).
--get::
Get the value for a given key (optionally filtered by a regex
@@ -51,6 +56,9 @@ OPTIONS
Like get, but does not fail if the number of values for the key
is not exactly one.
+--get-regexp::
+ Like --get-all, but interprets the name as a regular expression.
+
--unset::
Remove the line matching the key from .git/config.
diff --git a/repo-config.c b/repo-config.c
index c31e441..80f370e 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -2,32 +2,42 @@
#include <regex.h>
static const char git_config_set_usage[] =
-"git-repo-config [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]]";
+"git-repo-config [-l | --get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]]";
static char* key = NULL;
static char* value = NULL;
+static regex_t* key_regexp = NULL;
static regex_t* regexp = NULL;
+static int show_keys = 0;
+static int use_key_regexp = 0;
static int do_all = 0;
static int do_not_match = 0;
static int seen = 0;
static int show_config(const char* key_, const char* value_)
{
- if (!strcmp(key_, key) &&
- (regexp == NULL ||
- (do_not_match ^
- !regexec(regexp, value_, 0, NULL, 0)))) {
- if (do_all) {
- printf("%s\n", value_);
+ if (key && strcmp(key_, key))
return 0;
- }
- if (seen > 0) {
- fprintf(stderr, "More than one value: %s\n", value);
- free(value);
- }
- value = strdup(value_);
- seen++;
+ if (key_regexp && regexec(key_regexp, key_, 0, NULL, 0))
+ return 0;
+
+ if (regexp && (do_not_match ^
+ !!regexec(regexp, value_, 0, NULL, 0)))
+ return 0;
+
+ if (show_keys)
+ printf("%s ", key_);
+
+ if (do_all) {
+ printf("%s\n", value_);
+ return 0;
+ }
+ if (seen > 0) {
+ fprintf(stderr, ": More than one value: %s\n", value);
+ free(value);
}
+ value = strdup(value_);
+ seen++;
return 0;
}
@@ -35,10 +45,22 @@ static int get_value(const char* key_, c
{
int i;
- key = malloc(strlen(key_)+1);
- for (i = 0; key_[i]; i++)
- key[i] = tolower(key_[i]);
- key[i] = 0;
+ if (key_) {
+ if (use_key_regexp) {
+ key_regexp = (regex_t*)malloc(sizeof(regex_t));
+ if (regcomp(key_regexp, key_, REG_EXTENDED)) {
+ fprintf(stderr, "Invalid key pattern: %s\n",
+ regex_);
+ return -1;
+ }
+ } else {
+ key = malloc(strlen(key_)+1);
+ for (i = 0; key_[i]; i++)
+ key[i] = tolower(key_[i]);
+ key[i] = 0;
+ }
+ } else
+ key = NULL;
if (regex_) {
if (regex_[0] == '!') {
@@ -73,6 +95,15 @@ static int get_value(const char* key_, c
int main(int argc, const char **argv)
{
setup_git_directory();
+
+ if (!strcmp(argv[1], "-l")) {
+ if (argc > 2)
+ usage(git_config_set_usage);
+ show_keys = 1;
+ do_all = 1;
+ return get_value(NULL, NULL);
+ }
+
switch (argc) {
case 2:
return get_value(argv[1], NULL);
@@ -86,6 +117,11 @@ int main(int argc, const char **argv)
else if (!strcmp(argv[1], "--get-all")) {
do_all = 1;
return get_value(argv[2], NULL);
+ } else if (!strcmp(argv[1], "--get-regexp")) {
+ show_keys = 1;
+ use_key_regexp = 1;
+ do_all = 1;
+ return get_value(argv[2], NULL);
} else
return git_config_set(argv[1], argv[2]);
@@ -99,6 +135,11 @@ int main(int argc, const char **argv)
else if (!strcmp(argv[1], "--get-all")) {
do_all = 1;
return get_value(argv[2], argv[3]);
+ } else if (!strcmp(argv[1], "--get-regexp")) {
+ show_keys = 1;
+ use_key_regexp = 1;
+ do_all = 1;
+ return get_value(argv[2], argv[3]);
} else if (!strcmp(argv[1], "--replace-all"))
return git_config_set_multivar(argv[2], argv[3], NULL, 1);
--
1.1.4.g3d3a-dirty
^ permalink raw reply related
* Re: [PATCH] Don't send copies to the From: address
From: Christian Biesinger @ 2006-02-11 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson, Greg Kroah-Hartman
In-Reply-To: <7vk6c2sg66.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I cannot speak for Ryan or Greg, but I think the script
> deliberately does this to support this workflow:
Yeah, I suspected that this was the usecase. I don't think the patch
breaks that, it just compares those addresses to $from, i.e. the address
from which the email is sent.
> Me, personally I do not like CC: to people on the signed-off-by
> list, but dropping a note to From: person makes perfect sense to
> me, if it is to notify the progress of the patch.
I guess my description was a bit ambiguous, I didn't mean From: as in
"author of the patch", but instead From: as in "the email header for the
sender of the message", that is, the person who invokes git-send-email.
> What you are after _might_ be not CC'ing it if it was your own
> patch. Maybe something like this would help, but even if that
> is the case I suspect many people want to CC herself so it needs
> to be an optional feature.
So a new --no-cc-self option?
> - $cc = join(", ", unique_email_list(@cc));
> + $cc = join(", ", unique_email_list(grep { $_ ne $from } @cc));
This seems to be basically the same as what my patch does, except that
your way seems better :-)
^ permalink raw reply
* Re: [PATCH] Don't send copies to the From: address
From: Christian Biesinger @ 2006-02-11 12:33 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git, Ryan Anderson
In-Reply-To: <20060211045256.GA23066@kroah.com>
Greg KH wrote:
>> Me, personally I do not like CC: to people on the signed-off-by
>> list, but dropping a note to From: person makes perfect sense to
>> me, if it is to notify the progress of the patch.
>
> Yes, they specifically should be notified of the progress of their
> patch. And I like the fact that everyone else on the signed-off-by
> chain also get's cc: too. It keeps everyone in the loop so they know
> what is going on.
I didn't break that! At least, I don't think I did, and I didn't intend to.
> Heh, getting a patch sent back to yourself this way is not a real big
> deal at all :)
Maybe... but if I send the patch to a mailing list (like this one), this
means I get it twice. I guess that's already true for replies to the
patch, so maybe I should just live with it...
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Petr Baudis @ 2006-02-11 13:05 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: Craig Schlenter, Junio C Hamano, Git Mailing List
In-Reply-To: <43EDA3D0.7090204@gorzow.mm.pl>
Dear diary, on Sat, Feb 11, 2006 at 09:44:00AM CET, I got a letter
where Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> said that...
> Craig Schlenter wrote:
> > On 11 Feb 2006, at 7:48 AM, Junio C Hamano wrote:
> > It would be nice if the "partial pack" or whatever that has been
> > downloaded at the time of the breakage could be re-used and
> > things could start "from that point onwards" or the bits that were
> > already received could be unpacked. Comments?
>
> It even already works on plain http repos with git fetch.
> (e.g. WineHQ repository)
> Why git protocol doesn't support it?
Because it works totally different. When downloading from plain HTTP
repos, you are just downloading files from the remote repository and it
is easy to pick up wherever you left (and last night, I just added a
possibility to Cogito to resume an interrupted cg-clone by just cd'ing
inside and running cg-fetch, as is; it's pretty neat) - you just resume
downloading of the file you downloaded last, and don't download again
the files you already have.
But the native git protocol works completely differently - you tell the
server "give me all objects you have between object X and head", the
object will generate a completely custom pack just for you and send it
over the network. The next time you fetch, you just ask for a pack
between object X and head again, but the head can be already totally
different. What we would have to do is to check for interrupted
packfiles before fetching, attempt to fix them (cutting out the
incomplete objects and broken delta chains, if applicable), and then
tell the remote side to skip those objects; but that may not be easy
because there can be a lot of "loose fibres". Another way would be to
just tell the server "if head is still Y, start sending the pack only
after N bytes". *shudder*
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* stg branch switch causes unnecessary recompilation
From: Andrey Borzenkov @ 2006-02-11 13:07 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
{pts/1}% stg version
Stacked GIT 0.8.1
git version 1.1.6
Python version 2.4.2 (#2, Jan 30 2006, 18:33:58)
[GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]
Apparently stg branch is implemented as
- - pop all patches
- - do git checkout branch
- - push all patches
unfortunately it results in changing timestamp of all patched files causing
sometimes long recompilations. What I just had was:
- - I have several local patches for kernel that I keep in separate branches; I
also have one branch that I pick patches into and that I keep in sync with
upstream.
- - I pulled 2.6.15.4 stable and recompiled. In the process I noticed a trivial
error in one file
- - I created new branch, put fix in there, switched to my main branch, picked
patch and did make. It resulted in recompilation of *everything* that was
touched by *any* patch.
Sometimes it may be quite time consuming. Notice that git checkout does not
have this problem - it sets timestamp exactly to the one in index. It would
be nice if stg did the same.
regards
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD7eGPR6LMutpd94wRAmGEAJ49maPpI6VjGyp8sIOwPBKQNuUeZgCePOoN
C9bqat7QEA5Pt6bzegW0q2E=
=0JHo
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Radoslaw Szkodzinski @ 2006-02-11 13:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Craig Schlenter, Junio C Hamano, Git Mailing List
In-Reply-To: <20060211130530.GR31278@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
Petr Baudis wrote:
> But the native git protocol works completely differently - you tell the
> server "give me all objects you have between object X and head", the
> object will generate a completely custom pack just for you and send it
> over the network. The next time you fetch, you just ask for a pack
> between object X and head again, but the head can be already totally
> different. What we would have to do is to check for interrupted
> packfiles before fetching, attempt to fix them (cutting out the
> incomplete objects and broken delta chains, if applicable), and then
> tell the remote side to skip those objects; but that may not be easy
> because there can be a lot of "loose fibres". Another way would be to
> just tell the server "if head is still Y, start sending the pack only
> after N bytes". *shudder*
>
The other way would be:
- generate pack file between X and Y
- start sending from N bytes
It could break if the repo has been rebased in the meantime.
But we could safeguard against it by sending the hash of the packfile
up to N bytes.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Petr Baudis @ 2006-02-11 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vwtg2o37c.fsf@assigned-by-dhcp.cox.net>
BTW, some historical (from the very channel beginning) logs of #git for
fun, profit and late night reading are available at
http://pasky.or.cz/~pasky/cp/%23git/, e.g. the 2006-02-10 early morning
features the King Penguin explaining the deepness and intricacies of
pack files construction! Don't miss the opportunity!
New files won't be world-readable by default, but I hope to get some
irclogger with cutesy web interface set up for #git.
Dear diary, on Sat, Feb 11, 2006 at 06:48:55AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Anyway, _something_ like this is definitely needed. It could certainly be
> > better (if it showed the same kind of thing that git-unpack-objects did,
> > that would be much nicer, but would require parsing the object stream as
> > it comes in). But this is big step forward, I think.
> >
> > Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> > ---
> >
> > Comments? Hate-mail? Improvements?
>
> It probably should default to quiet if (!isatty(1)).
isatty(2) or something, 1 is in practice always a ref generator. Perhaps
it would be better not to clutter stderr, though; what about directly
opening /dev/tty? Does Cygwin support that?
> The real improvement, independent of this client-side patch,
> would be to reuse recently generated packs, but that needs
> writable cache directory on the server side. Another thing that
> I stumbled upon last time I tried it was that it did not look
> totally trivial to modify the csum-file interface so that I can
> splice the output from it into two different destinations (one
> to cachefile, the other to the consumer).
Yes, I said that on IRC yesterday as well. I don't think even a cache is
needed; just look at the repository and say:
* while there are packs containing only objects we are going to
send, pick the largest one and send it as-is.
* if there is a pack with more than a 75% (totally arbitrary)
overlap with the objects we are going to send, send it as-is.
* pack the loose objects.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Petr Baudis @ 2006-02-11 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20060211133340.GS31278@pasky.or.cz>
Dear diary, on Sat, Feb 11, 2006 at 02:33:40PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> BTW, some historical (from the very channel beginning) logs of #git for
> fun, profit and late night reading are available at
> http://pasky.or.cz/~pasky/cp/%23git/, e.g. the 2006-02-10 early morning
> features the King Penguin explaining the deepness and intricacies of
> pack files construction! Don't miss the opportunity!
>
> New files won't be world-readable by default, but I hope to get some
> irclogger with cutesy web interface set up for #git.
Like,
http://colabti.de/irclogger/irclogger_logs/git
(Courtesy of Francois Beerten.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Don't propagate SKIPPED warning to future commits.
From: Carl Worth @ 2006-02-11 14:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpslutz2t.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On Fri, 10 Feb 2006 18:21:30 -0800, Junio C Hamano wrote:
>
> I might be missing something fundamental, but isn't propagating
> the warning a good thing?
Yes, that would be fine.
The problem with the current behavior is that the warnings accumulate
for every commit that affects the particular file. So, after import,
the head commit will have a commit message ending in:
SKIPPED: broken-file
SKIPPED: broken-file
SKIPPED: broken-file
...
With one line per affected commit. So an alternate patch that simply
kept the warning unique per file would be fine too.
The discussion may be entirely moot since I don't know when it is
reasonable for a file to be missing in this way. In my specific case I
think the missing ,v file happened due to a combination of factors,
including old data in ~/.cvsps, and that data being stale due to some
manual surgery on the ,v files, (copying or renaming or so).
It would probably be fine to leave the current behavior until someone
runs into this again.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-commit: Only call git-rerere if $GIT_DIR/rr-cache exists
From: Johannes Schindelin @ 2006-02-11 15:03 UTC (permalink / raw)
To: git, junkio
This makes an error go away if you do not have Digest.pm installed, but
do not intend to make use of git-rerere anyway.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
111b9e1abeb98a8009a457fe8e7dff5a91b30778
diff --git a/git-commit.sh b/git-commit.sh
index 073ec81..28ec7c3 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -638,7 +638,7 @@ else
fi
ret="$?"
rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG"
-git-rerere
+test -d "$GIT_DIR/rr-cache" && git-rerere
if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
then
--
1.1.4.gaef2-dirty
^ permalink raw reply related
* gitk: searching on filenames?
From: walt @ 2006-02-11 15:42 UTC (permalink / raw)
To: git
A real example from this morning: I noticed when pulling from
Linus that kernel/sched.c had been updated, so I wanted to look
at that particular commit.
If I do 'gitk kernel/sched.c' then it does what I expect.
But, if I just start gitk with no arguments and then attempt
to search for kernel/sched.c it eventually stops with an error
saying "can't find diffs for <SHA1> <SHA2>".
Is this the expected behavior? (I have the 'Files' field
selected in the gitk search bar.)
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