* 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
* Re: [PATCH] provide advance warning of some future pack default changes
From: Mark Fasheh @ 2007-12-18 2:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712171517320.8467@xanadu.home>
Hi,
Just to "out" myself, I'm the "co-worker" whose name Joel has been
(politely) keeping anonymous.
On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> > You may not see a case for actual corruptions, but my coworker
> > updated his tree on a box with 1.5.x, then tried to work on a box with
> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > unusable. He had to re-clone, and I think he got lucky recovering
> > pending changes (probably using 1.5.x on the branches with the changes,
> > as master was what got broken).
>
> I still claim that there wasn't any corruptions.
The following description is really vague because this was a while ago:
Something made my ocfs2.git tree unusable in that I could no longer do
common tasks, such as git-log, etc without getting messages about corrupted
refs.
I wish I had saved off some of the messages. Sorry.
I had to re-create my git tree several times before I learned by deduction
that it was the older versions of git on some of the machines that were
writing some sort of incompatible format.
> Just for fun, just edit some document with Microsoft Office 95, then
> open the same document with Office 2007 and save it with default
> settings. Now try to open it back with Office 95. It won't work.
> Does that mean that the document got corrupted?
Boy, I hope Microsoft Office isn't our bar for compatiblity here...
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Mark Fasheh @ 2007-12-18 2:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vbq8o4yxc.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 04:41:19PM -0800, Junio C Hamano wrote:
> 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.
Junio, I agree 100% with your description here. This is all about user
experience and data which is silently made inaccessible makes them feel
pretty bad.
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-18 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <7vbq8o4yxc.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> 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.
Sure, but at some point that's something users mixing versions should be
ready to cope with. We try to make it as painless as possible of
course.
Data corruption is usually something you just cannot recover from
(unless you have backups). And if mixing different tool versions
actually cause data corruption then this is a much much more serious
issue and that must be avoided.
So at some point the distinction must be made, and if using an old
version of Git on a repo created by a new version actually produces data
corruption as Joel seemed to imply, then we must really take it
seriously. OTOH, compatibility issues are usually much less of a pain
to fix.
Nicolas
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-18 3:34 UTC (permalink / raw)
To: Mark Fasheh; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071218021556.GC13821@ca-server1.us.oracle.com>
On Mon, 17 Dec 2007, Mark Fasheh wrote:
> Hi,
>
> Just to "out" myself, I'm the "co-worker" whose name Joel has been
> (politely) keeping anonymous.
>
> On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> > > You may not see a case for actual corruptions, but my coworker
> > > updated his tree on a box with 1.5.x, then tried to work on a box with
> > > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > > unusable. He had to re-clone, and I think he got lucky recovering
> > > pending changes (probably using 1.5.x on the branches with the changes,
> > > as master was what got broken).
> >
> > I still claim that there wasn't any corruptions.
>
> The following description is really vague because this was a while ago:
>
> Something made my ocfs2.git tree unusable in that I could no longer do
> common tasks, such as git-log, etc without getting messages about corrupted
> refs.
>
> I wish I had saved off some of the messages. Sorry.
>
> I had to re-create my git tree several times before I learned by deduction
> that it was the older versions of git on some of the machines that were
> writing some sort of incompatible format.
Next time please don't hesitate to post your issue on this list. The
fix could have been so obvious to many people on the list, saving you
time and frustration. In your case I think the "fix" would have
consisted of simply running "git repack -a -d" on the machine with the
most recent Git version.
And if it was a case of real corruption then we certainly would have
liked to know about it ASAP.
> > Just for fun, just edit some document with Microsoft Office 95, then
> > open the same document with Office 2007 and save it with default
> > settings. Now try to open it back with Office 95. It won't work.
> > Does that mean that the document got corrupted?
>
> Boy, I hope Microsoft Office isn't our bar for compatiblity here...
We can do better of course, like allowing you to still produce the old
format with a new version of Git. But sometimes format changes are
unavoidable for many good reasons.
Nicolas
^ permalink raw reply
* Re: Question about git-svn import
From: Steven Walter @ 2007-12-18 3:48 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4766AF65.5060706@obry.net>
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]
On Mon, Dec 17, 2007 at 06:18:29PM +0100, Pascal Obry wrote:
> You'll find a script into this message that reproduce what I'll describe
> below. Basically the Subversion repository add a given structure in the
> past then rearranged to use the "standard" structure. The former
> structure was:
>
> <root>
> |
> | - dir1
> | - dir2
>
> The new one is:
>
> <root>
> |
> |- trunk
> | | - dir1
> | | - dir2
> |- branches
> |- tags
>
> Now I want to import this project into Git (using git-svn) as the
> project won't leave Subversion for the moment. When doing:
>
> $ git svn clone -s <repo> <git-repo>
>
> In git-repo we get only the commits done inside <root>/trunk and not the
> commits done in the former repository.
>
> The question is what is the best way to deal with such a case with git-svn ?
Not sure if this is the best way, but I would recommend cloning into two
repositories, then combining them. So you already have the newer
changes with the standard layout. You would now:
$ git svn init <repo>
And only fetch the revisions before the layout change. You could then
combine the two repositories using .git/info/grafts and
git-rewrite-branch.
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Martin Langhoff @ 2007-12-18 3:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Joel Becker, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999999.0712172212110.8467@xanadu.home>
On Dec 18, 2007 4:23 PM, Nicolas Pitre <nico@cam.org> wrote:
> Sure, but at some point that's something users mixing versions should be
> ready to cope with. We try to make it as painless as possible of
> course.
I have to say I agree with the "apparently minor updates should not
break cross-version compat". And I think it's a communication issue
around the version numbering. The fact that this will be introduced
with a v1.5.5 is, IMHO, a good part of the problem.
If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
revisions should interoperate with end users not even thinking about
it. But 1.5.5 has in its changelog lots of deprecations and interop
changes.
It's not good communication to label it 1.5.5.
Other than that, it's an _amazing_ thing, and I'm in love with git.
But the version number is a bit of a lie -- and is bound to confuse
and anger end users.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-18 4:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Joel Becker, Jakub Narebski, git
In-Reply-To: <46a038f90712171952i4f53876fv55b0e6993d5f4b0a@mail.gmail.com>
On Tue, 18 Dec 2007, Martin Langhoff wrote:
> On Dec 18, 2007 4:23 PM, Nicolas Pitre <nico@cam.org> wrote:
> > Sure, but at some point that's something users mixing versions should be
> > ready to cope with. We try to make it as painless as possible of
> > course.
>
> I have to say I agree with the "apparently minor updates should not
> break cross-version compat". And I think it's a communication issue
> around the version numbering. The fact that this will be introduced
> with a v1.5.5 is, IMHO, a good part of the problem.
>
> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
> revisions should interoperate with end users not even thinking about
> it. But 1.5.5 has in its changelog lots of deprecations and interop
> changes.
>
> It's not good communication to label it 1.5.5.
I agree. Might be time for 1.6.0?
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Linus Torvalds @ 2007-12-18 4:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, spearce, git
In-Reply-To: <20071218014455.GB14981@artemis.madism.org>
On Tue, 18 Dec 2007, Pierre Habouzit wrote:
>
> 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.
This should do it.
What this does is:
- make flex structures not have a size at all (so "sizeof()" will fail)
- add warnings for trying to add or subtract unsized pointers
so now you can try it on git with
make CC=cgcc
and while it finds a fair number of "sizeof(..)" things and complains
about them, the only invalid pointer arithmetic it finds is the
mem = index + 1;
line in diff-delta.c.
Whether it is worth fixing all the "sizeof()" calls too, I dunno. They
result in a slight waste of memory (ie we allocate too much memory), but
I guess they should be harmless.
However, one indication that there may still be something wrong is that if
you re-make git with FLEX_ARRAY set to some big insane value (say, 1234),
then git will still fail the test-suite. So maybe there's a "sizeof()"
that isn't just used for allocation sizes. I didn't check them all,
there's something like 44 complaints like
builtin-fetch.c:306:21: error: cannot size expression
from sparse with this patch.
Linus
---
evaluate.c | 8 ++++++++
symbol.c | 2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/evaluate.c b/evaluate.c
index 54fcd3f..cd816a8 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -576,6 +576,10 @@ static struct symbol *evaluate_ptr_add(struct expression *expr, struct symbol *i
expression_error(expr, "arithmetics on pointers to functions");
return NULL;
}
+ if (base->bit_size & 7) {
+ expression_error(expr, "arithmetic on unsized pointers");
+ return NULL;
+ }
/* Get the size of whatever the pointer points to */
multiply = base->bit_size >> 3;
@@ -820,6 +824,10 @@ static struct symbol *evaluate_ptr_sub(struct expression *expr)
expression_error(expr, "subtraction of functions? Share your drugs");
return NULL;
}
+ if (lbase->bit_size & 7) {
+ expression_error(expr, "subtracting unsized pointers");
+ return NULL;
+ }
expr->ctype = ssize_t_ctype;
if (lbase->bit_size > bits_in_char) {
diff --git a/symbol.c b/symbol.c
index 7539817..8b390ac 100644
--- a/symbol.c
+++ b/symbol.c
@@ -124,8 +124,10 @@ static void lay_out_struct(struct symbol *sym, struct struct_union_info *info)
* structure size
*/
if (base_size < 0) {
+ info->bit_size = -1;
info->align_size = 0;
base_size = 0;
+ return;
}
align_bit_mask = (sym->ctype.alignment << 3) - 1;
^ permalink raw reply related
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-18 5:01 UTC (permalink / raw)
To: Martin Langhoff
Cc: Nicolas Pitre, Junio C Hamano, Joel Becker, Jakub Narebski, git
In-Reply-To: <46a038f90712171952i4f53876fv55b0e6993d5f4b0a@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
> revisions should interoperate with end users not even thinking about
> it. But 1.5.5 has in its changelog lots of deprecations and interop
> changes.
>
> It's not good communication to label it 1.5.5.
There indeed are handful scheduled removals. I do not mind declaring
that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
1.6.0 and keep the scheduled change on hold a bit longer.
By the way, I'd appreciate an Ack or comment on the recent pserver
authentication enhancements in c934dca22ee07cb3ca146a249bdb73ab0f30b2b1
(Authentication support for pserver); I do not mind merging this in
1.5.4 as the change is fairly isolated and should not affect people who
do not use the feature.
^ permalink raw reply
* kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-18 5:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <20071217224812.GA6342@diana.vm.bytemark.co.uk>
On 2007-12-17 23:48:12 +0100, Karl Hasselström wrote:
> If you like, I can advance "safe" to include as many patches as I
> think you should merge right now.
And here it is:
The following changes since commit 5be69cd8d89bd89be31364e9c0fd9e947b6ef644:
Karl Hasselström (1):
Name the exit codes to improve legibility
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (17):
Add an StGit mode for emacs
Emacs mode: Improve the output buffer state
Emacs mode: Bind n and p
Emacs mode: add stgit-repair
Emacs mode: added stgit-commit and stgit-uncommit
Emacs mode: Add stgit-edit command
Emacs mode: added fontification
Emacs mode: Added stgit-new
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Karl Hasselström (24):
Emacs mode: Show keybindings when user presses "h" or "?"
Emacs mode: Add an explanatory header
Emacs mode: Makefile for building stgit.el
Emacs mode: push/pop next patch, not patch at point
Emacs mode: Let "P" push or pop patch at point
Emacs mode: Bind "G" to "stg goto"
Emacs mode: show patches' short description
Write removed fields for backwards compatibility
Nicer conflict markers
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
"stg status --reset" is not needed anymore
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
Remove "stg resolved"
New StGit core infrastructure: repository operations
Write metadata files used by the old infrastructure
Upgrade older stacks to newest version
Let "stg clean" use the new infrastructure
Add "stg coalesce"
Let "stg applied" and "stg unapplied" use the new infrastructure
Documentation/stg-cp.txt | 63 --------
Documentation/stg.txt | 2 -
Documentation/tutorial.txt | 31 +++--
contrib/Makefile | 19 +++
contrib/stgit-completion.bash | 4 +-
contrib/stgit.el | 318 +++++++++++++++++++++++++++++++++++++++++
examples/gitconfig | 19 +---
setup.py | 2 +-
stgit/commands/add.py | 44 ------
stgit/commands/applied.py | 27 ++--
stgit/commands/clean.py | 68 +++++-----
stgit/commands/coalesce.py | 84 +++++++++++
stgit/commands/common.py | 39 +++---
stgit/commands/copy.py | 45 ------
stgit/commands/pick.py | 2 +-
stgit/commands/resolved.py | 94 ------------
stgit/commands/rm.py | 48 ------
stgit/commands/status.py | 31 ++---
stgit/commands/sync.py | 1 -
stgit/commands/unapplied.py | 23 ++--
stgit/config.py | 1 -
stgit/git.py | 75 ++++++----
stgit/gitmergeonefile.py | 97 +------------
stgit/lib/__init__.py | 18 +++
stgit/lib/git.py | 260 +++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 172 ++++++++++++++++++++++
stgit/lib/stackupgrade.py | 96 ++++++++++++
stgit/lib/transaction.py | 79 ++++++++++
stgit/main.py | 10 +-
stgit/run.py | 3 +
stgit/stack.py | 156 ++++----------------
stgit/utils.py | 24 +++
t/t0002-status.sh | 15 +-
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 6 +-
t/t1203-push-conflict.sh | 70 +++++++++
t/t1204-pop-keep.sh | 2 +-
t/t1205-push-subdir.sh | 8 +-
t/t1300-uncommit.sh | 4 +-
t/t1301-repair.sh | 2 +-
t/t1400-patch-history.sh | 4 +-
t/t1500-float.sh | 14 +-
t/t1600-delete-one.sh | 12 +-
t/t1601-delete-many.sh | 2 +-
t/t1700-goto-top.sh | 2 +-
t/t2000-sync.sh | 12 +-
t/t2100-pull-policy-fetch.sh | 4 +-
t/t2101-pull-policy-pull.sh | 4 +-
t/t2102-pull-policy-rebase.sh | 4 +-
t/t2300-refresh-subdir.sh | 2 +-
t/t2600-coalesce.sh | 31 ++++
51 files changed, 1420 insertions(+), 735 deletions(-)
delete mode 100644 Documentation/stg-cp.txt
create mode 100644 contrib/Makefile
create mode 100644 contrib/stgit.el
delete mode 100644 stgit/commands/add.py
create mode 100644 stgit/commands/coalesce.py
delete mode 100644 stgit/commands/copy.py
delete mode 100644 stgit/commands/resolved.py
delete mode 100644 stgit/commands/rm.py
create mode 100644 stgit/lib/__init__.py
create mode 100644 stgit/lib/git.py
create mode 100644 stgit/lib/stack.py
create mode 100644 stgit/lib/stackupgrade.py
create mode 100644 stgit/lib/transaction.py
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t2600-coalesce.sh
-+-
The following changes since commit 1189271615e7157ca3da3288a9ce3c9bcaeb2d5f:
Karl Hasselström (1):
Let "stg applied" and "stg unapplied" use the new infrastructure
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
David Kågedal (2):
Emacs mode: Add mark command
Emacs mode: coalesce command
Karl Hasselström (10):
Teach the new infrastructure about the index and worktree
Let "stg clean" use the new transaction primitives
Let "stg goto" use the new infrastructure
Convert "stg uncommit" to the new infrastructure
New infrastructure: Make sure that the branch is initialized
Expose transaction abort function
stg coalesce: Support --file and --save-template
Set exit code to 3 on merge conflict
Convert "stg commit" to new infrastructure
Make "stg commit" fancier
contrib/stgit.el | 97 +++++++++++++++++++-----
stgit/commands/clean.py | 35 ++-------
stgit/commands/coalesce.py | 118 +++++++++++++++++++----------
stgit/commands/commit.py | 111 +++++++++++++++++----------
stgit/commands/goto.py | 52 +++++---------
stgit/commands/uncommit.py | 81 +++++++++-----------
stgit/lib/git.py | 127 +++++++++++++++++++++++++++++++
stgit/lib/stack.py | 10 ++-
stgit/lib/stackupgrade.py | 6 +-
stgit/lib/transaction.py | 178 ++++++++++++++++++++++++++++++++++++++------
stgit/main.py | 4 +-
stgit/utils.py | 1 +
t/t1300-uncommit.sh | 12 ++--
13 files changed, 588 insertions(+), 244 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-18 5:29 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20071217232259.0b41a3bf@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Mon, 17 Dec 2007 13:00:22 -0800, Junio C Hamano <gitster@pobox.com> wrote:
>
>> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>>
>> > HP-UX does not have select.h, but it offers all select () functionality.
>> > The defines are in <sys/types.h> and <X11/fd.h>
>>
>> Will apply the patch as-is for now, only because I do not want major
>> surgery during rc period, but I think is can be improved.
> ...
>> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
>
> That is defined in GNU gcc. I did not pass it with -D...
Actually I changed my mind. I won't be applying this as is.
For the selective inclusion of <sys/select.h>, I would prefer it see it
done like the attached.
The main point is to limit the "platform" dependency to configure and
Makefile, and keep #ifdef in the actual header files expressed in more
generic terms (e.g. "do we need to (and can we) include sys/select.h
here?").
I am fuzzy about the uname_S part, so I won't be applying the attached
patch either; the attached is for demonstration purposes only.
diff --git a/Makefile b/Makefile
index 617e5f5..f9f724a 100644
--- a/Makefile
+++ b/Makefile
@@ -100,6 +100,9 @@ all::
#
# Define NO_DEFLATE_BOUND if your zlib does not have deflateBound.
#
+# Define NO_SYS_SELECT_H if your C library header files do not have <sys/select.h>
+# but you do have select(2) (pre POSIX.1-2001 systems, e.g. HP-UX before 11.23).
+#
# Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
# that tells runtime paths to dynamic libraries;
# "-Wl,-rpath=/path/lib" is used instead.
@@ -504,6 +507,9 @@ endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
+ifeq ($(uname_S),HP-UX)
+ NO_SYS_SELECT_H = YesPlease
+endif
-include config.mak.autogen
-include config.mak
@@ -676,6 +682,10 @@ ifdef NO_DEFLATE_BOUND
BASIC_CFLAGS += -DNO_DEFLATE_BOUND
endif
+ifdef NO_SYS_SELECT_H
+ BASIC_CFLAGS += -DNO_SYS_SELECT_H
+endif
+
ifdef PPC_SHA1
SHA1_HEADER = "ppc/sha1.h"
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
diff --git a/config.mak.in b/config.mak.in
index 15fb26c..e8890e0 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -44,3 +44,4 @@ NO_MKDTEMP=@NO_MKDTEMP@
NO_ICONV=@NO_ICONV@
OLD_ICONV=@OLD_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
+NO_SYS_SELECT_H=@NO_SYS_SELECT_H@
diff --git a/configure.ac b/configure.ac
index 6f641e3..3bfd0b6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -256,6 +256,8 @@ AC_COMPILE_IFELSE(OLDICONVTEST_SRC,
OLD_ICONV=UnfortunatelyYes])
AC_SUBST(OLD_ICONV)
+AC_CHECK_HEADER([sys/select.h], [], [NO_SYS_SELECT_H=YesPlease])
+AC_SUBST(NO_SYS_SELECT_H)
## Checks for typedefs, structures, and compiler characteristics.
AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics])
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..ec3585e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -68,7 +68,9 @@
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#ifndef NO_SYS_SELECT_H
#include <sys/select.h>
+#endif
#include <assert.h>
#include <regex.h>
#include <netinet/in.h>
^ permalink raw reply related
* [PATCH] Fix some documentation typos.
From: Ralf Wildenhues @ 2007-12-18 6:07 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Documentation/config.txt | 2 +-
Documentation/git-help.txt | 6 +++---
Documentation/git-rev-list.txt | 2 +-
Documentation/git-send-email.txt | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ce16fc7..75ed4d3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -469,7 +469,7 @@ fetch.unpackLimit::
format.numbered::
A boolean which can enable sequence numbers in patch subjects.
- Seting this option to "auto" will enable it only if there is
+ Setting this option to "auto" will enable it only if there is
more than one patch. See --numbered option in
gitlink:git-format-patch[1].
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index da3f718..c370ee9 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -21,7 +21,7 @@ printed on the standard output.
If a git command is named, a manual page for that command is brought
up. The 'man' program is used by default for this purpose, but this
-can be overriden by other options or configuration variables.
+can be overridden by other options or configuration variables.
Note that 'git --help ...' is identical as 'git help ...' because the
former is internally converted into the latter.
@@ -30,7 +30,7 @@ OPTIONS
-------
-a|--all::
Prints all the available commands on the standard output. This
- option superseeds any other option.
+ option supersedes any other option.
-i|--info::
Use the 'info' program to display the manual page, instead of
@@ -50,7 +50,7 @@ The web browser can be specified using the configuration variable
these config variables is set, the 'git-help--browse' helper script
(called by 'git-help') will pick a suitable default.
+
-You can explicitly provide a full path to your prefered browser by
+You can explicitly provide a full path to your preferred browser by
setting the configuration variable 'browser.<tool>.path'. For example,
you can configure the absolute path to firefox by setting
'browser.firefox.path'. Otherwise, 'git-help--browse' assumes the tool
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 989fbf3..a03f9fe 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -274,7 +274,7 @@ limiting may be applied.
--quiet::
Don't print anything to standard output. This form of
- git-rev-list is primarly meant to allow the caller to
+ git-rev-list is primarily meant to allow the caller to
test the exit status to see if a range of objects is fully
connected (or not). It is faster than redirecting stdout
to /dev/null as the output does not have to be formatted.
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 659215a..f0bd285 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -148,7 +148,7 @@ sendemail.identity::
'sendemail.<identity>.<item>' will have higher precedence than
'sendemail.<item>'. This is useful to declare multiple SMTP
identities and to hoist sensitive authentication information
- out of the repository and into the global configuation file.
+ out of the repository and into the global configuration file.
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
--
1.5.3.6.950.g92b7b
^ permalink raw reply related
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Linus Torvalds @ 2007-12-18 6:12 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, spearce, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712172032090.21557@woody.linux-foundation.org>
On Mon, 17 Dec 2007, Linus Torvalds wrote:
>
> However, one indication that there may still be something wrong is that if
> you re-make git with FLEX_ARRAY set to some big insane value (say, 1234),
> then git will still fail the test-suite. So maybe there's a "sizeof()"
> that isn't just used for allocation sizes.
No, that's a different thing. In at least unpack-trees.c (line 593), we do
..
if (same(old, merge)) {
*merge = *old;
} else {
..
and that "merge" is a cache_entry pointer. If we have a non-zero
FLEX_ARRAY size, it will cause us to copy the first few bytes of the name
too.
That is technically wrong even for FLEX_ARRAY being 1, but you'll never
notice, since the names are always at least one byte, and the filenames
should basically always be the same. But if we do the same thing for a
rename, we'd be screwed.
So we probably should look out for those things too. A quick hack to
sparse shows that that was the only such occurrence in the current tree,
though.
Anyway, with this patch to current git, it passes all the test-suite with
FLEX_ARRAY artificially set to 123, and the only complaints from my
hacked-up sparse are about "sizeof()" calls (ie no pointer arithmetic, and
no assignments to flex-array-structures).
*Most* of the remaining sizeof() uses, in turn, are allocation-size
related, ie passed in to calloc() and friends, and while I didn't check
them all, such uses of sizeof() is fine (even if it causes some
unnecessarily big allocations).
But there's a few that aren't obviously allocations (this is a list done
with grep and sparse, I didn't look at whether the values used are then
all allocation-related):
- builtin-blame.c:128 memset(o, 0, sizeof(*o));
- diff-delta.c:250 memsize = sizeof(*index)
- object-refs.c:23 size_t size = sizeof(*refs) + count*sizeof(struct object *);
- object-refs.c:61 size_t size = sizeof(*refs) + j*sizeof(struct object *);
- attr.c:220 sizeof(*res) +
- remote.c:467 memset(ret, 0, sizeof(struct ref) + namelen);
- remote.c:474 memcpy(ret, ref, sizeof(struct ref) + strlen(ref->name) + 1);
- transport.c:491 memset(ref, 0, sizeof(struct ref));
maybe somebody else can check them out (I've not sent out the hacky patch
to 'sparse' that found that assignment in unpack-trees.c, but since that
one was the only one it found, nobody should care - and it really was
pretty hacky).
Linus
---
diff-delta.c | 2 +-
unpack-trees.c | 2 +-
2 files changed, 2 insertions(+), 2 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;
diff --git a/unpack-trees.c b/unpack-trees.c
index e9eb795..aa2513e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -590,7 +590,7 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
* a match.
*/
if (same(old, merge)) {
- *merge = *old;
+ memcpy(merge, old, offsetof(struct cache_entry, name));
} else {
verify_uptodate(old, o);
invalidate_ce_path(old);
^ permalink raw reply related
* Re: Question about git-svn import
From: Pascal Obry @ 2007-12-18 7:10 UTC (permalink / raw)
To: Steven Walter; +Cc: git list
In-Reply-To: <20071218034836.GA27080@dervierte>
Steven Walter a écrit :
> Not sure if this is the best way, but I would recommend cloning into two
> repositories, then combining them.
I feared that :)
> So you already have the newer
> changes with the standard layout. You would now:
>
> $ git svn init <repo>
>
> And only fetch the revisions before the layout change. You could then
> combine the two repositories using .git/info/grafts and
> git-rewrite-branch.
Hum, looks like something not easy to do (at least for a Git beginner
like me) ! Any documentation on this ? Would you mind showing this on
the example script I sent ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ 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