* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710031711070.28395@racer.site>
Dscho,
On Wednesday 03 October 2007 18:11, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current
> > HEAD of module
>
> AFAIR we do not allow committing via pserver protocol. Might that be your
> problem?
Thanks, but no. I'm using CVS over SSH. I've been looking around in
git-cvsserver source a bit and it aborts quite quickly if you try a
commit through pserver. I get a bit further, but it cannot find the HEAD
revision for some reason and (from later message), if I try to checkout
master instead of HEAD it finds the revision but I get a hash mismatch.
I've tried a bit debugging this, but in 15 years CVS experience I never
really needed to debug the protocol and my GIT experience is only 2
weeks old :-(
My hope is I'm doing something fundamentally wrong and git-cvsserver
just doesn't give a sensible error. I did setup the git repository using
two different routes, one adviced in the CVS conversion manual. GIT
operations work just fine, so does CVS checkout. I don't think you can
to that much wrong with cvs over ssh clients, especially if checkout
works just fine.
Does anyone out there has a working GIT <-> CVS+SHH setup? Based on
what version of GIT? Using what route to create the repository?
Thanks --- Jan
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-10-03 17:53 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Git Mailing List
In-Reply-To: <20071003165927.GA25055@coredump.intra.peff.net>
On Wed, 3 Oct 2007, Jeff King wrote:
>
> Try profiling the code, and you will see that the creation of the hashes
> is totally dwarfed by the comparisons. So yes, you might be able to
> speed up the creation code, but it's going to have a minimal impact on
> the overall run time.
Yeah. Oprofile is your friend.
The biggest win would be to avoid calling diffcore_count_changes() in the
first place, and we actually do that in the caller by looking at the size
of the files. However, while that prunes out the *really* obvious cases,
it's not nearly enough, since there tends to be very limited filesizes
anyway.
What we could also do is to pass in the minimum similarity score, and use
that to at least exit early. We currently pass in "delta_limit" which is
close, but we never use it, and we really probably would be better off
passing in the minimum score itself and perhaps be able to exit early from
diffcore_count_changes.
However, while I did think about doing that, I came to the conclusion that
we'd still always end up having to look at least at *half* the hash data
(for the default 50% score), so while it would help, it again wouldn't be
a matter of orders-of-magnitudes, and it looked like the end result would
be unnecessarily complex too.
The best option, of course, would be to use a similarity hash to make the
initial choice. I think we had one at one point, but it wasn't
fine-grained enough. But it might be interesting to do that as a filter in
*front* of the more expensive diffcore_count_changes() call.
We had some "similarity fingerprint" code at some point using a Rabin
polynomial. It wasn't reliable enough to be used as a direct score, but
maybe it can be used as a first-line "we know this isn't even worth doing
the expensive stuff on".
Linus
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Sam Ravnborg @ 2007-10-03 17:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, David Kastrup, Johannes Schindelin, git,
msysgit
In-Reply-To: <7vd4vwfou9.fsf@gitster.siamese.dyndns.org>
Hi Junio.
>
> In short, although I do appreciate Johannes's and Sam's attempt,
> I would really prefer to see us pick some externally maintained
> alternative, instead of inventing a homebrew system that we need
> to maintain ourselves. It is rumored that git has much higher
> developer count vs loc count ratio than many other open source
> projects, doing the documentation format is not part of our
> project, and I'd rather see them spend time working on git, not
> building and maintaining AsciiDoc lookalike.
For the kernel I would like to see a tool that does:
o Based on nicely formatted ascii/utf-8 be able to:
- Generate good looking and easy to read HTML
- Possible generate other output formats too
And if the kernel folks do not like it then at least the possibility
to run this on kbuild documentation locally so I can generate nice
html docs for that part.
For a kernel integrated tool the dependencies shall be minimal which
is where asciidoc fails today. If asciidoc people could address this
issue for the simpler output format then the tool IMO would
have a much stronger position.
Sam
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 17:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Pierre Habouzit, Wincent Colaiuta, Miles Bader, Junio C Hamano,
git
In-Reply-To: <Pine.LNX.4.64.0710031742400.28395@racer.site>
On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:
> I wonder how hard it would be to teach _everybody_ to specify
> _exactly_ what they want.
>
> Of course, we'd need an "--existing" option to git-push to trigger
> the behaviour that we have right now.
I could _definitely_ live with that. If the branch config doesn't say
what to do when no arguments are given, then demand a specification on
the command line.
I'll shut up on this topic now, though, since I'm not exactly helping
with the patch/opinion ratio.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git filetypes for vim
From: martin f krafft @ 2007-10-03 17:03 UTC (permalink / raw)
To: git discussion list; +Cc: git
In-Reply-To: <20071003160745.GA8173@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2007.10.03.1707 +0100]:
> My repo is here: http://git.madduck.net/v/misc/vim-git.git
> Tim's is here: git://git.tpope.net/~tpope/vim-git.git
We had to rewrite the repos history because some information slipped
in that we didn't want archived forever. I am sorry about this.
Please reclone.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-03 16:59 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <85641oy5ge.fsf@lola.goethe.zz>
On Wed, Oct 03, 2007 at 10:20:49AM +0200, David Kastrup wrote:
> Part of the reason is that it is not actually what I had in mind. Why
> create the hash array as a hash array? Filling the hash array in
> basically random order, then sort+compressing it is what is causing
> much of the costs. My idea was to just fill the "hash array"
> linearly. It is quite pointless (and certainly very inefficient with
> regard to cache poisoning) to do it in hash order when we are going to
> sort it anyway.
Try profiling the code, and you will see that the creation of the hashes
is totally dwarfed by the comparisons. So yes, you might be able to
speed up the creation code, but it's going to have a minimal impact on
the overall run time.
-Peff
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Johannes Schindelin @ 2007-10-03 16:44 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Karl Hasselström, Wincent Colaiuta, Miles Bader,
Junio C Hamano, git
In-Reply-To: <20071003162816.GA17403@artemis.corp>
Hi,
On Wed, 3 Oct 2007, Pierre Habouzit wrote:
> On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:
> > This thread is getting painful. Lot's of "I want"s, but nobody to date
> > came up with a solution that makes both oldtimers and newtimers happy.
>
> I think I made a proposal that tries to reach some kind of consensus:
>
> `git push`::
> no arguments given just pushes the current branch you're on, into
> origin, if a refspec matches.
I use that sometimes, and I do not want only the current branch to be
pushed.
> `git push <remote>`::
> works like now (aka pushes all branches that match a remote branch
> in the given remote).
That would make things inconsistent, and inconsistent things are always
hard to explain.
> This way, you can have current "git push" using "git push origin", but
> you also have a convenient way to push only the current branch into your
> default remote repository without needing to spell out:
>
> $ git push origin `git symbolic-ref HEAD`
I wonder how hard it would be to teach _everybody_ to specify _exactly_
what they want.
Of course, we'd need an "--existing" option to git-push to trigger the
behaviour that we have right now.
Ciao,
Dscho
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Pierre Habouzit @ 2007-10-03 16:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Karl Hasselström, Wincent Colaiuta, Miles Bader,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710031718110.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Wed, Oct 03, 2007 at 04:18:56PM +0000, Johannes Schindelin wrote:
> This thread is getting painful. Lot's of "I want"s, but nobody to date
> came up with a solution that makes both oldtimers and newtimers happy.
I think I made a proposal that tries to reach some kind of consensus:
`git push`::
no arguments given just pushes the current branch you're on, into
origin, if a refspec matches.
`git push <remote>`::
works like now (aka pushes all branches that match a remote branch
in the given remote).
This way, you can have current "git push" using "git push origin", but
you also have a convenient way to push only the current branch into your
default remote repository without needing to spell out:
$ git push origin `git symbolic-ref HEAD`
--
·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 push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Karl Hasselström, Miles Bader, Pierre Habouzit,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710031550490.28395@racer.site>
El 3/10/2007, a las 17:27, Johannes Schindelin escribió:
> On Wed, 3 Oct 2007, Karl Hasselström wrote:
>
>> 2. "push all branches" is the default, but the user intended to
>> push
>> only the current branch. She ends up pushing a superset of what
>> she wanted, which is not easily fixed if she can't be sure that
>> no one else has pulled from the public repo before she notices
>> what's happened.
>
> But that is not the default. Not at all.
>
> The default is to push the refs which the remote and the local side
> have
> _in common_.
Yes, that's already been covered in this thread, probably in the
first or second post, and (at least I hope) we've all read it and
take it as given.
Replace "push all branches" with "push all refs that both sides have
in common", which is presumably what Karl meant, and the concerns are
still there.
> Maybe we should initialise the "remote.origin.push" variable to
> "completely-bogus-branchname" when you "git init --im-a-newbie"?
How is this comment supposed to help in any way? Please try to think
about the image you're putting across; as an relatively active and
prominent contributer in the Git community you are part of the "face"
of the community.
Cheers,
Wincent
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Johannes Schindelin @ 2007-10-03 16:18 UTC (permalink / raw)
To: Karl Hasselström
Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, Junio C Hamano,
git
In-Reply-To: <20071003160731.GA7113@diana.vm.bytemark.co.uk>
Hi,
On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
> On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:
>
> > On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
> >
> > > 2. "push all branches" is the default, but the user intended to
> > > push only the current branch. She ends up pushing a superset
> > > of what she wanted, which is not easily fixed if she can't be
> > > sure that no one else has pulled from the public repo before
> > > she notices what's happened.
> >
> > But that is not the default. Not at all.
> >
> > The default is to push the refs which the remote and the local side
> > have _in common_.
>
> I know, and that's what I meant by "all branches". Sorry for the
> sloppy language.
>
> > Maybe we should initialise the "remote.origin.push" variable to
> > "completely-bogus-branchname" when you "git init --im-a-newbie"?
>
> I'd rather have a suboptimal default than different defaults depending
> on user settings. (See also Junio's comment on that elsewhere in this
> thread.)
This thread is getting painful. Lot's of "I want"s, but nobody to date
came up with a solution that makes both oldtimers and newtimers happy.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-10-03 16:13 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Git Mailing List
In-Reply-To: <20071003065414.GA13737@coredump.intra.peff.net>
On Wed, 3 Oct 2007, Jeff King wrote:
>
> I get slightly better speedups with my pathological case (around 30%):
Ok, 30% is definitely "worth doing". Even if your performance still sucks,
and 71 seconds is just way out of line for anything like this (of course,
these days you need that "-l0" to ever trigger that case, but it would be
nice if we could speed things up so much that we no longer care).
Linus
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Johannes Schindelin @ 2007-10-03 16:11 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200710031348.50800.wielemak@science.uva.nl>
Hi,
On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current
> HEAD of module
AFAIR we do not allow committing via pserver protocol. Might that be your
problem?
Ciao,
Dscho
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 16:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, Junio C Hamano,
git
In-Reply-To: <Pine.LNX.4.64.0710031550490.28395@racer.site>
On 2007-10-03 16:27:49 +0100, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
>
> > 2. "push all branches" is the default, but the user intended to
> > push only the current branch. She ends up pushing a superset
> > of what she wanted, which is not easily fixed if she can't be
> > sure that no one else has pulled from the public repo before
> > she notices what's happened.
>
> But that is not the default. Not at all.
>
> The default is to push the refs which the remote and the local side
> have _in common_.
I know, and that's what I meant by "all branches". Sorry for the
sloppy language.
> Maybe we should initialise the "remote.origin.push" variable to
> "completely-bogus-branchname" when you "git init --im-a-newbie"?
I'd rather have a suboptimal default than different defaults depending
on user settings. (See also Junio's comment on that elsewhere in this
thread.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v2] INSTALL: Update section on external dependencies
From: Shawn O. Pearce @ 2007-10-03 16:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Miklos Vajna, Junio C Hamano, Reece Dunn
In-Reply-To: <Pine.LNX.4.64.0710031655590.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 3 Oct 2007, Johan Herland wrote:
>
> > Includes:
> > - Mention dependency on "core" utilities, including coreutils, sed, cut, grep
>
> Maybe mention libc, too? Oh, and that you need a computer? ;-)
Don't forget that the computer must be plugged in and have
electricity as well. I see users all too often wonder why everything
they type is black, on a black background...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: Carl Worth @ 2007-10-03 16:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710031634300.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
On Wed, 3 Oct 2007 16:36:13 +0100 (BST), Johannes Schindelin wrote:
> Or as
>
> i=1
> while test $i -le 50
> do
...
> i=$(($i+1))
> done
/me steps aside to let the shell-script wizards finish the job
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] INSTALL: Update section on external dependencies
From: Johannes Schindelin @ 2007-10-03 15:56 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Miklos Vajna, Junio C Hamano, Reece Dunn
In-Reply-To: <200710031027.48999.johan@herland.net>
Hi,
On Wed, 3 Oct 2007, Johan Herland wrote:
> Includes:
> - Mention dependency on "core" utilities, including coreutils, sed, cut, grep
Maybe mention libc, too? Oh, and that you need a computer? ;-)
> - Fix up some whitespace and linebreaking issues
The commit message could use some of that, too... ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-03 15:54 UTC (permalink / raw)
To: Tom Clarke; +Cc: Junio C Hamano, Shawn O. Pearce, Carl Worth, git
In-Reply-To: <550f9510710030711p195378c5t2739292d31a12de@mail.gmail.com>
Hi,
On Wed, 3 Oct 2007, Tom Clarke wrote:
> On 10/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> > I do not offhand think of a place other than "git pull" that
> > would make sense to sometimes be able to rebase when you
> > normally use merge, so I am inclined to say it would be easier
> > to teach that "'git pull' is usually a 'git fetch' followed by
> > 'git merge', but in certain workflow it is handier to 'git
> > fetch' and then 'git rebase', and here are the ways to get the
> > rebasing behaviour...".
>
> I agree. I'll revisit teaching pull to be able to use rebase.
In that case, may I request a config variable to set this behaviour
automatically when calling "git pull <nick>"?
Had we stayed with the merge strategy approach, that would have come for
free with the --no-ff patch series.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add test case for ls-files --with-head
From: Carl Worth @ 2007-10-03 15:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <47038669.30302@viscovery.net>
This tests basic functionality and also exercises a bug noticed
by Keith Packard, (prune_cache followed by add_index_entry can
trigger an attempt to realloc a pointer into the middle of an
allocated buffer).
Signed-off-by: Carl Worth <cworth@cworth.org>
---
t/t3060-ls-files-with-head.sh | 55 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-ls-files-with-head.sh
On Wed, 03 Oct 2007 14:09:13 +0200, Johannes Sixt wrote:
> seq is not universally available. Can we have that as
Simple enough. I've included the amended patch, (and I even
remembered to do the sign-off thing this time).
Thanks,
-Carl
diff --git a/t/t3060-ls-files-with-head.sh b/t/t3060-ls-files-with-head.sh
new file mode 100755
index 0000000..bc3ef58
--- /dev/null
+++ b/t/t3060-ls-files-with-head.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Carl D. Worth
+#
+
+test_description='gt ls-files test (--with-head).
+
+This test runs git ls-files --with-head and in particular in
+a scenario known to trigger a crash with some versions of git.
+'
+. ./test-lib.sh
+
+# The bug we're exercising requires a fair number of entries in a
+# sub-directory so that add_index_entry will trigger a realloc
+echo file > expected
+mkdir sub
+for i in 0 1 2 3 4; do
+ for j in 0 1 2 3 4 5 6 7 8 9; do
+ > sub/file-$i$j
+ echo file-$i$j >> expected
+ done
+done
+git add .
+git commit -m "add a bunch of files"
+
+# We remove them all so that we'll have something to add back with
+# --with-head and so that we'll definitely be under the realloc size
+# to trigger the bug.
+rm -r sub
+git commit -a -m "remove them all"
+
+# The bug also requires some entry before our directory so that
+# prune_path will modify the_index.cache
+mkdir a_directory_that_sorts_before_sub
+touch a_directory_that_sorts_before_sub/file
+mkdir sub
+touch sub/file
+git add .
+
+# We have to run from a sub-directory to trigger prune_path
+cd sub
+
+# Then we finally get to run our --with-tree test
+test_expect_success \
+ 'git -ls-files --with-tree should succeed.' \
+ 'git ls-files --with-tree=HEAD~1 >../output'
+
+cd ..
+test_expect_success \
+ 'git -ls-files --with-tree should add entries from named tree.' \
+ 'diff output expected'
+
+test_done
+
+
--
1.5.3.3.131.g34c6d
^ permalink raw reply related
* Re: [PATCH] Add test case for ls-files --with-head
From: Johannes Schindelin @ 2007-10-03 15:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Carl Worth, Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <47038669.30302@viscovery.net>
Hi,
On Wed, 3 Oct 2007, Johannes Sixt wrote:
> Carl Worth schrieb:
> > +for num in $(seq -f%04g 1 50); do
> > + touch sub/file-$num
> > + echo file-$num >> expected
> > +done
>
> seq is not universally available. Can we have that as
>
> for i in 0 1 2 3 4; do
> for j in 0 1 2 3 4 5 6 7 8 9; do
> > sub/file-$i$j
> echo file-$i$j >> expected
> done
> done
Or as
i=1
while test $i -le 50
do
num=$(printf %04d $i)
> sub/file-$num
echo file-$num >> expected
i=$(($i+1))
done
This version should be as portable, with the benefit that it is easier to
change for different start and end values.
Ciao,
Dscho
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Johannes Schindelin @ 2007-10-03 15:27 UTC (permalink / raw)
To: Karl Hasselström
Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, Junio C Hamano,
git
In-Reply-To: <20071003104943.GA3017@diana.vm.bytemark.co.uk>
Hi,
On Wed, 3 Oct 2007, Karl Hasselstr?m wrote:
> 2. "push all branches" is the default, but the user intended to push
> only the current branch. She ends up pushing a superset of what
> she wanted, which is not easily fixed if she can't be sure that
> no one else has pulled from the public repo before she notices
> what's happened.
But that is not the default. Not at all.
The default is to push the refs which the remote and the local side have
_in common_.
Maybe we should initialise the "remote.origin.push" variable to
"completely-bogus-branchname" when you "git init --im-a-newbie"?
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 14:57 UTC (permalink / raw)
To: git
In-Reply-To: <200710031513.44446.wielemak@science.uva.nl>
On Wednesday 03 October 2007 15:13, Jan Wielemaker wrote:
> $ mkdir /pub/my-repo.git
> $ cd /pub/my-repo.git
> $ git --bare init --shared
> $ git --bare fetch /home/alice/myproject master:master
>
> Checked out freshly using CVS. No problem. But committing a change,
> nothing changed :-( The log output is exactly the same, showing only
> refs/heads/master. I'm starting to suspect git-cvsserver afterall, but
> the docs suggests it is operational for quite a while. Could someone
> give me a clue on what am I missed?
More tests ... As it didn't like the HEAD, and insisted it only knows
about master, I though what happens on
cvs -d :ext:user@host:/git-repos.git co master
<works fine>
<edit>
cvs commit
Commit failed (unknown reason)
:-( Logfile says:
================================================================
2007-10-03 16:43:37 : INFO - req_ci : [NULL]
2007-10-03 16:43:37 : INFO - Lockless commit start, basing commit
on '/tmp/VP2P
VNHPs0/6t4xncbMoN', index file is '/tmp/VP2PVNHPs0/SO4A6pzpau'
2007-10-03 16:43:37 : INFO - Start git show-ref -s refs/heads/master
2007-10-03 16:43:37 : INFO - Heads: 0b7b372d525a4fe7f662996fec9cd11b1038a6be
re
fs/heads/master
2007-10-03 16:43:37 : INFO - parenthash =
0b7b372d525a4fe7f662996fec9cd11b1038a
6be
2007-10-03 16:43:37 : INFO - Created index '/tmp/VP2PVNHPs0/SO4A6pzpau' with
fo
r head master - exit status 0
2007-10-03 16:43:37 : INFO - Committing collections-representation.txt
2007-10-03 16:43:37 : DEBUG - rename /tmp/VP2PVNHPs0/0SfbkMq6AN
collections-repr
esentation.txt
2007-10-03 16:43:37 : DEBUG - chmod u+rw-x collections-representation.txt
2007-10-03 16:43:37 : INFO - Updating file 'collections-representation.txt'
2007-10-03 16:43:37 : DEBUG - Treehash :
aba0f583177b3b7fca05935452de22612164a7f
3, Parenthash : 0b7b372d525a4fe7f662996fec9cd11b1038a6be
2007-10-03 16:43:37 : INFO - Commit hash :
2007-10-03 16:43:37 : WARN - Commit failed (Invalid commit hash)
================================================================
!? What happens? Is git-cvsserver completely broken and should I thus
forget about GIT for now (saying we cannot deal with cvs commit is
politically unacceptable in this project)? Any clue?
Please help
--- Jan
^ permalink raw reply
* Problems using StGit and -rt kernel patchset
From: Clark Williams @ 2007-10-03 14:19 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I've been working on the -rt patch series for the kernel and would like to to use
StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
ask the git/stgit community if what I'm doing is wrong.
I clone Linus's tree to a common directory, then clone it locally to work:
$ git clone -s -l /home/src/linux-2.6.git scratch.git
$ cd scratch.git
$ stg init
$ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
$ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
<fix the things quilt lets through and stg barfs on, like malformed email addresses>
<watch 368 patches be applied and committed>
<work work work>
<get a new patch queue>
$ (cd /home/src/linux-2.6.git && git pull)
$ stg pull
$ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
$ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
Checking for changes in the working directory ... done
stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)
At this point I'm clueless as to:
1. What I've done wrong
2. How to recover/debug this
I really like using stgit to manage the patch queue with each patch as a commit, so
I'd prefer to figure out how to either use stgit properly, or fix whatevers going wrong.
Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHA6TuqA4JVb61b9cRAl12AJ0V3SNg9hO4cnFhefRS/mWdGF696ACeNspM
a+aLdBeFCHCPeyypUr6AwJQ=
=Z2eU
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-10-03 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Shawn O. Pearce, Carl Worth, git
In-Reply-To: <7vr6kdl5rj.fsf@gitster.siamese.dyndns.org>
On 10/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> I do not offhand think of a place other than "git pull" that
> would make sense to sometimes be able to rebase when you
> normally use merge, so I am inclined to say it would be easier
> to teach that "'git pull' is usually a 'git fetch' followed by
> 'git merge', but in certain workflow it is handier to 'git
> fetch' and then 'git rebase', and here are the ways to get the
> rebasing behaviour...".
I agree. I'll revisit teaching pull to be able to use rebase.
Thanks,
-Tom
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: David Kastrup @ 2007-10-03 14:01 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Schindelin, git,
msysgit
In-Reply-To: <20071003134741.GQ21675@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Wed, Oct 03, 2007 at 12:25:44PM +0200, David Kastrup wrote:
>
>> The problem is that we are not editing plain text, but Docbook
>> source masquerading as plain text.
>
> I do a fair amount of editing of the asciidoc source, but 99% of it
> is done by just blind imitation of what's already there.
But not everything is already there, and when something surprising
happens, there is little chance to see how it came about.
> Maybe my experience would be the same with Docbook--I have no idea,
> never having worked with it--but if you're suggesting that knowledge
> of Docbook is a prerequisite for working with asciidoc, that
> certainly hasn't been my experience.
"making use of" and "working with" are two different things.
>> But it is not all _all_ easily writeable the moment you try to do
>> something with _structural_ impact. In fact, it is pretty much
>> impossible for anybody except wizards to do that. And when the
>> wizards do it, they can't actually document what they have been
>> doing since that would mean cluttering the purported "plain text
>> documentation" with formatting comments.
>
> I'm not sure what you're talking about here. Example?
Try including the manual pages as a (properly linked when man pages
are referenced) appendix in the user manual, so that the printed form
(or PDF) of the user manual is a single coherent document with all
information inside. That's what I tried for about a week, digging
into the various available (and unavailable) documentation and then
postponing the project indefinitely because it both exceeded my
current capability as well as demonstrating that there was no
reasonably outlined path for acquiring the necessary skills.
In Texinfo, this takes few commands, all of which are well-documented
and in a reasonable place in the Texinfo manual (which is all you need
to consult in order to write Texinfo documents).
But with git's AsciiDoc information, not only is the required
information scattered through half a dozen of different manuals all
describing completely different systems, but the necessary other
documentation is, at best, only mentioned in passing in every single
relevant document. So while you may know where you want to start and
end your journey, there is nothing which would tell you how to get
from start to end. You have to randomly pick your road until you may
or may not find something closer to the end.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: J. Bruce Fields @ 2007-10-03 13:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710030506360.28395@racer.site>
On Wed, Oct 03, 2007 at 05:23:35AM +0100, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Sam Vilain wrote:
> > Johannes Schindelin wrote:
> >
> > > I do not want to depend on more than necessary in msysGit, and
> > > therefore I started to write an asciidoc replacement.
> >
> > It's pretty good, I certainly wouldn't have trouble reading or
> > maintaining it, but I'll give you suggestions anyway.
>
> Thank you very much! (On both accounts...)
>
> > nice work, replacing a massive XML/XSL/etc stack with a small Perl
> > script ;-)
>
> Uhm... It is less capable, though...
By the way, without having looked at your script to see it does, a
couple things I know of that the user manual relies on that other docs
may not as much are automatic table of contents generation, and cross
references.
I'd be similarly inclined to work on improving asciidoc rather than
inventing something new, but I guess it's at least interesting to see
how far your approach gets us.
--b.
^ 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