* 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: [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
* 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: 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: 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: 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: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 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: 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: 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: [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
* [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: 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
* 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: 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: 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: 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: Andreas Ericsson @ 2006-04-04 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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.
>
I don't fully understand 3 here. The workflow makes it easier to test
how different topics work together, and make fixes to those that don't
play well with others. Granted, it's not possible to test each topic by
itself without checking it out, making the changes and re-compiling and
so on, but since commits are so easy to undo I think it'd be nice to
have the changes tracked. Another good thing is that fixes that apply on
top of the "work-together" fixes, but that only make the topic branch
build/work properly are completely rebase'able, and should result in a
fast-forward merge since they share the same commit.
> 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*].
>
Understandable, and this workflow would still be available, but see below.
> 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.
>
In short, you're from the school of centralized repositories. I used to
be very careful about committing things too, but since I switched to git
I happily commit smaller and more often, and regularly toss up a
throw-away branch to make small commits that may or may not work and
later apply the (tested) combined diff as a single commit or series of
commits at points where I've tested one feature/fix to actually work as
intended. This is nifty because people that help with testing can pull
from my throw-away branch and get to work without me having to send them
a tar-tree and a patch.
I believe in not *pushing* anything that hasn't been thoroughly tested,
but the ability to track and commit possibly broken changes without it
affecting the project as a whole is what makes git so great for me. In
the CVS days distributed testing was a nuissance. With git it's smooth
sailing.
>
>>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?
>
Unless someone can convince me I'm on the wrong track before I get off
work, yes.
--
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: Sam Ravnborg @ 2006-04-04 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
>
> 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?
No reason to waste time on make clean.
git ls-files -o | xargs rm
Does the same job nicely.
Other typical usecases for me:
Remove temporaries that I created while trying out stuff.
Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
around for no use. An easy way to remove these without breaking
my 'allmodconfig' build is nice. It anyway > 1 hour to build and
I like to get rid of the untracked stuff in an easy way.
So use cases goes like this:
- Remove everything not tracked by git (including .gitignore files)
- Remove everything except tracked by git or ignored
- Remove ignored files (replacement of make clean) (seldom)
Above should work both from top-level dir and in subdirectories.
That is my minimal expectations to git clean.
What Pavel came up with cover everything except the make clean
replacement part.
Sam
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 11:03 UTC (permalink / raw)
To: git
In-Reply-To: <44323C52.2030803@op5.se>
Andreas Ericsson wrote:
> 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.
Do you mean that you commit current state to the checked out (working)
branch, and commit *changes* (i.e. apply patch) to a different branch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Catalin Marinas @ 2006-04-04 11:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
As Linus pointed out, while darcs theory is interesting, it doesn't
work properly in practice. Dependency tracking can create problems
with merging. Darcs' patch commuting theory has (a big, IMHO) problem
since every time you pull a patch (or more) it needs to commute all
the patches back to the common ancestor. Over time, the merging
becomes slower and slower (i.e. even much slower than what darcs shows
in simple tests with the Linux kernel).
Inexact patch commuting can be achieved using diff3 (or merge) with 3
snapshots of the tree (the bottom of the patch, the top of the patch
and the current head on top of which the patch is being applied) which
GIT handles very well and fast since there is no need to commute
thousands of patches back to the common ancestor. The slight
disadvantage is that diff3 merging is not as exact as Darcs' patch
commuting but OK for 99% of the real cases.
StGIT is based on this inexact patch commuting "theory" and, with the
addition of upstream merging detection (based on reverse-applying), it
is seems to behave properly in almost all the cases (though you can
deliberately create some patches to break the algorithm).
I've been thinking about adding patch dependency tracking to StGIT but
only as a recommendation and not enforcement. The algorithm would be
similar to the upstream merging detection.
--
Catalin
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Andreas Ericsson @ 2006-04-04 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e0tjpk$ktu$1@sea.gmane.org>
Jakub Narebski wrote:
> Andreas Ericsson wrote:
>
>
>>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.
>
>
> Do you mean that you commit current state to the checked out (working)
> branch, and commit *changes* (i.e. apply patch) to a different branch?
>
No, I mean that this would commit both to the testing branch (being the
result of several merged topic-branches) and to the topic-branch merged
in. Commit as in regular commit, with a commit-message and a patch. The
resulting repository would be the exact same as if the change was
committed only to the topic-branch and then cherry-picked on to the
testing-branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404100035.GM27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
> Well, what is the actual advantage of DAV compared to
> git-update-server-info? Why would I prefer enabling DAV?
In theory, things should work the same either way. It seems that in
practice though, the server info files continue to surface as a source
of fetch problems.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] http-fetch: add optional DAV-based pack list
From: Nick Hengeveld @ 2006-04-04 12:33 UTC (permalink / raw)
To: git
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 7 +
http-fetch.c | 278 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 284 insertions(+), 1 deletions(-)
9aef9577cabbd96de20562902d2958108616a7e4
diff --git a/Makefile b/Makefile
index c79d646..19ce42c 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,11 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+ifdef NO_EXPAT
+http-fetch.o: http-fetch.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+endif
+
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@@ -532,7 +537,7 @@ git-imap-send$X: imap-send.o $(LIB_FILE)
git-http-fetch$X: fetch.o http.o http-fetch.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) $(CURL_LIBCURL)
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-http-push$X: revision.o http.o http-push.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
diff --git a/http-fetch.c b/http-fetch.c
index dc67218..71a7daf 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -4,6 +4,35 @@ #include "pack.h"
#include "fetch.h"
#include "http.h"
+#ifndef NO_EXPAT
+#include <expat.h>
+
+/* Definitions for DAV requests */
+#define DAV_PROPFIND "PROPFIND"
+#define DAV_PROPFIND_RESP ".multistatus.response"
+#define DAV_PROPFIND_NAME ".multistatus.response.href"
+#define DAV_PROPFIND_COLLECTION ".multistatus.response.propstat.prop.resourcetype.collection"
+#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
+
+/* Definitions for processing XML DAV responses */
+#ifndef XML_STATUS_OK
+enum XML_Status {
+ XML_STATUS_OK = 1,
+ XML_STATUS_ERROR = 0
+};
+#define XML_STATUS_OK 1
+#define XML_STATUS_ERROR 0
+#endif
+
+/* Flags that control remote_ls processing */
+#define PROCESS_FILES (1u << 0)
+#define PROCESS_DIRS (1u << 1)
+#define RECURSIVE (1u << 2)
+
+/* Flags that remote_ls passes to callback functions */
+#define IS_DIR (1u << 0)
+#endif
+
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
@@ -15,6 +44,7 @@ static struct curl_slist *no_pragma_head
struct alt_base
{
char *base;
+ int path_len;
int got_indices;
struct packed_git *packs;
struct alt_base *next;
@@ -56,8 +86,32 @@ struct alternates_request {
struct buffer *buffer;
struct active_request_slot *slot;
int http_specific;
+};
+
+#ifndef NO_EXPAT
+struct xml_ctx
+{
+ char *name;
+ int len;
+ char *cdata;
+ void (*userFunc)(struct xml_ctx *ctx, int tag_closed);
+ void *userData;
};
+struct remote_ls_ctx
+{
+ struct alt_base *repo;
+ char *path;
+ void (*userFunc)(struct remote_ls_ctx *ls);
+ void *userData;
+ int flags;
+ char *dentry_name;
+ int dentry_flags;
+ int rc;
+ struct remote_ls_ctx *parent;
+};
+#endif
+
static struct object_request *object_queue_head = NULL;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
@@ -500,6 +554,7 @@ static void process_alternates_response(
int serverlen = 0;
struct alt_base *newalt;
char *target = NULL;
+ char *path;
if (data[i] == '/') {
serverlen = strchr(base + 8, '/') - base;
okay = 1;
@@ -540,6 +595,13 @@ static void process_alternates_response(
newalt->base = target;
newalt->got_indices = 0;
newalt->packs = NULL;
+ path = strstr(target, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ newalt->path_len = strlen(path);
+ }
+
while (tail->next != NULL)
tail = tail->next;
tail->next = newalt;
@@ -608,9 +670,212 @@ #endif
got_alternates = -1;
free(data);
+ free(url);
+}
+
+#ifndef NO_EXPAT
+static void
+xml_start_tag(void *userData, const char *name, const char **atts)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ int new_len;
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ new_len = strlen(ctx->name) + strlen(c) + 2;
+
+ if (new_len > ctx->len) {
+ ctx->name = xrealloc(ctx->name, new_len);
+ ctx->len = new_len;
+ }
+ strcat(ctx->name, ".");
+ strcat(ctx->name, c);
+
+ if (ctx->cdata) {
+ free(ctx->cdata);
+ ctx->cdata = NULL;
+ }
+
+ ctx->userFunc(ctx, 0);
+}
+
+static void
+xml_end_tag(void *userData, const char *name)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ const char *c = index(name, ':');
+ char *ep;
+
+ ctx->userFunc(ctx, 1);
+
+ if (c == NULL)
+ c = name;
+ else
+ c++;
+
+ ep = ctx->name + strlen(ctx->name) - strlen(c) - 1;
+ *ep = 0;
+}
+
+static void
+xml_cdata(void *userData, const XML_Char *s, int len)
+{
+ struct xml_ctx *ctx = (struct xml_ctx *)userData;
+ if (ctx->cdata)
+ free(ctx->cdata);
+ ctx->cdata = xcalloc(len+1, 1);
+ strncpy(ctx->cdata, s, len);
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData);
+
+static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
+{
+ struct remote_ls_ctx *ls = (struct remote_ls_ctx *)ctx->userData;
+
+ if (tag_closed) {
+ if (!strcmp(ctx->name, DAV_PROPFIND_RESP) && ls->dentry_name) {
+ if (ls->dentry_flags & IS_DIR) {
+ if (ls->flags & PROCESS_DIRS) {
+ ls->userFunc(ls);
+ }
+ if (strcmp(ls->dentry_name, ls->path) &&
+ ls->flags & RECURSIVE) {
+ ls->rc = remote_ls(ls->repo,
+ ls->dentry_name,
+ ls->flags,
+ ls->userFunc,
+ ls->userData);
+ }
+ } else if (ls->flags & PROCESS_FILES) {
+ ls->userFunc(ls);
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
+ ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ ls->repo->path_len + 1);
+ strcpy(ls->dentry_name, ctx->cdata + ls->repo->path_len);
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
+ ls->dentry_flags |= IS_DIR;
+ }
+ } else if (!strcmp(ctx->name, DAV_PROPFIND_RESP)) {
+ if (ls->dentry_name) {
+ free(ls->dentry_name);
+ }
+ ls->dentry_name = NULL;
+ ls->dentry_flags = 0;
+ }
+}
+
+static int remote_ls(struct alt_base *repo, const char *path, int flags,
+ void (*userFunc)(struct remote_ls_ctx *ls),
+ void *userData)
+{
+ char *url = xmalloc(strlen(repo->base) + strlen(path) + 1);
+ struct active_request_slot *slot;
+ struct slot_results results;
+ struct buffer in_buffer;
+ struct buffer out_buffer;
+ char *in_data;
+ char *out_data;
+ XML_Parser parser = XML_ParserCreate(NULL);
+ enum XML_Status result;
+ struct curl_slist *dav_headers = NULL;
+ struct xml_ctx ctx;
+ struct remote_ls_ctx ls;
+
+ ls.flags = flags;
+ ls.repo = repo;
+ ls.path = strdup(path);
+ ls.dentry_name = NULL;
+ ls.dentry_flags = 0;
+ ls.userData = userData;
+ ls.userFunc = userFunc;
+ ls.rc = 0;
+
+ sprintf(url, "%s%s", repo->base, path);
+
+ out_buffer.size = strlen(PROPFIND_ALL_REQUEST);
+ out_data = xmalloc(out_buffer.size + 1);
+ snprintf(out_data, out_buffer.size + 1, PROPFIND_ALL_REQUEST);
+ out_buffer.posn = 0;
+ out_buffer.buffer = out_data;
+
+ in_buffer.size = 4096;
+ in_data = xmalloc(in_buffer.size);
+ in_buffer.posn = 0;
+ in_buffer.buffer = in_data;
+
+ dav_headers = curl_slist_append(dav_headers, "Depth: 1");
+ dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
+
+ slot = get_active_slot();
+ slot->results = &results;
+ curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (results.curl_result == CURLE_OK) {
+ ctx.name = xcalloc(10, 1);
+ ctx.len = 0;
+ ctx.cdata = NULL;
+ ctx.userFunc = handle_remote_ls_ctx;
+ ctx.userData = &ls;
+ XML_SetUserData(parser, &ctx);
+ XML_SetElementHandler(parser, xml_start_tag,
+ xml_end_tag);
+ XML_SetCharacterDataHandler(parser, xml_cdata);
+ result = XML_Parse(parser, in_buffer.buffer,
+ in_buffer.posn, 1);
+ free(ctx.name);
+
+ if (result != XML_STATUS_OK) {
+ ls.rc = error("XML error: %s",
+ XML_ErrorString(
+ XML_GetErrorCode(parser)));
+ }
+ } else {
+ ls.rc = -1;
+ }
+ } else {
+ ls.rc = error("Unable to start PROPFIND request");
+ }
+
+ free(ls.path);
free(url);
+ free(out_data);
+ free(in_buffer.buffer);
+ curl_slist_free_all(dav_headers);
+
+ return ls.rc;
}
+static void process_ls_pack(struct remote_ls_ctx *ls)
+{
+ unsigned char sha1[20];
+
+ if (strlen(ls->dentry_name) == 63 &&
+ !strncmp(ls->dentry_name, "objects/pack/pack-", 18) &&
+ !strncmp(ls->dentry_name+58, ".pack", 5)) {
+ get_sha1_hex(ls->dentry_name + 18, sha1);
+ setup_index(ls->repo, sha1);
+ }
+}
+#endif
+
static int fetch_indices(struct alt_base *repo)
{
unsigned char sha1[20];
@@ -632,6 +897,12 @@ static int fetch_indices(struct alt_base
if (get_verbosely)
fprintf(stderr, "Getting pack list for %s\n", repo->base);
+
+#ifndef NO_EXPAT
+ if (remote_ls(repo, "objects/pack/", PROCESS_FILES,
+ process_ls_pack, NULL) == 0)
+ return 0;
+#endif
url = xmalloc(strlen(repo->base) + 21);
sprintf(url, "%s/objects/info/packs", repo->base);
@@ -947,6 +1218,7 @@ int main(int argc, char **argv)
{
char *commit_id;
char *url;
+ char *path;
int arg = 1;
int rc = 0;
@@ -987,6 +1259,12 @@ int main(int argc, char **argv)
alt->got_indices = 0;
alt->packs = NULL;
alt->next = NULL;
+ path = strstr(url, "//");
+ if (path) {
+ path = index(path+2, '/');
+ if (path)
+ alt->path_len = strlen(path);
+ }
if (pull(commit_id))
rc = 1;
--
1.3.0.rc1.gd4df-dirty
^ permalink raw reply related
* [PATCH] Solaris needs strings.h when using index().
From: Peter Eriksen @ 2006-04-04 12:36 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 14:33:14 2006 +0200
Subject: [PATCH] Solaris needs strings.h when using index().
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
832067e6e16ae6c1ac3bd043ddeb56daa993e682
diff --git a/blame.c b/blame.c
index 396defc..1a08434 100644
--- a/blame.c
+++ b/blame.c
@@ -6,6 +6,7 @@ #include <assert.h>
#include <time.h>
#include <sys/time.h>
#include <math.h>
+#include <strings.h>
#include "cache.h"
#include "refs.h"
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
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