* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 17:11 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576F65A.6010707@xs4all.nl>
Dnia środa 6. grudnia 2006 17:56, Han-Wen Nienhuys napisał:
> Jakub Narebski escreveu:
>
>> I'm still not sure if this has place in git. Is it really common to
>> support building outside source directory? If git didn't support this,
>> so what?
>
> lots of serious tools support it, as it this comes automatically
> when using automake. Eg. emacs, gcc, make, pango, lilypond, etc etc.
>
> It's a quite standard feature ; you should be asking why git
> shouldn't support it.
Because git is not autotool'ed project. And people protested vehemently
against adding yet another dependency. So from the whole autotools suite
only autoconf is used, and only to generate config.mak.autogen Makefile
configuration, which otherwise would be needed to be generated by hand.
BTW git tries to guess configuration based on uname -a result.
There was also for a little while hand-generated configure script, but
it got abandoned when it appeared that it is hard to be portable (and
autoconf did the work; perhaps too hard but did, not using features
which weren't common but now are in standard, but did), and the fact
that it was possible to have _optional_ autoconf support.
Add to that the fact that people said that ./configure on Cygwin is slow
(can be slow), so they prefer _not_ to run this.
Besides, the fact that some tools suport some feature is not the reason
to add it. You have to look at how often is this feature _used_. For
example you don't need it (you need only DESTDIR support) for creating
RPMS from sources.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Jakub Narebski @ 2006-12-06 17:15 UTC (permalink / raw)
To: git
In-Reply-To: <200612061800.17087.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> I even would go so far to setup
> a default "git-pull" action even for branching off from local branches,
> by setting "branch.<newbranch>.remote = ." to merge from local "upstream".
I wouldn't go that far, as it would forbit perfectly good "git fetch"
from anywhere in the sources meaning "git fetch origin".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: J. Bruce Fields @ 2006-12-06 17:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, gpermus, hanwen, git
In-Reply-To: <Pine.LNX.4.63.0612061613460.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, Dec 06, 2006 at 04:16:57PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 6 Dec 2006, J. Bruce Fields wrote:
>
> > I'd rather leave that introduction as it is--just as a section that
> > advertises the git features without trying to explain much. And I'd
> > rather not mention push until we have a chance to explain how to use it.
>
> You talk like you'd have an eternity to explain Git. But that is not true.
> A developer, especially those whom Git is forced upon, have an attention
> span shorter than their pub1c hair.
Definitely, I agree. So that argues for locating the most import stuff
as close to start of the document as possible. But obviously there's
lot of important stuff and you can't do that with everything, so you
also have to rely on keeping things organized so people can more easily
skip to the middle.
The rest of the introduction is all git marketing: why you should like
using git instead of cvs. So someone skimming for the quickest possible
"how do I make changes?" stuff may skip it entirely.
The thing that might help such a skimmer the most, actually, would be
a more helpful title for the section that actually does have what
they're looking for. And making sure that particular section has the
right stuff. How about something like this?
--b.
cvs-migration: improved section titles, better push/commit explanation
Rename the section titles to make the "how-to" content of the section
obvious. Also clarify that changes have to be commited before they can
be pushed.
---
cvs-migration.txt | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 6812683..726b48d 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -76,8 +76,8 @@ variants of this model.
With a small group, developers may just pull changes from each other's
repositories without the need for a central maintainer.
-Emulating the CVS Development Model
------------------------------------
+Creating a Shared Repository
+----------------------------
Start with an ordinary git working directory containing the project, and
remove the checked-out files, keeping just the bare .git directory:
@@ -105,7 +105,10 @@ $ GIT_DIR=repo.git git repo-config core.
Make sure committers have a umask of at most 027, so that the directories
they create are writable and searchable by other group members.
-Suppose this repository is now set up in /pub/repo.git on the host
+Performing Development on a Shared Repository
+---------------------------------------------
+
+Suppose a repository is now set up in /pub/repo.git on the host
foo.com. Then as an individual committer you can clone the shared
repository:
@@ -134,15 +137,17 @@ Pull: master:origin
------------
================================
-You can update the shared repository with your changes using:
+You can update the shared repository with your changes by first commiting
+your changes, and then using:
------------------------------------------------
$ git push origin master
------------------------------------------------
-If someone else has updated the repository more recently, `git push`, like
-`cvs commit`, will complain, in which case you must pull any changes
-before attempting the push again.
+to "push" those commits to the shared repository. If someone else has
+updated the repository more recently, `git push`, like `cvs commit`, will
+complain, in which case you must pull any changes before attempting the
+push again.
In the `git push` command above we specify the name of the remote branch
^ permalink raw reply related
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: J. Bruce Fields @ 2006-12-06 17:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, gpermus, hanwen, git
In-Reply-To: <20061206171950.GD1714@fieldses.org>
On Wed, Dec 06, 2006 at 12:19:50PM -0500, J. Bruce Fields wrote:
> On Wed, Dec 06, 2006 at 04:16:57PM +0100, Johannes Schindelin wrote:
> Definitely, I agree. So that argues for locating the most import stuff
> as close to start of the document as possible. But obviously there's
> lot of important stuff and you can't do that with everything, so you
> also have to rely on keeping things organized so people can more easily
> skip to the middle.
Hm, but, come to think of it, I agree with you that the "how to commit
and push" really should come earlier, since that's the stuff most people
need to know; currently the order is roughly:
importing a cvs archive
creating a shared repository
committing to a shared repository
We should start out with the assumption that a shared repo is already
set up and make it:
committing to a shared repository
creating a shared repository
importing a cvs archive
which puts it in stuff-most-people-need-to-know to
stuff-less-people-need-to-know order. Maybe the current introduction
should even be postponed to later.
And some day we should move that whole final CVS annotate section
elsewhere.
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Junio C Hamano @ 2006-12-06 17:44 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20061206172450.GE1714@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> And some day we should move that whole final CVS annotate section
> elsewhere.
I agree that we should make that particular document shorter by
catering the immediate need of CVS migrant. No need for git
marketting and showing off the power.
In that spirit, I think we can lose the section on 'annotate'
altogether now. It was written in June 2005, way before
'annotate' and 'blame', both of which came in Feb 2006.
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Shawn Pearce @ 2006-12-06 18:13 UTC (permalink / raw)
To: Liu Yubao; +Cc: Alex Riesen, git
In-Reply-To: <4576A60A.3060003@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
> $ git merge "sync from origin" HEAD origin
> Updating 088406b..ff51a98
> include/linux/netfilter/xt_CONNMARK.h: needs update
> include/linux/netfilter/xt_DSCP.h: needs update
> include/linux/netfilter/xt_MARK.h: needs update
> include/linux/netfilter_ipv4/ipt_CONNMARK.h: needs update
> include/linux/netfilter_ipv4/ipt_DSCP.h: needs update
> include/linux/netfilter_ipv4/ipt_ECN.h: needs update
> include/linux/netfilter_ipv4/ipt_MARK.h: needs update
> include/linux/netfilter_ipv4/ipt_TCPMSS.h: needs update
> include/linux/netfilter_ipv4/ipt_TOS.h: needs update
> include/linux/netfilter_ipv4/ipt_TTL.h: needs update
> include/linux/netfilter_ipv6/ip6t_HL.h: needs update
> include/linux/netfilter_ipv6/ip6t_MARK.h: needs update
> net/ipv4/netfilter/ipt_ECN.c: needs update
> net/ipv4/netfilter/ipt_TOS.c: needs update
> net/ipv4/netfilter/ipt_TTL.c: needs update
> net/ipv6/netfilter/ip6t_HL.c: needs update
> net/netfilter/xt_CONNMARK.c: needs update
> net/netfilter/xt_DSCP.c: needs update
> net/netfilter/xt_MARK.c: needs update
> fatal: Entry 'net/ipv4/netfilter/ipt_ECN.c' not uptodate. Cannot merge.
>
> I really have never modified these files manually.
You are just *very unlucky*. :-)
The Linux kernel has case sensitive file names. In other words there
are two files in the kernel:
net/netfilter/xt_MARK.c
net/netfilter/xt_mark.c
and they have different content! On NTFS or FAT, where filenames
are not case sensitive, these become the same file. So Git now
starts to think that the file was modified, because one of those
files overwrote the other when they were checked out.
Moral of the story: You cannot work with the linux.git repository
on a case insensitive filesystem, like NTFS, FAT (Windows), or HFS+
(Mac OS X).
--
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Michael Loeffler @ 2006-12-06 18:16 UTC (permalink / raw)
To: git
In-Reply-To: <el6sni$re3$1@sea.gmane.org>
Am Mittwoch, den 06.12.2006, 17:58 +0100 schrieb Jakub Narebski:
...
> We could use perl for that, but embedded perl is a bit horrible.
I had the same idea after the sed problems with macos/solaris, but
embedded perl is really a bit horrible.
...
> '*' in destination part would mean $n / \n (n-th match for *).
> And you need some way to mark if it is prefix match, or whole path match.
> Ending prefix match with '/' is one way of doing this... Unless it would
> be prefix match always, but I think this leads way to confusion.
Then we could just use (.*) and \1..9 and use extended REs. The only
problem is this stupid sed thing, only GNU-sed has the -r
option to use extended REs.
> Just a thought.
I would prefer the following ways to do this globfetch stuff:
1.) The original refspec:
Pull: refs/heads/master:refs/remotes/origin/master
2.) The one with "prefix match":
Pull: refs/heads/:refs/remotes/origin/
3.) The one with extended regex:
Pull: refs/heads/(.*):refs/remotes/origin/\1
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Jakub Narebski @ 2006-12-06 18:27 UTC (permalink / raw)
To: git
In-Reply-To: <1165429001.993.35.camel@ibook.zvpunry.de>
Michael Loeffler wrote:
>> We could use perl for that, but embedded perl is a bit horrible.
>
> I had the same idea after the sed problems with macos/solaris, but
> embedded perl is really a bit horrible.
Or you can rewrite git-fetch in Perl (or as built-in in C).
> I would prefer the following ways to do this globfetch stuff:
>
> 1.) The original refspec:
> Pull: refs/heads/master:refs/remotes/origin/master
>
> 2.) The one with "prefix match":
> Pull: refs/heads/:refs/remotes/origin/
I just worry what would happen when someone would write e.g.
Pull: refs/heads/:refs/heads/origin-
> 3.) The one with extended regex:
> Pull: refs/heads/(.*):refs/remotes/origin/\1
3.) The one with shell-like (fnmatch / glob) globbing
Pull: refs/heads/*:refs/remotes/origin/*
By the way, with globbing we really need some other way than
first Pull: line to select remote head to merge on "git pull".
For example "Merge:" line / remote.<name>.merge config var.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Junio C Hamano @ 2006-12-06 18:31 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Johannes Schindelin
In-Reply-To: <874ps91v79.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> ... Even if this functionality
> weren't made available at all, I'd still be interested in your
> comments on the main thrust of my proposal. I think that consists of:
>
> 1. Unifying the two current commands that provide
> commit-working-tree-content semantics into a single,
> use-oriented description.
>
> 2. Avoiding a change of semantics triggered by merely applying
> pathname arguments without any command-line option or
> alternate command name.
I am not sure what needs to be commented on at this point, since
it is not yet clear to me where you want your proposal to lead
us.
I do not agree with your "three commands" or "two semantics"
characterization of the current way "git commit" works. "git
commit" without any optional argument already acts as if a
sensible default arguments are given, that is "no funny business
with additional paths, commit just what the user has staged
already."
"git commit" is primarily about committing what has been staged
in the index, and "--all" is just a type-saver short-hand (just
like "--include" is) to perform update-index the last minute and
nothing more. In other words, "--all" is a variant of the
pathname-less form "git commit". It is not a variant of "git
commit --only paths..." form, as you characterized.
The pathname form (the "--only" variant) on the surface seem to
work differently, but when you think about it, it is not all
that different from the normal commit. We explain that it
ignores index, but in the bigger picture, it does not really.
In this sequence:
edit a b
git update-index a
git commit --only b
git commit --all
the first commit does "jump" the changes already made to the
index, but after it makes the commit, the index has the same
contents as if you did "git update-index a b" where you ran that
"git commit". In other words, it is just a handy short-hand to
pretend as if you did the above sequence in this order instead:
edit a b
git update-index b
git commit
git update-index a
git commit
So I actually think it is a mistake to stress the fact that "git
commit --only paths..." seems to act differently from the normal
"git commit" too much. It just helps to split the changes in
your working tree if the changes happen to be cleanly separable
at file boundaries (aka "CVS mentality"). When the changes are
not cleanly separable at file boundaries, the "more painfully
index aware" variant also allows you to split the changes in
your working tree in the time dimension:
edit a
git update-index a
edit a
git commit ;# without paths
git update-index a
git commit
In short, while I understand that your "proposal" shows your own
way to summarize the semantics of "git commit", I am not seeing
what it buys us, and I do not see the need to come up with a
pair of new two commands for making commits (if that is what the
proposal is about, that is, but it is not clear to me if that is
what you are driving at). I think it would only confuse users.
> I receive a patch while I'm in the middle of doing other work,
> (but with a clean index compared to HEAD, which is what I've
> usually). The patch looks good, so I want to commit it right
> away, but I do want to separate it into two or more pieces,
> (commonly this is because I want to separate the "add a test
> case demonstrating a bug" part from the "fix the bug"
> part).
> ...
> Who said I wouldn't test it? I do split commits like this precisely so
> that I _can_ test it this way---and git helps a lot here. I do the
> split commit, then easily back up to the revision that adds the test
> case, verify the test fails before the bug fix, (which is something
> the maintainer doesn't get a chance to do with your (2) approach),
> then move forward and verify that the test passes after the fix.
>
> So, sure, I haven't ever had that working tree before the commit. But
> git makes it easy to get that working tree after I commit and test
> everything before I push anything out.
You saw a good patch in the middle of something that you did not
want to lose your working tree changes for. That good patch was
not really good enough to be applied straight into your tree but
needed tweaking and splitting. Nevertheless you went ahead and
made two commits out of that patch, even though you were in the
middle of something. You could not test them right away after
committing because your tree was in no shape to test them in
isolation. But that is excusable because you would not push
these commits out right away, before you have a chance to test
them by rewinding your working tree when you are done with what
you were originally doing.
Is it just me who finds the above a very much made-up example?
It means the patch (which is good and not good at the same time)
was not all that urgent after all, and it could well have waited
until you are done with what you were originally doing.
In any case, I should clarify my aversion to partial commits a
bit. What is more important is to notice that, while you cannot
compile-and-run test what is in the index in isolation (without
a fuse that exports the index contents as a virtual filesystem
-- anybody interested?), you _can_ preview and verify the text
that is going to be committed by comparing the index and the
HEAD. And for that, your "staging" action (i.e. Nico's "git
add") needs to be a separate step from your "committing" action.
In other words, I would even love Johannes's "per hunk commit"
idea, at least if it had an option to preview the whole thing
just one more time before committing, and I would love it better
if it had an option for not committing but just updating. You
could:
$ edit foo bar
: the whole mess in working tree is in no shape to be committed.
$ git add foo ;# stage the state of the entire file
$ git hunk-add bar ;# go interactive and update index selectively
$ git status -v ;# that is "git commit --dry-run --diff"
to review what would be committed. So while the commit that
would be made may not be compile-and-run tested, I would not
mind partial commit that much (and after all not all the
projects that track their contents with git are not "compiled"
nor "need testing" projects -- they could be tracking plain text
documentation, and the last-minute eyeballing may be a good
enough test for such contents).
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Junio C Hamano @ 2006-12-06 18:37 UTC (permalink / raw)
To: Michael Loeffler; +Cc: git
In-Reply-To: <1165429001.993.35.camel@ibook.zvpunry.de>
Michael Loeffler <zvpunry@zvpunry.de> writes:
>> Just a thought.
> I would prefer the following ways to do this globfetch stuff:
>
> 1.) The original refspec:
> Pull: refs/heads/master:refs/remotes/origin/master
>
> 2.) The one with "prefix match":
> Pull: refs/heads/:refs/remotes/origin/
>
> 3.) The one with extended regex:
> Pull: refs/heads/(.*):refs/remotes/origin/\1
Please, don't do regex when talking about paths. Uniformly
using fnmatch/glob is less confusing. I do not see anything
wrong with Andy's refspec glob we already have. Although I
agree that the second asterisk in "src/*:dst/*" has a certain
"Huh?" factor to UNIX-trained eyes, I think it is quite obvious
even to new people what it does.
Also, while I agree that (2) is logical and less typing, I would
avoid cases where foo and foo/ behave differently when "foo"
itself is a directory/tree like thing. Doing otherwise easily
invites mistakes.
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Junio C Hamano @ 2006-12-06 18:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el71tj$edm$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> 3.) The one with shell-like (fnmatch / glob) globbing
> Pull: refs/heads/*:refs/remotes/origin/*
>
> By the way, with globbing we really need some other way than
> first Pull: line to select remote head to merge on "git pull".
> For example "Merge:" line / remote.<name>.merge config var.
Why?
URL: some-where
Pull: refs/heads/master:refs/remotes/origin/master
Pull: refs/heads/*:refs/remotes/origin/*
works just fine.
But we should encourage people to use config to define default
merge source per-branch.
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Junio C Hamano @ 2006-12-06 19:01 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Florian Weimer
In-Reply-To: <87psax3qmb.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> * Eric Wong:
>
>> Florian Weimer <fw@deneb.enyo.de> wrote:
>>> * Eric Wong:
>>>
>>> > Does the following patch help?
>>>
>>> Don't think so. The issue is not timing-related. I've seen a failure
>>> every 1000 requests, which suggests to me that it's hitting the
>>> MaxKeepAliveRequests limit configured on the server.
>>
>> Actually, that's exactly what this patch should fix. git-svn restarts a
>> child every 1000 revisions to avoid memory usage from going through the
>> roof.
>
> Oh. My (limited) testing of the patch confirms that.
Ok, so this means I should apply this one, right?
-- >8 --
From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 4 Dec 2006 00:51:16 -0800
Subject: [PATCH] git-svn: avoid network timeouts for long-running fetches
Long-running fetches run inside children to avoid memory leaks.
When we refork, the connection in the parent can be idle for a
long time; attempting to reuse it in the next child can result
in timeouts.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d0bd0bd..747daf0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -459,6 +459,7 @@ sub fetch_lib {
$min = $max + 1;
$max += $inc;
$max = $head if ($max > $head);
+ $SVN = libsvn_connect($SVN_URL);
}
restore_index($index);
return { revision => $last_rev, commit => $last_commit };
--
1.4.4.1.g6129
^ permalink raw reply related
* Re: [RFC] gitweb: Add committags support (take 2)
From: Junio C Hamano @ 2006-12-06 19:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Pasky Baudis
In-Reply-To: <200612061351.02712.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> 1. Make it easier to have per repository gitweb configuration, for
> example by having gitweb configuration file in GIT_DIR for a project,
> "gitweb_conf.perl" by default:
>
> our $GITWEB_REPO_CONFIG = $ENV{'GITWEB_REPO_CONFIG'} ||
> "++GITWEB_CONFIG++";
> do "$projectroot/$project/$GITWEB_REPO_CONFIG"
> if -e "$projectroot/$project/$GITWEB_CONFIG";
I suspect site administrators would hesitate to have perl
scripts in repositories that could run arbitrary things as their
"side effects".
> 2. Put the configuration in config file, using/like %features support.
> For example gitweb.committags.<committag name> would hold parameters
> for <committag>. Committags sequence would be given by sequence of
> entries in config file. Comittags without options would have sole
> variable entry (which I think is equivalent to being bool variable
> and having 1 or 'yes' as value).
I think gitweb.* in $GIT_DIR/config and a config reader in Perl
are very sensible things to do, and you would need the config
reader eventually anyway. The longer we postpone it, the more
we risk the temptation to pollute $GIT_DIR/ with the likes of
"description", "owner", and "homepage", and I do not think we
want to make this worse.
> What do you think about it? Junio? Pasky?
If you are asking Pasky, you should CC him, I think. I added
him to the CC list.
^ permalink raw reply
* Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-06 19:24 UTC (permalink / raw)
To: Git Mailing List
I ask help to the list because my knowledge on this is not enough.
Currently qgit uses, socket based, QProcess class to read data from
'git rev-list' when loading the repository at startup.
The time it takes to read, without processing, the whole Linux tree
with this approach it's almost _double_ of the time it takes 'git
rev-list' to write to a file:
$git rev-list --header --boundary --parents --topo-order HEAD >> tmp.txt
We are talking of about 7s against less then 4s, on my box (warm cache).
So I have a patch to make 'git rev-list' writing into a temporary file
and then read it in memory, perhaps it's not the cleaner way, but it's
faster, about 1s less.
I have browsed Qt sources and found that QProcess uses internal
buffers that are then copied again before to be used by the
application. File approach uses a call to read() /fread() buired
inside the Qt's QFile class, and no intermediate buffers, so perhaps
this could be the reason the second way it's faster.
Anyway there are some issues:
1) File tmp.txt is deleted as soon as read, but this is not enough
sometimes to avoid a costly and wasteful write access to disk by the
OS. What is the easiest, portable way to create a temporary 'in memory
only' file, with no disk access? Or at least delay the HD write access
enough to be able to read and delete the file before the fist block of
tmp.txt is flushed to disk?
2) There is a faster/cleaner (and *safe* ) way to access directly 'git
rev-list' output, something like (just as an example):
$git rev-list --header --boundary --parents --topo-order HEAD >> /dev/mem
Or something similar, possibly _simple_ and _portable_ , so to be able
to copy the big amount of 'git rev-list' output just once (about 30MB
with current tree).
3) Other suggestions? ;-)
Thanks
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Shawn Pearce @ 2006-12-06 19:28 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612061124jcd0d94em47793710866776e7@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> The time it takes to read, without processing, the whole Linux tree
> with this approach it's almost _double_ of the time it takes 'git
> rev-list' to write to a file:
>
> 3) Other suggestions? ;-)
The revision listing machinery is fairly well isolated behind some
pretty clean APIs in Git. Why not link qgit against libgit.a and
just do the revision listing in process?
--
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Jakub Narebski @ 2006-12-06 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pasky Baudis
In-Reply-To: <7vveko3km4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> 2. Put the configuration in config file, using/like %features support.
>> For example gitweb.committags.<committag name> would hold parameters
>> for <committag>. Committags sequence would be given by sequence of
>> entries in config file. Comittags without options would have sole
>> variable entry (which I think is equivalent to being bool variable
>> and having 1 or 'yes' as value).
>
> I think gitweb.* in $GIT_DIR/config and a config reader in Perl
> are very sensible things to do, and you would need the config
> reader eventually anyway. The longer we postpone it, the more
> we risk the temptation to pollute $GIT_DIR/ with the likes of
> "description", "owner", and "homepage", and I do not think we
> want to make this worse.
By the way, what is the formal structure of the config file? Perhaps
something like the notation used in RFC?
Is it possible (and doesn't crash current git config parser) having
[gitweb]
blame = yes
pickaxe = no
snapshot = bzip2
[gitweb "committags"]
message-id = "http://news.gmane.org/find-root.php?message_id="
mantis = "http://bugs.or.cz/view.php?id="
url
sha1
in the config file?
--
Jakub Narebski
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-06 19:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List
In-Reply-To: <20061206192800.GC20320@spearce.org>
On 12/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> Marco Costalba <mcostalba@gmail.com> wrote:
> > The time it takes to read, without processing, the whole Linux tree
> > with this approach it's almost _double_ of the time it takes 'git
> > rev-list' to write to a file:
> >
> > 3) Other suggestions? ;-)
>
> The revision listing machinery is fairly well isolated behind some
> pretty clean APIs in Git. Why not link qgit against libgit.a and
> just do the revision listing in process?
>
Where can I found some documentation (yes I know RTFS, but...) or,
better, an example of using the API to read git-rev-list output?
if it is possible I also would like to avoid to mess with internal git
API's, of course *if it is possible* ;-)
Thanks
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Shawn Pearce @ 2006-12-06 19:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612061134r3725dcbu2ff2dd6284fcd651@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> On 12/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> >Marco Costalba <mcostalba@gmail.com> wrote:
> >> The time it takes to read, without processing, the whole Linux tree
> >> with this approach it's almost _double_ of the time it takes 'git
> >> rev-list' to write to a file:
> >>
> >> 3) Other suggestions? ;-)
> >
> >The revision listing machinery is fairly well isolated behind some
> >pretty clean APIs in Git. Why not link qgit against libgit.a and
> >just do the revision listing in process?
> >
>
> Where can I found some documentation (yes I know RTFS, but...) or,
> better, an example of using the API to read git-rev-list output?
builtin-rev-list.c. :-)
I think all you may need is:
#include "revision.h"
...
struct rev_info revs;
init_revisions(&revs, prefix);
revs.abbrev = 0;
revs.commit_format = CMIT_FMT_UNSPECIFIED;
argc = setup_revisions(argc, argv, &revs, NULL);
where argv just a char** of the arguments you were going to hand
to rev-list on the command line.
then get the data back:
static void show_commit(struct commit *commit)
{
const char * hex = sha1_to_hex(commit->object.sha1);
... copy from hex to your own structures ...
}
static void show_object(struct object_array_entry *p)
{
/* do nothing */
}
prepare_revision_walk(&revs);
traverse_commit_list(&revs, show_commit, show_object);
--
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Eric Wong @ 2006-12-06 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Florian Weimer
In-Reply-To: <7v64co4zo0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
>
> > * Eric Wong:
> >
> >> Florian Weimer <fw@deneb.enyo.de> wrote:
> >>> * Eric Wong:
> >>>
> >>> > Does the following patch help?
> >>>
> >>> Don't think so. The issue is not timing-related. I've seen a failure
> >>> every 1000 requests, which suggests to me that it's hitting the
> >>> MaxKeepAliveRequests limit configured on the server.
> >>
> >> Actually, that's exactly what this patch should fix. git-svn restarts a
> >> child every 1000 revisions to avoid memory usage from going through the
> >> roof.
> >
> > Oh. My (limited) testing of the patch confirms that.
>
> Ok, so this means I should apply this one, right?
Yes, please do. Thanks.
--
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Junio C Hamano @ 2006-12-06 19:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612062032.58706.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, what is the formal structure of the config file? Perhaps
> something like the notation used in RFC?
Is there an RFC for .INI format?
> Is it possible (and doesn't crash current git config parser) having
>
> [gitweb]
> blame = yes
> pickaxe = no
> snapshot = bzip2
>
> [gitweb "committags"]
> message-id = "http://news.gmane.org/find-root.php?message_id="
> mantis = "http://bugs.or.cz/view.php?id="
> url
> sha1
>
> in the config file?
If you are asking about [gitweb] stanza and (seemingly
overlapping) [gitweb "foo"] stanza, we already have prior
examples:
[diff]
color = auto
[diff "color"]
whitespace = blue reverse
so your example in the above would be legal (the dash in
'message-id' part might be questionable, though).
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Shawn Pearce @ 2006-12-06 19:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <20061206194258.GD20320@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> I think all you may need is:
>
> #include "revision.h"
> ...
You'll also need to call:
setup_git_directory();
before any of the below; but that should be done once per process.
> struct rev_info revs;
> init_revisions(&revs, prefix);
> revs.abbrev = 0;
> revs.commit_format = CMIT_FMT_UNSPECIFIED;
> argc = setup_revisions(argc, argv, &revs, NULL);
Although now that I think about it the library may not be enough
of a library. Some data (e.g. commits) will stay in memory forever
once loaded. Pack files won't be released once read; a pack recently
made available while the application is running may not get noticed.
Perhaps there is some fast IPC API supported by Qt that you could
use to run the revision listing outside of the main UI process,
to eliminate the bottlenecks you are seeing and remove the problems
noted above? One that doesn't involve reading from a pipe I mean...
--
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-06 20:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List
In-Reply-To: <20061206195142.GE20320@spearce.org>
On 12/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
> Perhaps there is some fast IPC API supported by Qt that you could
> use to run the revision listing outside of the main UI process,
> to eliminate the bottlenecks you are seeing and remove the problems
> noted above? One that doesn't involve reading from a pipe I mean...
>
Qt it's very fast in reading from files, also git-rev-list is fast in
write to a file...the problem is I would not want the file to be saved
on disk, but stay cached in the OS memory for the few seconds needed
to be written and read back, and then deleted. It's a kind of shared
memory at the end. But I don't know how to realize it.
Also let git-rev-list to write directly in qgit process address space
would be nice, indeed very nice.
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Shawn Pearce @ 2006-12-06 20:18 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612061208g6e4003e7ifa7dbd5ed69180c9@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> On 12/6/06, Shawn Pearce <spearce@spearce.org> wrote:
> >Shawn Pearce <spearce@spearce.org> wrote:
> >
> >Perhaps there is some fast IPC API supported by Qt that you could
> >use to run the revision listing outside of the main UI process,
> >to eliminate the bottlenecks you are seeing and remove the problems
> >noted above? One that doesn't involve reading from a pipe I mean...
> >
>
> Qt it's very fast in reading from files, also git-rev-list is fast in
> write to a file...the problem is I would not want the file to be saved
> on disk, but stay cached in the OS memory for the few seconds needed
> to be written and read back, and then deleted. It's a kind of shared
> memory at the end. But I don't know how to realize it.
On a modern Linux (probably your largest target audience) a small
file which has a very short lifespan (few seconds) is unlikey to
hit the platter. Most filesystems will put the data into buffer
cache and delay writing to disk because temporary files are so
common on UNIX.
Though our resident Linux experts may chime in with more details...
> Also let git-rev-list to write directly in qgit process address space
> would be nice, indeed very nice.
And ugly. :-)
SysV IPC (shared memory, semaphores) are messy and difficult to
get right. mmap against a random file in the filesystem tends
to work better on those systems which support it well, provided
that the file isn't on a network mount. But again you still need
semaphores or something like them to control access to the data in
the mmap'd region.
I was thinking that maybe if Qt had a bounded buffer available for
use between a process and its child, that you could use that to run
your own "qgit-rev-list" child and get the data back more quickly,
without the need for a temporary file. But it doesn't look like
they have one. Oh well.
Your current temporary file approach is probably the best you can
get, and has the simplest possible implementation. Doing better
would require linking against libgit.a, and getting the core Git
hackers to make at least the revision machinery more useful in a
library setting.
--
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Jakub Narebski @ 2006-12-06 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsaw3iyp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> By the way, what is the formal structure of the config file? Perhaps
>> something like the notation used in RFC?
>
> Is there an RFC for .INI format?
I don't think INI is standarized at all. The format of INI files is not
well defined. That's why I'd like to know exact format of git INI-like
config file format.
But what I meant was description of git config file in (used by RFCs)
augmented Backus-Naur Form (BNF) - RFC 4234.
>> Is it possible (and doesn't crash current git config parser) having
>>
>> [gitweb]
>> blame = yes
>> pickaxe = no
>> snapshot = bzip2
>>
>> [gitweb "committags"]
>> message-id = "http://news.gmane.org/find-root.php?message_id="
>> mantis = "http://bugs.or.cz/view.php?id="
>> url
>> sha1
>>
>> in the config file?
>
> If you are asking about [gitweb] stanza and (seemingly
> overlapping) [gitweb "foo"] stanza, we already have prior
> examples:
>
> [diff]
> color = auto
> [diff "color"]
> whitespace = blue reverse
>
> so your example in the above would be legal (the dash in
> 'message-id' part might be questionable, though).
That's what I was asking for. Thanks for an explanation.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Graham Percival @ 2006-12-06 21:02 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, hanwen, git
In-Reply-To: <20061206172450.GE1714@fieldses.org>
J. Bruce Fields wrote:
> We should start out with the assumption that a shared repo is already
> set up and make it:
>
> committing to a shared repository
> creating a shared repository
> importing a cvs archive
>
> which puts it in stuff-most-people-need-to-know to
> stuff-less-people-need-to-know order. Maybe the current introduction
> should even be postponed to later.
Yes, definitely!
I'm not complaining about changing to git, but Dscho's comment really
rings true:
> A developer, especially those whom Git is forced upon, have an
> attention span shorter than their pub1c hair.
I'm in the middle of exam period, I have a term papers to write, and I
have two weeks of lilypond bug reports and doc typos to process. I
don't care if git can do branches really nicely or walk my dog or cure
cancer. I can look at that stuff later -- right now I just want to fix
things and upload them.
Cheers,
^ 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