* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 16:54 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:
> -YFLAGS=-d
> +YFLAGS=-d -l
> +LFLAGS=-l
Works for me too; thanks for the fix.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Junio C Hamano @ 2006-04-03 17:23 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <443146EC.7060704@gentoo.org>
Daniel Drake <dsd@gentoo.org> writes:
> I maintain a small git repo. I upload it over ssh (with git-push) to a
> machine where it is distributed over http:
>
> http://dsd.object4.net/git/zd1211.git/
>...
> I have tried running git-prune and git-update-server-info, but that
> doesn't help.
>
> Any ideas?
My standard answer would be
http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
http-server$ GIT_DIR=. git-update-server-info
but you said you have run it already... Can you try to see if
there is some caching proxy involved that still serves stale
info/refs file?
client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-03 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Drake, git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 10:23:22AM -0700, Junio C Hamano wrote:
> My standard answer would be
>
> http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
> http-server$ GIT_DIR=. git-update-server-info
Is there any interest in making the HTTP transport slighly less dumb by
using DAV?
I have a working patch to http-fetch that tries to use PROPFIND to get a
remote pack list and falls back to using objects/info/packs. It's
feasible to do something similar to get a remote ref list when cloning,
although that's a bit more work as all refs would have to be fetched
into a local repo and parsed to determine the object type.
Long term, this could give a repo admin the choice of either making sure
git-update-server-info has been run after every ref/pack change or
enabling DAV once. Assuming they need to use HTTP.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
Ah, should have known. I am behind a (lame) transparent proxy on port 80.
I opened that file in my web browser and it showed the old heads. After
a force-refresh (ctrl+F5, which sends some additionally http headers to
refresh the page from the real server), the old heads disappeared, and
git now clones successfully.
git-http-fetch should probably send those extra headers too. I'll try to
find some time to look at this next week.
Thanks!
Daniel
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q1bglkp.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Apr 2006, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>> No problem. That's only an eye-issue though, since the diff is still a
>> valid diff according to its definition where D=A-B => B+D==A && A-D==B
>> From the day I released 0.18, xregression is continuosly running w/out
>> any issue. I'll check it out though ...
>
> There is another to report, when ctxlen == 0.
>
> Between the attached files "diff -u0 8f352aa dd40a03", the
> header for a hunk with only inserted lines misidentify the
> original location.
>
> For example, the first hunk says:
>
> @@ -0,0 +6 @@
> +#include "diff.h"
>
> Which is inconsistent with what GNU diff says:
>
> @@ -5,0 +6 @@
> +#include "diff.h"
>
> I've tried this patch but it is not right; the diff between the
> attached two files show a 47-line hunk that inserts at line 400,
> then the next 6-line hunk inserts at line 401 which is obviously
> bogus.
>
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index afaada1..3e7f999 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -244,7 +244,7 @@ int xdl_emit_hunk_hdr(long s1, long c1,
> memcpy(buf, "@@ -", 4);
> nb += 4;
>
> - nb += xdl_num_out(buf + nb, c1 ? s1: 0);
> + nb += xdl_num_out(buf + nb, c1 ? s1 : (s1-1));
>
> if (c1 != 1) {
> memcpy(buf + nb, ",", 1);
The fix is fine, but you should do the same even in the s2 case. The
correct hunk should have been:
@@ -6,0 +6 @@
because the lines are actually inserted at the 6th position, but patch
handle its own special 0 count case by adding 1 to the position, so I had
to change even the xpatchi.c code. The 0-context diffs are pretty
dangerous though, since in case of purely added hunks, patch has no way to
verify the orig-file position by matching contexts.
Now I'll take a look at the pre-diff optimization issue ...
- Davide
--- xdiff/xpatchi.c
+++ xdiff/xpatchi.c
@@ -162,9 +162,9 @@
* We start from zero, so decrement by one unless it's the special position
* '0' inside the unified diff (new or deleted file).
*/
- if (hki->s1 > 0)
+ if (hki->s1 > 0 && hki->c1 > 0)
hki->s1--;
- if (hki->s2 > 0)
+ if (hki->s2 > 0 && hki->c2 > 0)
hki->s2--;
return 0;
--- xdiff/xutils.c
+++ xdiff/xutils.c
@@ -537,7 +537,7 @@
memcpy(buf, "@@ -", 4);
nb += 4;
- nb += xdl_num_out(buf + nb, c1 ? s1: 0);
+ nb += xdl_num_out(buf + nb, c1 ? s1: s1 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
@@ -547,7 +547,7 @@
memcpy(buf + nb, " +", 2);
nb += 2;
- nb += xdl_num_out(buf + nb, c2 ? s2: 0);
+ nb += xdl_num_out(buf + nb, c2 ? s2: s2 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-03 19:37 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think we can conclude from this:
>
> - this is not impossible using the current model, and some extra
> useful information can be seen in the tree that shows more real
> dependency information and relationships between individual commits
>
> - doing automatic n-head creation would probably be madness, as
> far too many useless heads are created (though it is almost
> guaranteed that supporting 'patch commuting' a la darcs would
> make this *even worse* as it would mean that you could potentially
> have even more heads)
I suspect people have hard time grasping _why_ you are jumping
through hoops. At least I do. What problem are you trying to
solve? You perhaps described your mechanism well enough, but it
is not quite clear to me what kind of operations are made easier
with this exercise, against which possible downside of it, if
any, would be judged.
> - the current tools make this style of development difficult.
Git was born from necessity, and we have been aiming to have
tools to do what are commonly needed. It is not surprising to
see existing tools do not support modes of operations that are
"unusual" (meaning, things we have not done with git so far).
Also we do not tend to do things only because we can.
Now admittably I am guilty of having done a few things only
because we can. Octopus is an example. Making an Octopus only
because you can does not buy you much, other than its coolness
value, and it would make exporting the history to other SCMs
somewhat harder I suspect, and it makes bisecting more
expensive [*1*].
For example, the point jdl raised during the discussion is far
easier to understand. When working on multiple topics, he often
needs to test them as a whole, so he pulls them into a test
branch (can be a throwaway branch). When he needs to do fixups,
it is most efficient to do compile/run test while still in the
test branch, but after things test out, in order to keep
logically different things separate, he needs to go back to
relevant topic branches and make a commit. This is painful --
are there ways to make this easier [*2*]?
Would patch commutation calculus help with his problem?
I suspect patch commutation could be used to solve his problem,
but if it does not, it does not mean what you are trying to do
with hydra is not interesting. It just means from your
descriptions it is not clear what real problems hydra is trying
to solve, and I misunderstood that it is related to his problem
(just like jdl did, I suspect).
So can you step back a bit and start from describing what
problem you are trying to solve, before describing the
mechanisms you think would help?
One thing I can think of that could potentially come out of your
approach would be an alternative implementation of what StGIT
does. Inside a local developer repository, being able to
reorder patches and rewrite them flexibly is very useful.
While I agree with Linus's reaction "I want my merges fast", I
am not necessarily so negative about the approach. For example,
if you use it only as a tool to reorder and clean-up local
development history to a presentable form (IOW, using hydra to
manage your development, but the result exposed to the outside
world is exported from that hydra into a more linear form, that
does not give other people a heart attach when they look at the
ancestry graph in gitk), you would not negatively affect other
people who work with you.
[Footnote]
*1* Do not get me wrong. Octopus is sometimes the most natural
way to express what happened, but the case it applies to is
quite narrowly defined -- to merge in independent branches that
happened to mature at the same time together. So the tool
discourages you from making an Octopus that is not trivial,
deliberately.
*2* I see two approaches, the more obvious being "git checkout
-m that-topic". Just edit (but not update-index) on top of
test, have "checkout -m" adjust your changes to the topic branch
you want to commit to, make a commit there, and then come back
to the test branch, and merge the topic branch again.
Another obvious strategy would be to make commits on top of
"test" and then cherry-pick them back on top of the relevant
topics later.
topicA You have three topics
o---o you need to test together...
/
---o---o topicB
\
o---o
topicC
==>
topicA So merge them up and start testing.
o---o
/ \
---o---o---T
\ /
o---o
topicB
==>
topicA But you find problems, and fix them
o---o up as you go along...
/ \
---o---o---T---1---2
\ /
o---o
topicB
==>
topicA Later you cherry-pick them into
o---o---1' relevant topics.
/
---o---o topicB
\
o---o---2'
topicC
==>
topicA Next round of test will continue
o---o---1' by rebuilding the test branch
/ \
---o---o-------T
\ /
o---o---2'
topicC
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
On Mon, 3 Apr 2006, Davide Libenzi wrote:
> On Mon, 3 Apr 2006, Junio C Hamano wrote:
>>
>> I've tried this patch but it is not right; the diff between the
>> attached two files show a 47-line hunk that inserts at line 400,
>> then the next 6-line hunk inserts at line 401 which is obviously
>> bogus.
That's fine, since that's orig file position *before* the insert. Try the
same with GNU diff and you should see the same. Also try to create a diff
with libxdiff (with the fix) and feed it to GNU patch.
- Davide
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-03 20:01 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
Davide Libenzi <davidel@xmailserver.org> writes:
>> For example, the first hunk says:
>>
>> @@ -0,0 +6 @@
>> +#include "diff.h"
>>
>> Which is inconsistent with what GNU diff says:
>>
>> @@ -5,0 +6 @@
>> +#include "diff.h"
>>
>> I've tried this patch but...
>
> The fix is fine, but you should do the same even in the s2 case. The
> correct hunk should have been:
>
> @@ -6,0 +6 @@
You are right. GNU says -5,0 not -6,0 so presumably "patch"
other people use expect it to say -5,0 not -6,0; even though we
could argue the insertion happens at 6th position and saying
-6,0 is more logical, it does not matter -- what incumbent does
wins X-<. I notice that your fix shows -5,0 to match it ;-).
Thanks for the fix.
^ permalink raw reply
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-03 21:59 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
0 files changed, 0 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: linux @ 2006-04-03 22:13 UTC (permalink / raw)
To: junkio; +Cc: git
> I suspect people have hard time grasping _why_ you are jumping
> through hoops. At least I do. What problem are you trying to
> solve? You perhaps described your mechanism well enough, but it
> is not quite clear to me what kind of operations are made easier
> with this exercise, against which possible downside of it, if
> any, would be judged.
Oh... I thought he explained that pretty well.
The problem is a long-lived out-of-tree patch, or anything else that's
going to undergo repeated test releases before merging.
Think about swsusp2 or resiser4 or gfs or user-mode linux (now merged)
or nommu linux (now merged) or some similar large patch that takes a
lot of review.
The challenge is to be able to maintain a "latest Linux release + patches"
distribution and still keep a clean patch to submit to Linus that
doesn't have a zillion cross-merges because he doesn't like that,
and they confuse the development history.
It happens with a single developer when you're working on several
independent features and want a "latest & greatest" tree while still
keeping the feature branches separate.
This is the sort of thing that git-rebase and pu branches are used for,
and jgarzik's libata-dev ALL branch is basically a manually operated
hydra.
Some combination of automatic rebasing and automatic generation of
a pu/ALL tree seems like what's being asked for here. The former
adds new history "before" the branch development, and the latter
adds additional changes "after" it. All this subterfuge is in
the name of keeping the feature development history clean.
But all of darcs' "patch calculus" ideas are just basically
rebase strategies. If someone can come up with a good alternative
to diff-and-patch, perhaps git-rebase can develop a number of
underlying strategies like git-merge.
^ permalink raw reply
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-03 22:18 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.gitignore | 1 +
Documentation/git-clean.txt | 50 +++++++++++++++++++++++++++++++
Makefile | 2 +
git-clean.sh | 70 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 122 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 75891c3..b5959d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@ git-checkout
git-checkout-index
git-cherry
git-cherry-pick
+git-clean
git-clone
git-clone-pack
git-commit
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
new file mode 100644
index 0000000..0c671e1
--- /dev/null
+++ b/Documentation/git-clean.txt
@@ -0,0 +1,50 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d | -D] [-n] [-q] [-x]
+
+DESCRIPTION
+-----------
+Removes files unknown to git. This allows to clean the working tree
+from files that are not under version control. If the '-x' option is
+specified, ignored files are also removed, allowing to remove all
+build products.
+
+OPTIONS
+-------
+-d::
+ Remove untracked directories in addition to untracked files.
+
+-D::
+ Same as above, but use chmod first. This is useful for
+ read-only directories used in some testsuites.
+
+-n::
+ Don't actually remove anything, just show what would be done.
+
+-q::
+ Be quiet, only report errors, but not the files that are
+ successfully removed.
+
+-x::
+ Don't use the ignore rules. This allows removing all untracked
+ files, including build products. This can be used (possibly in
+ conjunction with gitlink:git-reset[1]) to create a pristine
+ working directory to test a clean build.
+
+
+Author
+------
+Written by Pavel Roskin <proski@gnu.org>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index c79d646..221e59a 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
diff --git a/git-clean.sh b/git-clean.sh
new file mode 100755
index 0000000..8470559
--- /dev/null
+++ b/git-clean.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Copyright (c) 2005-2006 Pavel Roskin
+#
+
+USAGE="[-d | -D] [-n] [-q] [-x]"
+LONG_USAGE='Clean untracked files from the working directory
+ -d remove directories as well
+ -D remove directories, try harder (chmod first)
+ -n don'\''t remove anything, just show what would be done
+ -q be quiet, only report errors
+ -x remove ignored files as well'
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+noexclude=
+cleandir=
+cleandirhard=
+quiet=
+rmf="rm -f"
+rmrf="rm -rf"
+rm_refuse="echo Not removing"
+echo1="echo"
+
+for arg in "$@"; do
+ if [ "$arg" = "-d" ]; then
+ cleandir=1
+ elif [ "$arg" = "-D" ]; then
+ cleandir=1
+ cleandirhard=1
+ elif [ "$arg" = "-n" ]; then
+ quiet=1
+ rmf="echo Would remove"
+ rmrf="echo Would remove"
+ rm_refuse="echo Would not remove"
+ echo1=":"
+ elif [ "$arg" = "-q" ]; then
+ quiet=1
+ elif [ "$arg" = "-x" ]; then
+ noexclude=1
+ else
+ echo >&2 "Unknown option: \"$arg\""
+ exit 1
+ fi
+done
+
+excl1=
+excl2=
+if [ -z "$noexclude" ]; then
+ excl1="--exclude-per-directory=.gitignore"
+ if [ -f "$GIT_DIR/info/exclude" ]; then
+ excl2="--exclude-from=$GIT_DIR/info/exclude"
+ fi
+fi
+
+git-ls-files --others --directory "$excl1" "$excl2" |
+while read -r file; do
+ if [ -d "$file" -a ! -L "$file" ]; then
+ if [ -z "$cleandir" ]; then
+ $rm_refuse "$file"
+ continue
+ fi
+ $echo1 "Removing $file"
+ [ "$cleandirhard" ] && chmod -R 700 "$file"
+ $rmrf "$file"
+ else
+ $echo1 "Removing $file"
+ $rmf "$file"
+ fi
+done
^ permalink raw reply related
* [PATCH 4/4] contrib/git-svn: make sure our git-svn is up-to-date for test
From: Eric Wong @ 2006-04-03 22:18 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11441027292908-git-send-email-normalperson@yhbt.net>
Bugs like the last one could've been avoided if it weren't for
this...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d3ce1325c4933cd0e5f8f9810b2ffc33ddf45aac
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index d7f1643..acedf73 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -28,7 +28,7 @@ git-svn.xml : git-svn.txt
git-svn.html : git-svn.txt
asciidoc -b xhtml11 -d manpage \
-f ../../Documentation/asciidoc.conf $<
-test:
+test: git-svn
cd t && $(SHELL) ./t0000-contrib-git-svn.sh
clean:
--
1.3.0.rc1.g595e
^ permalink raw reply related
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 22:19 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <1144083282.2303.102.camel@neko.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On Mon, 2006-04-03 at 09:54 -0700, Keith Packard wrote:
> On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:
>
> > -YFLAGS=-d
> > +YFLAGS=-d -l
> > +LFLAGS=-l
>
> Works for me too; thanks for the fix.
Well, -l *kinda* works; it places a limit on the maximum token size.
And, unlike 'lex', 'flex' places all input into the token buffer, even
if handled outside the usual lexer loop. So, my external function that
sucked up file contents was losing.
I switched it over to doing one-at-a-time reads from the input file, now
the external data function can directly use stdio. This eliminates all
calls to 'input' and 'unput' which should make it work for everyone now.
flex -- it's like lex, except less flexible.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
From: Eric Wong @ 2006-04-03 22:18 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
fetching from repos without an authors-file defined was broken.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
029626bf987cff7ba42d8158c687cf4902765968
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index edfb19c..e7fff46 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -77,10 +77,13 @@ foreach my $o (keys %opts) {
$arg .= ' --bool' if ($o !~ /=[sfi]$/);
$arg .= " svn.$key"; # $key only matches [a-z\-], always shell-safe
if (ref $v eq 'ARRAY') {
- chomp(@$v = `$arg`);
+ chomp(my @tmp = `$arg`);
+ @$v = @tmp if @tmp;
} else {
- chomp($$v = `$arg`);
- $$v = 0 if $$v eq 'false';
+ chomp(my $tmp = `$arg`);
+ if ($tmp && !($arg =~ / --bool / && $tmp eq 'false')) {
+ $$v = $tmp;
+ }
}
}
--
1.3.0.rc1.g595e
^ permalink raw reply related
* Re: [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
From: Eric Wong @ 2006-04-03 22:21 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <11441027292908-git-send-email-normalperson@yhbt.net>
Subject: Re: [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
^ oops, disregard that, these should've been 1/2 and 2/2
--
Eric Wong
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-03 22:38 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
Keith,
Looks nifty. Though I thought you'd go for writing a smarter cvsps, so
that git-cvsimport could take advantage of it.
Looks like I'll have to brush up on my C to get to play... :-(
m
^ permalink raw reply
* Re: git-svn and svn sw --relocate
From: Eric Wong @ 2006-04-03 22:39 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <44314B41.3050902@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> Eric Wong wrote:
> > Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> >>i have now my repository locally and i want to get it remotely on a
> >>server, in order to have a few collaborators...
> >>
> >>the steps on the svn-side are clear. But what do i have todo on the
> >>git-svn-side of this life?
> >>
> >>does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
> >
> >
> > Yes, you'll need to do that in .git/git-svn/tree and also update
> > .git/git-svn/info/url by hand.
>
> Will there be any other sha1-sums for that repository so that i have to
> merge them again and again? This issue occured to me the last time i
> encountered the git-svn-change with the external sources, where i had to
> repair my external git-svn-tree, which resulted in new sha1sums
> somehow... that was very unpleasant to my collegue..
sha1-sums for commits? or trees? I'm not sure that I follow, git-svn
should make commits with at least two explicit parents (one being the
commit you're using and, and the other remote/git-svn) back to
remotes/git-svn.
The commit sha1s for the same svn tree do not necessary always match,
and ac7490506418e3ec495775e432b7040a17449fa9 acknowledges that:
contrib/git-svn: allow rebuild to work on non-linear remote heads
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
The tree sha1 should always match, however. You can use the
--branch <refname/commit> option to do automatic branch joining
based on tree sha1 checksums to combine history.
--
Eric Wong
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqvictsc.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Apr 2006, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>>> For example, the first hunk says:
>>>
>>> @@ -0,0 +6 @@
>>> +#include "diff.h"
>>>
>>> Which is inconsistent with what GNU diff says:
>>>
>>> @@ -5,0 +6 @@
>>> +#include "diff.h"
>>>
>>> I've tried this patch but...
>>
>> The fix is fine, but you should do the same even in the s2 case. The
>> correct hunk should have been:
>>
>> @@ -6,0 +6 @@
>
> You are right. GNU says -5,0 not -6,0 so presumably "patch"
> other people use expect it to say -5,0 not -6,0; even though we
> could argue the insertion happens at 6th position and saying
> -6,0 is more logical, it does not matter -- what incumbent does
> wins X-<. I notice that your fix shows -5,0 to match it ;-).
Yeah, I had to make it such that GNU patch could swallow it, otherwise it
made no sense (being it right or not). Even the other issue is fixed now,
and I'll send you a libxdiff-based diff as soon as it passes some tests.
- Davide
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vzmj3k7x9.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>> On Sun, 2 Apr 2006, Junio C Hamano wrote:
>>
>>> $ git diff-tree -p 52e8a6^2 52d8a6 -- git-fetch.sh
>>>
>>> shows a change that trivially is redundant, like this:
>>>
>>> diff --git a/git-fetch.sh b/git-fetch.sh
>>> index b4325d9..de4f011 100755
>>> --- a/git-fetch.sh
>>> +++ b/git-fetch.sh
>>> @@ -320,7 +320,7 @@ fetch_main () {
>>> ..
>>> Notice the first '-' and '+' lines of second hunk are identical?
>>>
>>> There is another interesting thing. This is running diff
>>> between 52e8a6^2 and 52d8a6 blobs, but if I change them slightly
>>> so that the first hunk is not different, then this anomaly
>>> disappears.
>>
>> Could you send me the two files that creates the above diff?
>
> I should have tried your pristine xdiff code myself before
> bothering you, but I haven't (sorry).
>
> The problem is from the "stripped down" version we use in git,
> so you may or may not see the problem in your version. Attached
> are the files.
This is the change I made to libxdiff. Xregression already made a few
thousands on iterations w/out problems.
- Davide
--- xdiff/xdiffi.c
+++ xdiff/xdiffi.c
@@ -349,12 +349,7 @@
kvdf += xe->xdf2.nreff + 1;
kvdb += xe->xdf2.nreff + 1;
- /*
- * Classical integer square root approximation using shifts.
- */
- xenv.mxcost = 1;
- for (; ndiags; ndiags >>= 2)
- xenv.mxcost <<= 1;
+ xenv.mxcost = xdl_bogosqrt(ndiags);
if (xenv.mxcost < XDL_MAX_COST_MIN)
xenv.mxcost = XDL_MAX_COST_MIN;
xenv.snake_cnt = XDL_SNAKE_CNT;
--- xdiff/xprepare.c
+++ xdiff/xprepare.c
@@ -25,6 +25,7 @@
#define XDL_KPDIS_RUN 4
+#define XDL_MAX_EQLIMIT 1024
@@ -305,26 +306,48 @@
static int xdl_clean_mmatch(char const *dis, long i, long s, long e) {
- long r, rdis, rpdis;
+ long r, rdis0, rpdis0, rdis1, rpdis1;
- for (r = 1, rdis = 0, rpdis = 1; (i - r) >= s; r++) {
+ /*
+ * Scans the lines before 'i' to find a run of lines that either
+ * have no match (dis[j] == 0) or have multiple matches (dis[j] > 1).
+ * Note that we always call this function with dis[i] > 1, so the
+ * current line (i) is already a multimatch line.
+ */
+ for (r = 1, rdis0 = 0, rpdis0 = 1; (i - r) >= s; r++) {
if (!dis[i - r])
- rdis++;
+ rdis0++;
else if (dis[i - r] == 2)
- rpdis++;
+ rpdis0++;
else
break;
}
- for (r = 1; (i + r) <= e; r++) {
+ /*
+ * If the run before the line 'i' found only multimatch lines, we
+ * return 0 and hence we don't make the current line (i) discarded.
+ * We want to discard multimatch lines only when they appear in the
+ * middle of runs with nomatch lines (dis[j] == 0).
+ */
+ if (rdis0 == 0)
+ return 0;
+ for (r = 1, rdis1 = 0, rpdis1 = 1; (i + r) <= e; r++) {
if (!dis[i + r])
- rdis++;
+ rdis1++;
else if (dis[i + r] == 2)
- rpdis++;
+ rpdis1++;
else
break;
}
+ /*
+ * If the run after the line 'i' found only multimatch lines, we
+ * return 0 and hence we don't make the current line (i) discarded.
+ */
+ if (rdis1 == 0)
+ return 0;
+ rdis1 += rdis0;
+ rpdis1 += rpdis0;
- return rpdis * XDL_KPDIS_RUN < (rpdis + rdis);
+ return rpdis1 * XDL_KPDIS_RUN < (rpdis1 + rdis1);
}
@@ -334,34 +357,40 @@
* might be potentially discarded if they happear in a run of discardable.
*/
static int xdl_cleanup_records(xdfile_t *xdf1, xdfile_t *xdf2) {
- long i, rhi, nreff;
+ long i, nm, rhi, nreff, mlim;
unsigned long hav;
xrecord_t **recs;
xrecord_t *rec;
char *dis, *dis1, *dis2;
- if (!(dis = (char *) xdl_malloc((xdf1->nrec + xdf2->nrec + 2) * sizeof(char)))) {
+ if (!(dis = (char *) xdl_malloc(xdf1->nrec + xdf2->nrec + 2))) {
return -1;
}
- memset(dis, 0, (xdf1->nrec + xdf2->nrec + 2) * sizeof(char));
+ memset(dis, 0, xdf1->nrec + xdf2->nrec + 2);
dis1 = dis;
dis2 = dis1 + xdf1->nrec + 1;
+ if ((mlim = xdl_bogosqrt(xdf1->nrec)) > XDL_MAX_EQLIMIT)
+ mlim = XDL_MAX_EQLIMIT;
for (i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart]; i <= xdf1->dend; i++, recs++) {
hav = (*recs)->ha;
rhi = (long) XDL_HASHLONG(hav, xdf2->hbits);
- for (rec = xdf2->rhash[rhi]; rec; rec = rec->next)
- if (rec->ha == hav && ++dis1[i] == 2)
+ for (nm = 0, rec = xdf2->rhash[rhi]; rec; rec = rec->next)
+ if (rec->ha == hav && ++nm == mlim)
break;
+ dis1[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
}
+ if ((mlim = xdl_bogosqrt(xdf2->nrec)) > XDL_MAX_EQLIMIT)
+ mlim = XDL_MAX_EQLIMIT;
for (i = xdf2->dstart, recs = &xdf2->recs[xdf2->dstart]; i <= xdf2->dend; i++, recs++) {
hav = (*recs)->ha;
rhi = (long) XDL_HASHLONG(hav, xdf1->hbits);
- for (rec = xdf1->rhash[rhi]; rec; rec = rec->next)
- if (rec->ha == hav && ++dis2[i] == 2)
+ for (nm = 0, rec = xdf1->rhash[rhi]; rec; rec = rec->next)
+ if (rec->ha == hav && ++nm == mlim)
break;
+ dis2[i] = (nm == 0) ? 0: (nm >= mlim) ? 2: 1;
}
for (nreff = 0, i = xdf1->dstart, recs = &xdf1->recs[xdf1->dstart];
--- xdiff/xutils.c
+++ xdiff/xutils.c
@@ -29,6 +29,19 @@
+long xdl_bogosqrt(long n) {
+ long i;
+
+ /*
+ * Classical integer square root approximation using shifts.
+ */
+ for (i = 1; n > 0; n >>= 2)
+ i <<= 1;
+
+ return i;
+}
+
+
int xdl_emit_diffrec(char const *rec, long size, char const *pre, long psize,
xdemitcb_t *ecb) {
int i = 2;
--- xdiff/xutils.h
+++ xdiff/xutils.h
@@ -25,6 +25,7 @@
+long xdl_bogosqrt(long n);
int xdl_emit_diffrec(char const *rec, long size, char const *pre, long psize,
xdemitcb_t *ecb);
int xdl_mmfile_outf(void *priv, mmbuffer_t *mb, int nbuf);
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-03 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsloucuxk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>I suspect people have hard time grasping _why_ you are jumping
>through hoops. At least I do. What problem are you trying to
>solve? You perhaps described your mechanism well enough, but it
>is not quite clear to me what kind of operations are made easier
>with this exercise, against which possible downside of it, if
>any, would be judged.
>[...]
>So can you step back a bit and start from describing what
>problem you are trying to solve, before describing the
>mechanisms you think would help?
>
>
As a research exercise the principle purpose was first to see if there
is a natural fit with git's data model, and secondly to investigate what
benefits were possible from it. In a sense it was "bottom-up" investigation.
>> - the current tools make this style of development difficult.
>>
>>
>Git was born from necessity, and we have been aiming to have
>tools to do what are commonly needed. It is not surprising to
>see existing tools do not support modes of operations that are
>"unusual" (meaning, things we have not done with git so far).
>Also we do not tend to do things only because we can.
>
>
And a good principle that is, too.
>For example, the point jdl raised during the discussion is far
>easier to understand. When working on multiple topics, he often
>needs to test them as a whole, so he pulls them into a test
>branch (can be a throwaway branch). When he needs to do fixups,
>it is most efficient to do compile/run test while still in the
>test branch, but after things test out, in order to keep
>logically different things separate, he needs to go back to
>relevant topic branches and make a commit. This is painful --
>are there ways to make this easier [*2*]?
>
>Would patch commutation calculus help with his problem?
>
>
I'd provisionally say "yes, that's the fit". It's just like having
multiple topic branches all checked out at once, with commits going to
the appropriate branch as necessary.
In my experiment, when a commit touched files on more than one head,
then the heads would be collapsed to a single one, like a merge. As the
nature of the setup was such that you didn't explicitly name heads, this
was a natural thing to do. But if you're naming them, you probably would
want some way to choose between applying the commit to just one head,
both heads, or collapsing the two heads into one.
That approach actually offers the most flexibility - a porcelain could
do full darcs-like patch calculus if it wanted, or saner explicit topic
branching.
>One thing I can think of that could potentially come out of your
>approach would be an alternative implementation of what StGIT
>does. Inside a local developer repository, being able to
>reorder patches and rewrite them flexibly is very useful.
>
>
Oh, I didn't think of that. Were you thinking of an extra head for each
"uncommitted" chain of related patches? That's an interesting idea.
I think it might really help use cases like the -mm Linux tree, where
bunches of related commits are typically applied in a series, but you
especially want to track inter-set dependencies. Currently stgit takes a
very long time to import the split -mm series :-)
>Another obvious strategy would be to make commits on top of
>"test" and then cherry-pick them back on top of the relevant
>topics later.
>
> topicA You have three topics
> o---o you need to test together...
> /
> [...]
> \ /
> o---o---2'
> topicC
>
>
That's a nice illustration of it, yes.
Sam.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Junio C Hamano @ 2006-04-04 0:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060403221841.25097.18242.stgit@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> This command removes untracked files from the working tree. This
> implementation is based on cg-clean with some simplifications. The
> documentation is included.
I am not opposed to the command in the sense that I do not want
to forbid people from doing what they want to do, but on the
other hand I do not see why people (apparently many people) want
to have something like this. Are their "make clean" broken?
Having said that, just some nitpicks.
> diff --git a/.gitignore b/.gitignore
>...
> +git-clean
I appreciate the attention to the detail; very nice to have
a .gitignore entry along with addition of a command.
> diff --git a/git-clean.sh b/git-clean.sh
>...
> +for arg in "$@"; do
for arg
do
...
> + if [ "$arg" = "-d" ]; then
case "$arg" in -d)...
> +excl1=
> +excl2=
> +if [ -z "$noexclude" ]; then
> + excl1="--exclude-per-directory=.gitignore"
> + if [ -f "$GIT_DIR/info/exclude" ]; then
> + excl2="--exclude-from=$GIT_DIR/info/exclude"
> + fi
> +fi
> +
> +git-ls-files --others --directory "$excl1" "$excl2" |
> +while read -r file; do
> ...
The $noexclude case passes two empty strings to git-ls-files,
which may happen to be harmless with the current implementation,
but does not feel quite right.
Maybe better to read ls-files -z to be really pathname safe, I
dunno.
> + $echo1 "Removing $file"
> + [ "$cleandirhard" ] && chmod -R 700 "$file"
I am not quite sure this chmod -R is a good idea. If we are
trying really hard would we need to also make sure we can rmdir
the "$file" by chmod'ing its parent directory? But once we
start doing that where would we stop?
^ permalink raw reply
* [PATCH] contrib/git-svn: handle array values correctly
From: Eric Wong @ 2006-04-04 0:41 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
0511c05c013dc4e6d17832fad043847c35a30c6d
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index e7fff46..7c44450 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -75,12 +75,11 @@ foreach my $o (keys %opts) {
my $arg = 'git-repo-config';
$arg .= ' --int' if ($o =~ /=i$/);
$arg .= ' --bool' if ($o !~ /=[sfi]$/);
- $arg .= " svn.$key"; # $key only matches [a-z\-], always shell-safe
if (ref $v eq 'ARRAY') {
- chomp(my @tmp = `$arg`);
+ chomp(my @tmp = `$arg --get-all svn.$key`);
@$v = @tmp if @tmp;
} else {
- chomp(my $tmp = `$arg`);
+ chomp(my $tmp = `$arg --get svn.$key`);
if ($tmp && !($arg =~ / --bool / && $tmp eq 'false')) {
$$v = $tmp;
}
--
1.3.0.rc1.gd3ce-dirty
^ permalink raw reply related
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 0:51 UTC (permalink / raw)
To: git
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain wrote:
> The IRC log:
>
> 17:45 < mugwump> the other suggestions look quite good. I don't know
> how I got roped into spending a whole day on this :)
> 17:46 < mugwump> oh yeah, I remember now. somebody asked for a
> comparison between darcs and git
> 17:46 * ShadeHawk whistles innocently
Let me describe in my own words results of IRC discussion and posts on Git
Mailing List, both in this thread and in "Multi-headed branches (hydra? :))
for basic patch calculus" one
http://permalink.gmane.org/gmane.comp.version-control.git/18258
and Sam Vilain work (prototype). It might help with understanding Sam's
work; and I hope Sam would correct me if I'm wrong.
It started I think as a way to describe (represent, save) in core GIT the
partial ordering of patches (commits) by dependence Darcs uses in it's
patch algebra theory {i.e. patch1 <- patch2 if patch2 depends on patch1
(patches does not commute)} at *commit time*.
> Say you've got a sequence of changes like this:
>
> 1. add foo.c
> 2. add bar.c
> 3. modify foo.c
> 4. modify bar.c
>
> The darcs-like operation of this would be to have two sequences of
> ordered patches that combine to a final result. ie:
>
> 1 <- 3
> 2 <- 4
>
> Unless you jump through hoops, git will represent it as:
>
> 1 <- 2 <- 3 <- 4.
[the direction of arrows has changed in this quote]
First part of the idea is to represent the partial ordering of patches by
their interdependence (the sequences, chains of ordered patches) using
"parent" relation. (There was also idea of adding another field(s)
"depends-on" to represent only commit dependency in addition to "parent(s)"
relations defining history.)
Second part of the idea is to avoid creating, then recreating the final
something (commit) which combines commit chains to a final result
>
> 1 -> 3 \
> >- head
> 2 -> 4 /
>
> Where "head" is a merge commit that just combines the trees of 3 and 4.
>
So an idea of "hydra", or "n-head" was born, which is just virtual trivial
merge commit which gives us final result, HEAD of chains. (It is trivial
because trees 3 and 4 are independent, merge without conflicts.) And also
related idea of "hydra commit", which automatically adds commit to correct
chain (places commit in correct place of partial ordering by dependence)
and advances n-head (virtual trival merge commit which is HEAD).
The side effects (perhaps more important than making use of Darcs patch
algebra theory, and Darcs merge algorithm) is that we have automatical
topic branches, or to be more exact automatical dependency (sub)branches
(commit/patch dependency chains).
Does it make sense?
To be continued...
In next installment we will see how "hydra commits" or "n-heads" might work:
simplifications in defining commit dependency, "coarse" ordering i.e. no
branching dependency chains, updating n-head during commit and during
merge. Sam Vilain wrote some scripts for "proving of concept"; I would
present my idea on that matter, untested.
--
Jakub Narębski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Anand Kumria @ 2006-04-04 0:55 UTC (permalink / raw)
To: git
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
On Mon, 03 Apr 2006 16:03:48 +0200, Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
>> The UI is a total disaster, sufficient for testing. You must create an
>> Authors file in the current directory which looks like the git-cvsimport
>> authors file. You must also have a edit-change-log program in your path
>> which edits the commit message in place. /bin/true will work if you
>> don't need to edit the messages.
>>
>> I should clearly steal the existing git-cvsimport command line arguments
>> and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
cvsclone, recently released, might be what you are after.
I've only used it on my own CVS repositories so I've no idea just how hard
it hits the remote side.
<http://freshmeat.net/projects/cvsclone/>
Anand
^ permalink raw reply
* git-svnimport on OSX?
From: Randal L. Schwartz @ 2006-04-04 1:04 UTC (permalink / raw)
To: git
Working for anyone? Not working for me, and just wondered if it was me or a
known thing. Maybe I'm just holding my mouth wrong, and yes, I have SVN::Core
installed. If anyone wants details, I can provide.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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