* 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
* Re: WIP: asciidoc replacement
From: J. Bruce Fields @ 2007-10-03 13:47 UTC (permalink / raw)
To: David Kastrup
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Schindelin, git,
msysgit
In-Reply-To: <85k5q4v6jb.fsf@lola.goethe.zz>
On Wed, Oct 03, 2007 at 12:25:44PM +0200, David Kastrup wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > El 3/10/2007, a las 10:12, David Kastrup escribió:
> >
> >> What with output in print, HTML, info?
> >
> > Yes, that's still a problem...
> >
> >> Personally, I think it might make sense to just step away from the
> >> AsciiDoc documentation to Docbook: plain text (without cutified
> >> formatting control like in AsciiDoc) can be generated _from_ Docbook.
> >
> > Yes, but editing DocBook (XML) is relatively painful compared to
> > editing plain text.
>
> 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. I've never
learned docbook (I've barely learned asciidoc, to be honest), and with a
few (now forgotten) exceptions haven't tried to understand how the
toolchain works.
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.
> 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?
--b.
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 13:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, git
In-Reply-To: <7v8x6kfobq.fsf@gitster.siamese.dyndns.org>
On 2007-10-03 04:08:09 -0700, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > So it all comes down to case (2) mistakes being much harder to fix
> > than case (1) mistakes. Therefore, we should change the default,
> > since doing so makes it safer.
>
> I am not convinced.
>
> I've seen many new people alias "rm" to "rm -i" for this (I'd say
> "false") reasoning to "default to safer", and end up training their
> fingers to say "y" without thinking.
I don't think that's a good analogy here, since no one is proposing
any kind of interactive prompt.
> Also mistakes can cut both ways. Pushing out what you did not intend
> to is what you seem to be worried about more. But not pushing out
> enough and not noticing is an equally bad mistake.
It may be an equally bad mistake, but it's _not_ equally hard to fix.
(And in my book, that means they aren't in fact equally bad.)
You're right that some users will train their fingers to always type
"git push --all" to the point where they will push everything by
mistake even in cases where that's not what they wanted. But the same
thing will happen with the current default for people who almost
always push just a single branch, and train their fingers for that.
And you just said the two mistakes were equally bad. :-)
> People also argue for "default per user". I am not really convinced
> on that point either.
>
> You, an expert, will get asked for help by somebody, walk up to his
> shell prompt, and try to help and teach him by showing you type, and
> then you suddenly notice the command does not work as you expect
> because he set the default differently (because he read that
> configuration option on some web parge). And we will be in such a
> cumbersome to diagnose situation _very_ often if we have per-user
> default on many things.
I'm generally opposed to per-user settings for that reason. Users who
insist can alias "pusha" to "push --all".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <200710031348.50800.wielemak@science.uva.nl>
On Wednesday 03 October 2007 13:48, Jan Wielemaker wrote:
> Hi,
>
> I'm pretty new to GIT. I quickly convinced our project to move to GIT,
> except for one guy that wants to do Windows and CVS :-( I setup a test
> and the checkout works just fine, but commit from cvs doesn't work. The
> details:
>
> * Server: git version 1.5.3.1 compiled on SuSE 10.2, 64-bits
> * Client, both SuSE CVS 1.12.12 and the current WinCVS cvs.exe,
> so it appears irrelevant.
>
> I created a test repository from a papers directory using the sequence
> beloe. (P.s. isn't there a more elegant way to get to a bare shared repo
> from a set of files? I tried (mkdir papers.git && cd papers.git && git
> --bare init --shared=all), but I can't clone an empty bare repository
> (doesn't create anything), so I can't add to it).
>
> % cd ~/tmp/papers
> % git-init
> % git-add .
> % git-commit
> % cd /home/git
> % git-clone --bare --no-hardlinks ~/tmp/papers/ papers.git
> % cd papers.git
> % git-config core.sharedrepository all
> % chmod g+ws `find . -type d`
> % chmod g+w `find . -type f`
>
> Anyway, appears to work fine with GIT to clone, pull and push. Using
> CVS over SSH, I can checkout this just fine, creating HEAD. Now I change
> a file and run "cvs commit" to get:
>
> gollem (2006) 11_> cvs commit -m "test"
> cvs [commit aborted]: end of file from server (consult above messages if
> any)
I start to get a clue. Adding a line
$log->info("Heads: " . `git show-ref --heads`);
I see this in the log:
2007-10-03 14:13:44 : INFO - Heads: 0b7b372d525a4fe7f662996fec9cd11b1038a6be
refs/heads/master
Thus, I though I created the repository the wrong way. Tried again,
following the recipy of
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html:
$ 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?
Thanks --- Jan
> I enabled logging and added a few statements to git-cvsserver (line 1203)
>
> $log->info("Start git show-ref -s refs/heads/$state->{module}");
> # Remember where the head was at the beginning.
> my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
> $log->info("parenthash = $parenthash");
> chomp $parenthash;
> if ($parenthash !~ /^[0-9a-f]{40}$/) {
> $log->warn("error 1 pserver cannot find the current HEAD of
> module");
> exit;
> }
>
> Then I get this log output:
>
> ================================================================
> 2007-10-03 12:25:16 : DEBUG - Temporary directory is '/tmp/XwYVFFqjyd'
> 2007-10-03 12:25:16 : DEBUG - req_Root : /home/git/papers.git
> 2007-10-03 12:25:16 : DEBUG - req_Validresponses : ok error Valid-requests
> Referrer Redirect Checked-in New-entry Checksum Co
> py-file Updated Created Update-existing Merged Patched Rcs-diff Mode
> Mod-time Removed Remove-entry Set-static-directory Clear
> -static-directory Set-sticky Clear-sticky Edit-file Template Clear-template
> Notified Module-expansion Wrapper-rcsOption M Mbi
> nary E F MT
> 2007-10-03 12:25:16 : DEBUG - req_validrequests
> 2007-10-03 12:25:16 : DEBUG - SEND : Valid-requests remove add status Entry
> watchers ci tag log co Modified Questionable admi
> n Root history valid-requests Global_option Argumentx annotate
> Valid-responses Unchanged Directory rlog Argument expand-modul
> es diff editors update
> 2007-10-03 12:25:16 : DEBUG - SEND : ok
> 2007-10-03 12:25:16 : DEBUG - req_Globaloption : -q
> 2007-10-03 12:25:16 : DEBUG - Argument : -m
> 2007-10-03 12:25:16 : DEBUG - Argument : test
> 2007-10-03 12:25:16 : DEBUG - Argument : --
> 2007-10-03 12:25:16 : INFO - Setting prepend to '2006/'
> 2007-10-03 12:25:16 : DEBUG - Prepending '2006/' to state|directory
> 2007-10-03 12:25:16 : DEBUG - req_Directory : localdir=.
> repository=/home/git/papers.git/HEAD/2006 path=2006/ directory=2006/
> module=HEAD
> 2007-10-03 12:25:16 : INFO - Received entry line '/README.txt/1.1///'
> => '2006/README.txt'
> 2007-10-03 12:25:16 : DEBUG - Argument : README.txt
> 2007-10-03 12:25:16 : INFO - req_ci : [NULL]
> 2007-10-03 12:25:16 : INFO - Lockless commit start, basing commit
> on '/tmp/XwYVFFqjyd/ud4uGbbUJg', index file is '/tmp/XwYVF
> Fqjyd/3FeXMladmb'
> 2007-10-03 12:25:16 : INFO - Start git show-ref -s refs/heads/HEAD
> 2007-10-03 12:25:16 : INFO - parenthash =
> 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current HEAD
> of module
> ================================================================
>
> I don't like the req_ci : [NULL] very much, and the last 3 lines clearly
> shows a problem. I checked
> the latest git repository of git. There is no change to git-cvsserver.perl.
>
> I'm still a bit too newbie to (and not much of a Perl programmer). Does
> anyone has a clue? Do I have
> the wrong version for something? Did I setup the repository wrongly?
>
> Thanks --- Jan
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: merging .gitignore
From: Johan Herland @ 2007-10-03 13:06 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Andy Parkins, martin f krafft
In-Reply-To: <Pine.LNX.4.64.0710031314530.28395@racer.site>
On Wednesday 03 October 2007, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Johan Herland wrote:
> > - Teach the .gitignore parser to ignore conflict markers (i.e. regard them
> > as comments)
>
> You might be delighted to know that in practice, it works already (because
> you usually do not have a file named "<<<<<< blablub" or "======" or
> ">>>>>> blablub"...
I suspected so... ;)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: merging .gitignore
From: Johannes Schindelin @ 2007-10-03 12:41 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Andy Parkins, martin f krafft
In-Reply-To: <200710031128.56472.johan@herland.net>
Hi,
On Wed, 3 Oct 2007, Johan Herland wrote:
> - Teach the .gitignore parser to ignore conflict markers (i.e. regard them
> as comments)
You might be delighted to know that in practice, it works already (because
you usually do not have a file named "<<<<<< blablub" or "======" or
">>>>>> blablub"...
Ciao,
Dscho
^ permalink raw reply
* git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 11:48 UTC (permalink / raw)
To: git
Hi,
I'm pretty new to GIT. I quickly convinced our project to move to GIT,
except for one guy that wants to do Windows and CVS :-( I setup a test
and the checkout works just fine, but commit from cvs doesn't work. The
details:
* Server: git version 1.5.3.1 compiled on SuSE 10.2, 64-bits
* Client, both SuSE CVS 1.12.12 and the current WinCVS cvs.exe,
so it appears irrelevant.
I created a test repository from a papers directory using the sequence
beloe. (P.s. isn't there a more elegant way to get to a bare shared repo
from a set of files? I tried (mkdir papers.git && cd papers.git && git
--bare init --shared=all), but I can't clone an empty bare repository
(doesn't create anything), so I can't add to it).
% cd ~/tmp/papers
% git-init
% git-add .
% git-commit
% cd /home/git
% git-clone --bare --no-hardlinks ~/tmp/papers/ papers.git
% cd papers.git
% git-config core.sharedrepository all
% chmod g+ws `find . -type d`
% chmod g+w `find . -type f`
Anyway, appears to work fine with GIT to clone, pull and push. Using
CVS over SSH, I can checkout this just fine, creating HEAD. Now I change
a file and run "cvs commit" to get:
gollem (2006) 11_> cvs commit -m "test"
cvs [commit aborted]: end of file from server (consult above messages if any)
I enabled logging and added a few statements to git-cvsserver (line 1203)
$log->info("Start git show-ref -s refs/heads/$state->{module}");
# Remember where the head was at the beginning.
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$log->info("parenthash = $parenthash");
chomp $parenthash;
if ($parenthash !~ /^[0-9a-f]{40}$/) {
$log->warn("error 1 pserver cannot find the current HEAD of
module");
exit;
}
Then I get this log output:
================================================================
2007-10-03 12:25:16 : DEBUG - Temporary directory is '/tmp/XwYVFFqjyd'
2007-10-03 12:25:16 : DEBUG - req_Root : /home/git/papers.git
2007-10-03 12:25:16 : DEBUG - req_Validresponses : ok error Valid-requests
Referrer Redirect Checked-in New-entry Checksum Co
py-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time
Removed Remove-entry Set-static-directory Clear
-static-directory Set-sticky Clear-sticky Edit-file Template Clear-template
Notified Module-expansion Wrapper-rcsOption M Mbi
nary E F MT
2007-10-03 12:25:16 : DEBUG - req_validrequests
2007-10-03 12:25:16 : DEBUG - SEND : Valid-requests remove add status Entry
watchers ci tag log co Modified Questionable admi
n Root history valid-requests Global_option Argumentx annotate Valid-responses
Unchanged Directory rlog Argument expand-modul
es diff editors update
2007-10-03 12:25:16 : DEBUG - SEND : ok
2007-10-03 12:25:16 : DEBUG - req_Globaloption : -q
2007-10-03 12:25:16 : DEBUG - Argument : -m
2007-10-03 12:25:16 : DEBUG - Argument : test
2007-10-03 12:25:16 : DEBUG - Argument : --
2007-10-03 12:25:16 : INFO - Setting prepend to '2006/'
2007-10-03 12:25:16 : DEBUG - Prepending '2006/' to state|directory
2007-10-03 12:25:16 : DEBUG - req_Directory : localdir=.
repository=/home/git/papers.git/HEAD/2006 path=2006/ directory=2006/
module=HEAD
2007-10-03 12:25:16 : INFO - Received entry line '/README.txt/1.1///'
=> '2006/README.txt'
2007-10-03 12:25:16 : DEBUG - Argument : README.txt
2007-10-03 12:25:16 : INFO - req_ci : [NULL]
2007-10-03 12:25:16 : INFO - Lockless commit start, basing commit
on '/tmp/XwYVFFqjyd/ud4uGbbUJg', index file is '/tmp/XwYVF
Fqjyd/3FeXMladmb'
2007-10-03 12:25:16 : INFO - Start git show-ref -s refs/heads/HEAD
2007-10-03 12:25:16 : INFO - parenthash =
2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current HEAD of
module
================================================================
I don't like the req_ci : [NULL] very much, and the last 3 lines clearly shows
a problem. I checked
the latest git repository of git. There is no change to git-cvsserver.perl.
I'm still a bit too newbie to (and not much of a Perl programmer). Does
anyone has a clue? Do I have
the wrong version for something? Did I setup the repository wrongly?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Sixt @ 2007-10-03 12:19 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20071003105501.GD7085@admingilde.org>
Martin Waitz schrieb:
> At least on Linux the vfat file system honors chmod calls but does not
> store them permanently (as there is no on-disk format for it).
> So the filemode test which tries to chmod a file thinks that the file
> system does support file modes. This will result in problems when the
> file system gets mounted for the next time and all the executable bits
> are back.
>
> A more reliable test for file systems without filemode support is to
> simply check if new files are created with the executable bit set.
On Windows, we don't get an executable bit at all. Better use both
heuristics, i.e. set core.filemode false if either one diagnoses an
unreliable x-bit.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: Johannes Sixt @ 2007-10-03 12:09 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <87y7ekr86e.wl%cworth@cworth.org>
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
-- Hannes
^ permalink raw reply
* Re: [msysGit] Re: WIP: asciidoc replacement
From: David Kastrup @ 2007-10-03 12:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710031239410.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 2 Oct 2007, Junio C Hamano wrote:
>
>>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > So here it is: a perl script that does a good job on many .txt files
>> > in Documentation/, although for some it deviates from "make man"'s
>> > output, and for others it is outright broken. It is meant to be run
>> > in Documentation/.
>> >
>> > My intention is not to fix the script for all cases, but to make
>> > patches to Documentation/*.txt themselves, so that they are more
>> > consistent (and incidentally nicer to the script).
>>
>> How you spend your time is up to you, but I need to wonder...
>>
>> - Is "man" format important for msysGit aka Windows
>> environment? I had an impression that their helpfile format
>> were closer to "html" output.
>
> I wanted something that can output both "man" and "html" output (and
> if some suck^Wlos^Wtexi-fan wants to provide it, also a "texi" or
> even "info" backend).
And you have not even talked about print. The thing is that high
quality output is a lot of work (including design and design
decisions) for _every_ _single_ backend. If the only target were
"man" and text, then one would be better off writing as groff source
and be done.
We really can't afford another time sink. That nobody can actually
solve structural problems ("how do we include the man pages as an
appendix in the user manual?") also implies a waste of time, but at
some point of time people just throw up their hands and give up in
disgust.
You propose a larger time sink where people won't be forced to give
up. But we really don't want to waste time reinventing the wheel. It
would be better spent communicating with the wheelbuilders.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [msysGit] Re: WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit
In-Reply-To: <7vprzwhkgd.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 2 Oct 2007, Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So here it is: a perl script that does a good job on many .txt files
> > in Documentation/, although for some it deviates from "make man"'s
> > output, and for others it is outright broken. It is meant to be run
> > in Documentation/.
> >
> > My intention is not to fix the script for all cases, but to make
> > patches to Documentation/*.txt themselves, so that they are more
> > consistent (and incidentally nicer to the script).
>
> How you spend your time is up to you, but I need to wonder...
>
> - Is "man" format important for msysGit aka Windows
> environment? I had an impression that their helpfile format
> were closer to "html" output.
I wanted something that can output both "man" and "html" output (and if
some suck^Wlos^Wtexi-fan wants to provide it, also a "texi" or even "info"
backend).
IMHO "man" needs a stricter framework in place, so I went with that.
> - Does it make sense in the longer term for us to maintain
> in-house documentation tools? Can we afford it?
In the long run, I expect only few bugs (and I will try hard to squash
them when they crop up, _and_ make this beast more maintainable whenever
somebody has an idea how to do that).
However, it should definitely help keeping the docs clean, as now nobody
has an excuse to test doc changes a la "I do not have asciidoc, so I do
not know if it works, so please test".
> It appears that we heard about breakages for every minor docbook
> updates, and it is really appealing if we do not have to rely on xsl
> toolchain for manpage generation.
Exactly.
> But if patching the text means making it compatible with the in-house
> script _and_ incompatible with AsciiDoc, hmmm...
No, I do not want it _incompatible_. I want it _stricter_. For example,
you can do this in asciidoc:
This is some paragraph that is indented,
but the funny thing is:
This paragraph:
---------------
is indented all the same!
So one thing I absolutely detest here is that you are free to use one,
two, three or more spaces, or tabs, and asciidoc does the DWIMery of
handling them the same. But _not_ if there was any indentation before
that with _less_ spaces and/or tabs!
Therefore I'd like to enforce strict rules here: Tab it is. One tab per
indentation level. No spaces, no ambiguities.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Martin Waitz @ 2007-10-03 10:55 UTC (permalink / raw)
To: git
At least on Linux the vfat file system honors chmod calls but does not
store them permanently (as there is no on-disk format for it).
So the filemode test which tries to chmod a file thinks that the file
system does support file modes. This will result in problems when the
file system gets mounted for the next time and all the executable bits
are back.
A more reliable test for file systems without filemode support is to
simply check if new files are created with the executable bit set.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
builtin-init-db.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
NOTE: this is only tested on Linux with ext3 and vfat file systems.
I do not know enough about the behaviour of other systems so there
may be regressions.
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..fbccacb 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -246,10 +246,7 @@ static int create_default_files(const char *git_dir, const char *template_path)
/* Check filemode trustability */
filemode = TEST_FILEMODE;
if (TEST_FILEMODE && !lstat(path, &st1)) {
- struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
- !lstat(path, &st2) &&
- st1.st_mode != st2.st_mode);
+ filemode = !(st1.st_mode & S_IXUSR);
}
git_config_set("core.filemode", filemode ? "true" : "false");
--
1.5.3.3.8.g367dc7
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Andreas Ericsson @ 2007-10-03 11:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0710030503520.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 2 Oct 2007, Jeff King wrote:
>
>> On Tue, Oct 02, 2007 at 05:22:23PM -0700, Junio C Hamano wrote:
>>
>>>> strbuf_init(&url);
>>>> strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
>>> Ugh, this typically calls snprintf() twice doesn't it?
>> Yes, it probably does. However, I think it is considerably easier to
>> read and more maintainable. Are you "ugh"ing because of the performance
>> impact (which should be negligible unless this is in a tight loop) or
>> because of the portability problems associated with va_copy?
>
> I wonder, I wonder, if
>
> strbuf_addstr(&url, repo->base);
> strbuf_addstr(&url, "/objects/pack/pack-");
> strbuf_addstr(&url, hex);
> strbuf_addstr(&url, ".idx");
>
> would make anybody else but me happy...
strbuf_addstr_many(&url, repo->base, "/objects/pack/pack-", hex, ".idx", NULL);
is what I'd prefer. It's not overly complicated, requires no *printf(), and doesn't
introduce any new portability issues (va_arg() is C89).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-svn merge helper
From: Andreas Ericsson @ 2007-10-03 11:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Steven Walter, git
In-Reply-To: <20071003010233.GA8610@atjola.homenet>
Björn Steinbrink wrote:
> On 2007.10.02 20:42:52 -0400, Steven Walter wrote:
>> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
>>>> The other option is to have a "build" branch. By example:
>>>>
>>>> git checkout build
>>>> git reset --hard master
>>>> git merge mybranch
>>>> make
>>>>
>>>> In that way, I have branch with the latest changes from head and the
>>>> changes from mybranch together. The downside to this method is that you
>>>> may have to repeated resolve merges. Despite the downsides, I find
>>>> these two methods to work quite well.
>>> Thanks, but it makes no difference here, it stil results in a fast
>>> forward. This is a small test case which exhibits the behaviour and
>>> matches my current workflow with git-svn (except for the dcommits):
>>>
>>> git init
>>> echo Hi > file1; git add file1; git commit -m file1
>>> git checkout -b branch
>>> echo Hi > file2; git add file2; git commit -m file2
>>> git checkout master
>>> echo Hi > file3; git add file3; git commit -m file3
>>> git checkout branch
>>> git merge master
>>>
>>> # Then I'd normally do the following which causes a fast forward
>>> #git checkout master
>>> #git merge branch
>>>
>>> # Now I tried this, which also results in a fast-forward:
>>> git checkout -b merge
>>> git reset --hard master
>>> git merge branch
>> I believe you misunderstood my suggestion. In using a "build" branch,
>> you would not merge master into branch, as you did above. Instead, you
>> would create a third, unpublished branch to hold the merge.
>
> Almost though so.
>
>> At the same time, I have a slightly better understanding of what it is
>> you're trying to do. If you are trying to keep up an SVN-like workflow
>> (namely pulling changes from trunk into a branch from time to time),
>> then my solution probably isn't suitable for you. However, you might
>> consider why you actually /need/ to do that, outside of SVN convention.
>
> Due to the same reason for which the branch needs to be public at all,
> there are other people who want to follow it and test it, while there
> are external dependencies that currently change quite often. So I need
> to get the relevant changes from trunk into my branch anyway, even with
> svn conventions put aside (well, unless I force everyone else to merge
> over and over again). And as sometimes others commit to that branch, too
> (you just have to love that), keeping a separate branch for the final
> merge isn't so nice either, as I'd need to constantly cherry-pick those
> changes then and probably get even more conflicts along the way.
>
> That said, Google finally liked some of the search terms that I threw at
> it and revealed a thread [1] from march, where Linus was torn on whether
> or not a --no-fast-forward option should be introduced. That sounds like
> it would help here, any chance of getting such a thing?
>
Is this what you're looking for? It's in the 'next' branch in git.git.
commit d66424c4ac661c69640765260235452499d80378
Author: Lars Hjemli <hjemli@gmail.com>
Date: Mon Sep 24 00:51:45 2007 +0200
git-merge: add --ff and --no-ff options
These new options can be used to control the policy for fast-forward
merges: --ff allows it (this is the default) while --no-ff will create
a merge commit.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Miles Bader, Pierre Habouzit, git
In-Reply-To: <7v8x6kfobq.fsf@gitster.siamese.dyndns.org>
El 3/10/2007, a las 13:08, Junio C Hamano escribió:
> Also mistakes can cut both ways. Pushing out what you did not
> intend to is what you seem to be worried about more. But not
> pushing out enough and not noticing is an equally bad mistake.
I don't think they're of the same order. If you mistakenly push out
too little you can easily correct it by pushing again. But what do
you do if you push out too much? How do you fix that?
> You, an expert, will get asked for help by somebody, walk up to
> his shell prompt, and try to help and teach him by showing you
> type, and then you suddenly notice the command does not work as
> you expect because he set the default differently (because he
> read that configuration option on some web parge). And we will
> be in such a cumbersome to diagnose situation _very_ often if we
> have per-user default on many things.
True, true.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Andy Parkins @ 2007-10-03 11:13 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <200710030850.19614.andyparkins@gmail.com>
On Wednesday 2007 October 03, Andy Parkins wrote:
> I put a comment above the other changes like this in the same file, but
> thought I was being overly verbose putting it in every single time. I'm
> happy to copy the comment around in the file though.
I'm a liar; I remember writing them, but they're not in the patch. Perhaps
they are still in my working tree at home. Anyway; you're point was correct,
I'll find the explanatory comments or write new ones and add them to the
patch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Benoit SIGOURE @ 2007-10-03 11:10 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git list
In-Reply-To: <83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]
On Oct 3, 2007, at 12:25 PM, Wincent Colaiuta wrote:
> El 3/10/2007, a las 10:57, Miles Bader escribió:
>
>> To the extent that a command _is_ "dangerous", there's always a
>> tradeoff
>> between convenience and "danger". Some systems (e.g. those aimed at
>> newbies) might have as a goal to do the absolute minimum with every
>> command and always, always, err on the side of safety. I don't
>> think git
>> is that system.
>
> While much of this debate can be shortcircuited simply by making
> the behaviour configurable, I would like to take you up on the
> point that you raise here.
>
> If we're going to talk about what kind of system Git is then
> consider this:
>
> - it's inherently distributed and this design actively encourages
> users to treat their local repositories as sandboxes where things
> are tried out, perfected, and then pushed out into the public via
> one means or another
>
> - it's built from the ground up to be good at branching and
> merging; this, combined with my previous point, means that users
> are likely to have multiple heads and often some of them will be
> "works in progress" that aren't yet ready for publication
>
> So it's in that light I see accidentally pushing more than you
> thought you would as "dangerous"; when you make this mistake you're
> basically making stuff available that's not yet ready for
> consumption, and by its nature this mistake is basically
> irreversible: you can't really "unpush" what you pushed, you can
> only push out additional amendments which correct it.
>
> So, in this light, when you say:
>
>> What's "dangerous" for newbies, often ends up being what doesn't
>> correspond with their mental model.
>
> I don't know how much it has to do with mental models. I think in
> this case it's a bit simpler than that where you make the mistake
> once or twice and very quickly learn that "git push" means "push
> what's in my repo", not "push only what's on my current branch".
> It's a *very* easy lesson to learn if you get burnt and hardly
> requires any adjustments to ones "mental model".
>
> I personally would be in favour of changing the default because I
> tend to work on a particular branch at a time and then want to push
> *that* out -- generally I'm thinking about one general area or one
> task at a time, and that means one branch at a time; I almost never
> think along the lines of getting all my branches into shape at once
> and then pushing them out in a batch. I think this is more likely
> to be a common pattern, although obviously that remains speculation
> at this point.
>
> Changing the default would be great for people like me; by not
> having to pass additional parameters to git-push I save some
> keystrokes. If I ever want to push everything an "--all" switch
> would do the job. But if people prefer to keep the old default then
> there'll be .gitconfig for people like me. In any case I think more
> people need to speak up on the topic so that we can find out what
> most people really think about changing the default.
>
I completely second all that. I've been using Git for roughly 3
months and have been burnt the same way.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ 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