* Re: [PATCH] Improved and extended t5404
From: Junio C Hamano @ 2007-11-14 0:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Jeff King
In-Reply-To: <20071113230234.GI3268@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test
This proposed log message solicits a "Huh? -- Since when
ignoring exit code is an improvement?" reaction. If this push
is expected to error out, then wouldn't you want to make sure it
errors out as expected? If the problem is that the exit status
is unreliable, maybe we need to make it reliable instead?
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Alex Riesen @ 2007-11-14 0:02 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18234.14781.55429.671459@lisa.zopyra.com>
Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100:
> On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
> >...
> >> >I extend the part you quoted. The file is opened here:
> >> >...
> >> >This is strange. The current git should not produce anything like
> >> >this (and does not, here). ...
> >>
> >> You are absolutely correct. My comrade ran this with 1.5.0.1 by
> >> mistake. He reran the strace with 1.5.3.5, and I have replaced
> >> the tarball on my server:
> >>
> >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
> >
> >Still looks like v1.5.0.1:
> >
> > write(2, "fatal: ", 7) = 7
> > write(2, "cannot pread pack file: No such "..., 49) = 49
>
> Well, I just grepped for the above string in git-1.5.3.5:
>
> % grep 'cannot pread pack file' *.c
> index-pack.c: die("cannot pread pack file: %s", strerror(errno));
oh, you should be looking for usage.c, the function report (it is
called by default die handler). The old code used to fputs("fatal:"),
the new just vfprintf's everything, so the write should look like:
write(2, "fatal: cannot pread pack file: No such "...
^ permalink raw reply
* Re: [PATCH] Fix dependencies of parse-options test program
From: Junio C Hamano @ 2007-11-14 0:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Schindelin
In-Reply-To: <20071113231636.GJ3268@steel.home>
Ah, I saw the breakage once but was too late at night to see
what was wrong myself. Thanks.
^ permalink raw reply
* Re: Git and Scmbug integration
From: Alex Riesen @ 2007-11-14 0:04 UTC (permalink / raw)
To: David Symonds; +Cc: Kristis Makris, git, scmbug-users
In-Reply-To: <ee77f5c20711131553j587cb566id6d76bd23182dd6@mail.gmail.com>
David Symonds, Wed, Nov 14, 2007 00:53:43 +0100:
> On Nov 14, 2007 10:47 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > http://bugzilla.mkgnu.net/show_bug.cgi?id=992
> > >
> > > Git does not offer metadata describing a change on the commit trigger
> > >
> > > The commit trigger seems to be "post-commit" but it supplies no arguments.
> >
> > HEAD?
>
> That wouldn't be particularly safe if you have a very quick succession
> of commits (say, via a rebase, or automated operations) because HEAD
> could be moved by the time the post-commit hook reads it.
How's that? git-commit waits for its hooks.
^ permalink raw reply
* Re: [PATCH] Fix dependencies of parse-options test program
From: Pierre Habouzit @ 2007-11-14 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711132345310.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Tue, Nov 13, 2007 at 11:46:20PM +0000, Johannes Schindelin wrote:
> Hi,
>
> apparently I forgot to send this patch, which I thought was only relevant
> in the builtin-commit branch of mine:
Btw is there a reason why git doesn't use the gcc -M* options to have
proper dependency informations ? I understand not everyone has a gcc
compiler at hand, but still, most of the compilers know how to do that.
We could even borough depcomp from automake for that task.
I've been bitten by dependencies issues in git many times, and it's
only now that I understand that it was dependency issues, I always
assumed git Makefiles dealt with that already, and I believe that'd be
nice to have a real solution for that.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-14 0:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Kristis Makris, git, scmbug-users
In-Reply-To: <20071114000457.GM3268@steel.home>
On Nov 14, 2007 11:04 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> David Symonds, Wed, Nov 14, 2007 00:53:43 +0100:
> > On Nov 14, 2007 10:47 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > > http://bugzilla.mkgnu.net/show_bug.cgi?id=992
> > > >
> > > > Git does not offer metadata describing a change on the commit trigger
> > > >
> > > > The commit trigger seems to be "post-commit" but it supplies no arguments.
> > >
> > > HEAD?
> >
> > That wouldn't be particularly safe if you have a very quick succession
> > of commits (say, via a rebase, or automated operations) because HEAD
> > could be moved by the time the post-commit hook reads it.
>
> How's that? git-commit waits for its hooks.
Okay, so if it triggers an asynchronous process it just needs to be
careful enough to pass whatever HEAD resolves to at the time. Cool.
Dave.
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Bill Lear @ 2007-11-14 0:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071114000218.GL3268@steel.home>
On Wednesday, November 14, 2007 at 01:02:18 (+0100) Alex Riesen writes:
>Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100:
>> On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
>> >...
>> >> >I extend the part you quoted. The file is opened here:
>> >> >...
>> >> >This is strange. The current git should not produce anything like
>> >> >this (and does not, here). ...
>> >>
>> >> You are absolutely correct. My comrade ran this with 1.5.0.1 by
>> >> mistake. He reran the strace with 1.5.3.5, and I have replaced
>> >> the tarball on my server:
>> >>
>> >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
>> >
>> >Still looks like v1.5.0.1:
>> >
>> > write(2, "fatal: ", 7) = 7
>> > write(2, "cannot pread pack file: No such "..., 49) = 49
>>
>> Well, I just grepped for the above string in git-1.5.3.5:
>>
>> % grep 'cannot pread pack file' *.c
>> index-pack.c: die("cannot pread pack file: %s", strerror(errno));
>
>oh, you should be looking for usage.c, the function report (it is
>called by default die handler). The old code used to fputs("fatal:"),
>the new just vfprintf's everything, so the write should look like:
>
> write(2, "fatal: cannot pread pack file: No such "...
Are you sure?
% ls -l git-1.5.3.5.tar.bz2
-rw-r--r-- 1 blear software 1351433 2007-10-31 15:04 git-1.5.3.5.tar.bz2
% bunzip2 -c !$ | tar xf -
% cd git-1.5.3.5
% grep -A 5 'void report' usage.c
static void report(const char *prefix, const char *err, va_list params)
{
fputs(prefix, stderr);
vfprintf(stderr, err, params);
fputs("\n", stderr);
}
Bill
^ permalink raw reply
* Re: [PATCH] Fix dependencies of parse-options test program
From: Johannes Schindelin @ 2007-11-14 0:12 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <20071114000833.GC22836@artemis.corp>
Hi,
On Wed, 14 Nov 2007, Pierre Habouzit wrote:
> On Tue, Nov 13, 2007 at 11:46:20PM +0000, Johannes Schindelin wrote:
>
> > apparently I forgot to send this patch, which I thought was only
> > relevant in the builtin-commit branch of mine:
>
> Btw is there a reason why git doesn't use the gcc -M* options to have
> proper dependency informations ?
I suspect the reason is that we do not want to depend on gcc...
Ciao,
Dscho
^ permalink raw reply
* Re: Git and Scmbug integration
From: Kristis Makris @ 2007-11-14 0:16 UTC (permalink / raw)
To: David Symonds; +Cc: jnareb, git, scmbug-users
In-Reply-To: <ee77f5c20711131602m5b9042fx72689af53e24ddd2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
On Wed, 2007-11-14 at 11:02 +1100, David Symonds wrote:
> On Nov 14, 2007 10:55 AM, Kristis Makris <kristis.makris@asu.edu> wrote:
> > On Wed, 2007-11-14 at 10:00 +1100, David Symonds wrote:
> > > > http://bugzilla.mkgnu.net/show_bug.cgi?id=991
> > > >
> > > > There's no hook that will trigger when a tag is applied.
> > >
> > > I believe the 'update' hook is run when the tag is pushed.
> >
> > Even if that is true, there no hook that will trigger when a local tag
> > is applied.
>
> Unannotated tags don't make a proper new object, only a ref. If you
> stick to annotated tags, you'll get new objects added which, I think,
> should trigger the post-commit hook.
I just tried again tagging with both:
$ git tag TAG_NAME
$ git tag -a TAG_NAME
and I don't get the post-commit hook executed.
Perhaps I missed something ?
> > I'd like the commit hook to provide enough information to be able to
> > tell which files were modified and their respective old/new version (or
> > perhaps their old/new SHA-1 hash). If the new SHA-1 hash can be used to
> > extract all that, that's ok with me. But right now there's nothing.
>
> If you have the new commit's SHA-1, it's very simple to get the parent
> commit's SHA-1 and do whatever you want. A complexity would be with
> handling merges, where a commit has multiple parents. If you have a
> commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>"
> to get a list of the files changed by <hash>.
This sounds great. If the post-commit hook could now provide the new
commit SHA-1 hash than that should be what I need.
Can the new commit SHA-1 hash be added as a parameter to the post-commit
hook please ?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.
From: Jakub Narebski @ 2007-11-14 0:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711132154370.4362@racer.site>
Johannes Schindelin wrote:
> While we're at cherry-pick: Two days ago I had to rebase in a dirty
> working directory. Why? Because one of the submodules was not yet ready
> to be committed to the superproject.
>
> And you cannot easily stash away a submodule.
git stash --recursive (to be written)? ;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Junio C Hamano @ 2007-11-14 0:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <vpqd4ud6c0z.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> (2)
>
> $ mkdir ~/bare-repo
> $ cd ~/bare-repo
> $ git --bare init
> $ cd
> $ mkdir local/non-bare
> $ cd local/non-bare
> $ git init
...
If your publishing repo is local like the above, then
$ mkdir /tmp/junk && cd /tmp/junk
$ git init; tar xf /tmp/project.tar; git add .; ... populate ...
$ git commit -m initial
$ cd /else/where/to/publish
$ git clone --bare /tmp/junk myproject.git
$ rm -fr /tmp/junk
would be enough to get your published repository started, isn't
it? Then wouldn't:
$ cd $HOME
$ git clone /else/where/to/publish/myproject.git myproject
set up your ~/myproject exactly the same way as other people who
will work with that published repository?
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-14 0:27 UTC (permalink / raw)
To: Kristis Makris; +Cc: jnareb, git, scmbug-users
In-Reply-To: <1194999404.4106.40.camel@localhost>
On Nov 14, 2007 11:16 AM, Kristis Makris <kristis.makris@asu.edu> wrote:
> > Unannotated tags don't make a proper new object, only a ref. If you
> > stick to annotated tags, you'll get new objects added which, I think,
> > should trigger the post-commit hook.
>
> I just tried again tagging with both:
>
> $ git tag TAG_NAME
>
> $ git tag -a TAG_NAME
>
> and I don't get the post-commit hook executed.
>
> Perhaps I missed something ?
Okay, I don't know about that. Someone else might want to weigh in on this.
> > If you have the new commit's SHA-1, it's very simple to get the parent
> > commit's SHA-1 and do whatever you want. A complexity would be with
> > handling merges, where a commit has multiple parents. If you have a
> > commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>"
> > to get a list of the files changed by <hash>.
>
> This sounds great. If the post-commit hook could now provide the new
> commit SHA-1 hash than that should be what I need.
>
> Can the new commit SHA-1 hash be added as a parameter to the post-commit
> hook please ?
Sure -- I've got a patch for it that I'll send shortly. It's using the
existing shell git-commit, so might be suitable for maint; I haven't
followed what's happened with the builtinification of git-commit.
Dave.
^ permalink raw reply
* [PATCH] git-commit: Pass commit SHA-1 hash to post-commit hook.
From: David Symonds @ 2007-11-14 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kristis Makris, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
Documentation/hooks.txt | 4 ++--
git-commit.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index f110162..d5b18f1 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -81,8 +81,8 @@ The default 'commit-msg' hook, when enabled, detects duplicate
post-commit
-----------
-This hook is invoked by `git-commit`. It takes no
-parameter, and is invoked after a commit is made.
+This hook is invoked by `git-commit`. It is passed one
+parameter (the new commit's SHA-1 hash), and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-commit`.
diff --git a/git-commit.sh b/git-commit.sh
index 4853397..fff58cb 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -616,7 +616,7 @@ then
git gc --auto
if test -x "$GIT_DIR"/hooks/post-commit
then
- "$GIT_DIR"/hooks/post-commit
+ "$GIT_DIR"/hooks/post-commit $commit
fi
if test -z "$quiet"
then
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent
From: Junio C Hamano @ 2007-11-14 0:46 UTC (permalink / raw)
To: Josh Triplett; +Cc: git, Brian Downing, dsymonds
In-Reply-To: <473A3552.3060907@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> My standard test case for this:
>
> fprintf("some very long string",
> arguments);
>
> Type the first line, and press enter. A good editor should indent to
> the open parenthesis. However, it should not use a tab, because it
> needs to match up with the length of "fprintf(".
Sorry, I do not want to go into ideology or be anal, but I have
to disagree. Tab width is 8 spaces (in the kernel and git), so
"fprintf(" from the beginning of the line and an HT at the
beginning of the line have the same width.
Your project may have different conventions. Then you do not
have to use that option to check for 8 or more leading spaces.
And honestly, I think responding to that by saying "but somebody
can have tab width that is not 8" is irrelevant. Somebody else
can even use a non-proportional font to print it, so your 8
spaces and "fprintf(" won't line up ANYWAY.
If you REALLY want to be anal, then the rules to follow would
be:
- Do not assume you know the width of a HT, other than that the
same number of HT at the beginning of two lines indent to the
same distance from the left margin, and more of them indent
deeper;
- Do not assume the text will be printed in monospace;
which leads to:
- Indent with the same number of HT from the beginning of
lines. Go deeper with one more HT, go shallower with one
less HT.
- Start the continuation line with the same number of HT to
indent but DO NOT BOTHER aligning. There is no alignment,
period.
I happen to choose to be less anal, and accept 8 space HT _and_
monospace font. So "complaining at >=8 SP at the beginning"
makes perfect sense, so does a corresponding patch to convert
such runs of SPs to HTs with "git-apply --whitespace=fix" (which
should require an option to be enabled, and the is not here
yet) when applying a patch.
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Andreas Ericsson @ 2007-11-14 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Jakub Narebski, Sergei Organov, git
In-Reply-To: <7vr6itr96h.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> I've got half a patch ready to change all occurrences of anything but
>> "remote-tracking branch" to that self-same description. This is what
>> I've got in Documentation/glossary.txt so far:
>>
>> [[def_remote_tracking_branch]]remote-tracking branch:
>> A "remote-tracking branch" is a branch set up to track the
>> state of a branch in a remote repository which the user has named.
>> These branches follow exactly the same rules as the branches which
>> reside in the remote repository, except that they are manipulated
>> by `git fetch` instead of `git push`. That is, they can only be
>> updated if the update would result in a <<def_fastforward,fast
>> forward>>, or if the user supplies the '--force' option. They cannot
>> be checked out or committed to by users, but serve
>> solely as local reference-pointers to their corresponding branches
>> in the remote repository.
>> The most common example of a remote-tracking branch is origin/master.
>
> Please try to read it as if it were an entry in a glossary.
> The sentence "... follow exactly the same rules as ..." was
> "Huh?" to me. "rules? what rules? the set of valid characters
> in their names?"
>
> When branch 'foo' from remote is tracked with the standard layout
> (post 1.3.0) it is copied to refs/remotes/origin/foo and people
> often fork their local branch refs/heads/foo to build on top.
> The use of the word "corresonding" feels a bit confusing,
> because you can arguably say refs/heads/foo at remote
> corresopnds to refs/heads/foo in your repository.
>
> I'd drop "These branches follow ... the '--force' option. "
> from the above. The rules on how they are updated are
> irrelevant, before the reader understands what they are for.
> How about this?
>
> A "remote tracking branch" remembers which commit a branch
> in the remote repository was pointing at last time you
> checked. It cannot be checked out or committed because its
> purpose is to serve as a local reference point after you
> built your own changes on top of it in your local branch
> forked from it. The most common example of a remote
> tracking branch is "origin/master", which tracks the
> "master" branch of the "origin" remote.
>
I'd skip "after you built your own changes ..." and let it go at
that. Will amend. Thanks.
> BTW, when you have this data-flow (probably typical in a shared
> repository workflow):
>
> Remote repository Your repository
>
> refs/heads/foo -------(A)------> refs/remotes/origin/foo
> ^ |
> | (B)
> | |
> | V
> `-------------(C)---------- refs/heads/foo
>
> (A) "git fetch" with remote.origin.fetch configuration
> set to +refs/heads/*:refs/remotes/origin/* keeps
> your refs/remotes/origin/foo up-to-date with their
> refs/heads/foo
>
> (B) "git merge origin/foo" while on "foo" branch (there
> are few shorthands like "git pull origin foo" while
> on "foo" branch. If you say "git branch --track
> foo origin/foo", then running "git pull" without
> parameter while on "foo" branch).
>
> (C) "git push origin foo".
>
> * Everybody seems to agree that "refs/remotes/origin/foo" is
> called a "remote tracking branch";
>
I'd like to insert the significant dash there. remote-tracking vs
remote tracking. It solves the one ambiguity with it, and would
finally make it clear and consistent almost however it's used.
> * Your refs/heads/foo follows and builds on top of 'foo' branch
> at the remote. Some people errorneously call it "tracking"
> but that is because we do not have a good term for it;
>
"private tracking branch"? Nah...
> * There is no good name for "refs/heads/foo at the remote". We
> always say "the remote branch you follow" (or "track").
>
"remote-repo branch" perhaps? The universe doesn't exactly toll its
bells in approval at that, but at least it's not ambiguous.
I've seen it written as "remote tracking branch" on irc a few times.
It causes 10 minutes of confusion where no-one's sure what anyone
else means. With the dash in there, there's no room for ambiguity.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.
From: Junio C Hamano @ 2007-11-14 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711132154370.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But the more fundamental question is: should we eventually have a mode in
> cherry-pick (or for that matter, apply!) which can change the submodule?
> And if so, how to go about it?
I think that would be handled in exactly the same way as
switching between two branches that bind different commits at
the submodule path.
Your work tree and index knows commit X is at the path, an
operation wants to have commit Y at the path as its result.
What's next?
It does not make much difference what that "an operation" is.
It can be apply, cherry-pick, revert, merge, or branch
switching. I think they can and should follow the same rules.
The most important rule is not to lose local changes, be they in
the index or in the work tree. So "an operation" would error
out if the index does not match HEAD at such a path, and the
work tree does not match the index.
The implementation of "work tree does not match the index" is
different when you are talking about a regular blob vs a
submodule. For a blob you know what we do. For a submodule, I
would imagine that we would check if both the index matches the
HEAD and the work tree matches the index in the submodule
(this would go recursively).
And after making sure we won't lose local changes, we switch the
submodule directory from commit X to commit Y. Most likely
detaching the HEAD with "cd sub && git checkout Y^0" or
something like that.
Then probably there will be an option added to loosen that "work
tree matches the index" check and uses "-m" option to the
checkout in the submodule directory.
More tricky is what to do with a submodule that would disappear,
though. For that, we would want .git/subprojects/foo.git/ trick
we have discussed in the past or something similar.
^ permalink raw reply
* Re: Git and Scmbug integration
From: Junio C Hamano @ 2007-11-14 1:09 UTC (permalink / raw)
To: Kristis Makris; +Cc: David Symonds, jnareb, git, scmbug-users
In-Reply-To: <1194999404.4106.40.camel@localhost>
Kristis Makris <kristis.makris@asu.edu> writes:
> I just tried again tagging with both:
>
> $ git tag TAG_NAME
>
> $ git tag -a TAG_NAME
>
> and I don't get the post-commit hook executed.
>
> Perhaps I missed something ?
You didn't. You did not create any commit. No post-commit hook
runs. There is no post-tag hook.
> Can the new commit SHA-1 hash be added as a parameter to the post-commit
> hook please ?
Looking at "git-rev-parse HEAD" in your hook should be enough.
^ permalink raw reply
* Re: Git and Scmbug integration
From: Junio C Hamano @ 2007-11-14 1:11 UTC (permalink / raw)
To: David Symonds; +Cc: Kristis Makris, jnareb, git, scmbug-users
In-Reply-To: <ee77f5c20711131627q329d45aepe48102728cf2778c@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> Sure -- I've got a patch for it that I'll send shortly. It's using the
> existing shell git-commit, so might be suitable for maint; I haven't
> followed what's happened with the builtinification of git-commit.
No, 'maint' won't get a feature enhancements.
Again, why isn't reading HEAD enough?
^ permalink raw reply
* [PATCH] git-svn's dcommit must use subversion's config
From: Konstantin V. Arkhipov @ 2007-11-14 0:52 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When doing dcommit git-svn must use subversion's config or newly created
files will not include svn's properties
(defined in [auto-props] with 'enable-auto-props = yes').
Signed-off-by: Konstantin V. Arkhipov <voxus@onphp.org>
---
--- git-svn 2007-11-02 18:41:32.000000000 +0300
+++ git-svn 2007-11-12 19:35:44.000000000 +0300
@@ -406,6 +406,9 @@ sub cmd_dcommit {
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($gs->full_url),
+ config => SVN::Core::config_get_config(
+ $Git::SVN::Ra::config_dir
+ ),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-14 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristis Makris, jnareb, git, scmbug-users
In-Reply-To: <7vprydpr5o.fsf@gitster.siamese.dyndns.org>
On Nov 14, 2007 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "David Symonds" <dsymonds@gmail.com> writes:
>
> > Sure -- I've got a patch for it that I'll send shortly. It's using the
> > existing shell git-commit, so might be suitable for maint; I haven't
> > followed what's happened with the builtinification of git-commit.
>
> No, 'maint' won't get a feature enhancements.
Fair enough.
> Again, why isn't reading HEAD enough?
Reading HEAD would be fine. I guess it just seems a sensible and more
direct path to passing that information so that the hook has less to
do. It seems quite a simple thing that would be very helpful to hook
writers, with zero impact on everyone else.
Dave.
^ permalink raw reply
* Re: Git and Scmbug integration
From: Junio C Hamano @ 2007-11-14 1:27 UTC (permalink / raw)
To: David Symonds; +Cc: Kristis Makris, jnareb, git, scmbug-users
In-Reply-To: <ee77f5c20711131716l6dd1dccjcb3ff5f3a54c9359@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> Reading HEAD would be fine. I guess it just seems a sensible and more
> direct path to passing that information so that the hook has less to
> do. It seems quite a simple thing that would be very helpful to hook
> writers, with zero impact on everyone else.
You cannot just say "The hook did not get any parameter, nobody
would have cared, this does not regress."
Some anal people could have checked and checked "test $# = 0" at
the beginning to make sure their hooks do not get broken by
random interface changes on the git side. Now their carefully
written script errors out as designed. Also some people seem to
use different version of git on the same repository (e.g. NFS
mounted across hosts that run different versions of git).
I would 80% agree with you if the post-comit hook interface were
written in the way your patch does from day one. Unfortunately
that is not the case.
The remaining 20%? If we _were_ to change the hook interface, I
would also pass which branch the commit is added to, in addition
to what commit it is.
Both are easily obtainable by reading HEAD (you need to read
HEAD twice, though) but would be handy.
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Nicolas Pitre @ 2007-11-14 1:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bill Lear, git
In-Reply-To: <20071114000218.GL3268@steel.home>
On Wed, 14 Nov 2007, Alex Riesen wrote:
> Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100:
> > On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
> > >...
> > >> >I extend the part you quoted. The file is opened here:
> > >> >...
> > >> >This is strange. The current git should not produce anything like
> > >> >this (and does not, here). ...
> > >>
> > >> You are absolutely correct. My comrade ran this with 1.5.0.1 by
> > >> mistake. He reran the strace with 1.5.3.5, and I have replaced
> > >> the tarball on my server:
> > >>
> > >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
> > >
> > >Still looks like v1.5.0.1:
> > >
> > > write(2, "fatal: ", 7) = 7
> > > write(2, "cannot pread pack file: No such "..., 49) = 49
> >
> > Well, I just grepped for the above string in git-1.5.3.5:
> >
> > % grep 'cannot pread pack file' *.c
> > index-pack.c: die("cannot pread pack file: %s", strerror(errno));
>
> oh, you should be looking for usage.c, the function report (it is
> called by default die handler). The old code used to fputs("fatal:"),
> the new just vfprintf's everything, so the write should look like:
>
> write(2, "fatal: cannot pread pack file: No such "...
This is not included in 1.5.3.5 though.
Nicolas
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Junio C Hamano @ 2007-11-14 1:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Bill Lear, git
In-Reply-To: <alpine.LFD.0.9999.0711132027430.21255@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 14 Nov 2007, Alex Riesen wrote:
> ...
>> oh, you should be looking for usage.c, the function report (it is
>> called by default die handler). The old code used to fputs("fatal:"),
>> the new just vfprintf's everything, so the write should look like:
>>
>> write(2, "fatal: cannot pread pack file: No such "...
>
> This is not included in 1.5.3.5 though.
True; although I did not think it was risky at all, I did not
think that was serious enough change.
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS
From: Nicolas Pitre @ 2007-11-14 1:38 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18228.32091.865519.312011@lisa.zopyra.com>
On Fri, 9 Nov 2007, Bill Lear wrote:
> I've brought this up before, but I don't recall a resolution to it.
>
> We have an NFS-mounted filesystem, and git pull is choking on it.
>
> % uname -a
> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
I recall there was issues with NFS on some old linux version posted on
the list a while ago. Again the archive must have it but I'm too lazy
to check. Because the issue wasn't reproducible on later kernels, the
conclusion was that the kernel was to blame.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 3/3] send-pack: assign remote errors to each ref
From: Junio C Hamano @ 2007-11-14 1:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Pierre Habouzit, Daniel Barkalow, Alex Riesen
In-Reply-To: <20071113113710.GC15880@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This lets us show remote errors (e.g., a denied hook) along
> with the usual push output. ...
Yay!
> ... There are two drawbacks to this
> change:
>
> 1. cross-referencing the incoming status with the ref list
> is worst case O(n^2) (where n = number of refs); this
> can be fixed with a smarter implementation
Sure.
> 2. the status parsing is not foolproof. We get a line like
>
> ng refs/heads/master arbitrary msg
>
> which cannot be parsed unambiguously in the face of
> refnames with spaces. We do a prefix-match so that
> you will only run into problems if you have two refs,
> one of which is a prefix match of the other, and the
> longer having a space right after the prefix.
Is it really "arbitrary msg", or just a fixed set of strings?
Also I think we can rely on the order report-status extension
reports the per-ref result. It gives back the information the
same order send-pack side supplies the head information, no?
^ 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