* 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
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-18 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq8o370k.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007 21:29:31 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "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.
So do I
> 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
# uname -s
HP-UX
# uname -r
B.11.00
#
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [PATCH] filter-branch: Remove broken and unnecessary summary of rewritten refs.
From: Johannes Sixt @ 2007-12-18 7:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Johannes Sixt
There was an attempt to list the refs that were rewritten by filtering
the output of 'git show-ref' for 'refs/original'. But it got the
grep argument wrong, which did not account for the SHA1 that is listed
before the ref.
Moreover, right before this summary is the loop that actually does the
rewriting, and the rewritten refs are listed there anyway. So this extra
summary is plainly too verbose.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-filter-branch.sh | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 29d35fd..e730897 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -423,9 +423,6 @@ fi
cd ../..
rm -rf "$tempdir"
-echo
-test $count -gt 0 && echo "These refs were rewritten:"
-git show-ref | grep ^"$orig_namespace"
unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
test -z "$ORIG_GIT_DIR" || GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
--
1.5.4.rc0.73.gcaffa
^ permalink raw reply related
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 7:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <m3tzmgpzlu.fsf@roke.D-201>
On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski <jnareb@gmail.com>
wrote:
> 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.
And what if you OS *does* have an install, but one that is completely
useless^Wdifferent from the GNU install? Like the utterly useless
install on HP-UX.
> 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;
Yeah!
> 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.
Something like this? (gui part still missing). This is what I now
use
--8<--- make-install
#!/bin/sh
PREFIX=/pro/local
BINDIR=$PREFIX/bin
SHARED=$PREFIX/share
for p in git-fetch-pack git-hash-object git-index-pack git-fast-import \
git-daemon git-merge-index git-mktag git-mktree git-patch-id \
git-receive-pack git-send-pack git-shell git-show-index \
git-unpack-file git-update-server-info git-upload-pack \
git-pack-redundant git-var git-merge-tree git-imap-send \
git-merge-recursive git-bisect git-checkout git-clone \
git-merge-one-file git-mergetool git-parse-remote git-pull \
git-rebase git-rebase--interactive git-repack git-request-pull \
git-sh-setup git-am git-merge git-merge-stupid git-merge-octopus \
git-merge-resolve git-lost-found git-quiltimport git-submodule \
git-filter-branch git-stash git-add--interactive git-archimport \
git-cvsimport git-relink git-cvsserver git-remote git-cvsexportcommit \
git-send-email git-svn git-instaweb git-merge-subtree ; do
rm -f $BINDIR/$p
cp $p $BINDIR
chmod 755 $BINDIR/$p
done
cp git $BINDIR
cd templates
rm -rf $SHARED/git-core
mkdir $SHARED/git-core
mkdir $SHARED/git-core/templates
(cd blt && tar cf - .) | (cd $SHARED/git-core/templates/ && tar xf -)
cd ..
cd perl
make
make install UNINST=1
cd ..
for p in git-format-patch git-show git-whatchanged git-cherry \
git-get-tar-commit-id git-init git-repo-config git-fsck-objects \
git-cherry-pick git-peek-remote git-status git-add git-annotate \
git-apply git-archive git-blame git-branch git-bundle git-cat-file \
git-check-attr git-checkout-index git-check-ref-format git-clean \
git-commit git-commit-tree git-count-objects git-describe git-diff \
git-diff-files git-diff-index git-diff-tree git-fast-export \
git-fetch git-fetch-pack git-fetch--tool git-fmt-merge-msg \
git-for-each-ref git-fsck git-gc git-grep git-init-db git-log \
git-ls-files git-ls-tree git-ls-remote git-mailinfo git-mailsplit \
git-merge-base git-merge-file git-merge-ours git-mv git-name-rev \
git-pack-objects git-prune git-prune-packed git-push git-read-tree \
git-reflog git-send-pack git-config git-rerere git-reset \
git-rev-list git-rev-parse git-revert git-rm git-shortlog \
git-show-branch git-stripspace git-symbolic-ref git-tag git-tar-tree \
git-unpack-objects git-update-index git-update-ref \
git-upload-archive git-verify-pack git-verify-tag git-write-tree \
git-show-ref git-pack-refs ; do
rm -f $BINDIR/$p
ln $BINDIR/git $BINDIR/$p
done
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Johannes Sixt @ 2007-12-18 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, git
In-Reply-To: <7vbq8o370k.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "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.
Is select() actually needed? The one instance in pager.c can easily be
replaced by poll(), which I've already done in my own tree. The other one in
http.c is only used as a timer, but I don't know how to get rid of that.
Maybe a setitimer()/pause() combo?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 8:20 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218083843.42d7a15e@pc09.procura.nl>
On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
>
>> 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.
>
> And what if you OS *does* have an install, but one that is completely
> useless^Wdifferent from the GNU install? Like the utterly useless
> install on HP-UX.
Then "guess" section should have INSTALL=ginstall, or something.
Or just install with
INSTALL=/opt/bin/ginstall make install
or something like that.
>> 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;
>
> Yeah!
>
>> 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.
>
> Something like this? (gui part still missing). This is what I now
> use
>
> --8<--- make-install
Errr... please read more carefully. There is need for BSD-compatibile
`install` program as 'install-sh', not 'make-install' script. The idea
is to use system-provided 'install' if it exists and is compatibile,
because it should be faster than script version, and fallback to
provided install-sh only if system install is not found.
install-sh has to understand '-d' and '-m <mode>' switches for git
install purposes, and probably implement all three (src dest, src dir,
dir) formats.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: H.Merijn Brand @ 2007-12-18 8:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <200712180920.39633.jnareb@gmail.com>
On Tue, 18 Dec 2007 09:20:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> > On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
> >
> >> 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.
> >
> > And what if you OS *does* have an install, but one that is completely
> > useless^Wdifferent from the GNU install? Like the utterly useless
> > install on HP-UX.
>
> Then "guess" section should have INSTALL=ginstall, or something.
> Or just install with
>
> INSTALL=/opt/bin/ginstall make install
Chances are close to zero that HP-UX systems have installed any working
or compliant version of install
> or something like that.
>
> >> 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;
> >
> > Yeah!
> >
> >> 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.
> >
> > Something like this? (gui part still missing). This is what I now
> > use
> >
> > --8<--- make-install
>
> Errr... please read more carefully. There is need for BSD-compatibile
> `install` program as 'install-sh', not 'make-install' script. The idea
> is to use system-provided 'install' if it exists and is compatibile,
There lies the problem. HP-UX does have an 'install', but it is not
compatible, and chances are (very) small that people have installed
the GNU or any other BSD compliant install.
> because it should be faster than script version, and fallback to
> provided install-sh only if system install is not found.
The problem again. It *does* find install, but it turns out to be
unusable.
> install-sh has to understand '-d' and '-m <mode>' switches for git
> install purposes, and probably implement all three (src dest, src dir,
> dir) formats.
BTW the same, but worse exists for the 'patch' program. On HP-UX there
is a program called 'patch' which is used for system upgrades, but it
has nothing to do with the patch util the rest of the world so happily
uses.
So far that is used in a few places in the test suite, but I heared it
would not be too hard to eliminate the use of the hard-coded patch util
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-18 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Gerald Gutierrez, git
In-Reply-To: <7vbq8o6gxw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> It will show an empty output for "git diff", but I doubt thit will
>>> change anything at commit time. Probably the "filter" thing on the same
>>> file (also "man gitattributes") can help though.
>>
>> Ah, right. I completely missed that you were talking about git-commit,
>> not git-log on git commits.
>>
>> Yes, setting up a "clean" filter that removes the timestamps is probably
>> the reasonable thing to do here.
>
> I wouldn't do filters for something like that. Can you guarantee that
> the output from corresopnding smudge filter will load cleanly back to
> the mysql database?
The original poster said the date was an SQL comment, so, it should be
safe to strip it. That said, precommit hook is probably a good or
better solution. At least, if you're not sure you didn't make a
mistake writting it, you'll notice either a good commit or no commit
at all. With filters, you might well notice you corrupted the commit
too late :-(.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix segfault in diff-delta.c when FLEX_ARRAY is 1
From: Junio C Hamano @ 2007-12-18 9:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, spearce, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712172146070.21557@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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));
This is harmless and in fact unnecessary clearing, immediately before
calling free(3).
> - diff-delta.c:250 memsize = sizeof(*index)
I haven't studied this codepath.
> - object-refs.c:23 size_t size = sizeof(*refs) + count*sizeof(struct object *);
Overallocation to have at least "count" pointers to "struct object".
> - object-refs.c:61 size_t size = sizeof(*refs) + j*sizeof(struct object *);
Ditto for "j" pointers.
> - attr.c:220 sizeof(*res) +
Overallocation to have at least "num_attr" instances of "struct
attr_state" (plus name string if needed, which is stored using location
past state[num_attr]).
> - remote.c:467 memset(ret, 0, sizeof(struct ref) + namelen);
Clearing an arena that was overallocated to have at least namelen
elements of char[] on the line immediately before this, with matching
size. All callers pass namelen = strlen(name) + 1 so we are Ok even
when FLEX_ARRAY gives no extra space.
> - remote.c:474 memcpy(ret, ref, sizeof(struct ref) + strlen(ref->name) + 1);
Ditto.
> - transport.c:491 memset(ref, 0, sizeof(struct ref));
A line above overallocates to have enough room for strlen(ref_name) plus
terminating NUL, and after this lines clears the non-flex part, name is
copied. So this overclears a bit, but is harmless.
> 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);
Portability of offsetof() is slightly worrisome, but giving a
compatibility macro is trivial if this turns out to be problematic for
some people.
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: Catalin Marinas @ 2007-12-18 9:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071217224812.GA6342@diana.vm.bytemark.co.uk>
On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-17 11:09:06 +0000, Catalin Marinas wrote:
>
> > On 14/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> >
> > > The following series an emacs interface to stgit patch stacks. It
> > > shows a buffer with the the output of "stg series" and allows you
> > > to do some common operations on it, such as push/pop,
> > > commit/uncommit, edit, rename, repair, and coalesce.
> >
> > That's really cool stuff! Thanks.
>
> Yes, incredibly useful.
Other useful commands would be support for 'patches' and a local
diff/status (and maybe a menu).
> Be careful about merging past the "goto" patch -- I'm pretty sure it
> breaks when called from a subdirectory, and I don't have time to fix
> that right now. (It should be a clean fix, though -- just adjust the
> cwd for precisely those git subprocesses that need it, which is very
> few. I think.)
Why not just change the cwd when the command starts and it should be
safe for all the git subprocesses.
> If you like, I can advance "safe" to include as many patches as I
> think you should merge right now.
OK, thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jakub Narebski @ 2007-12-18 9:14 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andy Dougherty, git
In-Reply-To: <20071218093819.0b1caf16@pc09.procura.nl>
On Tue, 18 Dec 2007, H.Merijn Brand wrote:
> On Tue, 18 Dec 2007 09:20:38 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 18 Dec 2007, H.Merijn Brand wrote:
>>> On Mon, 17 Dec 2007 17:21:08 -0800 (PST), Jakub Narebski wrote:
>>>>
>>>> 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...
>>
>> [...]. There is need for BSD-compatibile
>> `install` program as 'install-sh', not 'make-install' script. The idea
>> is to use system-provided 'install' if it exists and is compatibile,
>
> There lies the problem. HP-UX does have an 'install', but it is not
> compatible, and chances are (very) small that people have installed
> the GNU or any other BSD compliant install.
>
>> because it should be faster than script version, and fallback to
>> provided install-sh only if system install is not found.
>
> The problem again. It *does* find install, but it turns out to be
> unusable.
Could you check if ./configure correctly uses install-sh in your case?
Copy install-sh from for example autotools[*1*] (e.g. libtool has one)
to the git sources, uncomment line with AC_PROG_INSTALL in configure.ac,
generate configure script using "make configure" and check what
./configure chooses.
In my case it is:
$ cp /usr/share/libtool/install-sh .
$ make configure
GIT_VERSION = 1.5.4.rc0.56.g6fbe-dirty
GEN configure
$ ./configure
configure: CHECKS for programs
[...]
checking for a BSD-compatible install... /usr/bin/install -c
What is ./configure output in your case?
Footnotes:
----------
[*1*] Or for example http://svn.scheffers.net/zlib/tclconfig/install-sh
which is smaller (2189 bytes vs. 9233 autotools one, or 10970 from
kapptemplate (kdesdk 3.5.3)).
--
Jakub Narebski
Poland
^ 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