* how to properly update dumb-hosted repo (using rsync..?)
From: Stephen Sinclair @ 2007-12-17 23:11 UTC (permalink / raw)
To: git
Hello!
I have a question related to dumb transports (i.e., http hosting without git).
I have a shell-accessible server which on which I have installed git,
but it is not a web server. So to make my git repo public I have put
the repo on a web server which I cannot install git on. I have made a
post-update hook on my server repo which runs git-update-server-info
and then uses rsync to copy the repo over to the public web server.
So far so good. I am able to clone the http-hosted repo and push
changes to my private server which then get copied over to the http
repo.
However, after a git-push/rsync operation, I typed git-pull to try and
pull the changes I'd just made, and got the following:
-------------------
$ git-pull
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch fetched.
No changes.
-------------------
However I haven't done any branching in this cloned repo, it is
immediately after a git-clone from the web server.
My .git/config basically looks like this, minus the "core" section:
-------------------
[remote "origin"]
url = http://my.server.com/git/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
-------------------
Which seems fine to me...
Any ideas?
This is of course only for people who want to clone my web-hosted repo
and then be able to subsequently git-pull my updates.
thanks,
Steve
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-17 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, git
In-Reply-To: <Pine.LNX.4.64.0712172300510.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 17 Dec 2007, Gerald Gutierrez wrote:
>
>> I do a nightly mysqldump of a database and check it into a git
>> repository. mysqldump generates a timestamp as part of that output which
>> is causing git to think that the file changes every night when it really
>> doesn't. The timestamp is simply in an SQL comment.
>>
>> So what I'd like to do is teach git to ignore that particular SQL
>> timestamp comment. I've tried to set up an external diff script that
>> runs diff -I "<<sql timestamp comment>>" that effectively ignores the
>> timestamp. While this works with "git diff", it seems when git commits,
>> it still sees the differences.
>>
>> How do I properly teach git to ignore these types of differences?
>
> You might be interested in reading Documentation/gitattributes.txt, look
> for "diff driver".
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.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Jeff King @ 2007-12-17 23:07 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <20071217210116.GB13004@artemis.madism.org>
On Mon, Dec 17, 2007 at 10:01:16PM +0100, Pierre Habouzit wrote:
> Err I misread your point, _yes_ we do, see builtin-show-ref.c, or see
> --start-number in builtin-log.c. There is a precedent.
Ugh. Well, in that case, it seems we are stuck with it, and I think
the behavior Junio laid out is the right course of action.
-Peff
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Jeff King @ 2007-12-17 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, J. Bruce Fields, git
In-Reply-To: <7vy7bt57wn.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 01:27:20PM -0800, Junio C Hamano wrote:
> > my $sanitized_sender = sanitize_address($sender);
> > - make_message_id();
> > + make_message_id() unless defined($message_id);
>
> Isn't this called inside a loop? If the outgoing message does not
> originally have "Message-Id:", does the loop correctly reinitialize
> $message_id to undef, or does this change make everybody reuse the same
> $message_id over and over again?
Yes, sorry. I realized it right after I sent the other out, but then a
repairman showed up to fix my non-working furnace. :)
The following needs to be squashed in (alternatively, the message_id
doesn't need to be a loop variable, so it could be cleaned up. But part
of me says that git-send-email is beyond hope for being clean).
diff --git a/git-send-email.perl b/git-send-email.perl
index 083466a..248d035 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -808,6 +808,7 @@ foreach my $t (@files) {
$references = "$message_id";
}
}
+ $message_id = undef;
}
if ($compose) {
> I have a feeling that --thread to format-patch is a misfeature. Why is
> it needed if you are feeding the output to send-email?
I think it is a case of --thread being added for people not using
send-email, and then getting it misused. I am just trying to add a
sanity check to send-email in case the user does something silly (though
one could certainly argue that it is already hopelessly tied to
git-format-patch, and fixing git-format-patch is the right way to go).
> I wonder if stripping existing "Message-Id:" away just like we strip
> away "Date:" from @xh would be a much saner fix.
That is definitely wrong if we expect to re-use the in-reply-to and
references headers that already exist (though obviously we could strip
out all three of those headers and re-add our own).
I don't have a strong opinion. I never use git-send-email myself, but
was just trying to fix a reported bug.
-Peff
^ permalink raw reply related
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Linus Torvalds @ 2007-12-17 23:01 UTC (permalink / raw)
To: Geert Bosch; +Cc: Harvey Harrison, Git Mailing List
In-Reply-To: <37BDCA73-4318-4BC8-9CCE-1DA30E4A09FC@adacore.com>
On Mon, 17 Dec 2007, Geert Bosch 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
Oops.
> Any ideas on what to do to resolve this?
Can you try the current git tree? "git fetch" is built-in these days, and
that old shell-script that ran "git fetch--tool" on all the refs is no
more, so most likely the problem simply no longer exists.
But maybe there is some way to raise the argument size limit on OS X. One
thing to check is whether maybe you have an excessively big environment
(just run "printenv" to see what it contains) which might be cutting down
on the size allowed for arguments.
Linus
^ permalink raw reply
* Re: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-17 23:01 UTC (permalink / raw)
To: Gerald Gutierrez; +Cc: git
In-Reply-To: <60687a7d0712171456p14328817y5aa229f0df23c02f@mail.gmail.com>
Hi,
On Mon, 17 Dec 2007, Gerald Gutierrez wrote:
> I do a nightly mysqldump of a database and check it into a git
> repository. mysqldump generates a timestamp as part of that output which
> is causing git to think that the file changes every night when it really
> doesn't. The timestamp is simply in an SQL comment.
>
> So what I'd like to do is teach git to ignore that particular SQL
> timestamp comment. I've tried to set up an external diff script that
> runs diff -I "<<sql timestamp comment>>" that effectively ignores the
> timestamp. While this works with "git diff", it seems when git commits,
> it still sees the differences.
>
> How do I properly teach git to ignore these types of differences?
You might be interested in reading Documentation/gitattributes.txt, look
for "diff driver".
Hth,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Junio C Hamano @ 2007-12-17 23:00 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Sebastian Harl, git
In-Reply-To: <506C6191-655D-46AE-A5C2-1335A9044F44@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> ... The current behavior of git stash is very
> dangerous as the following frequently happens to new comers:
> $ git stash
> $ <hack on something else>
> $ git commit
> $ git stash apply
> $ git stash clean # Oops, typo, I just stashed my changes again
> $ git stash clear # Oops, I just lost my changed
This is a plain FUD, isn't it? The first Oops should not happen these
days.
^ permalink raw reply
* Re: "Argument list too long" in git remote update (Was: Git and GCC)
From: Johannes Schindelin @ 2007-12-17 22:59 UTC (permalink / raw)
To: Geert Bosch; +Cc: Harvey Harrison, Git Mailing List
In-Reply-To: <37BDCA73-4318-4BC8-9CCE-1DA30E4A09FC@adacore.com>
Hi,
On Mon, 17 Dec 2007, Geert Bosch wrote:
> On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
> > After the discussions lately regarding the gcc svn mirror. I'm coming
> > up with a recipe to set up your own git-svn mirror. Suggestions on the
> > following.
> >
> > // Create directory and initialize git
> > mkdir gcc
> > cd gcc
> > git init
> > // add the remote site that currently mirrors gcc
> > // I have chosen the name gcc.gnu.org *1* as my local name to refer to
> > // this choose something else if you like
> > git remote add gcc.gnu.org git://git.infradead.org/gcc.git
> > // fetching someone else's remote branches is not a standard thing to do
> > // so we'll need to edit our .git/config file
> > // you should have a section that looks like:
> > [remote "gcc.gnu.org"]
> > url = git://git.infradead.org/gcc.git
> > fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> > // infradead's mirror puts the gcc svn branches in its own namespace
> > // refs/remotes/gcc.gnu.org/*
> > // change our fetch line accordingly
> > [remote "gcc.gnu.org"]
> > url = git://git.infradead.org/gcc.git
> > fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> > // fetch the remote data from the mirror site
> > git remote update
>
> 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
> warning: no common commits
> [after a long wait and a good amount of network traffic]
> fatal: index-pack died of signal 13
> fetch gcc.gnu.org: command returned error: 126
> potomac%:~/gcc%
>
> Any ideas on what to do to resolve this?
Unfortunately, the builtin remote did not make it into git's master yet,
and it will probably miss 1.5.4.
Chances are that this would make the bug go away, but Junio said that on
one of his machines, the regression tests fail with the builtin remote.
In the meantime, "git fetch gcc.gnu.org" should do what you want,
methinks.
Hth,
Dscho
^ permalink raw reply
* git with custom diff for commits
From: Gerald Gutierrez @ 2007-12-17 22:56 UTC (permalink / raw)
To: git
Hello folks,
I do a nightly mysqldump of a database and check it into a git
repository. mysqldump generates a timestamp as part of that output
which is causing git to think that the file changes every night when
it really doesn't. The timestamp is simply in an SQL comment.
So what I'd like to do is teach git to ignore that particular SQL
timestamp comment. I've tried to set up an external diff script that
runs diff -I "<<sql timestamp comment>>" that effectively ignores the
timestamp. While this works with "git diff", it seems when git
commits, it still sees the differences.
How do I properly teach git to ignore these types of differences?
Gerald.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-17 22:55 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <20071217223055.GI13515@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> Hm. We tell people to set up public repo's by doing something like:
>
> git clone --bare ~/proj proj.git
> touch proj.git/git-daemon-export-ok
> scp -r proj.git example.com:
>
> Is that going to hit the same problem if the public server has an older
> git version?
It will, but I think you should teach people --mirror pushing these
days, which was specifically invented for priming the public
repository.
That way, the administrator at example.com, as long as he initializes an
empty repository with suitable daemon-export-ok and necessary hooks
(which can be automated via templates), does not even have to allow you
a full ssh access.
^ permalink raw reply
* Re: [PATCH] Minor portability patch to git-submodule
From: Johannes Schindelin @ 2007-12-17 22:54 UTC (permalink / raw)
To: Andy Dougherty; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712171639420.24957@fractal.phys.lafayette.edu>
Hi,
On Mon, 17 Dec 2007, Andy Dougherty wrote:
> - git ls-files --stage -- "$@" | grep -e '^160000 ' |
> + git ls-files --stage -- "$@" | egrep -e '^160000 ' |
Nack. egrep is not available on all platforms. But then I have to wonder
why not saying "grep '^160000 '" instead?
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH 00/17] Series short description
From: Karl Hasselström @ 2007-12-17 22:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712170309n415dc6cs9d1c1f8a9c687bf8@mail.gmail.com>
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.
I've put this series in kha/safe -- except for the mark and coalesce
patches, which are at the tip of kha/experimental. The latter because
it obviously has to be, the former because the latter is the only
thing using it and it's _extremely annoying_ to be able to mark
patches but not, say, push or pop all marked patches.
My stack is now 53 patches deep, so running the test suite on every
patch is getting time consuming -- I'd guess about two hours on my
poor laptop. And I plan to sleep while that runs, so I won't actually
push this until tomorrow.
> > The coalesce command obviosly requires the kha/experimental
> > branch. The edit command requires the edit fixes in kha/safe.
>
> I'll start this week merging patches from kha/experimental (I'm a
> bit slow because of the Christmas activities).
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.)
If you like, I can advance "safe" to include as many patches as I
think you should merge right now.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Explain what 'ginstall' is
From: Andy Dougherty @ 2007-12-17 21:46 UTC (permalink / raw)
To: git
While trying git out on Solaris 8, the 'make install' step failed because
I don't have a 'ginstall' command. After puzzling over it for a while,
I finally figured out that
a) it's referring to the 'install' command that is now part of the
GNU coreutils package, and
b) it's probably unnecessary, as using the Solaris install command
gave me the same results. (However, I didn't do anything fancy,
so it may be that in some scenarios using 'ginstall' matters.
I didn't do anything other than a very simple test.)
Anyway, this patch documents it a tiny bit more. Perhaps configure
should just go looking for a suitable install program instead of
assuming everyone has one.
--- git-1.5.4.rc0/Makefile 2007-12-12 21:29:16.000000000 -0500
+++ git-andy/Makefile 2007-12-17 15:15:12.000000000 -0500
@@ -416,6 +416,9 @@
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
endif
+# For SunOS, this assumes you have ginstall from the
+# GNU coreutils package. It's not clear whether that
+# is actually necessary.
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* [PATCH] Minor portability patch to git-submodule
From: Andy Dougherty @ 2007-12-17 21:41 UTC (permalink / raw)
To: git
While trying git out on Solaris 8, I needed the following patch.
The 'grep' command on Solaris doesn't understand the -e option, though
egrep does.
More mysterious is the printf patch. Without it, the sed command didn't
match anything.
--- git-1.5.4.rc0/git-submodule.sh Wed Dec 12 21:29:16 2007
+++ git-andy/git-submodule.sh Mon Dec 17 14:30:46 2007
@@ -74,7 +74,7 @@
module_name()
{
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
- re=$(printf '%s' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
+ re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
@@ -176,7 +176,7 @@
#
modules_init()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
# Skip already registered paths
@@ -209,7 +209,7 @@
#
modules_update()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
@@ -268,7 +268,7 @@
#
modules_list()
{
- git ls-files --stage -- "$@" | grep -e '^160000 ' |
+ git ls-files --stage -- "$@" | egrep -e '^160000 ' |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Benoit Sigoure @ 2007-12-17 22:32 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20071217110322.GH14889@albany.tokkee.org>
On Dec 17, 2007, at 12:03 PM, Sebastian Harl wrote:
> Hi,
>
> By default, git-stash (when called without any other arguments)
> creates a new
> stash. This is quite different to the behavior of most other Git
> commands
> (e.g. git-tag, git-branch, etc. do "list" by default). In order to
> improve
> consistency git-stash should imho adopt this as well.
>
> The creation of a new stash should not do any harm. However, I
> think that
> consistency is more important (iirc this has been mentioned in the
> current
> survey a couple of times) and doing "list" is (in general) the best
> default.
Hi Sebastian,
this topic has been brought up the ML several times already, and
there seems to be some sort of consensus on the misbehavior of git
stash and what the default should be (listing the stashes seems like
a decent default action). The current behavior of git stash is very
dangerous as the following frequently happens to new comers:
$ git stash
$ <hack on something else>
$ git commit
$ git stash apply
$ git stash clean # Oops, typo, I just stashed my changes again
$ git stash clear # Oops, I just lost my changed
Hopefully, Git gives you means to recover from this sort of error,
but most of the time new comers don't know them and just assume they
lost their work.
Whenever I use git stash, it gives me chills, because I know I can
easily screw things up (even though now I know how to recover from
this sort of "user error").
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-17 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vtzmh55lu.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> >> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >>
> >> > By the way, just as a data point: I do keep some git repositories on
> >> > NFS, and access them from multiple machines with different git versions
> >> > (not on purpose--it's just that the machines don't all run the same
> >> > distro, so it'd be extra work to give them all the same version). I
> >> > don't use anything older than 1.5.0. If the repository became unusable
> >> > on one of those machines without warning it'd be annoying.
> >>
> >> What the v1.5.5 release notes will say is that you'll have to set
> >> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
> >
> > Is there any reason not to make pack.indexversion=1 the default (for
> > preexisting repositories at the very least) and suggest in the release
> > notes that people set something else if they want the features the new
> > version provides?
>
> That's a judgement call.
Sure. And I'm totally unfamiliar with the details here, so don't my let
my judgement weigh too heavily.
> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?). But from the end
> user's point of view, all the usual "I do not want to be forced to
> update that old box I do not want to touch" applies.
>
> And the people who needs to suffer from the dilemma are only the ones
> who access a single repository across NFS with git from different
> vintage.
Hm. We tell people to set up public repo's by doing something like:
git clone --bare ~/proj proj.git
touch proj.git/git-daemon-export-ok
scp -r proj.git example.com:
Is that going to hit the same problem if the public server has an older
git version? (Servers do tend to be on longer upgrade cycles; the
public server I use was on something 1.4ish till about a month ago.)
--b.
^ permalink raw reply
* Re: [PATCH] the use of 'tr' in the test suite isn't really portable
From: H.Merijn Brand @ 2007-12-17 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk7t6pc6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
On Mon, 17 Dec 2007 12:25:29 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> The contents looked correct but the patch was garbled.
http://www.xs4all.nl/~procura/git-tr.diff
and attached
The docs tell me to use git-diff, but I don't have a git repos for git,
because git on HP-UX doesn't work yet out of the box, so I use the
snapshots from http://www.codemonkey.org.uk/projects/git-snapshots/git/
This was based on 2007-12-17
--
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/
[-- Attachment #2: git-tr.diff --]
[-- Type: text/x-patch, Size: 6991 bytes --]
diff -pur git-2007-12-10_01/git-filter-branch.sh git-2007-12-10/git-filter-branch.sh
--- git-2007-12-10_01/git-filter-branch.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/git-filter-branch.sh 2007-12-11 13:39:02 +0100
@@ -290,7 +290,7 @@ while read commit parents; do
eval "$filter_tree" < /dev/null ||
die "tree filter failed: $filter_tree"
- git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
+ git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
diff -pur git-2007-12-10_01/t/diff-lib.sh git-2007-12-10/t/diff-lib.sh
--- git-2007-12-10_01/t/diff-lib.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/diff-lib.sh 2007-12-11 13:39:56 +0100
@@ -21,8 +21,8 @@ compare_diff_raw_z () {
# Also we do not check SHA1 hash generation in this test, which
# is a job for t0000-basic.sh
- tr '\0' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
- tr '\0' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
+ tr '\000' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
+ tr '\000' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
git diff .tmp-1 .tmp-2 && rm -f .tmp-1 .tmp-2
}
diff -pur git-2007-12-10_01/t/t0020-crlf.sh git-2007-12-10/t/t0020-crlf.sh
--- git-2007-12-10_01/t/t0020-crlf.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t0020-crlf.sh 2007-12-10 14:25:58 +0100
@@ -5,7 +5,7 @@ test_description='CRLF conversion'
. ./test-lib.sh
q_to_nul () {
- tr Q '\0'
+ tr Q '\000'
}
append_cr () {
diff -pur git-2007-12-10_01/t/t1300-repo-config.sh git-2007-12-10/t/t1300-repo-config.sh
--- git-2007-12-10_01/t/t1300-repo-config.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t1300-repo-config.sh 2007-12-10 09:49:48 +0100
@@ -591,12 +591,12 @@ Qsection.sub=section.val4
Qsection.sub=section.val5Q
EOF
-git config --null --list | tr '[\000]' 'Q' > result
+git config --null --list | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --list' 'cmp result expect'
-git config --null --get-regexp 'val[0-9]' | tr '[\000]' 'Q' > result
+git config --null --get-regexp 'val[0-9]' | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --get-regexp' 'cmp result expect'
diff -pur git-2007-12-10_01/t/t3300-funny-names.sh git-2007-12-10/t/t3300-funny-names.sh
--- git-2007-12-10_01/t/t3300-funny-names.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t3300-funny-names.sh 2007-12-11 13:40:32 +0100
@@ -54,7 +54,7 @@ echo 'just space
no-funny
tabs ," (dq) and spaces' >expected
test_expect_success 'git ls-files -z with-funny' \
- 'git ls-files -z | tr \\0 \\012 >current &&
+ 'git ls-files -z | tr \\000 \\012 >current &&
git diff expected current'
t1=`git write-tree`
@@ -83,11 +83,11 @@ test_expect_success 'git diff-tree with-
echo 'A
tabs ," (dq) and spaces' >expected
test_expect_success 'git diff-index -z with-funny' \
- 'git diff-index -z --name-status $t0 | tr \\0 \\012 >current &&
+ 'git diff-index -z --name-status $t0 | tr \\000 \\012 >current &&
git diff expected current'
test_expect_success 'git diff-tree -z with-funny' \
- 'git diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
+ 'git diff-tree -z --name-status $t0 $t1 | tr \\000 \\012 >current &&
git diff expected current'
cat > expected <<\EOF
diff -pur git-2007-12-10_01/t/t4020-diff-external.sh git-2007-12-10/t/t4020-diff-external.sh
--- git-2007-12-10_01/t/t4020-diff-external.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4020-diff-external.sh 2007-12-11 13:40:44 +0100
@@ -99,7 +99,7 @@ test_expect_success 'no diff with -diff'
git diff | grep Binary
'
-echo NULZbetweenZwords | tr Z '\0' > file
+echo NULZbetweenZwords | tr Z '\000' > file
test_expect_success 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
diff -pur git-2007-12-10_01/t/t4103-apply-binary.sh git-2007-12-10/t/t4103-apply-binary.sh
--- git-2007-12-10_01/t/t4103-apply-binary.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4103-apply-binary.sh 2007-12-11 13:40:57 +0100
@@ -24,10 +24,10 @@ git update-index --add --remove file1 fi
git-commit -m 'Initial Version' 2>/dev/null
git-checkout -b binary
-tr 'x' '\0' <file1 >file3
+tr 'x' '\000' <file1 >file3
cat file3 >file4
git add file2
-tr '\0' 'v' <file3 >file1
+tr '\000' 'v' <file3 >file1
rm -f file2
git update-index --add --remove file1 file2 file3 file4
git-commit -m 'Second Version'
diff -pur git-2007-12-10_01/t/t4116-apply-reverse.sh git-2007-12-10/t/t4116-apply-reverse.sh
--- git-2007-12-10_01/t/t4116-apply-reverse.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4116-apply-reverse.sh 2007-12-11 13:42:13 +0100
@@ -12,14 +12,14 @@ test_description='git apply in reverse
test_expect_success setup '
for i in a b c d e f g h i j k l m n; do echo $i; done >file1 &&
- tr "[ijk]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "ijk" '\''\000\001\002'\'' <file1 >file2 &&
git add file1 file2 &&
git commit -m initial &&
git tag initial &&
for i in a b c g h i J K L m o n p q; do echo $i; done >file1 &&
- tr "[mon]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "mon" '\''\000\001\002'\'' <file1 >file2 &&
git commit -a -m second &&
git tag second &&
diff -pur git-2007-12-10_01/t/t4200-rerere.sh git-2007-12-10/t/t4200-rerere.sh
--- git-2007-12-10_01/t/t4200-rerere.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4200-rerere.sh 2007-12-11 13:42:28 +0100
@@ -129,7 +129,7 @@ test_expect_success 'rerere kicked in' "
test_expect_success 'rerere prefers first change' 'git diff a1 expect'
rm $rr/postimage
-echo "$sha1 a1" | tr '\012' '\0' > .git/rr-cache/MERGE_RR
+echo "$sha1 a1" | tr '\012' '\000' > .git/rr-cache/MERGE_RR
test_expect_success 'rerere clear' 'git rerere clear'
diff -pur git-2007-12-10_01/t/t5300-pack-object.sh git-2007-12-10/t/t5300-pack-object.sh
--- git-2007-12-10_01/t/t5300-pack-object.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t5300-pack-object.sh 2007-12-11 13:42:46 +0100
@@ -15,7 +15,7 @@ test_expect_success \
'rm -f .git/index*
for i in a b c
do
- dd if=/dev/zero bs=4k count=1 | tr "\\0" $i >$i &&
+ dd if=/dev/zero bs=4k count=1 | tr "\\000" $i >$i &&
git update-index --add $i || return 1
done &&
cat c >d && echo foo >>d && git update-index --add d &&
diff -pur git-2007-12-10_01/test-sha1.sh git-2007-12-10/test-sha1.sh
--- git-2007-12-10_01/test-sha1.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/test-sha1.sh 2007-12-11 13:39:29 +0100
@@ -10,7 +10,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | ./test-sha1 $cnt
`
if test "$expect" = "$actual"
@@ -55,7 +55,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | sha1sum |
sed -e 's/ .*//'
`
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-17 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x3t6nq1.fsf@gitster.siamese.dyndns.org>
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.
Probably. but there is so much to be improved :)
> POSIX.1-2001 expects <sys/select.h> declares select(2). With earlier
> standards, including <sys/time.h>, <sys/types.h> and <unistd.h> would
> have given it.
Those three are there. I have 10.20 through 11.23 on PA-RISC and
11.23 on Itanium 2.
10.20, 11.00, and 11.11 (11i v1) do not have sys/select.h. 11.23 and
on do have it. The problem for now is that git on HP-UX does not build
with HP's C-ANSI-C compiler. I need to use gcc. Up to and including
11.11, I cannot use 4.x, as that has serious problems when used in 64bit
mode, so I'm stuck with gcc-3.4.6
> HP-UX cannot be the only pre-POSIX system; "#ifndef _HPUX_SOURCE" feels
> very wrong.
HP-UX 11.23/IPC, which is rather recent, does include sys/select.h
I didn't sent my HP-UX patch yet for the Makefile, as that is still
very premature. It is OK for 11.00, but as I need 64bit on 11.23,
because I only have 64bit OpenSSL and other util libraries, the 32bit
addition would not work.
> 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...
> are for the application to define, and for the implementation (iow, the
> header files) to find out what set of names the application wants to
> see. You are making the application examine the symbol to see what
> implementation it is on, which feels backwards to me.
--
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] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-17 22:17 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <20071217215709.GH13515@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
>> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
>>
>> > By the way, just as a data point: I do keep some git repositories on
>> > NFS, and access them from multiple machines with different git versions
>> > (not on purpose--it's just that the machines don't all run the same
>> > distro, so it'd be extra work to give them all the same version). I
>> > don't use anything older than 1.5.0. If the repository became unusable
>> > on one of those machines without warning it'd be annoying.
>>
>> What the v1.5.5 release notes will say is that you'll have to set
>> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
>
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?
That's a judgement call.
Pack-idx format v2 is by design much safer in the face of bitflip (do we
have a test case to make sure this is indeed true?). But from the end
user's point of view, all the usual "I do not want to be forced to
update that old box I do not want to touch" applies.
And the people who needs to suffer from the dilemma are only the ones
who access a single repository across NFS with git from different
vintage. If that is a minority and/or tends to be more clueful people,
the inconvenience factor may be outweighed by the advantage v2 offers,
and pushing adoption of v2 harder the way Nico is driving at would
generally be a good thing.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 22:15 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217215709.GH13515@fieldses.org>
On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> > On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >
> > > By the way, just as a data point: I do keep some git repositories on
> > > NFS, and access them from multiple machines with different git versions
> > > (not on purpose--it's just that the machines don't all run the same
> > > distro, so it'd be extra work to give them all the same version). I
> > > don't use anything older than 1.5.0. If the repository became unusable
> > > on one of those machines without warning it'd be annoying.
> >
> > What the v1.5.5 release notes will say is that you'll have to set
> > pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
>
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?
That's already the case now.
But the thing is that index version 2 is better and actually plug a flaw
in the repacking process where unnoticed corruption could be repacked
otherwise. So for better repo integrity sake, it has to become the
default at some point.
Nicolas
^ permalink raw reply
* "Argument list too long" in git remote update (Was: Git and GCC)
From: Geert Bosch @ 2007-12-17 22:15 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Git Mailing List
In-Reply-To: <1197572755.898.15.camel@brick>
On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
> After the discussions lately regarding the gcc svn mirror. I'm coming
> up with a recipe to set up your own git-svn mirror. Suggestions on
> the
> following.
>
> // Create directory and initialize git
> mkdir gcc
> cd gcc
> git init
> // add the remote site that currently mirrors gcc
> // I have chosen the name gcc.gnu.org *1* as my local name to refer to
> // this choose something else if you like
> git remote add gcc.gnu.org git://git.infradead.org/gcc.git
> // fetching someone else's remote branches is not a standard thing
> to do
> // so we'll need to edit our .git/config file
> // you should have a section that looks like:
> [remote "gcc.gnu.org"]
> url = git://git.infradead.org/gcc.git
> fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> // infradead's mirror puts the gcc svn branches in its own namespace
> // refs/remotes/gcc.gnu.org/*
> // change our fetch line accordingly
> [remote "gcc.gnu.org"]
> url = git://git.infradead.org/gcc.git
> fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> // fetch the remote data from the mirror site
> git remote update
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
warning: no common commits
[after a long wait and a good amount of network traffic]
fatal: index-pack died of signal 13
fetch gcc.gnu.org: command returned error: 126
potomac%:~/gcc%
Any ideas on what to do to resolve this?
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-17 21:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712171646230.8467@xanadu.home>
On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
>
> > By the way, just as a data point: I do keep some git repositories on
> > NFS, and access them from multiple machines with different git versions
> > (not on purpose--it's just that the machines don't all run the same
> > distro, so it'd be extra work to give them all the same version). I
> > don't use anything older than 1.5.0. If the repository became unusable
> > on one of those machines without warning it'd be annoying.
>
> What the v1.5.5 release notes will say is that you'll have to set
> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
Is there any reason not to make pack.indexversion=1 the default (for
preexisting repositories at the very least) and suggest in the release
notes that people set something else if they want the features the new
version provides?
--b.
> And even if you forget about it then there'll be a simple way to regain
> compatibility after the facts.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 21:52 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217213049.GG13515@fieldses.org>
On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> By the way, just as a data point: I do keep some git repositories on
> NFS, and access them from multiple machines with different git versions
> (not on purpose--it's just that the machines don't all run the same
> distro, so it'd be extra work to give them all the same version). I
> don't use anything older than 1.5.0. If the repository became unusable
> on one of those machines without warning it'd be annoying.
What the v1.5.5 release notes will say is that you'll have to set
pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
And even if you forget about it then there'll be a simple way to regain
compatibility after the facts.
Nicolas
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Steffen Prohaska @ 2007-12-17 21:52 UTC (permalink / raw)
To: Git Mailing List, msysGit
In-Reply-To: <7vbq8v5n0u.fsf_-_@gitster.siamese.dyndns.org>
On Dec 13, 2007, at 3:47 AM, Junio C Hamano wrote:
> The tip of 'master' is now tagged as 1.5.4-rc0. Tarballs are found in
> the usual places:
A fresh msysgit self-contained Windows setup is available from
http://msysgit.googlecode.com/files/Git-1.5.4-rc0-preview20071217.exe
Steffen
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <7v3au16myj.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> This is mostly spilt milk under the bridge now, but I have to mildly
> disagree.
>
> If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,
> and made the format negotiation in fetch-pack protocol pay attention to
> that variable, Joel's coworker did not have to suffer if the repository
> explicitly asked OFS_DELTA not to be used.
>
> 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.
If, on the other hand, the latest Git version wasn't able to read it
either then this is a different matter entirely.
Nicolas
^ 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