* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 10:00 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, Daniel Drake, git
In-Reply-To: <20060403180929.GA14967@reactrix.com>
Dear diary, on Mon, Apr 03, 2006 at 08:09:30PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> 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.
Well, what is the actual advantage of DAV compared to
git-update-server-info? Why would I prefer enabling DAV?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-04 9:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44323C52.2030803@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Sam Vilain wrote:
>> Junio C Hamano wrote:
>>> [ made change on a test branch that bundles topic branches
>>> -- now want to commit back to the component topic branch ]
>>>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.
>
> Wouldn't "git commit -M -b topic", for committing to a different
> branch than what is checked out (-b) and also to the checked out
> branch (-M) have the same beneficial effects, but without the
> complexity of hydras and patch dependency theory? It would only remove
> the cherry-pick stage though, but perhaps it's good enough. Although
> when I think about it, -b
> <branch> for committing to another branch and -B <branch> for doing
> the above probably makes more sense.
It feels to me that the above set of flags encourage a workflow
that:
(1) modify the source and run tests in "test" branch;
(2) have tool automatically adjust the change to match the other
branch (i.e. the topic to be checked in) automatically;
(3) make a commit, without a chance to do the final sanity
check in the context of the branch being committed.
An individual topic branch itself might not be even testable
standalone, but at least I'd prefer to have a chance to double
check if the "patch commuting" (or "cherry-pick stage") did a
sensible thing [*1*].
As I said on the list in the past, I am from a school that
believes in not committing anything that has not been
tested/reviewed as a whole, especially when it comes to
individual developers, so I am not sure it is a good idea
in general to make it easy to do so to begin with.
But that is just my personal preference, and it does not
necessarily have to stop people wishing to have that feature to
have it, especially when there are enough of them.
> Those flags don't exist currently btw, in case someone's reading this
> on the archives.
I take it that you are volunteering to come up with an initial
round of implementation of these flags?
[Footnote]
*1* ... that's where "git checkout -m that-topic", perhaps
followed by "git diff HEAD", comes in.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 9:28 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <4431B60E.3030008@vilain.net>
Sam Vilain wrote:
> Junio C Hamano wrote:
>
>>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.
>
Wouldn't "git commit -M -b topic", for committing to a different branch
than what is checked out (-b) and also to the checked out branch (-M)
have the same beneficial effects, but without the complexity of hydras
and patch dependency theory? It would only remove the cherry-pick stage
though, but perhaps it's good enough. Although when I think about it, -b
<branch> for committing to another branch and -B <branch> for doing the
above probably makes more sense.
Those flags don't exist currently btw, in case someone's reading this on
the archives.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Alex Riesen @ 2006-04-04 9:17 UTC (permalink / raw)
To: Martin Waitz; +Cc: Pavel Roskin, git
In-Reply-To: <20060404082002.GJ4663@admingilde.org>
On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:
> What is the use case of cleaning up all untracked files without also
> cleaning ignored files?
Thinks of git's .gitignore: it has config.mak in it. Are you sure you want
"clean" your build customizations?
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Junio C Hamano @ 2006-04-04 9:08 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060404082002.GJ4663@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> +-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.
>
> as ignored files are generally generated files, doesn't it make sense
> to clean up the "ignored" files, and leave other untracked files
> alone? That way you don't loose files which you forgot to add to git.
Sounds like a sane suggestion, but my previous comment about
"make clean" broken for people who want this "git clean" feature
applies here as well.
One justification I can think of for "git clean" without -x flag
is to make a clean tree that has only the source and build
products, removing editor backup files, throwaway test output
files and friends, but as you pointed out, this risks losing
newly created source files that you forgot to add, so I would
need a bit of convincing before I use such a command myself.
Compared to that, removing only ignored files sounds like a much
safer operation -- they are explicitly listed as expendable, so
it is a lot less likely to lose anything important. But again,
that is what "make clean" is there for...
^ permalink raw reply
* [RFH] Solaris cloning woes...
From: Junio C Hamano @ 2006-04-04 8:47 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <7vy7yol0nk.fsf@assigned-by-dhcp.cox.net>
The sigaction() patch cooked by Linus and Jason are in "next",
to fix pack-objects breakage started between 1.2.2 and 1.2.3.
Once this is confirmed to fix the problem on Solaris boxes, I'd
like to include and do an 1.2.5, just in case OpenSolaris folks
would want to play with it, and also put them in the "master"
branch.
I have an access to a not-so-well-maintained Solaris box at
work, and built the relevant parts with somewhat stripped down
configuration to run the test. The "master" version without the
sigaction() patches exhibits the symptom Oejet and I observed
the other night, and "next" seems to fix it. I am reasonably
happy.
^ permalink raw reply
* Re: [PATCH] Add git-clean command
From: Martin Waitz @ 2006-04-04 8:20 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060403221841.25097.18242.stgit@dv.roinet.com>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
hoi :)
> +-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.
as ignored files are generally generated files, doesn't it make sense
to clean up the "ignored" files, and leave other untracked files
alone? That way you don't loose files which you forgot to add to git.
What is the use case of cleaning up all untracked files without also
cleaning ignored files?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Junio C Hamano @ 2006-04-04 7:03 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060403180929.GA14967@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Is there any interest in making the HTTP transport slighly less dumb by
> using DAV?
I personally feel PROPFIND is the right way to do "wget -r", and
very much welcome a patch to replace objects/info/packs with it
when able.
> 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.
Faking info/refs with PROPFIND, if we do not have to peel the
onion ^{}, should be relatively cheap operation, and could be
done as an enhancement to git-ls-remote.sh. If your faked
info/refs file lacks ^{} entries, git-fetch cannot auto-follow
tags, but git-clone should work as before.
A clever sysadmins could mod_rewrite requests to info/refs and
objects/info/packs with a custom CGI, but then probably they
would be running git-daemon ;-).
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Junio C Hamano @ 2006-04-04 6:09 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1144122709.2303.153.camel@neko.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> I've just changed parsecvs to generate blobs for every revision in
> each ,v file right after they're read in; putting the necessary code
> right into parsecvs should be reasonably straightforward; we don't need
> the multi-patch logic as we do want to compute each intermediate version
> of the file.
If you want to go really fast without extra fork, are writing it
in C, and have the data for blob in core, you could link with
libgit.a and call write_sha1_file() yourself:
unsigned char sha1[20];
void *buf;
unsigned long len;
write_sha1_file(buf, len, "blob", sha1);
instead of forking "hash-object -w". You feed your blob data
in buf, with its length in len, and you will get the blob object
name back in sha1[]. buf is owned by you and after
write_sha1_file() returns it is safe for you to scribble over it
or free() it. sha1[] stores binary object name (20 bytes, not
40-byte hexadecimal), and you can use the helper function
sha1_to_hex() if you need a hex representation:
char *sha1_to_hex(sha1)
which returns a pointer to a static buffer that is valid until
next call to sha1_to_hex(), so you need to strdup it if you want
to retain it.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-04 3:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Git Mailing List
In-Reply-To: <46a038f90604031942w779894b8p5ef221482a70a301@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Tue, 2006-04-04 at 14:42 +1200, Martin Langhoff wrote:
> Cool. What's the matter with the Pg repo? (Where can I get hold of that repo?)
As usual, the detection of branch locations is messed up.
The postgresql CVS tree is available at:
rsync anoncvs.postgresql.org::pgsql-cvs/* postgresql.cvs
It's a fairly hefty 300M.
> > > Does it run incrementally? Can it discover non-binary files and pass -kk?
> >
> > It doesn't run incrementally, and it unconditionally passes -kk. It's
>
> I thought that the .git-cvs directory it created was to be able to run
> incrementally (btw, I think it's fair game to create subdirs inside
> .git for this kind of status-tracking). And passing -kk uncoditionally
> is destructive in some cases (I know... git-cvsimport does it, and I
> want to fix that). If you can ask rcs about the mode if the file and
> not pass -kk for binary files...
nah, the .git-cvs directory is purely for debugging; I leave the various
command outputs there so I can see what went wrong.
I don't really have a good idea of how we'd do this process
incrementally; that's not something I am personally interested in
either, I want to run screaming from CVS as fast as I can at this point.
> > currently using rcs to check out versions of the files, so it should
> > deal with binary content as well as rcs does. Is there something magic I
> > need to do here? Like for DOS?
>
> We'll let DOS take care of itself ;)
I did discover that rcs has less sophisticated keyword substitution than
cvs; not having any ability to customize stuff.
I guess we need to figure out when to pass -ko and when to pass -kk. The
other alternative I'd like to get around to trying is to directly
generate all of the revision contents from the ,v file.
I've just changed parsecvs to generate blobs for every revision in
each ,v file right after they're read in; putting the necessary code
right into parsecvs should be reasonably straightforward; we don't need
the multi-patch logic as we do want to compute each intermediate version
of the file.
With the blobs all generated, the rest of the operation is a simple
matter of building suitable indices and creating commits out of them.
That's a reasonably fast operation now as it doesn't manipulate any file
contents. Plus, I can do all of the index operations using a single
git-update-index command, so I eliminate a pile of forking.
Doing the file revision generation in-line would allow us to eliminate
most of the remaining forks; we'd run one git-hash-object per file (or
so), then a git-update-index, git-write-tree and git-commit-tree per
resulting commit.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-04 2:42 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144117473.2303.132.camel@neko.keithp.com>
On 4/4/06, Keith Packard <keithp@keithp.com> wrote:
> On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:
>
> > Meh, had you done it in Perl, I'd be helping you with the Pg repo,
> > attic files and ensuring that files created on a branch and then put
> > into HEAD are handled gracefully. (But you'll get Linus' and Junio's
> > attention. Smarty cookie.)
>
> I think those parts are working correctly, I've had plenty of examples
> of that kind of adventure.
Cool. What's the matter with the Pg repo? (Where can I get hold of that repo?)
> > Does it run incrementally? Can it discover non-binary files and pass -kk?
>
> It doesn't run incrementally, and it unconditionally passes -kk. It's
I thought that the .git-cvs directory it created was to be able to run
incrementally (btw, I think it's fair game to create subdirs inside
.git for this kind of status-tracking). And passing -kk uncoditionally
is destructive in some cases (I know... git-cvsimport does it, and I
want to fix that). If you can ask rcs about the mode if the file and
not pass -kk for binary files...
> currently using rcs to check out versions of the files, so it should
> deal with binary content as well as rcs does. Is there something magic I
> need to do here? Like for DOS?
We'll let DOS take care of itself ;)
m
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-04 2:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Git Mailing List
In-Reply-To: <46a038f90604031916r4651b572lb9bae4c5a3d47bc9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Tue, 2006-04-04 at 14:16 +1200, Martin Langhoff wrote:
> Meh, had you done it in Perl, I'd be helping you with the Pg repo,
> attic files and ensuring that files created on a branch and then put
> into HEAD are handled gracefully. (But you'll get Linus' and Junio's
> attention. Smarty cookie.)
I think those parts are working correctly, I've had plenty of examples
of that kind of adventure.
> Does it run incrementally? Can it discover non-binary files and pass -kk?
It doesn't run incrementally, and it unconditionally passes -kk. It's
currently using rcs to check out versions of the files, so it should
deal with binary content as well as rcs does. Is there something magic I
need to do here? Like for DOS?
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-04 2:16 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1144116459.2303.129.camel@neko.keithp.com>
On 4/4/06, Keith Packard <keithp@keithp.com> wrote:
> Trust me, it wasn't because I wanted to replace git-cvsimport; it's
> solely that cvsps was generating complete garbage for most of my
> repositories.
Oh, I don't mind -- we may as well bury cvsimport but I can't do C
like I can do Perl, and I surely want to help on this one.
> My new tool isn't perfect yet; it isn't getting exactly the expected
> answers for the postgresql repository, but it's working perfectly for my
> X server one.
Meh, had you done it in Perl, I'd be helping you with the Pg repo,
attic files and ensuring that files created on a branch and then put
into HEAD are handled gracefully. (But you'll get Linus' and Junio's
attention. Smarty cookie.)
Does it run incrementally? Can it discover non-binary files and pass -kk?
cheers,
martin
^ permalink raw reply
* Re: git-svnimport on OSX?
From: Martin Langhoff @ 2006-04-04 2:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fyku2ltk.fsf@blue.stonehenge.com>
On 03 Apr 2006 18:04:07 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
> 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.
I think I tried and gave up on it a month or two ago, but can't
remember the details. Fink's SVN::Core is too old, and having all the
SVN toolchain is a pain. What is the problem?
BTW, getting git-svnimport to work normally takes me quite a few tries
with different options, so OSX may be perfectly innocent this time...
m
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-04 2:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Git Mailing List
In-Reply-To: <46a038f90604031538x3c94d86ap9f1400427513a3a7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Tue, 2006-04-04 at 10:38 +1200, Martin Langhoff wrote:
> Looks nifty. Though I thought you'd go for writing a smarter cvsps, so
> that git-cvsimport could take advantage of it.
Once I had the change set information sitting in memory, it was far
easier to just generate the appropriate git commands than attempt to
recreate the cvsps output format...
> Looks like I'll have to brush up on my C to get to play... :-(
Trust me, it wasn't because I wanted to replace git-cvsimport; it's
solely that cvsps was generating complete garbage for most of my
repositories.
My new tool isn't perfect yet; it isn't getting exactly the expected
answers for the postgresql repository, but it's working perfectly for my
X server one.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-04 1:55 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031625330.30048@alien.or.mcafeemobile.com>
Davide Libenzi <davidel@xmailserver.org> writes:
> This is the change I made to libxdiff. Xregression already made a few
> thousands on iterations w/out problems.
Thanks. Merged-in and builds fine.
^ 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
* 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
* 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
* [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: [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
* 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: [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: [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: 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
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