* Re: irc usage..
From: Linus Torvalds @ 2006-05-21 19:24 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <446FA262.7080900@gentoo.org>
On Sat, 20 May 2006, Donnie Berkholz wrote:
>
> I don't want to post the link publicly for a few reasons, including the
> huge amount of bandwidth it would suck up for lots of people to download
> it. I've sent it to you off-list, and if anyone else would also like it,
> please drop me a note.
Ok. It's still converting (that's a big archive), but it has passed the
cvsps stage without errors for me, and the conversion so far seems ok. But
it has only gotten to
Author: vapier <vapier> 2002-09-23 12:32:42
Changed GPL to GPL-2 in LICENSE and updated SRC_URI to use mirror:
so it has converted only slightly more than the first two years of
history in the roughly 30 minutes I've let it run. So it will take several
hours.
The reason it works for me is likely simply the fact that I had a few
patches to my cvsps already. I'm appending the stupid patches, I'm not
guaranteeing that they are correct at all, although the three _committed_
patches are almost certainly correct (and the last uncommitted one is
almost certainly totally broken). The patches are against clean cvsps 2.1.
Also, when I say "the conversion so far seems ok", I obviously don't
actually know what the hell the archive is supposed to look like, so I can
only say that the end result seems not totally insane.
To do a good conversion, you'll want to make sure that you have a author
name conversion file. See the "-A" flag in "git help cvsimport" (if you
have the man-pages installed).
Linus
---
commit 534120d9a47062eecd7b53fd7ac0b70d97feb4fd
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:20:59 2006 -0800
Increase log-length limit to 64kB
Yeah, it should be dynamic. I'm lazy.
---
cvsps_types.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cvsps_types.h b/cvsps_types.h
index b41e2a9..dba145d 100644
--- a/cvsps_types.h
+++ b/cvsps_types.h
@@ -8,7 +8,7 @@ #define CVSPS_TYPES_H
#include <time.h>
-#define LOG_STR_MAX 32768
+#define LOG_STR_MAX 65536
#define AUTH_STR_MAX 64
#define REV_STR_MAX 64
#define MIN(a, b) ((a) < (b) ? (a) : (b))
commit 82fcf7e31bbeae3b01a8656549e9b8fd89d598eb
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 11:23:37 2006 -0800
Improve handling of file collisions in the same patchset
Take the file revision into account.
---
cvsps.c | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 1e64e3c..c22147e 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2384,8 +2384,31 @@ void patch_set_add_member(PatchSet * ps,
for (next = ps->members.next; next != &ps->members; next = next->next)
{
PatchSetMember * m = list_entry(next, PatchSetMember, link);
- if (m->file == psm->file && ps->collision_link.next == NULL)
- list_add(&ps->collision_link, &collisions);
+ if (m->file == psm->file) {
+ int order = compare_rev_strings(psm->post_rev->rev, m->post_rev->rev);
+
+ /*
+ * Same revision too? Add it to the collision list
+ * if it isn't already.
+ */
+ if (!order) {
+ if (ps->collision_link.next == NULL)
+ list_add(&ps->collision_link, &collisions);
+ return;
+ }
+
+ /*
+ * If this is an older revision than the one we already have
+ * in this patchset, just ignore it
+ */
+ if (order < 0)
+ return;
+
+ /*
+ * This is a newer one, remove the old one
+ */
+ list_del(&m->link);
+ }
}
psm->ps = ps;
commit 3d1ebcef6b4f9f6c9064efd64da4dd30d93c3c96
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Wed Mar 22 17:20:20 2006 -0800
Fix branch ancestor calculation
Not having any ancestor at all means that any valid ancestor (even of
"depth 0") is fine.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cvsps.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index c22147e..2695a0f 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2599,7 +2599,7 @@ static void determine_branch_ancestor(Pa
* note: rev is the pre-commit revision, not the post-commit
*/
if (!head_ps->ancestor_branch)
- d1 = 0;
+ d1 = -1;
else if (strcmp(ps->branch, rev->branch) == 0)
continue;
else if (strcmp(head_ps->ancestor_branch, "HEAD") == 0)
uncommitted diff
Author: Linus Torvalds <torvalds@g5.osdl.org>
Probably totally broken dot counting
---
cvsps.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 2695a0f..2ad1595 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -2357,9 +2357,16 @@ static int revision_affects_branch(CvsFi
static int count_dots(const char * p)
{
int dots = 0;
+ int len = strlen(p);
- while (*p)
- if (*p++ == '.')
+ while (len > 2) {
+ if (memcmp(p+len-2, ".1", 2))
+ break;
+ len -= 2;
+ }
+
+ while (len)
+ if (p[--len] == '.')
dots++;
return dots;
@@ -2613,7 +2620,7 @@ static void determine_branch_ancestor(Pa
/* HACK: we sometimes pretend to derive from the import branch.
* just don't do that. this is the easiest way to prevent...
*/
- d2 = (strcmp(rev->rev, "1.1.1.1") == 0) ? 0 : count_dots(rev->rev);
+ d2 = count_dots(rev->rev);
if (d2 > d1)
head_ps->ancestor_branch = rev->branch;
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-05-21 19:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
[ This is sent to the kernel list as well, because I suspect
Eric's quiltimport matches the audience there and it deserves
a bit more exposure. "What's in git.git" is sometimes more
important and significant than [ANNOUNCE] messages, and this
is such a time. ]
* The 'maint' branch has these fixes since the last announcement.
Elrond:
git-cvsimport: Handle "Removed" from pserver
Fredrik Kuivinen:
Update the documentation for git-merge-base
Junio C Hamano:
merge-base: Clarify the comments on post processing.
* The 'master' branch has these since the last announcement, in
addition to the above.
- git-quiltimport (Eric W. Biederman)
This will probably see more enhancements over time taking
inputs from real quilt users.
- use config file to store remotes information (Johannes Schindelin)
- pack-objects further 15% improvements (Nicolas Pitre)
- "diff --check" (Johannes Schindelin)
- "git apply --cached"
- read-tree -m -u: do not overwrite or remove untracked working tree files.
- more built-in commands (Linus, Lukas, Timo and me)
- commit: allow --pretty= args to be abbreviated (Eric Wong)
- Other minor fixes to "git apply", "git diff".
- many cleanups from Sean Estabrooks, Shawn Pearce,
Remove unnecessary local in get_ref_sha1.
Reference git-check-ref-format in git-branch.
Elaborate on why ':' is a bad idea in a ref name.
Also Tilman Sauerbeck twisted my arm sufficiently enough that
I incorporated some of what I use to generate html/man pages
automatically every time I update "master" in the main
Makefile; so if I do not forget to update my release script,
there will be html/man documentation tarballs next to the
usual source tarball release when 1.4.0 release is done.
* The 'next' branch, in addition, has these.
- built-in "git add/rm" (Linus)
Will merge to "master" shortly, unless somebody finds
breakage soon enough.
- built-in "git format-patch" (Johannes Schindelin)
Will merge to "master" shortly, unless somebody finds
breakage soon enough.
- "git tar-tree --remote"
This change itself is low-impact and while it is not a
substitute for true shallow/lazy clone people may find it
useful in other scenarios. I dunno.
- cache-tree with read-tree/write-tree --prefix
I haven't made any progress on this one, but haven't been
bitten by it either, so it is a good sign.
* The 'pu' branch, in addition, has these.
Eric Wong:
git-svn: ignore expansion of svn:keywords [test patch]
Sean Estabrooks:
Remove possible segfault in http-fetch.
Shawn Pearce:
Improve abstraction of ref lock/write.
Convert update-ref to use ref_lock API.
Log ref updates to logs/refs/<ref>
Support 'master@2 hours ago' syntax
Fix ref log parsing so it works properly.
General ref log reading improvements.
Added logs/ directory to repository layout.
Force writing ref if it doesn't exist.
Log ref updates made by fetch.
Change 'master@noon' syntax to 'master@{noon}'.
Correct force_write bug in refs.c
Change order of -m option to update-ref.
Include ref log detail in commit, reset, etc.
Create/delete branch ref logs.
Enable ref log creation in git checkout -b.
^ permalink raw reply
* Re: [PATCH] compress output of `cd' when installing templates
From: Junio C Hamano @ 2006-05-21 18:23 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, Gang Chen
In-Reply-To: <20060521185421.a91bf118.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Gang Chen <goncha.ml@gmail.com> wrote:
>
>> When CDPATH is set in Bash, `cd' writes new working directory to
>> stdout, which corrupts output of `tar cf - .'.
>
> Fix bash instead, or just don't export CDPATH. It is used by bash only
> so exporting it is unnecessary.
Thanks.
It is not just unnecessary, but "export CDPATH" anywhere in your
rc scripts is actively *WRONG*.
^ permalink raw reply
* Re: synchronizing incremental git changes to cvs
From: Junio C Hamano @ 2006-05-21 18:21 UTC (permalink / raw)
To: Jim Meyering; +Cc: git, Martin Langhoff
In-Reply-To: <87mzdcjqey.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> I'd like to develop using git, and have a commit hook mirror the
> day-to-day changes (tags/commits) made in the git repo to a
> cvs repository. The idea is that the only way changes get into
> the cvs repo is via the git commit hook.
I do not use the automated tools myself, but I sync the day-job
work in my git repository to CVS at work. I do not develop with
CVS but use it merely as a publishing medium. Although other
people can make commits into CVS in which case I have to slurp
the change back into my git repository.
(0) Bootstrap. I did use git-cvsimport myself (this repository
started before the tool was written). Instead:
. cvs checkout the tip of the CVS development history
. "git init-db", edit .gitignore to ignore CVS, and "git
add ."
. "git commit -m epoch"; the git side of development
history in this repository starts at that point for me.
. "git branch origin"; the tip of CVS repository is kept
track of with this branch. I work in "master".
I think I could have done the above with git-cvsimport,
(1) Beginning of the day. In case other people did work on
the CVS side, I do this:
. "git checkout origin", "cvs -q update". If there is no
change, go to step (3).
. add any new files with "git add", and update the "origin"
branch with "git commit -a -m 'from CVS'".
(2) Merge other's work into my git master branch.
. "git checkout master" and "git pull . cvs"; conflict
resolve as needed.
(3) Do my work.
. "git checkout master" if I haven't done so.
. hack away, grow "master" branch using full power of git
including the use of topic branches etc.
(4) Publish, when "master" changes are ready.
. To avoid conflicts with other people working on CVS,
perform (1) again to make sure "origin" matches the tip
of CVS.
. "git checkout origin", "git pull . master".
. generate the consolidated log I am about to push back to
CVS with "git log --no-merges ORIG_HEAD.. | git shortlog >L".
. add any new files with "cvs add", and "cvs commit -F L"
. go back to (3) and continue.
This can be extended to multiple CVS branches. Per one CVS
branch, use one git branch to track its head (plays the role of
"origin" in the above), use another to do the real development
for that branch ("master" in the above). Never use merges on
the CVS side, but perform merges on the git side and then
pushing the merge result back to CVS. This frees you from the
nightmarish branch management.
The above obviously have advantages and disadvantages.
. I do not use any git import tool, so in theory you can apply
this to _any_ foreign SCM.
. I treat the foreign SCM as a second class citizen; multiple
commits made there are rolled into a single commit on the git
side (the real project history as far as I am concerned),
which may or may not be nice. The people who see my work
through CVS see multiple commits on git side as a single
commit in CVS.
In my situation this is fine as is, but I think you could leave
the management of "origin" to git-cvsimport (then your working
tree would not have CVS metadirectories as the above outline
does) if you wanted to avoid the "rolled into one commit" issue.
Pushing the changes on the git side back to CVS may become
trickier (and that is why I still keep the above setup without
using git-cvsimport), as I do not offhand know how exportcommit
works. The commits on the git side you would want to push back
are the ones on "master" but not on "origin", which you can get
from "git rev-list origin..master", so I presume if you feed
that to exportcommit things all magically work?
By the way, I met Paul a few days ago and he mentioned that you
have some quick audit results on our code from your evaluation.
Can we expect fixes or at least pointing-out-problems from you
sometime soon please?
^ permalink raw reply
* Re: how to display file history?
From: Jonas Fonseca @ 2006-05-21 17:35 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Junio C Hamano, Brown, Len, git
In-Reply-To: <m164k76ylb.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman <ebiederm@xmission.com> wrote Mon, May 15, 2006:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Mon, 15 May 2006, Eric W. Biederman wrote:
> > People still don't seem to realize how flexible (and powerful) the git
> > revision specifications are. It's not just limiting by path, all of these
> > work on _all_ of the "history tools" (whether they be gitk, qgit, "git
> > log", "git whatchanged" or your own home-cooked stuff):
> >
> > [examples]
>
> But regardless of where we put it, it needs to be documented someplace
> besides in the email so you don't need to read the code to see that
> the option is there.
I've put some of this on http://git.or.cz/gitwiki/RevisionSpecification
that for now may serve as an introduction ...
--
Jonas Fonseca
^ permalink raw reply
* Re: synchronizing incremental git changes to cvs
From: Jim Meyering @ 2006-05-21 16:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605201709n3a840fd9n7e85a289f49a3c5f@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> wrote:
> git-cvsserver is the word. It currently tracks the git repo itself
> pretty well (perfectly, AFAICS) and it also tracks a git tree that is
> actually imported daily from CVS -- doing
>
> CVSrepo ->cvsimport -> GIT -> cvsserver -> CVS checkout
Thanks, but I'd rather do primary development directly using git,
rather than with CVS.
^ permalink raw reply
* Re: [PATCH] compress output of `cd' when installing templates
From: Timo Hirvonen @ 2006-05-21 15:54 UTC (permalink / raw)
To: Gang Chen; +Cc: git
In-Reply-To: <83mzdbjshd.fsf@skypiea.yi.org>
Gang Chen <goncha.ml@gmail.com> wrote:
> When CDPATH is set in Bash, `cd' writes new working directory to
> stdout, which corrupts output of `tar cf - .'.
Fix bash instead, or just don't export CDPATH. It is used by bash only
so exporting it is unnecessary.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [PATCH] compress output of `cd' when installing templates
From: Gang Chen @ 2006-05-21 15:41 UTC (permalink / raw)
To: GIT
When CDPATH is set in Bash, `cd' writes new working directory to
stdout, which corrupts output of `tar cf - .'.
Signed-off-by: Gang Chen <goncha.ml@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/templates/Makefile b/templates/Makefile
index 8f7f4fe..cb67489 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -44,5 +44,5 @@ clean:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(template_dir))
- (cd blt && $(TAR) cf - .) | \
+ (cd blt > /dev/null && $(TAR) cf - .) | \
(cd $(call shellquote,$(DESTDIR)$(template_dir)) && $(TAR) xf -)
--
If it makes you happy, it can't be that bad.
^ permalink raw reply related
* First tarball release of qgit with tabs
From: Marco Costalba @ 2006-05-21 14:29 UTC (permalink / raw)
To: git
This is qgit1.3rc1
Rewritten a big chunk of UI code and added support for tabbed views
and powerful key bindings. Now should be far easier and quick to
browse through patches.
1.3 release will be mainly about user friendliness. Any suggestion,
comment and of course bug is, as usual, greatly appreciated.
Detailed changelog in shipped file or directly through public git repo.
Note: Sourceforge seems to have some download problem today!
Marco
Download
--------------
Git archive is at
http://digilander.libero.it/mcostalba/scm/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
Install
--------
git 1.3.0 is required.
To install from tarball:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
^ permalink raw reply
* Re: synchronizing incremental git changes to cvs
From: Jim Meyering @ 2006-05-21 13:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605210104470.3148@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 21 May 2006, Jim Meyering wrote:
>
>> Why am I interested? I want to switch the development of GNU coreutils
>> from cvs to git. I would also like to continue making the repository
>> available via cvs, for the sake of continuity. At worst, I can always
>> cut the CVS cord, but that's a last resort.
>
> If you only want to make a cvs repository available for tracking the
> project, git-cvsserver is what you want. It is even faster than the
> original cvs...
That might work if I had sufficient access to the system hosting the
public CVS repository. But there are restrictions (like no ssh access).
Currently I rsync the master repo to an intermediate site, from which
it is periodically pulled by savannah. Paranoia on both sides.
If I end up leaving savannah, can someone propose a good site,
i.e., secure, yet with git and rsync access?
I haven't made the leap to git yet, but git-cvsimport (from git-1.3.2)
seems to do a very good job of converting the cvs module (89MB).
FYI, here are some stats on the resulting git repository:
Size (nothing repacked):
1051MB (du -sh, actual, on reiserfs 3)
708MB (du --apparent-size)
Size repacked, (via git-repack -a -d && git-prune-packed)
65MB (du --si -s)
20k+ patchsets (counted by cvsps)
40k+ revisions (counted by cvs ... rlog cu|grep -c '^revision')
While repacking, git said something about more than 100K objects.
There were 120K files under .git/ before repacking.
^ permalink raw reply
* Re: [idea] Converting sha1 evaluator into parser/interpreter
From: Jakub Narebski @ 2006-05-21 10:13 UTC (permalink / raw)
To: git
In-Reply-To: <e4p71u$t0s$1@sea.gmane.org>
Jakub Narebski wrote:
> Shawn Pearce wrote:
>
>> There was just a short conversation on #git about converting
>> the sha1 expression evaluator into a split parser/interpreter
>> model. The idea here would be to convert an expression such as
>>
>> HEAD@{yesterday}~3^{tree}
>>
>> into a an expression tree such as (in LISP style):
>>
>> (peel-onion (walk-back 3 (date-spec yesterday (ref HEAD))))
>>
>> with such a tree it is relatively easy to evaluate the expression,
>> but its also easy to determine if a ref name is valid. Just pass
>> it through the parser and see if you get back anything more complex
>> then '(ref <input>)'.
>
> Didn't you meant to see if we get correct tree (not a forest),
> and if the root of said tree is '(ref <commit-ish>)' [1]?
I'm sorry. Of course branch names (ref names) should be limited to the ones
that doesn't make problems for the parser, i.e. they should parse to single
element parse tree:
<input> ---parses to---> (ref <input>)
and doesn't give problems for other parsers (e.g.commit list parser
including '^A B' and 'A..B'; remotes branch mapping parser 'srcref:destref'
and '+srcref:destref') and shell (e.g. globbing).
P.S. Hmmm... is '--' branch name (heads/--) possible?
P.P.S. Would branch name which include '!' and/or '$' cause trouble?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: irc usage..
From: Thomas Glanzmann @ 2006-05-21 9:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Donnie Berkholz, Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605201543260.3649@g5.osdl.org>
Hello Linus,
> and I'm a humanitarian - rescuing people from CVS is
> to me not just a good idea, it's a moral imperative.
you're a very brave man.
Thomas
^ permalink raw reply
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Junio C Hamano @ 2006-05-21 9:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060519091716.GM22257@spearce.org>
I've swallowed all 10 and pushed them out in "pu", but could you
add tests to check the Porcelainish commands you touched with
this series to make sure they all log correctly?
BTW, I noticed that a patch earlier in the series depended on
something not in "master" (it's rfc2822_date from js/fmt-patch
series). Generally I do not want to make a branch hostage of
another branch by introducing a dependency, but for now I'll
pull in early part of js/fmt-patch branch into sp/reflog branch
and see what happens.
If sp/reflog branch graduates to the "master" first, it will
pull early parts of js/fmt-patch along with it, but the built-in
will be called "git fmt-patch" in the result, so it wouldn't
affect the use of "git format-patch".
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Junio C Hamano @ 2006-05-21 9:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060521084313.GA12825@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> What do you suggest for this performance issue, then?
> A manual no-delta trigger, or just going to get a cup of coffee while
> pushing (my tests showed 5-6x slowdown from deltifying)?
In the short term, give --depth to send-pack, would be better
than nothing.
I agree we should be able to do better. But let me grab some
sleep now first ;-).
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Jakub Narebski @ 2006-05-21 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060521084403.GB12825@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, May 21, 2006 at 10:24:37AM +0200, Jakub Narebski wrote:
>
>> Hmmm... isn't the patch slightly against git coding style?
>
> Oops, yes (though the point is moot since the patch is conceptually
> wrong). Is there a git coding style document somewhere?
Not that I know of. It's better to follow the coding style used
in the rest of files.
Besides, differentiating between
if (condition)
and
function(argument);
makes IMVHO sense.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Junio C Hamano @ 2006-05-21 9:14 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060521084403.GB12825@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, May 21, 2006 at 10:24:37AM +0200, Jakub Narebski wrote:
>
>> Hmmm... isn't the patch slightly against git coding style?
>
> Oops, yes (though the point is moot since the patch is conceptually
> wrong). Is there a git coding style document somewhere?
When in doubt, please follow the kernel coding style ;-).
^ permalink raw reply
* Re: [PATCH] Reference git-check-ref-format in git-branch.
From: Junio C Hamano @ 2006-05-21 9:07 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060521015446.GA7605@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Sorry about this patch being built on pu. It clearly has no
> relationship to current pu, but the new -l appears in the hunk
> below...
"am -3 -s -u" is how I handle patches anyway, and it did not
have much trouble backporting it to the tip of "master".
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Jeff King @ 2006-05-21 8:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4p83e$uqt$1@sea.gmane.org>
On Sun, May 21, 2006 at 10:24:37AM +0200, Jakub Narebski wrote:
> Hmmm... isn't the patch slightly against git coding style?
Oops, yes (though the point is moot since the patch is conceptually
wrong). Is there a git coding style document somewhere?
-Peff
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Jeff King @ 2006-05-21 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlksvzsmd.fsf@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 01:31:22AM -0700, Junio C Hamano wrote:
> We do not delta an otherwise perfectly deltifiable object if its
> delta base happens to be at the depth edge in the original pack.
> So no, we do _NOT_ know if it is not worth it merely from the
> fact that it is not deltified in the existing pack. And the
Yes, you're right. What do you suggest for this performance issue, then?
A manual no-delta trigger, or just going to get a cup of coffee while
pushing (my tests showed 5-6x slowdown from deltifying)?
-Peff
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Junio C Hamano @ 2006-05-21 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060521081435.GA4526@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, May 20, 2006 at 11:17:42PM -0700, Junio C Hamano wrote:
>
>> base delta for that object to skip computation". What you want
>> here is "if the object we are going to send is not a delta in
>> the source, and there are sufficient number of other objects the
>> object could have been deltified against, then it is very likely
>> that it was not worth deltifying when it was packed; so it is
>> probably not worth deltifying it now".
>
> I think we can make a stronger statement in many cases: "if the object
> we are going to send is not a delta in the source, and there are no
> other objects it could be deltified against, then it is not worth
> deltifying." That is, in the case that we just packed we KNOW that it's
> not worth it, since we're not sending anything that isn't already
> packed.
Careful.
We do not delta an otherwise perfectly deltifiable object if its
delta base happens to be at the depth edge in the original pack.
So no, we do _NOT_ know if it is not worth it merely from the
fact that it is not deltified in the existing pack. And the
latter part of your test "there are no other objects it could be
deltified against" is either expensive (you have to try first to
see if that is the case to really see it) or stupid (you just
assume there is no suitable delta base without looking at other
objects like we currently do).
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Jakub Narebski @ 2006-05-21 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <87y7wyv72m.fsf@morpheus.hq.vtech>
David Kågedal wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
[...]
>> So from the user's point of view, 'branch' is simply _named line of
>> development_. Refer to topic and tracking branches.
>
> But the definition of 'branch' in git is quite different from the
> definition in CVS or many other systems. It CVS, each revision
> (commit) belongs to a branch, and the branch is a linear sequence of
> revisions, not a full DAG. In git, a commit doesn't really "belong"
> in any specific branch.
>
> So, while it makes sense to describe branches as "lines of
> development" in general terms, it is also important to note the
> specific meaning of 'branch' in the context of git; i.e. as the
> history of a single head commit.
We can always say that branch is 1-st parent linear history of head branch,
up to unmarked but computable branching/fork/creation point, i.e.
{i = 0..N: branch-head~i}
where N is the length of the branch.
BTW. HEAD~0 == HEAD, isn't it?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Jakub Narebski @ 2006-05-21 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060521081435.GA4526@coredump.intra.peff.net>
Jeff King wrote:
Hmmm... isn't the patch slightly against git coding style?
> + if(unpacked)
[...]
>+ for(i = 0; i < len; i++)
compare to:
> for (ref = refs; ref; ref = ref->next) {
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 2/2] Add builtin "git rm" command
From: Junio C Hamano @ 2006-05-21 8:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605191607580.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think the new behaviour is strictly an improvement, but perhaps more
> importantly, it is _different_. As a special case, the semantics are
> identical for the single-file case (which is the only one our test-suite
> seems to test).
>
> The other question is what to do with leading directories. The old "git
> rm" script didn't do anything, which is somewhat inconsistent. This one
> will actually clean up directories that have become empty as a result of
> removing the last file, but maybe we want to have a flag to decide the
> behaviour?
I too think these are improvements. Thanks for the patch.
BTW, this needed another "evil merge" into "next", so this time
I made a separate evil merge branch that I speculated as a
possibly better alternative approach in an earlier message.
^ permalink raw reply
* Re: [RFC] send-pack: allow skipping delta when sending pack
From: Jeff King @ 2006-05-21 8:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7wvx5o9.fsf@assigned-by-dhcp.cox.net>
On Sat, May 20, 2006 at 11:17:42PM -0700, Junio C Hamano wrote:
> base delta for that object to skip computation". What you want
> here is "if the object we are going to send is not a delta in
> the source, and there are sufficient number of other objects the
> object could have been deltified against, then it is very likely
> that it was not worth deltifying when it was packed; so it is
> probably not worth deltifying it now".
I think we can make a stronger statement in many cases: "if the object
we are going to send is not a delta in the source, and there are no
other objects it could be deltified against, then it is not worth
deltifying." That is, in the case that we just packed we KNOW that it's
not worth it, since we're not sending anything that isn't already
packed.
Following this logic, I believe we could always turn off deltification
if there are no loose objects. It seems a bit special case, but it
optimizes the "repack -d then push" workflow which I suspect may be
relatively common.
The patch below runs git-rev-list with --unpacked; if there are no
objects returned, it tells pack-objects to set depth=0 (is that really
what we want? It's OK to use existing deltas; we just don't want to
compute any new ones. I'm not sure how --depth behaves in that respect).
-Peff
---
f3e7fb4a5025cc8157557f3da6f9dc7d0a89395f
send-pack.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 58 insertions(+), 14 deletions(-)
f3e7fb4a5025cc8157557f3da6f9dc7d0a89395f
diff --git a/send-pack.c b/send-pack.c
index 409f188..0bddc0a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -25,18 +25,7 @@ static int is_zero_sha1(const unsigned c
return 1;
}
-static void exec_pack_objects(void)
-{
- static const char *args[] = {
- "pack-objects",
- "--stdout",
- NULL
- };
- execv_git_cmd(args);
- die("git-pack-objects exec failed (%s)", strerror(errno));
-}
-
-static void exec_rev_list(struct ref *refs)
+static void exec_rev_list(struct ref *refs, int unpacked)
{
struct ref *ref;
static const char *args[1000];
@@ -47,6 +36,8 @@ static void exec_rev_list(struct ref *re
args[i++] = "--objects-edge";
else
args[i++] = "--objects";
+ if(unpacked)
+ args[i++] = "--unpacked";
/* First send the ones we care about most */
for (ref = refs; ref; ref = ref->next) {
@@ -85,6 +76,59 @@ static void exec_rev_list(struct ref *re
die("git-rev-list exec failed (%s)", strerror(errno));
}
+static int rev_list_loose_objects(struct ref *refs)
+{
+ int fd[2];
+ pid_t pid;
+
+ if(pipe(fd) < 0)
+ die("rev-list setup: pipe failed");
+ pid = fork();
+ if(pid < 0)
+ die("rev-list setup: fork failed");
+ if(!pid) {
+ dup2(fd[1], 1);
+ close(fd[0]);
+ close(fd[1]);
+ exec_rev_list(refs, 1);
+ die("rev-list failed");
+ }
+ close(fd[1]);
+ return fd[0];
+}
+
+static int count_loose_objects(struct ref *refs)
+{
+ int fd = rev_list_loose_objects(refs);
+ unsigned count = 0;
+ char buf[4096];
+ int len;
+
+ while((len = read(fd, buf, sizeof buf)) > 0) {
+ int i;
+ for(i = 0; i < len; i++)
+ if(buf[i] == '\n')
+ count++;
+ }
+ if(len < 0)
+ die("rev-list read failed");
+ return count;
+}
+
+static void exec_pack_objects(struct ref *refs)
+{
+ static const char *args[] = {
+ "pack-objects",
+ "--stdout",
+ NULL,
+ NULL
+ };
+ if(count_loose_objects(refs) == 0)
+ args[2] = "--depth=0";
+ execv_git_cmd(args);
+ die("git-pack-objects exec failed (%s)", strerror(errno));
+}
+
static void rev_list(int fd, struct ref *refs)
{
int pipe_fd[2];
@@ -99,7 +143,7 @@ static void rev_list(int fd, struct ref
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
- exec_pack_objects();
+ exec_pack_objects(refs);
die("pack-objects setup failed");
}
if (pack_objects_pid < 0)
@@ -108,7 +152,7 @@ static void rev_list(int fd, struct ref
close(pipe_fd[0]);
close(pipe_fd[1]);
close(fd);
- exec_rev_list(refs);
+ exec_rev_list(refs, 0);
}
static int pack_objects(int fd, struct ref *refs)
--
1.3.3.gf1cf-dirty
^ permalink raw reply related
* Re: [idea] Converting sha1 evaluator into parser/interpreter
From: Jakub Narebski @ 2006-05-21 8:06 UTC (permalink / raw)
To: git
Shawn Pearce wrote:
> There was just a short conversation on #git about converting
> the sha1 expression evaluator into a split parser/interpreter
> model. The idea here would be to convert an expression such as
>
> HEAD@{yesterday}~3^{tree}
>
> into a an expression tree such as (in LISP style):
>
> (peel-onion (walk-back 3 (date-spec yesterday (ref HEAD))))
Rather
(peel-onion 'tree (walk-back 3 (date-spec yesterday (ref HEAD))))
> with such a tree it is relatively easy to evaluate the expression,
> but its also easy to determine if a ref name is valid. Just pass
> it through the parser and see if you get back anything more complex
> then '(ref <input>)'.
Didn't you meant to see if we get correct tree (not a forest),
and if the root of said tree is '(ref <commit-ish>)' [1]?
Interpreting said parse tree anch checking if it folds to correct object
reference is the task of interpreter, not parser...
[*1*] if I understand currectly that <commit-ish> mean direct sha1,
shortened sha1, or ref (head or tag)? commit-ish is not in
git glossary...
--
Jakub Narebski
Warsaw, Poland
^ 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