* Re: how to properly update dumb-hosted repo (using rsync..?)
From: Junio C Hamano @ 2007-12-17 23:46 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20712171511r41e6bd4p64d243747ad4d2af@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
> $ git-pull
> Warning: No merge candidate found because value of config option
> "branch.master.merge" does not match any remote branch fetched.
> No changes.
> -------------------
>
> However I haven't done any branching in this cloned repo, it is
> immediately after a git-clone from the web server.
>
> My .git/config basically looks like this, minus the "core" section:
>
> -------------------
> [remote "origin"]
> url = http://my.server.com/git/project.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> -------------------
>
> Which seems fine to me...
> Any ideas?
A dumb question. does "git ls-remote origin" show what you expect to be
there? Specifically, does refs/heads/master exist?
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-18 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vprx553u4.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 02:55:15PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > Hm. We tell people to set up public repo's by doing something like:
> >
> > git clone --bare ~/proj proj.git
> > touch proj.git/git-daemon-export-ok
> > scp -r proj.git example.com:
> >
> > Is that going to hit the same problem if the public server has an older
> > git version?
>
> It will, but I think you should teach people --mirror pushing these
> days, which was specifically invented for priming the public
> repository.
>
> That way, the administrator at example.com, as long as he initializes an
> empty repository with suitable daemon-export-ok and necessary hooks
> (which can be automated via templates), does not even have to allow you
> a full ssh access.
So the basic instructions would be something like this?:
ssh example.com "git init --bare myproj.git"
# (or ask your admin to do the previous step)
git add remote example example.com:myproj.git
git push --mirror example
OK, that's neat, thanks.
On the backwards-compatibility issue, though: this won't help the large
number of people who learned to just clone a bare repo and copy it
around, since they aren't of their own initiative going to seek out new
ways of doing things that they think they already know how to do.
--b.
^ permalink raw reply
* Re: git annotate runs out of memory
From: Linus Torvalds @ 2007-12-18 0:05 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jeff King, Daniel Berlin, Git Mailing List
In-Reply-To: <20071217232450.GA13012@efreet.light.src>
On Tue, 18 Dec 2007, Jan Hudec wrote:
> On Tue, Dec 11, 2007 at 11:50:08AM -0800, Linus Torvalds wrote:
> > And, btw: the diff is totally different from the xdelta we have, so even
> > if we have an already prepared nice xdelta between the two versions, we'll
> > end up re-generating the files in full, and then do a diff on the end
> > result.
>
> The problem is whether git does not end-up re-generating the same file
> multiple times. When it needs to construct the diff between two versions of
> a file and one is delta-base (even indirect) of the other, does it know to
> create the first, remember it, continue to the other and calculate the diff?
Yes.
Actually, it doesn't "know" anything at all - what happens is that git
internally has a simple "delta-cache", which just caches the latest
objects we've generated from deltas, and which automatically handles this
common case (and others).
So when we tend to work with multiple versions of the same file (which is
obviously very common with diff, and even more so with something like
"annotate"), those multiple versions will obviously also tend to be deltas
against each other and/or against some shared base object, and when we see
a delta, we'll look the base object up in the delta cache, and if it has
been generated earlier we'll be able to short-circuit the whole delta
chain and just use the whole object we already cached.
So if you compare two objects that each have a very deep delta chain, you
will obviously have to walk the whole delta chain _once_ (to generate
whichever version of the file you happen to look up first), but you won't
need to do it twice, because the second time you'll end up hitting in the
delta cache.
Linus
^ permalink raw reply
* Re: [PATCH] Clean up documentation that references deprecated 'git peek-remote'.
From: Junio C Hamano @ 2007-12-18 0:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1197882503-4296-1-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Now that 'git peek-remote' is deprecated and only an alias for
> 'git ls-remote', it should not be referenced from other manual pages.
>
> This also removes the description of the --exec option, which is no
> longer present.
It seems to be supported as a backward compatibility option but not
shown in the short help. Removal of it from the documentation is
alright nevertheless.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Jakub Narebski @ 2007-12-18 0:12 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Petr Baudis
In-Reply-To: <200712151536.33296.jnareb@gmail.com>
On Sat, 15 Dec 2007, Jakub Narebski wrote:
> This is important for the list of clone urls, where if there are
> no per-repository clone URL configured, the default base URLs
> are never used for URL construction without this patch.
>
> Add tests for different ways of setting project URLs, just in case.
> Note that those tests in current form wouldn't detect breakage fixed
> by this patch, as it only checks for errors and not for expected
> output.
The patch applied to master bc8b95ae4a4b21753e84bbfd28cbcbf1b3f6e0a8
does have above paragraph in commit message, but DOES NOT have the
tests itself.
> I have added tests _then_ I have realized that in current form they
> cannot detect regression corrected by this patch. So if you want, you
> can not apply changes to test (and remove paragraph about test from
> commit message).
See above...
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 24b3158..a746a85 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1511,7 +1511,7 @@ sub config_to_int {
> sub config_to_multi {
> my $val = shift;
>
> - return ref($val) ? $val : [ $val ];
> + return ref($val) ? $val : (defined($val) ? [ $val ] : []);
> }
And somehow (I don't know how[*1*]) patch got whitespace corrupted,
and now the line is indented with spaces, instead of with tab.
[*1*] Other patches are fine.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Junio C Hamano @ 2007-12-18 0:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Schuberth, Sebastian, git, gitster
In-Reply-To: <Pine.LNX.4.64.0712171220540.9446@racer.site>
Thanks. Applied.
^ permalink raw reply
* Re: [PATCH] the use of 'tr' in the test suite isn't really portable
From: Junio C Hamano @ 2007-12-18 0:20 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20071217232846.476940ec@pc09.procura.nl>
Thanks. Applied.
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-18 0:31 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Sebastian Harl, git
In-Reply-To: <57F403E7-AF5B-40F1-AE9D-8EA036675A67@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> On Dec 18, 2007, at 12:00 AM, Junio C Hamano wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> ... The current behavior of git stash is very
>>> dangerous ...
> ...
>> This is a plain FUD, isn't it? The first Oops should not happen these
>> days.
>
> *git pull in git*
> *reads Documentation/RelNotes-1.5.4.txt*
>
> Blah. I didn't know follow the development over the past 3 weeks well
> enough, sorry for the noise. I'm glad that this was improved.
But the original point by Sebastian hasn't been answered. He wanted to
make the command list the stash without arguments.
This was discussed already in the early days of stash and there indeed
was a suggestion to do so (I think I sided with that), but the users did
not want it. IIRC, the argument went like: "when I say 'stash', that is
because I want a quick and immediate way to stash, and I do not want a
list. If I do not have to have a quick way, I would create a temporary
commit on the current branch, or switch to a temporary branch and commit
there."
^ permalink raw reply
* Re: [PATCH 5/6] whitespace: more accurate initial-indent highlighting
From: Jakub Narebski @ 2007-12-18 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, J. Bruce Fields, Git Mailing List
In-Reply-To: <7vwsrdd9wa.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > Basically I would have proposed extracting out each type of whitespace
> > error into an inline function in ws.c, where it could be used by both
> > check_and_emit_line() in ws.c and apply_one_fragment() in builtin-
> > apply.c.
> >
> > Unfortunately, mixing checking and emission phases makes this proposed
> > refactoring a little bit ugly.
>
> The right refactoring would be what JBF hinted in his message, to record
> and return a list of suspicious ranges from the checker function and
> have the highlighter and the fixer make use of that list.
>
> Such a refactoring is still possible but I think it is beyond the scope
> of pre 1.5.4 clean-up.
By the way, does "trailing empty lines at the end of file" whitespace
error get detected and hightlighted with refactored whitespace checking?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-18 0:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999999.0712171641460.8467@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 17 Dec 2007, Junio C Hamano wrote:
> ...
>> Instead we unconditionally said "if you are downloading with the new
>> client, we assume you would never be using older client to access that
>> repository locally, if you did so, you are screwed."
>>
>> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
>> native protocol use offsets to delta base when possible) could have been
>> a bit more careful in this respect.
>
> Probably. But this can hardly be called a "corruption" since nothing
> was actually lost, rather an incompatibility problem.
It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now. The
data that was made inaccessible is inaccessible. The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Johannes Schindelin @ 2007-12-18 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuberth, Sebastian, git
In-Reply-To: <7vtzmg5072.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Thanks. Applied.
Dumb question: with, or without, the diff.external patch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Junio C Hamano @ 2007-12-18 0:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200712180112.52094.jnareb@gmail.com>
Please send updates if something is not right. Thanks.
^ permalink raw reply
* Re: [PATCH 5/6] whitespace: more accurate initial-indent highlighting
From: Junio C Hamano @ 2007-12-18 0:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Wincent Colaiuta, J. Bruce Fields, Git Mailing List
In-Reply-To: <m3y7bsq1vo.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, does "trailing empty lines at the end of file" whitespace
> error get detected and hightlighted with refactored whitespace checking?
Did you read the whole thread yet?
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Junio C Hamano @ 2007-12-18 0:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Schuberth, Sebastian, git
In-Reply-To: <Pine.LNX.4.64.0712180047300.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 17 Dec 2007, Junio C Hamano wrote:
>
>> Thanks. Applied.
>
> Dumb question: with, or without, the diff.external patch?
Swapped the order to first make diff.external work and then document.
^ permalink raw reply
* Re: [PATCH] Document diff.external and mergetool.<tool>.path
From: Johannes Schindelin @ 2007-12-18 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Schuberth, Sebastian, git
In-Reply-To: <7vy7bs3jv2.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 17 Dec 2007, Junio C Hamano wrote:
> >
> >> Thanks. Applied.
> >
> > Dumb question: with, or without, the diff.external patch?
>
> Swapped the order to first make diff.external work and then document.
Thank you very much!
Ciao,
Dscho
^ permalink raw reply
* FLEX_ARRAY=1 causes SIGSEGV on SPARC
From: Shawn O. Pearce @ 2007-12-18 1:01 UTC (permalink / raw)
To: git
So today I discovered latest master will cause a SIGSEGV on
Solaris/SPARC if FLEX_ARRAY is defined to the default value of 1.
The issue is the (old) compiler I'm using from Sun doesn't pass
the tests defined in 8e9739914972419baad820e76b44d9720ed885c2 (aka
"git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY
a bit better") so we fallback to #define FLEX_ARRAY 1.
Then git-pack-objects finds something unaligned and segfaults.
It always segfaults. During the deltification phase. Probably it
was working on deltifying loose objects; the set I fed it was about
100 most recent objects so they were probably all loose.
I'll try to track it down tomorrow. But the immediate workaround was
to just add '-DFLEX_ARRAY=/* empty */' to my CFLAGS and recompile
the world. This compiler accepts the empty FLEX_ARRAY macro but
I'm not sure what feature test(s) would be necessary to make Git
able to automatically set that, seeing as how the tests defined in
8e97 are perfectly reasonable and didn't pass.
Yea, yea, shame on me for not testing Git since Nov 20th on this
system... I should have caught the failure sooner. I'm buried in
non-Git work these days, but will try to come up with a reasonable
detection patch. Maybe someone will beat me to it. :-)
--
Shawn.
^ permalink raw reply
* Re: FLEX_ARRAY=1 causes SIGSEGV on SPARC
From: Junio C Hamano @ 2007-12-18 1:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071218010126.GP14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I'll try to track it down tomorrow. But the immediate workaround was
> to just add '-DFLEX_ARRAY=/* empty */' to my CFLAGS and recompile
> the world. This compiler accepts the empty FLEX_ARRAY macro but
> I'm not sure what feature test(s) would be necessary to make Git
> able to automatically set that, seeing as how the tests defined in
> 8e97 are perfectly reasonable and didn't pass.
> ..., but will try to come up with a reasonable
> detection patch....
Actually I would be more worried about the breakage in FLEX_ARRAY=1 case
than misdetection. Even if your compiler supports the flexible array
members, the fallback to FLEX_ARRAY=1 ought to work and you are seeing a
case where it doesn't.
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 1:21 UTC (permalink / raw)
To: Andy Dougherty; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712171641370.24957@fractal.phys.lafayette.edu>
Andy Dougherty <doughera@lafayette.edu> writes:
> [...]. Perhaps configure
> should just go looking for a suitable install program instead of
> assuming everyone has one.
First, configure is, and (I think) consensus is that it should remain
optional. This means that Makefile "guess" section should have good
defaults for your operating system.
Second, the default autoconf macro AC_PROG_INSTALL *requires* that
there is BSD-compatible `install' program (as 'install-sh' or
'install.sh') in the sources. Adding such script is (I think) not a
problem; finding minimal portable[*1*] script is. So if you know
one...
Footnotes:
----------
[*1*] By "portable" I mean here 'git portable', i.e. requiring only
those shell constructs/features that git require, not necessary
insanelt portable the way ./configure script is.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Pierre Habouzit @ 2007-12-18 1:39 UTC (permalink / raw)
To: gitster, spearce; +Cc: git, Pierre Habouzit
aka don't do pointer arithmetics on structs that have a FLEX_ARRAY member,
or you'll end up believing your array is 1 cell off its real address.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
diff-delta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff-delta.c b/diff-delta.c
index 9e440a9..601b49e 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -264,7 +264,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
index->src_size = bufsize;
index->hash_mask = hmask;
- mem = index + 1;
+ mem = index->hash;
packed_hash = mem;
mem = packed_hash + (hsize+1);
packed_entry = mem;
--
1.5.4.rc0.1153.gb1b3d-dirty
^ permalink raw reply related
* The 6th edition of the msysGit Herald
From: Johannes Schindelin @ 2007-12-18 1:42 UTC (permalink / raw)
To: msysgit-/JYPxA39Uh5TLH3MbocFFw, git-u79uwXL29TY76Z2rM5mHXA
Good morning git land!
This silent midnight is as good an occasion as any to offer to you the
6th edition of the msysGit Herald, the not-quite-biweekly news letter
to keep you informed about msysGit, the effort to bring one of the
most powerful Source Code Management systems to the poor souls stuck
with Windows.
These are the covered topics:
Git Gui's fetch problems resolved
vim colours improved
Getting more hits via git.or.cz than Google
Update to 1.5.4-rc0
New naming scheme: Git and msysGit
We busted the quota of Google Code
msysGit-netinstall: HTTP proxy and directories containing spaces
Next things
So this not-quite bi-weekly newsletter took a little bit longer this
time. But only for the better! Seems like the installer really
stabilises, as I hoped, and we really concentrated on some serious git
work.
Oh, and we got mentioned on kernel trap. For those who got the
impression from there that Git on Windows is not quite there yet: not
only is msysGit one of its own heaviest users, it is very much at the
technical front of Git: we use submodules, and we promote Git Gui
heavily. So there you have it: Git on Windows is already here.
Although we call it beta. Just to cover our buttocks.
Git Gui's fetch problems resolved
=================================
We updated git to a version where git-fetch is a builtin, in the hope
that the issues with fetching were resolved (for those who do not
follow the Herald: when fetching within Git Gui, a window would pop up
with the remote refs, instead of redirecting this output to
git-fetch).
Alas, it turns out that the implementation of spawnvpe() in Windows'
runtime library leaves a lot to be desired. Amongst other issues, it
does not automatically attach the child process to the same console as
the parent window, which gave us some grief.
Hannes Sixt finally broke down and reimplemented spawnvpe() as it
should have been (but was never fixed to).
Since then, it is running like a charm. The only issue left is when
you access a remote host via ssh, and have to type in a password. We
have do not intercept that yet. There is a relatively low-hanging
fruit waiting for somebody to harvest it.
vim colours improved
====================
We got a bug report that the colours in vim made a user blind ;-)
While investigating, we found out that not only did we have a useless
/etc/vimrc (the correct location is /share/vim/vimrc), but the code to
show nice colours for a dark background was already there, only at the
wrong spot.
With that fixed, our user can recover, and open his eyes again to this
lovely world we live in.
Getting more hits via git.or.cz than Google
===========================================
Seems that the recent linking from the Git home page really changed
things in the statistics! While Google's search referalls dominated
the traffic sources earlier, 30% more users find our home page via
git.or.cz than via Google now, which might also mean that they are
referred to the Git home page first. ;-)
We also got some attention on November 19, when KernelTrap had a story
on us.
Update to 1.5.4-rc0
===================
Since the last Herald, Hannes was very busy sending patches to Junio
Hamano, the maintainer of (non-MinGW) Git, in order to bring mingw.git
closer to git.git. In the midst of all those wonderful efforts, a
feature freeze was declared on git.git, to stabilise for 1.5.4. Such
is life ;-)
Nevertheless, a few patches made it in, and Hannes made quite a few
more cleanups, such as a rework of the environment variable handling
(when you setenv() on Windows, references you got earlier via getenv()
are now stale), or avoiding dup()s which confused Windows -- in the
commit messages, this issue is known as the "dup dance".
At the same time, Steffen Prohaska worked on bringing 4msysgit.git
closer to mingw.git ;-)
The fallout of these endeavours is that we are not only much closer to
mingw.git, but we are in fact pretty close to the current prerelease
of Git -- 1.5.4-rc0!
Together with the usability improvements in the installer, such as
installing shortcuts for all users when installing as administrator,
or the integration of the release notes into the installer, I am
pretty happy with the state of the project.
New naming scheme: Git and msysGit
==================================
When taking the first steps of "Git on MSys", there was only one
pretty large zip file, containing the development environment to
compile git, along with a checkout of mingw.git.
Since then, we decided that we wanted installers. Three of them.
The final goal is a Git installer, meant for the end user.
To attract developers to that end, we also wanted to have two
installers for the development environment: a small one, containing
barely enough of Git and MSys to fetch and checkout the master branch
of the development environment's repository, and the master branch of
our fork of mingw.git (and recently, we got another submodule for the
documentation). And a big installer, which does not clone anything,
but is an all-in-one package of the development environment, not even
setting up git remotes -- basically the big zip we had during the
first day, turned into an installer.
As I am pretty bad with British slang names, I could not think of any
really good names, and we ended up with "WinGit" (from "to wing it")
for the Git installer, "GitMe" for the net installer of the
development environment, and "msysGit" for the full installer.
That was confusing.
Steffen pointed out that we should thrive for the crown of Git on
Windows, leaving cygwin's Git behind, and therefore our Git installer
should really be called "Git".
Also, since the other two installers are in fact just two different
ways to obtain the development environment, they should share the same
name, "msysGit", with one being the net installer and the other the
full installer.
So, these are the downloads we offer: Git, msysGit-netinstall and
msysGit-fullinstall.
But maybe we decide to rename the latter two to Git-Dev-netinstall and
Git-Dev-full some day... we'll see.
We busted the quota of Google Code
==================================
A mere 5 months after starting the project page
http://msysgit.googlecode.com/ we reached the (default) quota of
100MB. We used up about 7-9 megabytes for each release of the Git
installer, and the full msysGit installer weighs in with a 14
megabytes.
When Dmitry Kakurin suggested to get some project hosting, back in
July, my first address was sourceforge. However, they dragged their
feet (and our project was really moving along at a breathtaking pace,
back then) so we ended up using Google Code's friendly hosting service
instead.
Already it became quite clear that we'd eventually need more quota,
but we were being told that we would get more when we needed it. That
point was reached on Friday, 14th of December, when Steffen was unable
to upload the current preview due to space constraints.
When I found the right spot to ask (in case you wonder, it was not the
email address code-hosting-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, as suggested by the Google Code
FAQ, but the Project Hosting discussion group at
http://groups.google.com/group/google-code-hosting?lnk=gschg), things
went smoothly and we now have a quota of 200MB. See you in 5 months,
Google ;-)
msysGit-netinstall: HTTP proxy and directories containing spaces
================================================================
A long standing bug in msysGit-netinstall (then known as GitMe) was
fixed quite some time ago, but I never got around to wrap up new
installers: If you installed msysGit into a directory containing
spaces, it would not be able to finish the installation.
Another bug(let) was that we did not have any method to specify an
HTTP proxy in the net installer.
This was the reason, probably, that the net installer was
substantially less popular (2817 downloads) than the full installer
(4306 downloads), despite the former being featured on the main page.
With both bugs fixed in both msysGit installers -- also updated to the
same state as the Git installer -- we lay the old installers,
GitMe-0.4.2 and msysGit-0.6, to rest. Requiescant in pace.
Next things
===========
The commands git-svn and git-cvsimport had to take a backseat while
more visible _Git_ issues were being taken care of. But postponed is
not abandoned, so they will both see some attention again soon.
My pet project, git-cheetah, should also get integrated as a submodule
of msysgit.git. It is a lightweight Explorer extension a la
TortoiseCVS, and given enough people working on it, it should be able
to kick rear ends pretty quickly.
Rxvt. Ah, so long ago, I abandoned hope that this would be fixed
eventually (for one, git-log is not able to spawn a pager, and thus
the history just whizzes by). So we use cmd instead.
It is no secret that cmd (or the console window it opens) has pretty
annoying restrictions (such as no proper multi-line selections, no
_real_ resizing support, and you have to use the mouse to scroll
back). But with the work we did to recompile Perl for MSys, it should
become easier to tackle Rxvt. Or maybe we'll just include Xming
instead, a very small and lean rootless X11 server for MinGW.
^ permalink raw reply
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Derek Fawcus @ 2007-12-18 1:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Geert Bosch, Harvey Harrison, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712171455220.21557@woody.linux-foundation.org>
On Mon, Dec 17, 2007 at 03:01:25PM -0800, Linus Torvalds wrote:
>
> > With git version 1.5.3.6 on Mac OS X, this results in:
> > potomac%:~/gcc%git remote update
> > Updating gcc.gnu.org
> > /opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
> But maybe there is some way to raise the argument size limit on OS X.
Well the certification for Leopard claims it can be up to 256k.
I don't know about Tiger or earlier, but ARG_MAX on my 10.4
box is also (256 * 1024).
So - how much do people want? Or maybe there is some sort limit in play here?
DF
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Pierre Habouzit @ 2007-12-18 1:44 UTC (permalink / raw)
To: gitster, spearce; +Cc: git
In-Reply-To: <1197941997-11421-1-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Tue, Dec 18, 2007 at 01:39:57AM +0000, Pierre Habouzit wrote:
> aka don't do pointer arithmetics on structs that have a FLEX_ARRAY member,
> or you'll end up believing your array is 1 cell off its real address.
I wonder if we could teach sparse to prevent us from using pointer
arithmetics on some types… because I obviously didn't read all the git
code, and I wouldn't be surprised an instance of this still remains
somehwere.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] diff-delta.c: make FLEX_ARRAY=1 work.
From: David Kastrup @ 2007-12-18 1:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vtzmg3j37.fsf@gitster.siamese.dyndns.org>
I remarked previously that diff-delta.c does not work with FLEX_ARRAY=1.
Here is one attempt to change this. It conceivably still suffers from
potential misalignment problems (which would likely need some union type
magic to avoid 100%), but at least the index calculation should not go
as horribly wrong as previously.
---
Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> I'll try to track it down tomorrow. But the immediate workaround was
>> to just add '-DFLEX_ARRAY=/* empty */' to my CFLAGS and recompile
>> the world. This compiler accepts the empty FLEX_ARRAY macro but
>> I'm not sure what feature test(s) would be necessary to make Git
>> able to automatically set that, seeing as how the tests defined in
>> 8e97 are perfectly reasonable and didn't pass.
>> ..., but will try to come up with a reasonable
>> detection patch....
>
> Actually I would be more worried about the breakage in FLEX_ARRAY=1 case
> than misdetection. Even if your compiler supports the flexible array
> members, the fallback to FLEX_ARRAY=1 ought to work and you are seeing a
> case where it doesn't.
diff-delta.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/diff-delta.c b/diff-delta.c
index 9e440a9..099235c 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -247,7 +247,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
/* Now create the packed index in array form rather than
* linked lists */
- memsize = sizeof(*index)
+ memsize = (char *)&index->hash - (char *)index
+ sizeof(*packed_hash) * (hsize+1)
+ sizeof(*packed_entry) * entries;
@@ -264,7 +264,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
index->src_size = bufsize;
index->hash_mask = hmask;
- mem = index + 1;
+ mem = &index->hash;
packed_hash = mem;
mem = packed_hash + (hsize+1);
packed_entry = mem;
--
1.5.3.6.995.ge8abd
^ permalink raw reply related
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Shawn O. Pearce @ 2007-12-18 1:52 UTC (permalink / raw)
To: Derek Fawcus
Cc: Linus Torvalds, Geert Bosch, Harvey Harrison, Git Mailing List
In-Reply-To: <20071218013401.A1716@edi-view2.cisco.com>
Derek Fawcus <dfawcus@cisco.com> wrote:
> On Mon, Dec 17, 2007 at 03:01:25PM -0800, Linus Torvalds wrote:
> >
> > > With git version 1.5.3.6 on Mac OS X, this results in:
> > > potomac%:~/gcc%git remote update
> > > Updating gcc.gnu.org
> > > /opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
>
> > But maybe there is some way to raise the argument size limit on OS X.
>
> Well the certification for Leopard claims it can be up to 256k.
>
> I don't know about Tiger or earlier, but ARG_MAX on my 10.4
> box is also (256 * 1024).
>
> So - how much do people want? Or maybe there is some sort limit in play here?
I heard there's like 1000 branches in that GCC repository, not
counting tags.
Each branch name is at least 12 bytes or so ("refs/heads/..").
It adds up.
It should be fixed in latest git (1.5.4-rc0) as that uses the new
builtin-fetch implementation, which passes the lists around in
memory rather than on the command line. Much faster, and doesn't
suffer from argument/environment limits.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 5/7] parse-options: Add a gitcli(5) man page.
From: Wayne Davison @ 2007-12-18 2:00 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1197915797-30679-6-git-send-email-madcoder@debian.org>
On Mon, Dec 17, 2007 at 07:23:15PM +0100, Pierre Habouzit wrote:
> + * when a command line option takes an argument, use the 'sticked' form.
A minor issue: the word "sticked" reads very strangely to me (in this
spot and several others in your text). I think something like joined or
attached (or even abutted) would be better, as seen in this altered text
for the spot cited above (with a few other improvements thrown in):
* when a command line option takes an argument, it is best to use the
'joined' form. In other words, write `"git foo -oArg"` instead of
`"git foo -o Arg"` for short options, and `"git foo --long-opt=Arg"`
instead of `"git foo --long-opt Arg"` for long options. If an option
takes an optional option-argument, it MUST be written using the
'joined' form when providing the option-argument.
..wayne..
^ 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