* [RFCv3 0/4] CVS remote helper
From: Johan Herland @ 2009-08-12 0:13 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, Johannes.Schindelin
Hi,
Another iteration of the patch series implementing a CVS remote helper, as
promised a couple of days ago. Changes from the previous iteration:
- Rebased on top of Daniel Barkalow's latest foreign VCS helpers work
(aka. 'db/vcs-helper' (early part)). This means that all the "generic"
foreign-scm patches that were part of the previous iteration are no
longer needed, and only the CVS remote helper patches remain.
Also, this series applies cleanly to current 'pu'.
- Replaced the "git-vcs-cvs" naming with "git-remote-cvs" throughout the code
and documentation.
- Minor updates to the git-remote-cvs implementation in order to more closely
follow the current remote helper API.
- Split up the patch series into somewhat smaller patches to (hopefully) be
allowed onto git@vger.kernel.org.
Have fun! :)
...Johan
Johan Herland (4):
Basic build infrastructure for Python scripts
Add Python support library for CVS remote helper
Third draft of CVS remote helper program
Add simple selftests of git-remote-cvs functionality
Documentation/git-remote-cvs.txt | 85 ++++
Makefile | 46 ++
configure.ac | 3 +
git-remote-cvs.py | 697 ++++++++++++++++++++++++++++
git_remote_cvs/.gitignore | 2 +
git_remote_cvs/Makefile | 27 ++
git_remote_cvs/changeset.py | 114 +++++
git_remote_cvs/commit_states.py | 52 +++
git_remote_cvs/cvs.py | 884 ++++++++++++++++++++++++++++++++++++
git_remote_cvs/cvs_revision_map.py | 362 +++++++++++++++
git_remote_cvs/cvs_symbol_cache.py | 283 ++++++++++++
git_remote_cvs/git.py | 586 ++++++++++++++++++++++++
git_remote_cvs/setup.py | 12 +
git_remote_cvs/util.py | 147 ++++++
t/t9800-remote-cvs-basic.sh | 524 +++++++++++++++++++++
t/t9801-remote-cvs-fetch.sh | 291 ++++++++++++
t/test-lib.sh | 1 +
17 files changed, 4116 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-remote-cvs.txt
create mode 100755 git-remote-cvs.py
create mode 100644 git_remote_cvs/.gitignore
create mode 100644 git_remote_cvs/Makefile
create mode 100644 git_remote_cvs/__init__.py
create mode 100644 git_remote_cvs/changeset.py
create mode 100644 git_remote_cvs/commit_states.py
create mode 100644 git_remote_cvs/cvs.py
create mode 100644 git_remote_cvs/cvs_revision_map.py
create mode 100644 git_remote_cvs/cvs_symbol_cache.py
create mode 100644 git_remote_cvs/git.py
create mode 100644 git_remote_cvs/setup.py
create mode 100644 git_remote_cvs/util.py
create mode 100755 t/t9800-remote-cvs-basic.sh
create mode 100755 t/t9801-remote-cvs-fetch.sh
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Johannes Schindelin @ 2009-08-12 0:14 UTC (permalink / raw)
To: Jeff King
Cc: Nanako Shiraishi, Bert Wesarg, Junio C Hamano, Daniel Barkalow,
git, Brian Gernhardt
In-Reply-To: <20090811230233.GA25642@coredump.intra.peff.net>
Hi,
On Tue, 11 Aug 2009, Jeff King wrote:
> On Wed, Aug 12, 2009 at 07:59:14AM +0900, Nanako Shiraishi wrote:
>
> > Then how about using a prefix that has been invalid, "vcs::$string",
> > for example?
>
> I have no problem with that, and I think it makes it even more visually
> obvious what is going. For example:
>
> svn::http://server/path/to/repo
>
> makes the "svn" prefix jump out a bit more.
... and http:://repo.or.cz/r/git.git ? Thanks. But no, thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Johannes Schindelin @ 2009-08-11 23:53 UTC (permalink / raw)
To: Jeff King
Cc: Bert Wesarg, Junio C Hamano, Daniel Barkalow, git,
Brian Gernhardt
In-Reply-To: <20090811214849.GA3868@sigill.intra.peff.net>
Hi,
On Tue, 11 Aug 2009, Jeff King wrote:
> On Tue, Aug 11, 2009 at 06:20:54PM +0200, Johannes Schindelin wrote:
>
> > > o [user@]host.xz:/path/to/repo.git/
> >
> > That is a valid concern. I'd suggest to disallow @ and . in the protocol
> > name (maybe even everything non-alnum). For shortcuts that really read
> > like "svn", I think it is not too much asked for to require adjusting the
> > URL (by prefixing ssh:// and adjusting the path).
> >
> > If there is really anybody who uses Git via ssh to access a server called
> > "svn", we could just as well have a little fun with them, don't you agree?
>
> It is not actually that unreasonable. I have remotes which point to:
>
> vcs:git/foo.git
That is still not "svn".
> where "vcs" is a shorthand for vcs.gtisc.gatech.edu, defined in my
> .ssh/config (it's a machine which hosts several different version
> control systems). So I could see somebody having something like "svn" if
> they were, e.g., hosting a git-to-svn conversion on their company's svn
> server.
If _I_ were to judge whether to make it convenient for computer-savvy
people like you who would have _no_ problem diagnosing the problem (_if_
they have the problem, having edited .ssh/config themselves!), who would
curse briefly, and then go on fixing the problem, or in the alternative
make it convenient for people who do not know their way around .ssh/config
as well as you (and who happen to make up the _vast_ majority of Git users
by now [*1*]), and who would really prefer to have an easy way to clone
"foreign" repositories, I have _no_ problem deciding which way to go.
So I'm a bastard. Big news. But I'm a pragmatic one.
Ciao,
Dscho
Footnote [*1*]: Maybe I was helping to increase the number of Git users
who do not know .ssh/config with my work on Git for Windows, but that was
not my original intention. Maybe I should start to feel better about
it...
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Artur Skawina @ 2009-08-11 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908111550470.28882@localhost.localdomain>
Linus Torvalds wrote:
>
> One thing that strikes me is that I've been just testing with gcc-4.4, and
> BenH (who did some tests on PPC where SHA1 is just _trivial_ because it
> all fits in the normal register space) noticed that older versions of gcc
> that he tested did much worse on this.
>
> I think Artur also posted (x86) numbers with older gcc versions doing
> worse. Maybe you're seeing some of that?
FWIW, this is how it looks here. On 32-bit x86 gcc4.4 makes a large
difference[1], but your code does fairly well w/ most gccs, relatively
to all the other C implementations.
artur
P4: [linusv is the recent one w/ the volatile stores]
### sha1bench-gcc295: GCCVER 2.95.4 20030502 (prerelease)
rfc3174 0.9438 64.67
linus 0.9081 67.21
linusv 0.4155 146.9
linusp4 0.8761 69.66
linusas 0.9619 63.45
linusas2 1.025 59.52
mozilla 1.314 46.46
mozillaas 1.132 53.92
### sha1bench-gcc31: GCCVER 3.2 2002-07-26 (prerelease)
rfc3174 0.8582 71.12
linus 0.7943 76.84
linusv 0.5667 107.7
linusp4 0.7224 84.48
linusas 0.7127 85.64
linusas2 0.5109 119.5
mozilla 1.251 48.79
mozillaas 1.239 49.27
### sha1bench-gcc32: GCCVER 3.2.3
rfc3174 0.9062 67.35
linus 0.5555 109.9
linusv 0.3647 167.4
linusp4 0.5337 114.4
linusas 0.7126 85.66
linusas2 0.5089 119.9
mozilla 1.138 53.64
mozillaas 1.075 56.78
### sha1bench-gcc33: GCCVER 3.3.6
rfc3174 0.9029 67.6
linus 0.6059 100.7
linusv 0.3734 163.4
linusp4 0.6695 91.16
linusas 0.7832 77.93
linusas2 0.571 106.9
mozilla 1.083 56.36
mozillaas 1.078 56.62
### sha1bench-gcc34: GCCVER 3.4.6 20060121 (prerelease)
rfc3174 0.9277 65.79
linus 0.6583 92.71
linusv 0.6096 100.1
linusp4 0.7326 83.31
linusas 0.7383 82.67
linusas2 0.6264 97.44
mozilla 1.398 43.67
mozillaas 1.392 43.84
### sha1bench-gcc40: GCCVER 4.0.4 20061113 (prerelease)
rfc3174 0.9889 61.72
linus 0.7508 81.29
linusv 0.7752 78.73
linusp4 0.6548 93.21
linusas 0.4904 124.5
linusas2 0.6378 95.7
mozilla 1.528 39.93
mozillaas 1.596 38.24
### sha1bench-gcc41: GCCVER 4.1.3 20080704 (prerelease)
rfc3174 0.9798 62.29
linus 0.6993 87.28
linusv 0.767 79.57
linusp4 0.6785 89.95
linusas 0.6555 93.11
linusas2 0.691 88.32
mozilla 1.594 38.3
mozillaas 1.566 38.98
### sha1bench-gcc42: GCCVER 4.2.5 20090330 (prerelease)
rfc3174 1.138 53.63
linus 0.7772 78.53
linusv 0.6138 99.43
linusp4 0.7018 86.97
linusas 0.8164 74.76
linusas2 0.7038 86.73
mozilla 1.697 35.97
mozillaas 1.491 40.94
### sha1bench-gcc43: GCCVER 4.3.5 20090810 (prerelease)
rfc3174 1.148 53.15
linus 0.7085 86.14
linusv 0.5474 111.5
linusp4 0.5399 113
linusas 0.7522 81.14
linusas2 0.5341 114.3
mozilla 1.723 35.43
mozillaas 1.502 40.64
### sha1bench-gcc44: GCCVER 4.4.2 20090809 (prerelease)
rfc3174 1.451 42.06
linus 0.5871 104
linusv 0.3713 164.4
linusp4 0.4367 139.8
linusas 0.4083 149.5
linusas2 0.4372 139.6
mozilla 1.104 55.27
mozillaas 1.314 46.44
And on Atom:
### sha1bench-gcc295: GCCVER 2.95.4 20030502 (prerelease)
rfc3174 1.905 32.04
linus 1.089 56.06
linusv 0.8134 75.04
linusp4 1.086 56.19
linusas 1.009 60.52
linusas2 1.255 48.63
mozilla 2.663 22.92
### sha1bench-gcc31: GCCVER 3.2 2002-07-26 (prerelease)
rfc3174 2.141 28.51
linus 1.022 59.75
linusv 0.8323 73.34
linusp4 1.061 57.54
linusas 0.9889 61.72
linusas2 0.9204 66.32
mozilla 2.573 23.72
### sha1bench-gcc32: GCCVER 3.2.3
rfc3174 2.155 28.32
linus 0.9031 67.58
linusv 0.7849 77.76
linusp4 0.847 72.06
linusas 0.9888 61.73
linusas2 0.912 66.93
mozilla 2.485 24.56
### sha1bench-gcc33: GCCVER 3.3.6
rfc3174 2.178 28.02
linus 0.9489 64.32
linusv 0.8642 70.63
linusp4 0.8784 69.48
linusas 1.017 60.03
linusas2 0.906 67.37
mozilla 2.541 24.02
### sha1bench-gcc34: GCCVER 3.4.6 20060121 (prerelease)
rfc3174 2.157 28.3
linus 0.9481 64.37
linusv 0.8383 72.8
linusp4 0.965 63.25
linusas 0.9852 61.95
linusas2 0.9809 62.22
mozilla 3.143 19.42
### sha1bench-gcc40: GCCVER 4.0.4 20061113 (prerelease)
rfc3174 2.088 29.24
linus 0.9706 62.89
linusv 0.928 65.77
linusp4 1.003 60.85
linusas 0.9478 64.4
linusas2 0.9475 64.42
mozilla 2.742 22.26
### sha1bench-gcc41: GCCVER 4.1.3 20080704 (prerelease)
rfc3174 2.047 29.81
linus 0.9778 62.42
linusv 1.051 58.06
linusp4 1.062 57.46
linusas 1.052 58.01
linusas2 1.069 57.12
mozilla 2.6 23.47
### sha1bench-gcc42: GCCVER 4.2.5 20090330 (prerelease)
rfc3174 2.025 30.14
linus 0.9622 63.43
linusv 0.7984 76.44
linusp4 0.8967 68.07
linusas 1.018 59.94
linusas2 0.9048 67.46
mozilla 2.748 22.21
### sha1bench-gcc43: GCCVER 4.3.5 20090810 (prerelease)
rfc3174 2.043 29.88
linus 0.9436 64.69
linusv 0.8532 71.54
linusp4 0.8531 71.54
linusas 1.04 58.71
linusas2 0.8495 71.85
mozilla 2.678 22.79
### sha1bench-gcc44: GCCVER 4.4.2 20090809 (prerelease)
rfc3174 2.119 28.8
linus 0.9132 66.84
linusv 0.8632 70.71
linusp4 0.9842 62.02
linusas 1.027 59.45
linusas2 0.9844 62
mozilla 2.214 27.57
^ permalink raw reply
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Ori Avtalion @ 2009-08-11 23:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20090812075946.6117@nanako3.lavabit.com>
On 08/12/2009 01:59 AM, Nanako Shiraishi wrote:
>> -git-mailsplit - Simple UNIX mbox splitter program
>> +git-mailsplit - Simple UNIX mbox splitter
>>
>> SYNOPSIS
>> --------
>
> Sorry, but I don't understand why it is necessary.
>
It's another case where a command is called a "program" when, to the
user, it's simply a command such as "git mailsplit". Having the word
"command" in a command description is redundant, so I just dropped the word.
And here's another command with a similar description that I missed before:
"git-merge-one-file - The standard helper *program* to use with
git-merge-index"
^ permalink raw reply
* Re: [RFC/PATCH 5/6] Let transport_helper_init() decide if a remote helper program can be used
From: Daniel Barkalow @ 2009-08-11 23:28 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster, benji, Johannes.Schindelin
In-Reply-To: <1249985426-13726-6-git-send-email-johan@herland.net>
On Tue, 11 Aug 2009, Johan Herland wrote:
> @@ -293,6 +301,16 @@ int transport_helper_init(struct transport *transport)
> data->name = xstrndup(transport->url, eom - transport->url);
> }
>
> + strbuf_addf(&buf, "remote-%s", data->name);
> + cmd = strbuf_detach(&buf, NULL);
> + if (!is_git_command_or_alias(cmd)) {
> + warning("Could not find remote helper command \"git %s\". Assuming native remote.", cmd);
Won't this give you a warning for:
url = master.kernel.org:something
of 'Could not find (...) "git remote-master.kernel.org" (...)'? That
would be certain to upset some people. I think we can assume that people's
scheme parts of their URLs that are actually URLs don't contain '.', and
that people with:
url = master:something
will append their domains if the warning gets annoying.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: sharing git work while downstream from svn?
From: Avery Pennarun @ 2009-08-11 23:17 UTC (permalink / raw)
To: tom fogal; +Cc: git
In-Reply-To: <auto-000020209671@sci.utah.edu>
On Tue, Aug 11, 2009 at 11:14 PM, tom fogal<tfogal@alumni.unh.edu> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> wrote:
>> > This gets to be a mess when trunk changes: I'll rebase + potentially
>> > fix some conflicts. Other developers with some of the experimental
>> > patches will svn update, and get similar conflicts. These might differ
>> > in subtle ways, and now exchanging patches gets more difficult.
>>
>> Instead, do all your work in a branch *other* than the git-svn main
>> branch. When you're ready to merge your stuff into svn, do:
> [snip]
>> This basically results in a *single* commit getting sent to svn,
>> rather than the batch of all the git commits you've been working
>> on. Most svn users don't care about this, because they lose all that
>> granularity whenever they merge a branch anyhow.
>
> ... but I, as a git user forced to live in an svn world, *do* value all
> of that history. When I find a bug a month later, I want git-bisect
> to be useful. Further, when I'm reviewing sets of changes in a search
> for some particular change, I want to be able to skip over large sets
> of patches simply by looking at the first line of a commit log. If I
> squash all that history down, I have to wade into the patch itself.
That's the great thing! Your git history never gets lost with this
technique, since you *never* rewind any branches. The detailed
history just never makes it into svn, which has no way of representing
it anyhow.
As a bonus, the fact that your git history becomes more and more
detailed vs. the svn history slowly makes your case for switching
everybody else to git that much stronger :)
Have fun,
Avery
P.S. Shameless plug: I wrote the chapter about git-svn in O'Reilly's
"Version Control With Git," in which I described this technique in
more detail. (I *don't* make any money on commissions on that book,
as I'm not the primary author.)
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Linus Torvalds @ 2009-08-11 23:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908111550470.28882@localhost.localdomain>
On Tue, 11 Aug 2009, Linus Torvalds wrote:
>
>
> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >
> > Well... gcc is really strange in this case (and similar other ones) with
> > ARM compilation. A good indicator of the quality of the code is the
> > size of the stack frame. When using the "+m" then gcc creates a 816
> > byte stack frame, the generated binary grows by approx 3000 bytes, and
> > performances is almost halved (7.600s). Looking at the assembly result
> > I just can't figure out all the crazy moves taking place. Even the
> > version with no barrier what so ever produces better assembly with a
> > stack frame of 560 bytes.
>
> Ok, that's just crazy. That function has a required stack size of exactly
> 64 bytes, and anything more than that is just spilling. And if you end up
> with a stack frame of 560 bytes, that means that gcc is doing some _crazy_
> spilling.
Btw, what I think happens is:
- gcc turns all those array accesses into pseudo's
So now the 'array[16]' is seen as just another 16 variables rather than
an array.
- gcc then turns it into SSA, where each assignment basically creates a
new variable. So the 16 array variables (and 5 regular variables) are
now expanded to 80 SSA asignments (one array assignment per SHA1 round)
plus an additional 2 assignments to the "regular" variables per round
(B and E are changed each round). So in SSA form, you actually end up
having 240 pseudo's associated with the actual variables. Plus all
the temporaries of course.
- the thing then goes crazy and tries to generate great code from that
internal SSA model. And since there are never more than ~25 things
_live_ at any particular point, it works fine with lots of registers,
but on small-register machines gcc just goes crazy and has to spill.
And it doesn't spill 'array[x]' entries - it spills the _pseudo's_ it
has created - hundreds of them.
- End result: if the spill code doesn't share slots, it's going to create
a totally unholy mess of crap.
That's what the whole 'volatile unsigned int *' game tried to avoid. But
it really sounds like it's not working too well for you. And the _big_
memory barrier ends up helping just because with that in place, you end up
being almost entirely unable to schedule _anything_ between the different
SHA rounds, so you end up with only six or seven variables "live" in
between those barriers, and the stupid register allocator/spill logic
doesn't break down too badly.
The thing is, if you do full memory barriers, then you're probably better
off making both the loads and the stores be "volatile". That should have
similar effects.
The downside with that is that it really limits the loads. So (like the
full memory barrier) it's a big hammer approach. But it probably generates
better code for you, because it avoids the mental breakdown of gcc
spilling its pseudo's.
Linus
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Brandon Casey @ 2009-08-11 23:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0908111553460.28882@localhost.localdomain>
Linus Torvalds wrote:
>
> On Tue, 11 Aug 2009, Brandon Casey wrote:
>> In that case, why not change the interface of blk_SHA1Block() so that its
>> second argument is const unsigned char* and get rid of __d and the { } ?
>
> Because on big-endian, or on architectures like x86 that have an efficient
> byte swap, that would be horrible.
Sorry, I missed Nicolas's first message where he said his SHA_SRC macro was
for arm only.
I started at your reply to him which only has the snippet which says
"...this provides the exact same performance as the ntohl() based version
except that this now cope with unaligned buffers too".
My mistake.
-brandon
^ permalink raw reply
* Re: sharing git work while downstream from svn?
From: tom fogal @ 2009-08-11 23:14 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130908111603v1e3f6c42peac792caf7097e0d@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> wrote:
> > This gets to be a mess when trunk changes: I'll rebase + potentially
> > fix some conflicts. Other developers with some of the experimental
> > patches will svn update, and get similar conflicts. These might differ
> > in subtle ways, and now exchanging patches gets more difficult.
>
> Instead, do all your work in a branch *other* than the git-svn main
> branch. When you're ready to merge your stuff into svn, do:
[snip]
> This basically results in a *single* commit getting sent to svn,
> rather than the batch of all the git commits you've been working
> on. Most svn users don't care about this, because they lose all that
> granularity whenever they merge a branch anyhow.
... but I, as a git user forced to live in an svn world, *do* value all
of that history. When I find a bug a month later, I want git-bisect
to be useful. Further, when I'm reviewing sets of changes in a search
for some particular change, I want to be able to skip over large sets
of patches simply by looking at the first line of a commit log. If I
squash all that history down, I have to wade into the patch itself.
-tom
^ permalink raw reply
* Re: sharing git work while downstream from svn?
From: Avery Pennarun @ 2009-08-11 23:03 UTC (permalink / raw)
To: tfogal; +Cc: git
In-Reply-To: <auto-000020209577@sci.utah.edu>
On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> wrote:
> This gets to be a mess when trunk changes: I'll rebase + potentially
> fix some conflicts. Other developers with some of the experimental
> patches will svn update, and get similar conflicts. These might differ
> in subtle ways, and now exchanging patches gets more difficult.
We use git-svn at Versabanq, and our process is very simple: never use
rebase, period.
Instead, do all your work in a branch *other* than the git-svn main
branch. When you're ready to merge your stuff into svn, do:
git checkout git-svn
git svn rebase
git checkout myworkingbranch
git merge git-svn
# and resolve any conflicts
git checkout git-svn
git merge --no-ff myworkingbranch # the --no-ff is very important here!
git svn dcommit
This basically results in a *single* commit getting sent to svn,
rather than the batch of all the git commits you've been working on.
Most svn users don't care about this, because they lose all that
granularity whenever they merge a branch anyhow. Meanwhile, all your
git users never have to worry about rebasing *anything* and can use
the normal git merge/pull stuff.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Jeff King @ 2009-08-11 23:02 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Bert Wesarg, Junio C Hamano, Daniel Barkalow,
git, Brian Gernhardt
In-Reply-To: <20090812075914.6117@nanako3.lavabit.com>
On Wed, Aug 12, 2009 at 07:59:14AM +0900, Nanako Shiraishi wrote:
> Then how about using a prefix that has been invalid, "vcs::$string",
> for example?
I have no problem with that, and I think it makes it even more visually
obvious what is going. For example:
svn::http://server/path/to/repo
makes the "svn" prefix jump out a bit more.
-Peff
^ permalink raw reply
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Nanako Shiraishi @ 2009-08-11 22:59 UTC (permalink / raw)
To: Ori Avtalion; +Cc: Junio C Hamano, git
In-Reply-To: <4A815AAC.2030601@avtalion.name>
Quoting Ori Avtalion <ori@avtalion.name>
> On 08/11/2009 06:58 AM, Nanako Shiraishi wrote:
>> From: Ori Avtalion<ori@avtalion.name>
>> Date: Fri, 7 Aug 2009 17:24:21 +0300
>> Subject: [PATCH] Change mentions of "git programs" to "git commands"
>>
>> Most of the docs and printouts refer to "commands" when discussing what
>> the end users call via the "git" top-level program. We should refer them
>> as "git programs" when we discuss the fact that the commands are
>> implemented as separate programs, but in other contexts, it is better to
>> use the term "git commands" consistently.
>>
>> Signed-off-by: Ori Avtalion<ori@avtalion.name>
>> Signed-off-by: Nanako Shiraishi<nanako3@lavabit.com>
>> ---
>>
>
> Thanks Nanako!
You're welcome, and sorry if I sounded as if I was accusing that you were
wasting other's time by not re-submitting sooner. I only wanted to see a
good patch go in.
> You might want to consider this patch too:
>
> diff --git a/Documentation/git-mailsplit.txt
> b/Documentation/git-mailsplit.txt
> index 5cc94ec..8f1b99b 100644
> --- a/Documentation/git-mailsplit.txt
> +++ b/Documentation/git-mailsplit.txt
> @@ -3,7 +3,7 @@ git-mailsplit(1)
>
> NAME
> ----
> -git-mailsplit - Simple UNIX mbox splitter program
> +git-mailsplit - Simple UNIX mbox splitter
>
> SYNOPSIS
> --------
Sorry, but I don't understand why it is necessary.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Linus Torvalds @ 2009-08-11 22:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: Nicolas Pitre, Git Mailing List, Junio C Hamano
In-Reply-To: <fLYKSyures_wcvAvAV9-MgKQlhk959HJpx-pKz7T1n-Mel7f2RBkMw@cipher.nrlssc.navy.mil>
On Tue, 11 Aug 2009, Brandon Casey wrote:
>
> In that case, why not change the interface of blk_SHA1Block() so that its
> second argument is const unsigned char* and get rid of __d and the { } ?
Because on big-endian, or on architectures like x86 that have an efficient
byte swap, that would be horrible.
You absoluetoy MUST NOT do things a byte at a time in those cases. The
memory operations and the shifting just kills you.
The reason you want to do things a byte at a time on ARM is that ARM
cannot do unaligned accesses well (very modern cores are better, but
rare), and that ARM has no bswap instruction and has fairly cheap shifts.
On no sane architecture is that true. Unaligned loads are fast (and quite
frankly, hardware where unaliged loads aren't fast is just crazy sh*t),
and doing 'bswap' is way faster than doing many shifts and masks.
So everything should be fundamentally word-oriented. Then, broken
architectures that can't handle it should split up the words, not the
other way around.
Linus
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Linus Torvalds @ 2009-08-11 22:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0908111437160.10633@xanadu.home>
On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>
> Well... gcc is really strange in this case (and similar other ones) with
> ARM compilation. A good indicator of the quality of the code is the
> size of the stack frame. When using the "+m" then gcc creates a 816
> byte stack frame, the generated binary grows by approx 3000 bytes, and
> performances is almost halved (7.600s). Looking at the assembly result
> I just can't figure out all the crazy moves taking place. Even the
> version with no barrier what so ever produces better assembly with a
> stack frame of 560 bytes.
Ok, that's just crazy. That function has a required stack size of exactly
64 bytes, and anything more than that is just spilling. And if you end up
with a stack frame of 560 bytes, that means that gcc is doing some _crazy_
spilling.
One thing that strikes me is that I've been just testing with gcc-4.4, and
BenH (who did some tests on PPC where SHA1 is just _trivial_ because it
all fits in the normal register space) noticed that older versions of gcc
that he tested did much worse on this.
I think Artur also posted (x86) numbers with older gcc versions doing
worse. Maybe you're seeing some of that?
Linus
^ permalink raw reply
* sharing git work while downstream from svn?
From: tom fogal @ 2009-08-11 22:55 UTC (permalink / raw)
To: git
How do others manage distributed version control when everyone is
forced to rebase all the time?
To give a concrete example: in one project where I have this issue,
there's a developer who is effectively 'downstream' from me. There's
a few other developers who are peers, w/ commit bits set on the
centralized server. I'll make some patches that should end up on our
centralized trunk, and some that our for our experimental sub-project,
so I use format-patch and send patches around for those.
This gets to be a mess when trunk changes: I'll rebase + potentially
fix some conflicts. Other developers with some of the experimental
patches will svn update, and get similar conflicts. These might differ
in subtle ways, and now exchanging patches gets more difficult.
I'm not sure getting them to use git would even help. Once I rebase,
I screw my downstream. Yet I can't avoid rebasing since I need to
update.
As I recall, some members of the gcc community are handling this
problem, somehow. How do you do it? Or do you just not collaborate at
the git level?
Thanks,
-tom
^ permalink raw reply
* Re: [EGIT] Push to GitHub caused corruption
From: John Bito @ 2009-08-11 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <200908110810.45369.robin.rosenberg@gmail.com>
Running git fsck -full on the repo that I pushed from is clean.
Here's the git fsck -full from GitHub
<mojombo> git fsck --full
<mojombo> broken link from tree
f4f9ecd1875938baa42467dfd6a8134d75fe5de4 to tree
57548924f1eca854dc8db00844f95d3de2c82957
<mojombo> broken link from tree
f4f9ecd1875938baa42467dfd6a8134d75fe5de4 to tree
3d1f74522c3e7c3c03390fae376446fda6eed306
<mojombo> missing tree 3d1f74522c3e7c3c03390fae376446fda6eed306
<mojombo> missing tree 57548924f1eca854dc8db00844f95d3de2c82957
<mojombo> dangling commit ab6ce47159c1eaff0e4bae19291679267de9f669
The repo on GitHub is back where it was before the push. I have a
copy of the corrupt one from GitHub (358MB tar.gz). If there's
something I can do that would help to improve JGit/EGit, please let me
know.
Thanks,
John
On Mon, Aug 10, 2009 at 23:10, Robin Rosenberg<robin.rosenberg@gmail.com> wrote:
> måndag 10 augusti 2009 23:46:34 skrev John Bito <jwbito@gmail.com>:
>> Using the 'release' build of EGit (0.4.9.200906240051) I pushed a
>> commit to GitHub. After that, using git to pull, I get 'bad tree
>> object' resulting in 'remote: aborting due to possible repository
>> corruption on the remote side'. I had a similar problem back in April
>> (using integration builds of 0.4.0). I'm willing to investigate if
>> there's interest in finding the root of the problem.
>
> Fixing problems related to repository integrity is definitely interesting. One
> can live all kinds of problem, as long as they don't destroy anything.
>
> -- robin
>
>
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Nicolas Sebrecht @ 2009-08-11 22:14 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908111343v73fa475fqb6353dcf2f718101@mail.gmail.com>
The 11/08/09, skillzero@gmail.com wrote:
> Sorry if this is dumb question, but I didn't see any good info in my searches.
>
> How do gmail users normally apply patches that come through the list?
It doesn't rely on your address mail provider but on your local email
workflow/MUA.
> Do you just manually copy and paste the email to patch files and use
> git apply? Do you use a tool to export to mbox files and use git am?
Yes, that's what most users do. As I use local maildirs instead of
mailboxes, I copy the patches (from mutt) into a dedicated maildir (one
per project) and directly 'git am' the e-mails.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support sparse checkout in unpack_trees() and read-tree
From: skillzero @ 2009-08-11 22:03 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Junio C Hamano
In-Reply-To: <m3ab26owub.fsf@localhost.localdomain>
On Tue, Aug 11, 2009 at 2:38 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> skillzero@gmail.com writes:
>> 2009/8/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
>> > [1] .git/info/sparse has the same syntax as .git/info/exclude. Files
>> > that match the patterns will be set as CE_VALID.
>>
>> Does this mean it will only support excluding paths you don't want
>> rather than letting you only include paths you do want?
>
> Errr... what I read is that paths set by .git/info/sparse would be
> excluded from checkout (marked as assume-unchanged / CE_VALID).
>
> But if it is the same mechanism as gitignore, then you can use !
> prefix to set files (patterns) to include, e.g.
>
> !Documentation/
> *
>
> (I think rules are processed top-down, first matching wins).
I wasn't sure because the .gitignore negation stuff mentions negating
a previously ignored pattern. But for sparse patterns, there likely
wouldn't be a previous pattern. Include patterns are a little
different in that if there are no include patterns (but maybe some
exclude patterns), I think the expectation is that everything will be
included (minus excludes), but if you have some include patterns then
only those paths will be included (minus any excludes).
It's great if it already supports includes as well as excludes
(although it's a little confusing to say !Documentation to mean
"include it"), but I wasn't sure from the comment so I was just
asking.
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Brandon Casey @ 2009-08-11 21:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0908111735010.10633@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 11 Aug 2009, Brandon Casey wrote:
>
>> Nicolas Pitre wrote:
>>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>>>
>>>> On Tue, 11 Aug 2009, Linus Torvalds wrote:
>>>>
>>>>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>>>>>> #define SHA_SRC(t) \
>>>>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
>>>>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
>>>>>>
>>>>>> And this provides the exact same performance as the ntohl() based
>>>>>> version (4.980s) except that this now cope with unaligned buffers too.
>>>>> The actual object SHA1 calculations are likely not aligned (we do that
>>>>> object header thing), and if you can't do the htonl() any better way I
>>>>> guess the byte-based thing is the way to go..
>>> OK, even better: 4.400s.
>>>
>>> This is with this instead of the above:
>>>
>>> #define SHA_SRC(t) \
>>> ({ unsigned char *__d = (unsigned char *)data; \
>>> (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
>>> (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
>>>
>>> The previous version would allocate a new register for __d and then
>>> index it with an offset of 0, 1, 2 or 3. This version always uses the
>>> register containing the data pointer with absolute offsets. The binary
>>> is a bit smaller too.
>> In that case, why not change the interface of blk_SHA1Block() so that its
>> second argument is const unsigned char* and get rid of __d and the { } ?
>
> Because not all architectures care to access the data bytewise. Please
> see the original SHA_SRC definition.
You mean this:
#define SHA_SRC(t) htonl(data[t])
? Or was there a definition before this one?
I don't follow what you are saying. Are you saying that the following two
examples are different?
unsigned int *data;
#define SHA_SRC(t) \
({ unsigned char *__d = (unsigned char *)data; \
(__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
(__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
and
unsigned char *data;
#define SHA_SRC(t) \
( (data[(t)*4 + 0] << 24) | (data[(t)*4 + 1] << 16) | \
(data[(t)*4 + 2] << 8) | (data[(t)*4 + 3] << 0) )
-brandon
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Jeff King @ 2009-08-11 21:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Bert Wesarg, Junio C Hamano, Daniel Barkalow, git,
Brian Gernhardt
In-Reply-To: <alpine.DEB.1.00.0908111817490.4638@intel-tinevez-2-302>
On Tue, Aug 11, 2009 at 06:20:54PM +0200, Johannes Schindelin wrote:
> > o [user@]host.xz:/path/to/repo.git/
>
> That is a valid concern. I'd suggest to disallow @ and . in the protocol
> name (maybe even everything non-alnum). For shortcuts that really read
> like "svn", I think it is not too much asked for to require adjusting the
> URL (by prefixing ssh:// and adjusting the path).
>
> If there is really anybody who uses Git via ssh to access a server called
> "svn", we could just as well have a little fun with them, don't you agree?
It is not actually that unreasonable. I have remotes which point to:
vcs:git/foo.git
where "vcs" is a shorthand for vcs.gtisc.gatech.edu, defined in my
.ssh/config (it's a machine which hosts several different version
control systems). So I could see somebody having something like "svn" if
they were, e.g., hosting a git-to-svn conversion on their company's svn
server.
And as far as asking people in such a situation to change, consider:
1. No matter how small a change, asking for a change means you are
breaking people's current config.
2. ssh:// really is inferior, especially if you are typing it on the
command-line as part of a one-off pull. It is really convenient to
assume you start in your home directory (as above), and to be able
to use tilde-notation to point to the home directories of others
(e.g., "git pull vcs:~mike/foo.git").
-Peff
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support sparse checkout in unpack_trees() and read-tree
From: Jakub Narebski @ 2009-08-11 21:38 UTC (permalink / raw)
To: skillzero
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Junio C Hamano
In-Reply-To: <2729632a0908111418m57e03d8as9c122cbb52efc21a@mail.gmail.com>
skillzero@gmail.com writes:
> 2009/8/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> > [1] .git/info/sparse has the same syntax as .git/info/exclude. Files
> > that match the patterns will be set as CE_VALID.
>
> Does this mean it will only support excluding paths you don't want
> rather than letting you only include paths you do want?
Errr... what I read is that paths set by .git/info/sparse would be
excluded from checkout (marked as assume-unchanged / CE_VALID).
But if it is the same mechanism as gitignore, then you can use !
prefix to set files (patterns) to include, e.g.
!Documentation/
*
(I think rules are processed top-down, first matching wins).
> I'm currently using your other patch series that lets you include or
> exclude paths (via config variable) and I find that I mostly use the
> include side of it with only a few excluded paths. This is because I
> typically want to include only a small subset of the repository so
> using excludes would require a pretty large list and any time somebody
> adds new files, I'd have to update the exclude list.
Not true, see above.
--
Jakub Narebski
Git User's Survey 2009
http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Nicolas Pitre @ 2009-08-11 21:36 UTC (permalink / raw)
To: Brandon Casey; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <fLYKSyures_wcvAvAV9-MgKQlhk959HJpx-pKz7T1n-Mel7f2RBkMw@cipher.nrlssc.navy.mil>
On Tue, 11 Aug 2009, Brandon Casey wrote:
> Nicolas Pitre wrote:
> > On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >
> >> On Tue, 11 Aug 2009, Linus Torvalds wrote:
> >>
> >>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >>>> #define SHA_SRC(t) \
> >>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
> >>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
> >>>>
> >>>> And this provides the exact same performance as the ntohl() based
> >>>> version (4.980s) except that this now cope with unaligned buffers too.
> >>> The actual object SHA1 calculations are likely not aligned (we do that
> >>> object header thing), and if you can't do the htonl() any better way I
> >>> guess the byte-based thing is the way to go..
> >
> > OK, even better: 4.400s.
> >
> > This is with this instead of the above:
> >
> > #define SHA_SRC(t) \
> > ({ unsigned char *__d = (unsigned char *)data; \
> > (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
> > (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
> >
> > The previous version would allocate a new register for __d and then
> > index it with an offset of 0, 1, 2 or 3. This version always uses the
> > register containing the data pointer with absolute offsets. The binary
> > is a bit smaller too.
>
> In that case, why not change the interface of blk_SHA1Block() so that its
> second argument is const unsigned char* and get rid of __d and the { } ?
Because not all architectures care to access the data bytewise. Please
see the original SHA_SRC definition.
Nicolas
^ permalink raw reply
* Re: git gc expanding packed data?
From: Nicolas Pitre @ 2009-08-11 21:33 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: git
In-Reply-To: <3ace41890908110317k6e6ada07jc39ea446f9fa246e@mail.gmail.com>
On Tue, 11 Aug 2009, Hin-Tak Leung wrote:
> On Wed, Aug 5, 2009 at 11:39 PM, Nicolas Pitre<nico@cam.org> wrote:
> > Anyway... To solve your problem, you simply need to run 'git gc' with
> > the --prune=now argument to disable that grace period and get rid of
> > those unreferenced objects right away (safe only if no other git
> > activities are taking place at the same time which should be easy to
> > ensure on a workstation). The resulting .git/objects directory size
> > will shrink to about 441 MB. If the gcc.gnu.org git server was doing
> > its job properly, the size of the clone transfer would also be
> > significantly smaller, meaning around 414 MB instead of the current 600+
> > MB.
> >
> > And BTW, using 'git gc --aggressive' with a later git version (or
> > 'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects
> > directory size of 310 MB, meaning that the actual repository with all
> > the trunk history is _smaller_ than the actual source checkout. If that
> > repository was properly repacked on the server, the clone data transfer
> > would be 283 MB. This is less than half the current clone transfer
> > size.
> >
> >
> > Nicolas
> >
>
> 'git gc --prune=now' does work, but 'git gc --prune=now --aggressive'
> (before) and 'git gc --aggressive' (after) both create very large
> (>2GB; I stopped it) packs from the ~400MB-600MB packed objects. I
> noted that you specifically wrote 'with a later git version' -
> presumably there is a some sort of a known and fixed issue there? Just
> curious.
>From git v1.6.3 the --aggressive switch makes for 'git repack' to be
called with --window=250 --depth=250, meaning the equivalent of:
git repack -a -d -f --window=250 --depth=250
Do you still get a huge pack with the above?
> I guess --aggressive doesn't always save space...
If so that is (and was) a bug.
Nicolas
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Emmanuel Trillaud @ 2009-08-11 21:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0908111355m1a15d81cs7f33e1bbc5e1701b@mail.gmail.com>
Huuu! Sorry!
I read your mail too fast.
If you manage to save the interresting mails localy in the mailbox
format (claws mail and thunderbird can do that), you can
then use 'git am' to apply the patches (an example:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Integrator).
Best regards
Emmanuel Trillaud
Le Tue, 11 Aug 2009 13:55:38 -0700,
Sverre Rabbelier <srabbelier@gmail.com> a écrit :
> Heya,
>
> On Tue, Aug 11, 2009 at 13:47, Emmanuel Trillaud<etrillaud@gmail.com>
> wrote:
> > To quote Documentation/SubmittingPatches:
>
> Not relevant, these instructions are for the other way around; that
> is, sending your patches _to_ the ML, rather than getting patches
> _from_ the ML.
>
^ 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