* etckeeper, metastore and mr
From: Martin Langhoff @ 2008-01-01 22:56 UTC (permalink / raw)
To: Git Mailing List
reading planet debian, I found that Joey Hess has written a couple of
git-based tools, and one of them seems to address the "how to keep my
etc with git" fairly well. The readme is educational too. Thought it'd
be worth mentioning them
etckeeper
http://kitenet.net/~joey/code/etckeeper/
etckeeper uses metastore, which sounds useful too
as a pre-commit-hook
http://david.hardeman.nu/software.php
mr - for your cross-SCM projects
http://kitenet.net/~joey/code/mr/
adding them to the git wiki too ;-) -- with a bit of luck, this will
kill the next "how do I store etc with git" flamefest...
happy new year!
m
^ permalink raw reply
* input validation in receive-pack
From: Martin Koegler @ 2008-01-01 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In the function "static const char *update(struct command *cmd)" in
receive-pack.c:
| if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
| !is_null_sha1(old_sha1) &&
| !prefixcmp(name, "refs/heads/")) {
| struct commit *old_commit, *new_commit;
| struct commit_list *bases, *ent;
|
| old_commit = (struct commit *)parse_object(old_sha1);
| new_commit = (struct commit *)parse_object(new_sha1);
| bases = get_merge_bases(old_commit, new_commit, 1);
| for (ent = bases; ent; ent = ent->next)
| if (!hashcmp(old_sha1, ent->item->object.sha1))
| break;
| free_commit_list(bases);
| if (!ent) {
| error("denying non-fast forward %s"
| " (you should pull first)", name);
| return "non-fast forward";
| }
| }
As far as I understand the code, it assumes, that sha1 values provided
by the client really point to a commit. Shouldn't there be a check for
the object type?
Some lines above:
| if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
| error("refusing to create funny ref '%s' remotely", name);
| return "funny refname";
| }
Is this code really correct? All refnames starting with "refs/" may
only contain allowed characters, while all other may contain any
characters (except \0 and \n)?
For the updating code path, lock_any_ref_for_update calls
check_ref_format, so the error will happen latter. For the delete code
path, the refname seems not to be checked.
In the update code path, the check is done in refs.c:
| struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
| {
| if (check_ref_format(ref) == -1)
| return NULL;
| return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
| }
check_ref_format may also return -2 (less than two name levels) and -3
(* at the end), which are ignored. Is it really intended, that
receive-pack can create such refs.
mfg Martin Kögler
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jan Hudec @ 2008-01-01 20:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Grégoire Barbier, git
In-Reply-To: <m3myrpo1p0.fsf@roke.D-201>
On Tue, Jan 01, 2008 at 10:12:28 -0800, Jakub Narebski wrote:
> Grégoire Barbier <gb@gbarbier.org> writes:
>
> > I think that real HTTP support is better than all workarounds we
> > will be able to find to get through firewalls (when CONNECT is not
> > available, some awful VPNs that send Etherne over HTTP may work
> > ;-)). That's why I'm ok to work several hours on git code to
> > enhance real HTTP(S) support.
>
> There was also an idea to create a CGI program, or enhance gitweb
> to use for pushing. I don't know if it would be better way to pursue
> to work around corporate firewalls, or not...
It is what bzr and mercurial do and I think it would be quite good way to go
for cases like this. Eg. while our corporate firewall does allow anything
through connect on 443 (so I can use ssh that way), it does *not* support
web-dav in non-ssl mode. So I eg. can't even get from public subversion
repositories at work.
I have also thought about optimizing download using CGI, but than I thought,
that maybe there is a way to statically generate packs so, that if the client
wants n revisions, the number of revisions it downloads is O(n) and the
number of packs it gets them from (and thus number of round-trips) is
O(log(n)). Assuming the client always wants everything up to the tip, of
course. Now this is trivial with linear history (pack first half, than half
of what's left, etc., gives logarithmic number of packs and you always
download at most twice as much as you need), but it would be nice if somebody
found a way (even one that satisfies the conditions on average only) to do
this with non-linear history, it would be very nice improvement to the http
download -- native git server optimizes amount of data transfered very well,
but at the cost of quite heavy CPU load on the server.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: qgit 2.1 questions about range selection
From: Steffen Prohaska @ 2008-01-01 20:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801010733k63ed0c3du273f28b684efe904@mail.gmail.com>
Hello Marco,
On Jan 1, 2008, at 4:33 PM, Marco Costalba wrote:
> On Dec 31, 2007 11:42 AM, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> Here is a first impressions and some questions about the range
>> selection, which I find pretty hard to understand.
>>
>
> I have just pushed to
>
> git://git.kernel.org/pub/scm/qgit/qgit4.git
>
> a patch series that should address some of your concerns.
Thanks. The changes work for me.
Two minor remarks:
- I'd call the menu entry "View > Select range..." instead of
"View > Open range dialog...". This is shorter and the
dots already indicate that a dialog will open.
- I find the wizard icon in the menu entry confusing. The
wizard icon is already associated with "Toggle filter by
tree". It should be reserved for this.
Steffen
^ permalink raw reply
* Re: git config problem with strange config files
From: Junio C Hamano @ 2008-01-01 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Oberndorfer, Git Mailing List
In-Reply-To: <20080101062314.GA21555@coredump.intra.peff.net>
I agree with your analysis, and thanks for the patch.
^ permalink raw reply
* [PATCH] Let transport.c use git without a dash
From: Pieter de Bie @ 2008-01-01 19:39 UTC (permalink / raw)
To: git, gitster; +Cc: Pieter de Bie
This fixes transport.c by using "git upload-pack" and "git receive pack".
Using the old dashed form, git fetch would fail on a remote installation where
the git binaries are installed in a separate dir
---
I think this might have been on the list before, but then it was never applied
to master. git fetch fails when you have used make gitexecdir=/somewhereelse
on the remote side, as it can't find git-upload-pack.
transport.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 4e151a9..ad4c7e0 100644
--- a/transport.c
+++ b/transport.c
@@ -721,10 +721,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->disconnect = disconnect_git;
data->thin = 1;
- data->uploadpack = "git-upload-pack";
+ data->uploadpack = "git upload-pack";
if (remote && remote->uploadpack)
data->uploadpack = remote->uploadpack;
- data->receivepack = "git-receive-pack";
+ data->receivepack = "git receive-pack";
if (remote && remote->receivepack)
data->receivepack = remote->receivepack;
}
--
1.5.4.rc2.3.gbe5a8-dirty
^ permalink raw reply related
* Re: [PATCH 3/3] Replace setenv(GIT_DIR_ENVIRONMENT, ...) with set_git_dir()
From: Steffen Prohaska @ 2008-01-01 18:52 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Junio C Hamano, Johannes Schindelin,
Dmitry Kakurin
In-Reply-To: <3B6B19E6-255F-4D8F-B6A3-255A9E8E0AB0@zib.de>
Eventually I found some time to investigate this issue ...
On Nov 22, 2007, at 6:56 PM, Steffen Prohaska wrote:
>
> On Nov 22, 2007, at 10:58 AM, Johannes Sixt wrote:
>
>> Steffen Prohaska schrieb:
>>> On Nov 22, 2007, at 8:52 AM, Junio C Hamano wrote:
>>>> I suspect that if there are even earlier callers than these
>>>> early parts in the codepaths (handle_options, enter_repo, and
>>>> setup_git_directory_gently), maybe these earlier callers are
>>>> doing something wrong. Logically, if you are somewhere very
>>>> early in the codepath that you can still change the value of
>>>> GIT_DIR, you shouldn't have assumed the unknown value of GIT_DIR
>>>> and cached locations relative to that directory, no? What are
>>>> the problematic callers? What values do they access and why?
>>> I thought about these questions, too. But only very briefly.
>>> I did not analyze the code path that lead to calls of getenv().
>>> I'm not sure if it's really necessary. Calling set_git_dir()
>>> looks more sensible too me than the old code. I believe using
>>> set_git_dir() is the safer choice, and should not do any harm.
>>> So I stopped analyzing too much, and instead proposed to use
>>> set_git_dir().
>>
>> Junio's point is this: If we stumble over a dangling pointer that
>> getenv() produced, then this has obviously happened before setenv
>> (GIT_DIR), and caching that pointer is probably the wrong thing to
>> do anyway (because it refers to the wrong GIT_DIR) and needs to be
>> fixed.
>
> I see your point. It is probably more important to investigate
> this than I recognized at a first glance.
I instrumented the code to verify if setenv(GIT_DIR) is called after
setup_git_env(). This is not the case for all tests.
I also searched for problematic code paths.
setup_git_directory_gently() looks correct. It explicitly calls
getenv(GIT_DIR_ENVIRONMENT); but uses the value returned in a
safe manner. It does not cache the result and the only code path
that calls set_git_dir() does not access the return value of the
getenv() call after the call to set_git_dir().
setup_work_tree() looks correct, too. Here, get_git_dir() is
called, which implicitly results in caching the pointer returned
from getenv(GIT_DIR_ENVIRONMENT). But the result of get_git_dir() is
neither cached nor used after a subsequent call to set_git_dir().
So, I don't find any obvious problems.
>>> Interesting, though, is to find out if we have other potentially
>>> dangerous calls to getenv() that are not removed by this patch.
>>
>> Side note for other readers: This is a Windows specific problem
>> for the moment because its getenv() does not behave well.
>
> Yes, and apparently even nobody knows how to trigger the problem
> on Windows. At this point, we only know that caching getenv()
> calls is unsafe, while on Unix it is safe (at least for BSD
> it's documented to be safe).
In conclusion, using setenv() as in the original code instead of
set_git_dir() should be safe and this patch is not needed.
I tend to revert the changes in msysgit and see if we hit any
problems. But I'll wait until 1.5.4 is released.
Steffen
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jakub Narebski @ 2008-01-01 18:12 UTC (permalink / raw)
To: Grégoire Barbier; +Cc: git
In-Reply-To: <477A26FD.7020408@gbarbier.org>
Grégoire Barbier <gb@gbarbier.org> writes:
> I think that real HTTP support is better than all workarounds we
> will be able to find to get through firewalls (when CONNECT is not
> available, some awful VPNs that send Etherne over HTTP may work
> ;-)). That's why I'm ok to work several hours on git code to
> enhance real HTTP(S) support.
There was also an idea to create a CGI program, or enhance gitweb
to use for pushing. I don't know if it would be better way to pursue
to work around corporate firewalls, or not...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit 2.1 questions about range selection
From: Marco Costalba @ 2008-01-01 15:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <771EDDAF-F479-45F7-AB85-F7B6603FB061@zib.de>
On Dec 31, 2007 11:42 AM, Steffen Prohaska <prohaska@zib.de> wrote:
>
> Here is a first impressions and some questions about the range
> selection, which I find pretty hard to understand.
>
Hi Steffen,
I have just pushed to
git://git.kernel.org/pub/scm/qgit/qgit4.git
a patch series that should address some of your concerns.
More questions are welcomed ;-)
Marco
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Pierre Habouzit @ 2008-01-01 14:51 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Marco Costalba, Junio C Hamano, git
In-Reply-To: <20080101063616.GA21605@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On Tue, Jan 01, 2008 at 06:36:16AM +0000, Jeff King wrote:
> zlib makes a noticeable impact in real world cases. On a git.git repo,
> fully packed with stock config, warm cache:
On linux-2.6.git, with compressed packs:
$ =time git whatchanged >|/dev/null
19.67user 1.24system 0:21.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+38556minor)pagefaults 0swaps
Without compression:
$ =time git whatchanged >|/dev/null
14.41user 1.23system 0:15.67elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+44678minor)pagefaults 0swaps
> More pagefaults, but a 25% improvement in wall clock time. The packfile
> is noticeably larger (55M versus 40M), so I'm sure the cold cache case
> sucks. It may also change with larger repos, where the packfile size
> difference kills your cache.
The packfile is _incredibly_ larger (~200Mo -> ~420, though I suppose
the first one was packed with a larger window, coming from kernel.org).
I experience the same 25% wall clock reduction here as well. Though,
even if larger, linux-2.6.git still stays in RAM easily on my machine.
On an unrelated note, I wonder if it wouldn't be possible for git at
fetch time to "share" a very efficient pack that was computed on some
host. I mean, if I'm not mistaken, at clone time you get the efficient
pack, but at fetch time only incremental parts. I wonder if there would
be ways to say "hey, we recomputed here a very very very good pack, take
it instead of yours.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git config problem with strange config files
From: Peter Oberndorfer @ 2008-01-01 14:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080101061734.GA15453@coredump.intra.peff.net>
On Dienstag 01 Januar 2008, Jeff King wrote:
> On Mon, Dec 31, 2007 at 06:47:41PM +0100, Peter Oberndorfer wrote:
>
> > In case of a strange .git/config file "git config key value" can
> > create a bogus config entry, where one old value is wrong and the new
> > value resides in the wrong section until the config file is fixed up
> > by hand
>
> This patch fixes the test case you gave.
>
> Junio, even though such a config file should be rare, I think this is
> v1.5.4 material. But there is one tricky thing which I will point out in
> a followup mail.
>
Thank you for the patch
I would also guess this is relative rare, but IIRC somebody posted a patch to
handle a bogus config with a better message,
and the breakage example in the mail looked similar to mine.
How i came up with this bogus config is relative simple.
I wanted to add a new remote so i copied the already existing remote and
branch sections down to the last line and somehow also added a trailing tab.
Then i did a stg init which uses git repo-config to add its
stackformatversion = 2 setting
Greetings Peter
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Grégoire Barbier @ 2008-01-01 11:41 UTC (permalink / raw)
To: git
In-Reply-To: <20080101113301.GC9214@efreet.light.src>
Jan Hudec a écrit :
> On Mon, Dec 31, 2007 at 10:57:52 -0600, Graham Barr wrote:
>
>> Daniel Barkalow wrote:
>>
>>> On Sun, 30 Dec 2007, Grégoire Barbier wrote:
>>>
>>>> As for me, the main rationale to use http(s) rather than
>>>> git or ssh is to get through corporate firewalls, otherwise I would probably
>>>> not bother with webdav.
>>>>
>>> In general, we've been able to either get through firewalls with ssh or
>>> it's all in the same VPN. So it's kind of unloved at this point. People
>>> poke at it occasionally, but mostly in the context of other fixes, I
>>> think.
>>>
>> If you have a http proxy that you can use, the you can use ssh via that with
>> something like corkscrew. http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https
>>
>
> This, obviously, requires, that ssh is running on port 443, because most HTTP
> proxies won't let you CONNECT anywhere else. I have also heared of a HTTP
> proxy, that will check whether the session inside CONNECT starts with SSL
> handshake and will break your connection if it does not.
>
Hello Jan.
I think we have similar experiences. I have personnaly be faced to
proxies that not only scan for the SSL handshake but do
man-in-the-middle "attack" to break the SSL into two parts, checking for
HTTP inside it (and probably scanning for viruses and things like hat, I
think).
I first replied privatly to Graham because I didn't think it was
interesting for the whole list.
It was a mistake, here is my answer:
In fact, I already use this hack where it is possible.
However some well advised companies does not allow CONNECT through their HTTP proxy without some limitations that make this tip unusable (for instance: allowing only port 443, allowing only sites of a white-list, forcing a man-in-the-middle that not only breaks the confidentiality but too forbids the use of other protocols such as SSH, even on port 443).
BTW such circumvention of the security facilities is often (at less where I live and with my clients) forbidden in some corporate rules, even when it is technically possible.
Therefore I'm not allowed to do so and, furthermore, I cannot tell my clients to do so and write documents that tell it's the good way.
I think that real HTTP support is better than all workarounds we will be able to find to get through firewalls (when CONNECT is not available, some awful VPNs that send Etherne over HTTP may work ;-)).
That's why I'm ok to work several hours on git code to enhance real HTTP(S) support.
--
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jan Hudec @ 2008-01-01 11:33 UTC (permalink / raw)
To: Graham Barr; +Cc: Daniel Barkalow, Grégoire Barbier, git
In-Reply-To: <47791F90.8030302@pobox.com>
On Mon, Dec 31, 2007 at 10:57:52 -0600, Graham Barr wrote:
> Daniel Barkalow wrote:
>> On Sun, 30 Dec 2007, Grégoire Barbier wrote:
>
>>> I'm using Git for a rather short time but enough to fall in love with it. For
>>> a few days I'm trying to use it over webdav, that is over http/https with
>>> write (push) access. As for me, the main rationale to use http(s) rather than
>>> git or ssh is to get through corporate firewalls, otherwise I would probably
>>> not bother with webdav.
>
>> In general, we've been able to either get through firewalls with ssh or
>> it's all in the same VPN. So it's kind of unloved at this point. People
>> poke at it occasionally, but mostly in the context of other fixes, I
>> think.
>
> If you have a http proxy that you can use, the you can use ssh via that with
> something like corkscrew. http://wiki.kartbuilding.net/index.php/Corkscrew_-_ssh_over_https
This, obviously, requires, that ssh is running on port 443, because most HTTP
proxies won't let you CONNECT anywhere else. I have also heared of a HTTP
proxy, that will check whether the session inside CONNECT starts with SSL
handshake and will break your connection if it does not.
> A simple shell script wrapper around ssh to detect when you are behind a firewall
> can inject the ProxyCommand into the command line arguments with -o
Most of the time simply setting the parameter in .ssh/config works better
-- because you are often behind a proxy for some sites only.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2008-01-01 9:01 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <e5bfff550801010040k59c9608do1acb9da548620f85@mail.gmail.com>
On Jan 1, 2008 9:40 AM, Marco Costalba <mcostalba@gmail.com> wrote:
> On Jan 1, 2008 7:36 AM, Jeff King <peff@peff.net> wrote:
> >
> > The packfile is noticeably larger (55M versus 40M)
>
> Well 55M versus 40M is _only_ 27% of compression ratio. It means that
> the compression algorithm is not so fundamental because the data is
> already, how to say, well packaged.
>
I think zlib is a very good general purpose algorithm, but is main
strength is to give good final file sizes, it is mainly intended for
files that are seldom decompressed.
For the use we do in git IMHO it would seem appropriate to look for
algorithms used in the field of filesystem compression, where
decompression penalty is a design goal. I know very little about this
but I think among kernel people, expert and competent hackers should
not be difficult to find, given that compressed filesystem are around
from many years under linux/fs/ directory.
Marco
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2008-01-01 8:40 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20080101063616.GA21605@coredump.intra.peff.net>
On Jan 1, 2008 7:36 AM, Jeff King <peff@peff.net> wrote:
>
> The packfile is noticeably larger (55M versus 40M)
Well 55M versus 40M is _only_ 27% of compression ratio. It means that
the compression algorithm is not so fundamental because the data is
already, how to say, well packaged.
IOW if a compression algorithm X is say 30% less size efficient then
zlib it means that the final packfile size using X would be 44.5M
instead of 40M, i.e. only 11% bigger then using zlib.
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Marco Costalba @ 2008-01-01 8:26 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Filippo Zangheri, Linux Kernel Development, Git Mailing List
In-Reply-To: <4779F200.1020507@panasas.com>
On Jan 1, 2008 8:55 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>
>
> We use it a lot here. When the guys make a mess, and you need to figure what
> happened than qgit is your only friend. I intend to hack some extra stuff that
> we need often.
>
Glad to hear this. Hacking on qgit spans from very easy to nasty,
according to what you hack, in case, please, don't hesitate to write
me for some hints or API clarifications.
Thanks
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
From: Boaz Harrosh @ 2008-01-01 7:55 UTC (permalink / raw)
To: Marco Costalba
Cc: Filippo Zangheri, Linux Kernel Development, Git Mailing List
In-Reply-To: <e5bfff550712311007j1cd8223es51b6a59dfb958193@mail.gmail.com>
On Mon, Dec 31 2007 at 20:07 +0200, "Marco Costalba" <mcostalba@gmail.com> wrote:
> On Dec 31, 2007 6:47 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> On Mon, Dec 31 2007 at 13:58 +0200, "Marco Costalba" <mcostalba@gmail.com> wrote:
>>> On Dec 31, 2007 11:59 AM, Filippo Zangheri <filippo.zangheri@yahoo.it> wrote:
>>>> Hi,
>>>>
>>>> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but `make` gave me errors.
>>> Yes, you need qmake of Qt4 not the Qt3 one.
>>>
>> <snip>
>>
>> A Theoretical question.
>> Is it possible to compile Qt4 app all statically linked and run it on a Qt3 based KDE
>> machine. Some thing like the windows installation, where every thing is self-contained?
>>
>
> It's also very practical...I have _only_ KDE 3 installed, not KDE 4 ;-)
>
> I have both Qt4 and Qt3 development (shared) libraries installed and
> there is absolutely no compatibility problem, the only thing you have
> to remember is when running
>
> qmake qgit.pro
>
> the first time, you need to be sure is the Qt4 qmake, not the Qt3.
> Because I have Qt3 qmake in path, not the Qt4 one, I need to
> explicitly give the whole path the first time I configure the sources,
> something like
>
> /usr/lib/qt4/bin/qmake qgit.pro
>
> Then no other settings are needed, when you call make, the Makefiles
> are already built by qmake to search for the correct libraries.
>
>
> Hope this helps...
>
> Marco
Thanks because of your help I was brave enough to install qt4 and compile qgit.
It works.
We use it a lot here. When the guys make a mess, and you need to figure what
happened than qgit is your only friend. I intend to hack some extra stuff that
we need often.
Boaz
^ permalink raw reply
* Re: observing changes to a git repository
From: Jeff King @ 2008-01-01 6:54 UTC (permalink / raw)
To: Brian Swetland; +Cc: git
In-Reply-To: <20071231222820.GA11278@bulgaria.corp.google.com>
On Mon, Dec 31, 2007 at 02:28:20PM -0800, Brian Swetland wrote:
> - periodically:
> - grab the current head (call this Current)
> - if it's the same as Last stop
> - do a git log Current ^Last to observe what has happened since
> we last noticed a change. report on these commits.
> - Last = Current
Overall this makes sense. But in the case of history going backwards,
you might want to show a log of "Current...Last". IOW, imagine this
history:
B-C
/
A-D-E
Last is set to 'C' from some iteration of your script. In one period,
somebody does a git-reset back to A, then makes commits D and E. So you
want to see not just B and C, but some representation that D and E are
no longer of interest. "gitk Last...Current" will show you a nice graph
with a fork. git-log's --left-right option can represent the same
information textually. What you want depends, I think, on the goal of
your script.
> If these branches can be updated such that history is rewritten (not
> a concern in my particular case), I assume that for correctness you'd
> have to make Last and Current actual branches (perhaps under
> refs/heads/observer/... or whatever) to ensure that they don't get gc'd
> out from under you.
Yes, although realistically the reflog will keep it intact (unless you
have a bare repo without reflog).
> If I'm tracking several branches which can be merged between, I might
> want to keep track of which commits I've sent reports about if I don't
> want to re-report commits when they're merged into another branch.
What you have should work in the face of merges. Here's a history with
some merges:
B-C H-I <-- branch1
/ \ / \
A-D-E-F-G-J-K-L <-- master
where 'F' and 'L' are our merges. Because ^H implies ^G, but not ^J, if
we have something like Current=L, Last=H, you will see I, J, K, L.
So you will see each commit only once, unless you are running this
script per-branch, in which case you will see it once per branch. :) In
that case, you can do something like "git log Current ^LastBranch1
^LastBranch2 ...". IOW, Last* indicates "I've seen this and don't care
about it anymore".
-Peff
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Jeff King @ 2008-01-01 6:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.00.0712311232520.32517@woody.linux-foundation.org>
On Mon, Dec 31, 2007 at 12:37:36PM -0800, Linus Torvalds wrote:
> And quite honestly I'm not really even sure that the performance downside
> is entirely about zlib itself: I suspect a lot of the reason zlib shows up
> in the profiles is that the source data is usually cold in the cache, so
> it probably takes a lot of cache misses (it also will take all the page
> faults!).
zlib makes a noticeable impact in real world cases. On a git.git repo,
fully packed with stock config, warm cache:
$ /usr/bin/time git whatchanged >/dev/null
4.12user 0.37system 0:04.50elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+6452minor)pagefaults 0swaps
$ git config pack.compression 0
$ git repack -a -d -f
$ /usr/bin/time git whatchanged >/dev/null
2.93user 0.43system 0:03.36elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8501minor)pagefaults 0swaps
More pagefaults, but a 25% improvement in wall clock time. The packfile
is noticeably larger (55M versus 40M), so I'm sure the cold cache case
sucks. It may also change with larger repos, where the packfile size
difference kills your cache.
-Peff
^ permalink raw reply
* Re: git config problem with strange config files
From: Jeff King @ 2008-01-01 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Oberndorfer, Git Mailing List
In-Reply-To: <20080101061734.GA15453@coredump.intra.peff.net>
On Tue, Jan 01, 2008 at 01:17:34AM -0500, Jeff King wrote:
> @@ -118,7 +119,7 @@ static int get_value(config_fn_t fn, char *name, unsigned int len)
> /* Get the full name */
> for (;;) {
> c = get_next_char();
> - if (c == EOF)
> + if (config_file_eof)
> break;
> if (!iskeychar(c))
> break;
> @@ -182,7 +183,7 @@ static int get_base_var(char *name)
>
> for (;;) {
> int c = get_next_char();
> - if (c == EOF)
> + if (config_file_eof)
> return -1;
> if (c == ']')
> return baselen;
In these two hunks, we now check the eof flag correctly, which follows
through on the intent of the original code. But if you look carefully at
get_next_char(), it _never_ returns EOF in the first place; it replaces
it with '\n' and sets an external flag. So this 'if' branch was never
reached, but happened to work because the returned newline triggers a
similar effect.
By actually looking at the flag, I am implementing the original intent,
but it is a potential behavior change (I don't _think_ it should matter,
and it passes all of the config tests, but I haven't looked carefully at
all the ramifications). So it might be simpler yet to just eliminate
that conditional return.
-Peff
^ permalink raw reply
* Re: git config problem with strange config files
From: Jeff King @ 2008-01-01 6:17 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <200712311847.41499.kumbayo84@arcor.de>
On Mon, Dec 31, 2007 at 06:47:41PM +0100, Peter Oberndorfer wrote:
> In case of a strange .git/config file "git config key value" can
> create a bogus config entry, where one old value is wrong and the new
> value resides in the wrong section until the config file is fixed up
> by hand
This patch fixes the test case you gave.
Junio, even though such a config file should be rare, I think this is
v1.5.4 material. But there is one tricky thing which I will point out in
a followup mail.
-- >8 --
config: handle lack of newline at end of file better
The config parsing routines use the static global
'config_file' to store the FILE* pointing to the current
config file being parsed. The function get_next_char()
automatically converts an EOF on this file to a newline for
the convenience of its callers, and it sets config_file to
NULL to indicate that EOF was reached.
This throws away useful information, though, since some
routines want to call ftell on 'config_file' to find out
exactly _where_ the routine ended. In the case of a key
ending at EOF boundary, we ended up segfaulting in some
cases (changing that key or adding another key in its
section), or failing to provide the necessary newline
(adding a new section).
This patch adds a new flag to indicate EOF and uses that
instead of setting config_file to NULL. It also makes sure
to add newlines where necessary for truncated input. All
three included tests fail without the patch.
---
config.c | 14 +++++++++-----
t/t1303-wacky-config.sh | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 5 deletions(-)
create mode 100755 t/t1303-wacky-config.sh
diff --git a/config.c b/config.c
index fa56c70..7ef8b75 100644
--- a/config.c
+++ b/config.c
@@ -13,6 +13,7 @@
static FILE *config_file;
static const char *config_file_name;
static int config_linenr;
+static int config_file_eof;
static int zlib_compression_seen;
static int get_next_char(void)
@@ -34,7 +35,7 @@ static int get_next_char(void)
if (c == '\n')
config_linenr++;
if (c == EOF) {
- config_file = NULL;
+ config_file_eof = 1;
c = '\n';
}
}
@@ -118,7 +119,7 @@ static int get_value(config_fn_t fn, char *name, unsigned int len)
/* Get the full name */
for (;;) {
c = get_next_char();
- if (c == EOF)
+ if (config_file_eof)
break;
if (!iskeychar(c))
break;
@@ -182,7 +183,7 @@ static int get_base_var(char *name)
for (;;) {
int c = get_next_char();
- if (c == EOF)
+ if (config_file_eof)
return -1;
if (c == ']')
return baselen;
@@ -205,8 +206,7 @@ static int git_parse_file(config_fn_t fn)
for (;;) {
int c = get_next_char();
if (c == '\n') {
- /* EOF? */
- if (!config_file)
+ if (config_file_eof)
return 0;
comment = 0;
continue;
@@ -469,6 +469,7 @@ int git_config_from_file(config_fn_t fn, const char *filename)
config_file = f;
config_file_name = filename;
config_linenr = 1;
+ config_file_eof = 0;
ret = git_parse_file(fn);
fclose(f);
config_file_name = NULL;
@@ -918,6 +919,9 @@ int git_config_set_multivar(const char* key, const char* value,
contents, contents_sz,
store.offset[i]-2, &new_line);
+ if (copy_end > 0 && contents[copy_end-1] != '\n')
+ new_line = 1;
+
/* write the first part of the config */
if (copy_end > copy_begin) {
if (write_in_full(fd, contents + copy_begin,
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
new file mode 100755
index 0000000..99985dc
--- /dev/null
+++ b/t/t1303-wacky-config.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='Test wacky input to git config'
+. ./test-lib.sh
+
+setup() {
+ (printf "[section]\n" &&
+ printf " key = foo") >.git/config
+}
+
+check() {
+ echo "$2" >expected
+ git config --get "$1" >actual
+ git diff actual expected
+}
+
+test_expect_success 'modify same key' '
+ setup &&
+ git config section.key bar &&
+ check section.key bar
+'
+
+test_expect_success 'add key in same section' '
+ setup &&
+ git config section.other bar &&
+ check section.key foo &&
+ check section.other bar
+'
+
+test_expect_success 'add key in different section' '
+ setup &&
+ git config section2.key bar &&
+ check section.key foo &&
+ check section2.key bar
+'
+
+test_done
--
1.5.4.rc2.1103.g1042-dirty
^ permalink raw reply related
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Marco Costalba @ 2007-12-31 23:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.00.0712311232520.32517@woody.linux-foundation.org>
On Dec 31, 2007 9:37 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> Even today, I don't really know of a better compression choice, despite
> now being more aware of how critical uncompression performance is.
>
In the kernel, from not long ago, is used also LZO compression that
_seems_ much faster to decompress then zlib
http://lkml.org/lkml/2007/5/1/297
The developer, Richard Purdie, says it's also 40% faster to read for jffs2.
>
> Quite possibly, the cache miss costs dominate over any algorithmic costs.
>
What way could be used to build up a test to check this?
Thanks
Marco
^ permalink raw reply
* [PATCH] Remove duplication in t9119-git-svn-info.sh
From: David D. Kilzer @ 2007-12-31 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git, David D. Kilzer
In-Reply-To: <7vodc65whw.fsf@gitster.siamese.dyndns.org>
Simplify arguments to ptouch bash function.
---
t/t9119-git-svn-info.sh | 27 +++++++++++++--------------
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/t/t9119-git-svn-info.sh b/t/t9119-git-svn-info.sh
index 6d9bec9..907058e 100755
--- a/t/t9119-git-svn-info.sh
+++ b/t/t9119-git-svn-info.sh
@@ -20,7 +20,7 @@ ptouch() {
my $atime = $mtime;
utime $atime, $mtime, $git_file;
}
- ' "`svn info $1 | grep '^Text Last Updated:'`" "$2"
+ ' "`svn info svnwc/$1 | grep '^Text Last Updated:'`" "gitwc/$1"
}
test_expect_success 'setup repository and import' "
@@ -40,10 +40,10 @@ test_expect_success 'setup repository and import' "
git-svn fetch &&
cd .. &&
svn co $svnrepo svnwc &&
- ptouch svnwc/file gitwc/file &&
- ptouch svnwc/directory gitwc/directory &&
- ptouch svnwc/symlink-file gitwc/symlink-file &&
- ptouch svnwc/symlink-directory gitwc/symlink-directory
+ ptouch file &&
+ ptouch directory &&
+ ptouch symlink-file &&
+ ptouch symlink-directory
"
test_expect_success 'info' "
@@ -116,7 +116,7 @@ test_expect_success 'info added-file' "
git add added-file &&
cd .. &&
cp gitwc/added-file svnwc/added-file &&
- ptouch svnwc/added-file gitwc/added-file &&
+ ptouch added-file &&
cd svnwc &&
svn add added-file > /dev/null &&
cd .. &&
@@ -132,7 +132,7 @@ test_expect_success 'info --url added-file' '
test_expect_success 'info added-directory' "
mkdir gitwc/added-directory svnwc/added-directory &&
- ptouch svnwc/added-directory gitwc/added-directory &&
+ ptouch added-directory &&
touch gitwc/added-directory/.placeholder &&
cd svnwc &&
svn add added-directory > /dev/null &&
@@ -161,7 +161,7 @@ test_expect_success 'info added-symlink-file' "
ln -s added-file added-symlink-file &&
svn add added-symlink-file > /dev/null &&
cd .. &&
- ptouch svnwc/added-symlink-file gitwc/added-symlink-file &&
+ ptouch added-symlink-file &&
(cd svnwc; svn info added-symlink-file) \
> expected.info-added-symlink-file &&
(cd gitwc; git-svn info added-symlink-file) \
@@ -184,7 +184,7 @@ test_expect_success 'info added-symlink-directory' "
ln -s added-directory added-symlink-directory &&
svn add added-symlink-directory > /dev/null &&
cd .. &&
- ptouch svnwc/added-symlink-directory gitwc/added-symlink-directory &&
+ ptouch added-symlink-directory &&
(cd svnwc; svn info added-symlink-directory) \
> expected.info-added-symlink-directory &&
(cd gitwc; git-svn info added-symlink-directory) \
@@ -295,7 +295,7 @@ test_expect_success 'info --url symlink-directory (deleted)' '
test_expect_success 'info unknown-file' "
echo two > gitwc/unknown-file &&
cp gitwc/unknown-file svnwc/unknown-file &&
- ptouch svnwc/unknown-file gitwc/unknown-file &&
+ ptouch unknown-file &&
(cd svnwc; svn info unknown-file) 2> expected.info-unknown-file &&
(cd gitwc; git-svn info unknown-file) 2> actual.info-unknown-file &&
git-diff expected.info-unknown-file actual.info-unknown-file
@@ -309,7 +309,7 @@ test_expect_success 'info --url unknown-file' '
test_expect_success 'info unknown-directory' "
mkdir gitwc/unknown-directory svnwc/unknown-directory &&
- ptouch svnwc/unknown-directory gitwc/unknown-directory &&
+ ptouch unknown-directory &&
touch gitwc/unknown-directory/.placeholder &&
(cd svnwc; svn info unknown-directory) \
2> expected.info-unknown-directory &&
@@ -332,7 +332,7 @@ test_expect_success 'info unknown-symlink-file' "
cd svnwc &&
ln -s unknown-file unknown-symlink-file &&
cd .. &&
- ptouch svnwc/unknown-symlink-file gitwc/unknown-symlink-file &&
+ ptouch unknown-symlink-file &&
(cd svnwc; svn info unknown-symlink-file) \
2> expected.info-unknown-symlink-file &&
(cd gitwc; git-svn info unknown-symlink-file) \
@@ -355,8 +355,7 @@ test_expect_success 'info unknown-symlink-directory' "
cd svnwc &&
ln -s unknown-directory unknown-symlink-directory &&
cd .. &&
- ptouch svnwc/unknown-symlink-directory \
- gitwc/unknown-symlink-directory &&
+ ptouch unknown-symlink-directory &&
(cd svnwc; svn info unknown-symlink-directory) \
2> expected.info-unknown-symlink-directory &&
(cd gitwc; git-svn info unknown-symlink-directory) \
--
1.5.3.7
^ permalink raw reply related
* Re: On the many files problem
From: Martin Langhoff @ 2007-12-31 23:31 UTC (permalink / raw)
To: Yannick Gingras; +Cc: Linus Torvalds, git
In-Reply-To: <873atjtbmu.fsf@enceladus.ygingras.net>
On Dec 31, 2007 11:13 PM, Yannick Gingras <ygingras@ygingras.net> wrote:
> > but if you want to check odder cases, try creating a huge
> > directory, and then deleting most files, and then adding a few
> > new ones. Some filesystems will take a huge hit because they'll
> > still scan the whole directory, even though it's mostly empty!
> >
> > (Also, a "readdir() + stat()" loop will often get *much* worse access
> > patterns if you've mixed deletions and creations)
>
> This is something that will be interesting to benchmark later on. So,
> an application with a lot of turnaround, say a mail server, should
> delete and re-create the directories from time to time? I assume this
> is specific to some file system types.
This is indeed the case. Directories with a lot of movement get
fragmented on most FSs -- ext3 is a very bad case for this -- and
there are no "directory defrag" tools other than regenarating them.
The "Maildir" storage used for many IMAP servers these days shows the
problem.
This (longish) threads has some interesting tidbits on getdents() and
directory fragmentation.
http://kerneltrap.org/mailarchive/git/2007/1/7/235215
cheers,
m
^ permalink raw reply
* Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive
From: Shawn O. Pearce @ 2007-12-31 22:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550712301106l133dd38btd2cc4be02159387d@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> Just for document the profiling I have uploaded a snapshot of
> KCachegrind profiling data on a run of git-log on the git tree:
>
> http://digilander.libero.it/mcostalba/callgrind_git_log1.png
>
> From there you can see that pretty.c and strbuf.c, after all the
> optimizations, account for less then 8% of total time.
> The biggest part is that 86.64% that is due almost entirely to zlib.
>
> In particular
>
> st = inflate(&stream, Z_FINISH);
>
> called from unpack_compressed_entry() in sha1_file.c accounts for 72%
> of total time.
That's one of the areas where packv4 was actually a reasonably
good gain. It was faster for packv4 to convert a dict based commit
or tree into the canonical raw format used by git than it was for
zlib inflate to decompress the very same data.
It wasn't a huge gain, but if I recall we were saving a good half
second on a 4 second "git log --raw >/dev/null" time. And that
was before we even tried to improve the tree walking APIs to
take advantage of the smaller (and easier to read) dict based
tree objects.
Linus already mentioned in another reply on this thread that the
inflate time may be all page faults. The savings we were seeing
from the dict based format may have simply been due to less page
faults; the dict based format was slightly smaller so we probably
got a lot more in disk cache at once.
--
Shawn.
^ 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