* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, Julian Phillips, git
In-Reply-To: <7v1wezohi4.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
>> I live by new-workdir. I do everything with it. And today I
>> just spent over an hour sorting out cases where my many, many
>> workdirs have different refs than their base repositories,
>> because their packed-refs files are different.
>> Grrrrrrrrrrrrrrrrrr.
>>
>> So we really need to make anyone that edits packed-refs (and
>> maybe also config) resolve the symlink and do the edit in the
>> target directory. Then we can consider adding this workdir thing
>> to core git.
>
> This is actually not limited to packed-refs file, but applies to
> other things as well.
>
> I have been wondering if something like this patch would be
> sufficient. The idea essentially is to take the lock on the link
> target when we try to take a lock on something that is a symlink
> pointing elsewhere.
(..snip..)
While you guys are discussing this, please please keep in mind that
there are Windows users (/me raises his hand) out there that really
really want this too. So, please try to keep it light on the symlinks.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Simon 'corecode' Schubert @ 2007-07-24 8:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Jason Sewall, git, raa.lkml
In-Reply-To: <200707240223.54228.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
>>> It may be that we may want to fix this inside cvsexportcommit
>>> itself, instead of working it around in the tests. If somebody
>>> tries to push more than one commit from git using two
>>> cvsexportcommit in a row, he would need to make sure that the
>>> second run happens one or more seconds after the first run,
>>> otherwise he will see the exact corruption in real life.
>> Ah, now I see the problem. The timestamp in the CVS/Entries is the same (because it only has second granularity),
>> so cvs commit won't consider it as changed.
>>
>> That's the reason why CVS usually waits until the second turns after a "update" (obviously not after a "commit").
>> So we could either turn back the timestamp in the Entries file (ugly) or simply wait until the second turns. Given
>> the overall cvs performance, this won't be a big issue, I guess.
>
> CVS sleeps after commit here. Can we bisect it? I have 1.12.3
> (mandriva). The patch below I think would work around the problem,
> rather than trying to fix the test. but I'd like to have the last CVS
> revision where it does not work for the patch comment
This is a strange thing. CVS has this in their commit code since 1996. So I wonder why this is getting triggered.
> Since the sleep is per invocation of cvsexportcommit it won't hurt
> too much since it is rarely invoked on a huge number of git commits.
The question also is, why does this happen on two sequential invocations of cvsexportcommit, but not on two cvs commits done by cvsexportcommit? This should look the same to cvs, no?
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* [PATCH/RFH] Mark user-manual as UTF-8
From: Junio C Hamano @ 2007-07-24 7:46 UTC (permalink / raw)
To: git; +Cc: J. Bruce Fields, H. Peter Anvin
There have been several complaints against k.org's user-manual
page. The document is generated in ISO-8859-1 by the xsltproc
toolchain (I suspect this is because released docbook.xsl we use
has xsl:output element that says the output is ISO-8859-1) but
server delivers it with "charset=UTF-8", and all h*ll breaks
loose.
This attempts to force UTF-8 on the generating end.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I have to warn that I do not really think I know what I am
doing, but this seems to "work for me".
Documentation/Makefile | 2 +-
Documentation/docbook.xsl | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
create mode 100644 Documentation/docbook.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index b062757..3bc5357 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -131,7 +131,7 @@ clean:
user-manual.xml: user-manual.txt user-manual.conf
$(ASCIIDOC) -b docbook -d book $<
-XSLT = http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
+XSLT = docbook.xsl
XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
diff --git a/Documentation/docbook.xsl b/Documentation/docbook.xsl
new file mode 100644
index 0000000..9a6912c
--- /dev/null
+++ b/Documentation/docbook.xsl
@@ -0,0 +1,5 @@
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version='1.0'>
+ <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
+ <xsl:output method="html" encoding="UTF-8" indent="no" />
+</xsl:stylesheet>
^ permalink raw reply related
* Re: having problems with building the manpages
From: VMiklos @ 2007-07-24 7:38 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707231937210.32580@beast.quantumfyre.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
Hello,
Na Mon, Jul 23, 2007 at 07:40:04PM +0100, Julian Phillips <julian@quantumfyre.co.uk> pisal(a):
> Are you using docbook xsl 1.72? There are known problems building the
> manpages with that version. 1.71 works, and 1.73 should work when it
> get released.
yes, i'm was uging 1.72. in the mentime 1.73 has been released, here is
the error i get when using it:
asciidoc -b docbook -d manpage -f asciidoc.conf \
-a asciidoc7compatible -agit_version=1.5.2.4 -o git-add.xml+ git-add.txt
mv git-add.xml+ git-add.xml
xmlto -m callouts.xsl man git-add.xml
runtime error: file file:///usr/share/xml/docbook/manpages/other.xsl line 129 element call-template
The called template 'read-character-map' was not found.
Note: meta date : no date; using generated date git-add
Note: meta date : see http://docbook.sf.net/el/date git-add
runtime error: file file:///usr/share/xml/docbook/manpages/other.xsl line 537 element call-template
The called template 'apply-character-map' was not found.
Note: Writing git-add.1
error: file /var/tmp/fst/src/git-1.5.2.4/Documentation/git-add.xml
xsltRunStylesheet : run failed
make[1]: *** [git-add.1] Error 1
rm git-add.xml
make[1]: Leaving directory `/var/tmp/fst/src/git-1.5.2.4/Documentation'
make: *** [doc] Error 2
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git log -g: Complain, but do not fail, when no reflogs are there
From: Alex Riesen @ 2007-07-24 7:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707240039300.14781@racer.site>
On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> When asking "git log -g --all", clearly you want to see only those refs
> that do have reflogs, but you do not want it to fail, either.
>
> So instead of die()ing, complain about it, but move on to the other refs.
>
I believe you wont even see these complaints: the pager will start shortly
afterwards and fill the screen with commits, completely hiding the errors.
^ permalink raw reply
* Re: [PATCH] Add glossary that can be converted into a po file for each language.
From: Junio C Hamano @ 2007-07-24 6:56 UTC (permalink / raw)
To: Christian Stimming
Cc: Johannes Schindelin, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <200707232216.40300.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
> new file mode 100644
> index 0000000..e079bb2
> --- /dev/null
> +++ b/po/glossary/git-gui-glossary.txt
> @@ -0,0 +1,34 @@
> +"English Term (Dear translator: This file will never be visible to the user!)" "English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
> +"amend" ""
> +"annotate" ""
> +"branch [noun]" "A 'branch' is an active line of development."
> +"branch [verb]" ""
> +"checkout [noun]" ""
> +"checkout [verb]" "The action of updating the working tree to a revision which was stored in the object database."
> +"commit [noun]" "A single point in the git history."
I wonder.... couldn't this be written as a Tcl array that maps
word to its definition, marked with [mc] 'gettext'ese, perhaps,
glossary.tcl? Then perhaps git-gui can include it and have a
user-visible glossary as part of its help system.
Am I dreaming, or too drunk?
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Nix @ 2007-07-24 6:56 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, git
In-Reply-To: <86ps2ithyl.fsf@lola.quinscape.zz>
On 24 Jul 2007, David Kastrup spake thusly:
> But merging will become nicer if the permissions actually stay
> associated with the file rather than the file name. Even in things
> like /etc backups, blobs not infrequently relocate from one place to
> another when the system gets updated.
Even without that we'd need to merge without context, i.e. with totally
independent lines, for such a file. So it's not the standard git file
merge.
^ permalink raw reply
* Re: git-send-email and pine alias format
From: Junio C Hamano @ 2007-07-24 6:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707231146160.6889@blarg.am.freescale.net>
Kumar Gala <galak@kernel.crashing.org> writes:
> I was wondering why we don't parse the pine alias format according to the
> following spec:
>
> http://www.washington.edu/pine/tech-notes/low-level.html
>
> I'd expect something like, to get the address field.
My guess is simply because we got a "works-for-us" regexp by
observing the program's behaviour, done by real Pine users. On
top of that, probably nobody knew and/or bothered to check if
there is such "official spec" available.
Could you send a signed and testable patch to the list so other
Pine users can try it out please? After seeing a few Ack's on
the list, I'd like to apply it and preferably do so before 1.5.3
final.
^ permalink raw reply
* Re: [PATCH] Test case for "git diff" outside a git repo
From: Junio C Hamano @ 2007-07-24 6:14 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20070723132248.GA24122@midwinter.com>
Junio C Hamano <gitster@pobox.com> writes:
> Steven Grimm <koreth@midwinter.com> writes:
>
>> Signed-off-by: Steven Grimm <koreth@midwinter.com>
>> ---
>> git-diff --quiet is pretty broken right now. If you do
>> "strace git diff --quiet file1 file2" you will see that
>> it never calls open() on either file! And it always
>> returns a zero exit code whether or not the files are
>> different.
>>
>> I'm trying to follow the code to figure out what's going on,
>> but meanwhile, here's a test case. Perhaps someone more
>> familiar with the diff code will beat me to a fix.
The code to do "untracked diff" is an ugly stepchild and not
really part of git-diff proper. In fact, --quiet also is an
afterthought and I would not be too surprised if the "untracked
diff" code does not work with it.
>> diff --git a/t/t4021-diff-norepo.sh b/t/t4021-diff-norepo.sh
>> new file mode 100755
>> index 0000000..dfee3d7
>> --- /dev/null
>> +++ b/t/t4021-diff-norepo.sh
>> @@ -0,0 +1,26 @@
>> +#!/bin/sh
>> +
>> +test_description='test git diff outside a repo'
>> +
>> +. ./test-lib.sh
>> +
>> +rm -rf .git
Unless you are testing the t/ directory and git.git suite from a
tarball, the only effect of this is to make t/trash controlled
by its ../../.git repository (i.e. the git.git repository). You
are still inside a git repository.
^ permalink raw reply
* Re: [PATCH] git log -g: Complain, but do not fail, when no reflogs are there
From: Junio C Hamano @ 2007-07-24 5:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707240039300.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When asking "git log -g --all", clearly you want to see only those refs
> that do have reflogs, but you do not want it to fail, either.
>
> So instead of die()ing, complain about it, but move on to the other refs.
Hmph, do we even want to error(), I wonder...
Can you tell, at that point, if there were explicit branch
names given originally on the command line, or the refs came
from --all?
^ permalink raw reply
* Re: [PATCH] filter-branch: Big syntax change; support rewriting multiple refs
From: Junio C Hamano @ 2007-07-24 5:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707231829210.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Junio, I know that this comes quite late in the game, but I really
> think that the "first arg is new branch name" was a bad syntax.
>
> Could you please consider taking this patch (or whatever version
> comes out after review ;-) or keeping filter-branch of 1.5.3? I
> do not want people to get used to the borked syntax...
Yeah, "No new features after -rc" should not apply to this one.
I was actually going to ask you about it, since this is a
feature we have already advertised to the public, but still is a
new feature, and we'd be better off getting it right in the
first public version.
> BTW I considered "git log -g --all" as an alternative to
> inspecting refs/original/, but ATM this die()s if just _one_ of
> the refs has no logs. Probably should fix that, too.
I do not think refs/original/ is such a hot feature. What's
wrong with "gitk mine@{1}...mine"?
^ permalink raw reply
* http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 3:44 UTC (permalink / raw)
To: git
- Sorry for the noise if this has already been reported.
- It's on a Mandriva Spring machine with git 1.5.0.4
- It's a glibc detected memory error. If I restart with
MALLOC_CHECK_=0 I dont' get the crash.
[bsergean@marge1 src]$ git --version
git version 1.5.0.4
[bsergean@marge1 src]$ git clone http://www.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /home/bsergean/src/git/.git/
got de9879a91fd7d4d123a303b4bcdc918f43ca3a62
walk de9879a91fd7d4d123a303b4bcdc918f43ca3a62
got 68cb399f1760d4a54ae9ff1f367fea8b6bed9453
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
got f6002a9d88be66b5d7ac79bf312feb0b622791ca
walk f6002a9d88be66b5d7ac79bf312feb0b622791ca
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Getting index for pack 6ce718d496eba4857e76cc9b8f7a1a82f5dfb416
got 896ff1d95a2a307fd764b66de4fbd882e64dd9c6
*** glibc detected *** git-http-fetch: corrupted double-linked list:
0x0808ad50 ***
======= Backtrace: =========
/lib/i686/libc.so.6[0xb7c35516]
/lib/i686/libc.so.6[0xb7c37728]
/lib/i686/libc.so.6(__libc_malloc+0x85)[0xb7c39075]
/lib/libz.so.1(zcalloc+0x20)[0xb7edbfd0]
git-http-fetch[0x804c6e8]
git-http-fetch[0x804a9bb]
git-http-fetch[0x804aa3b]
git-http-fetch[0x804db94]
git-http-fetch[0x804a310]
git-http-fetch[0x804cb97]
/lib/i686/libc.so.6(__libc_start_main+0xdc)[0xb7be7d8c]
git-http-fetch[0x8049c31]
======= Memory map: ========
08048000-08068000 r-xp 00000000 03:02 506123 /usr/bin/git-http-fetch
08068000-08069000 rwxp 00020000 03:02 506123 /usr/bin/git-http-fetch
08069000-08436000 rwxp 08069000 00:00 0 [heap]
b7900000-b7921000 rwxp b7900000 00:00 0
b7921000-b7a00000 ---p b7921000 00:00 0
b7ad9000-b7ae3000 r-xp 00000000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
b7ae3000-b7ae4000 rwxp 0000a000 03:02 678969 /lib/libgcc_s-4.1.2.so.1
b7af9000-b7b19000 rwxp b7af9000 00:00 0
b7b19000-b7b27000 r-xp 00000000 03:02 678959 /lib/libresolv-2.4.so
b7b27000-b7b29000 rwxp 0000e000 03:02 678959 /lib/libresolv-2.4.so
b7b29000-b7b2b000 rwxp b7b29000 00:00 0
b7b2b000-b7b2f000 r-xp 00000000 03:02 678947 /lib/libnss_dns-2.4.so
b7b2f000-b7b31000 rwxp 00003000 03:02 678947 /lib/libnss_dns-2.4.so
b7b31000-b7b41000 r-xp 00000000 03:02 678943 /lib/libnsl-2.4.so
b7b41000-b7b43000 rwxp 00010000 03:02 678943 /lib/libnsl-2.4.so
b7b43000-b7b45000 rwxp b7b43000 00:00 0
b7b45000-b7b4d000 r-xp 00000000 03:02 678953 /lib/libnss_nis-2.4.so
b7b4d000-b7b4f000 rwxp 00007000 03:02 678953 /lib/libnss_nis-2.4.so
b7b4f000-b7b57000 r-xp 00000000 03:02 678949 /lib/libnss_files-2.4.so
b7b57000-b7b59000 rwxp 00007000 03:02 678949 /lib/libnss_files-2.4.so
b7b59000-b7b5a000 rwxp b7b59000 00:00 0
b7b5a000-b7b99000 r-xp 00000000 03:02 36383 /usr/lib/libssl.so.0.9.8
b7b99000-b7b9d000 rwxp 0003e000 03:02 36383 /usr/lib/libssl.so.0.9.8
b7b9d000-b7bcd000 r-xp 00000000 03:02 215594 /usr/lib/libidn.so.11.5.23
b7bcd000-b7bce000 rwxp 0002f000 03:02 215594 /usr/lib/libidn.so.11.5.23
b7bce000-b7bd0000 r-xp 00000000 03:02 678939 /lib/libdl-2.4.so
b7bd0000-b7bd2000 rwxp 00001000 03:02 678939 /lib/libdl-2.4.so
b7bd2000-b7cfb000 r-xp 00000000 03:02 678918 /lib/i686/libc-2.4.so
b7cfb000-b7cfc000 r-xp 00129000 03:02 678918 /lib/i686/libc-2.4.so
b7cfc000-b7cfe000 rwxp 0012a000 03:02 678918 /lib/i686/libc-2.4.so
b7cfe000-b7d02000 rwxp b7cfe000 00:00 0
b7d02000-b7d20000 r-xp 00000000 03:02 215102 /usr/lib/libexpat.so.0.5.0
b7d20000-b7d22000 rwxp 0001e000 03:02 215102 /usr/lib/libexpat.so.0.5.0
b7d22000-b7d70000 r-xp 00000000 03:02 215628 /usr/lib/libcurl.so.4.0.0
b7d70000-b7d71000 rwxp 0004d000 03:02 215628 /usr/lib/libcurl.so.4.0.0
b7d71000-b7ebc000 r-xp 00000000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
b7ebc000-b7ed1000 rwxp 0014b000 03:02 36382 /usr/lib/libcrypto.so.0.9.8
b7ed1000-b7ed4000 rwxp b7ed1000 00:00 0
b7ed4000-b7ee6000 r-xp 00000000 03:02 678968 /lib/libz.so.1.2.3
b7ee6000-b7ee7000 rwxp 00011000 03:02 678968 /lib/libz.so.1.2.3
b7efc000-b7efd000 rwxp b7efc000 00:00 0
b7efd000-b7f15000 r-xp 00000000 03:02 678928 /lib/ld-2.4.so
b7f15000-b7f16000 r-xp 00017000 03:02 678928 /lib/ld-2.4.so
b7f16000-b7f17000 rwxp 00018000 03:02 678928 /lib/ld-2.4.so
bfd02000-bfd18000 rw-p bfd02000 00:00 0 [stack]
bfffe000-bffff000 r-xp bfffe000 00:00 0
/usr/bin/git-clone: line 33: 12780 Aborted
git-http-fetch -v -a -w "$tname" "$name" "$1/"
Benjamin.
^ permalink raw reply
* [PATCH] rebase -i: exchange all "if [ .. ]" by "if test .."
From: Johannes Schindelin @ 2007-07-24 2:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vvecak1aw.fsf@assigned-by-dhcp.cox.net>
This patch is literally
:%s/if \[ *\(.*[^ ]\) *\]/if test \1/
in vi, after making sure that the other instances of "[..]" are not
actually invocations of "test".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 23 Jul 2007, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > Not all shells grok a closing ']' of the shell '[' command without
> > surrounding space.
> >
> > Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> > ---
> >
> > I didn't go the long way to change all `[ ... ]` into `test ...`
>
> Maybe that would have been a better idea.
Voila.
(Obviously, this is on top of my last patch to rebase -i, to bug
you into applying it ;-)
Seriously again, if I should rather redo it relative to "master",
please say so. Or apply the regsub and get all the karma for
free...
git-rebase--interactive.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ac1f5a2..93289c0 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -102,7 +102,7 @@ pick_one () {
pick_one_preserving_merges "$@" && return
parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
current_sha1=$(git rev-parse --verify HEAD)
- if [ $current_sha1 = $parent_sha1 ]; then
+ if test $current_sha1 = $parent_sha1; then
output git reset --hard $sha1
test "a$1" = a-n && output git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
@@ -116,7 +116,7 @@ pick_one_preserving_merges () {
case "$1" in -n) sha1=$2 ;; *) sha1=$1 ;; esac
sha1=$(git rev-parse $sha1)
- if [ -f "$DOTEST"/current-commit ]
+ if test -f "$DOTEST"/current-commit
then
current_commit=$(cat "$DOTEST"/current-commit) &&
git rev-parse HEAD > "$REWRITTEN"/$current_commit &&
@@ -130,7 +130,7 @@ pick_one_preserving_merges () {
new_parents=
for p in $(git rev-list --parents -1 $sha1 | cut -d\ -f2-)
do
- if [ -f "$REWRITTEN"/$p ]
+ if test -f "$REWRITTEN"/$p
then
preserve=f
new_p=$(cat "$REWRITTEN"/$p)
@@ -188,7 +188,7 @@ nth_string () {
}
make_squash_message () {
- if [ -f "$SQUASH_MSG" ]; then
+ if test -f "$SQUASH_MSG"; then
COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
< "$SQUASH_MSG" | tail -n 1)+1))
echo "# This is a combination of $COUNT commits."
@@ -286,7 +286,7 @@ do_next () {
HEADNAME=$(cat "$DOTEST"/head-name) &&
OLDHEAD=$(cat "$DOTEST"/head) &&
SHORTONTO=$(git rev-parse --short $(cat "$DOTEST"/onto)) &&
- if [ -d "$REWRITTEN" ]
+ if test -d "$REWRITTEN"
then
test -f "$DOTEST"/current-commit &&
current_commit=$(cat "$DOTEST"/current-commit) &&
@@ -403,7 +403,7 @@ do
require_clean_work_tree
- if [ ! -z "$2"]
+ if test ! -z "$2"
then
output git show-ref --verify --quiet "refs/heads/$2" ||
die "Invalid branchname: $2"
@@ -426,7 +426,7 @@ do
echo $ONTO > "$DOTEST"/onto
test -z "$STRATEGY" || echo "$STRATEGY" > "$DOTEST"/strategy
test t = "$VERBOSE" && : > "$DOTEST"/verbose
- if [ t = "$PRESERVE_MERGES" ]
+ if test t = "$PRESERVE_MERGES"
then
# $REWRITTEN contains files for each commit that is
# reachable by at least one merge base of $HEAD and
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* Re: [PATCH] Fix problematic ']'
From: Junio C Hamano @ 2007-07-24 2:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin
In-Reply-To: <200707232236.21389.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Not all shells grok a closing ']' of the shell '[' command without
> surrounding space.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
>
> I didn't go the long way to change all `[ ... ]` into `test ...`
Maybe that would have been a better idea.
^ permalink raw reply
* Re: [PATCH] Add glossary that can be converted into a po file for each language.
From: Junio C Hamano @ 2007-07-24 1:48 UTC (permalink / raw)
To: Christian Stimming
Cc: Johannes Schindelin, Shawn O. Pearce, Brett Schwarz, git,
Paul Mackerras
In-Reply-To: <200707232216.40300.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> As I already wrote: Having a glossary in the header of the po file has
> some (IMHO serious) drawbacks.
Yeah, that was me talking without knowing what are the usual
workflows with gettext toolchain. A separate glossary that
properly is PO is much nicer. We could even use that in the
help text.
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-24 1:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707231743w759afabfvd43045ad2e2eba5a@mail.gmail.com>
Hi,
On Mon, 23 Jul 2007, Jon Smirl wrote:
> Thanks for working on this. I'd like to see it added to git toolkit.
I plan to submit it to patchutils instead, since this is not really
dependent on git.
> This diff is way easier to read now. I can see that it has SPI support
> backported from some future version.
>
> But... it still has some problems. For the phytec patch it's not getting
> the $Log changes in the qlogic files right.
You are correct. This slipped by my eyes.
> I'm checking the output diff line by line for problems. It's down to
> 11,528 lines from 88,787. That's a lot of junk removed, I'll have to
> make sure it isn't removing too much.
May I ask you to test this version?
Thanks,
Dscho
-- snipsnap --
#!/usr/bin/perl
# This is a simple state machine.
#
# There is the state of the current file; its header is stored
# in $current_file to avoid outputting it when all hunks were
# culled. It is only printed before the first hunk, and then
# set to "" to avoid outputting it twice.
#
# There are the states of the current hunk, stored in
# * $current_hunk (possibly modified hunk)
# * $start_minus, $start_plus (from the original)
# * $plus, $minus, $space (the current count of the respective lines)
# a hunk is only printed (in flush_hunk) if any '+' or '-' lines
# are left after filtering.
#
# For $Log..$, there is the state $skip_logs, which is set to 1
# after seeing such a line, and set to 0 when the first line
# was seen which does not begin with '+'.
#
# A particularly nasty special case is when a single "*" was
# misattributed by the diff to be _inserted before_ a $Log, instead
# of _appended after_ a $Log.
# This is the purpose of the $before_log and $after_log variables:
# if not empty, the state machine expects the next line to begin
# with '+' or '-', respectively, and followed by a $Log. If this
# expectation is not met, the variable is output.
#
# The variable $plus_minus_adjust contains the number of lines which
# were skipped from the "+" side, so that the correct offset is shown.
# This function gets a hunk header.
#
# It initializes the state variables described above
sub init_hunk {
my $line = $_[0];
$current_hunk = "";
($start_minus, $dummy, $start_plus, $dummy) =
($line =~ /^\@\@ -(\d+)(,\d+|) \+(\d+)(,\d+|) \@\@/);
$plus = $minus = $space = 0;
$skip_logs = 0;
$before_log = '';
$after_log = '';
# we prefer /dev/null as original file name when a file is new
if ($start_minus eq 0) {
$current_file =~ s/\n--- .*\n/\n--- \/dev\/null\n/;
} elsif ($start_plus eq 0) {
$current_file =~ s/\n\+\+\+ .*\n/\n+++ \/dev\/null\n/;
}
}
# This function is called whenever there is possibly a hunk to print.
# Nothing is printed if no '+' or '-' lines are left.
# Otherwise, if the file header was not yet shown, it does so now.
sub flush_hunk {
if (($plus > 0 || $minus > 0) && $current_hunk ne '') {
if ($current_file ne "") {
print $current_file;
$current_file = "";
}
$minus += $space;
$plus += $space;
print "\@\@ -$start_minus,$minus "
. "+" . ($start_plus - $start_plus_adjust)
. ",$plus \@\@\n";
print $current_hunk;
$current_hunk = '';
}
}
# This adds a line to the current hunk and updates $space, $plus or $minus
sub add_line {
my $line = $_[0];
$current_hunk .= $line;
if ($line =~ /^ /) {
$space++;
} elsif ($line =~ /^\+/) {
$plus++;
} elsif ($line =~ /^-/) {
$minus++;
} elsif ($line =~ /^\\/) {
# do nothing
} else {
die "Unexpected line: $line";
}
}
# This function splits the current hunk into the part before the current
# line, and the part after the current line.
sub skip_line {
my $line = $_[0];
if ($start_minus == 0) {
# This patch adds a new file, just ignore that line
return;
} elsif ($start_plus == 0) {
# This patch removes a file, so include the line nevertheless
add_line $_;
return;
}
flush_hunk;
if ($line =~ /^-/) {
$minus++;
} elsif ($line =~ /^\+/) {
$plus++;
$start_plus_adjust++;
}
init_hunk "@@ -" . ($start_minus + $minus + $space)
. " +" . ($start_plus + $plus + $space)
. " @@\n";
}
$simple_keyword = "Id|Revision|Author|Date|Source|Header";
# This is the main loop
sub check_file {
$_ = $_[0];
$current_file = $_;
$start_plus_adjust = 0;
while (<>) {
if (/^\@\@/) {
last;
}
$current_file .= $_;
}
init_hunk $_;
# check hunks
while (<>) {
if ($before_log) {
if (!/\+.*\$Log.*\$/) {
add_line $before_log;
} else {
skip_line $before_log;
}
$before_log = '';
}
if ($after_log) {
if (!/-.*\$Log.*\$/) {
add_line $after_log;
} else {
skip_line $after_log;
}
$after_log = '';
}
if ($skip_logs) {
if (/^\+/) {
skip_line $_;
$skip_logs = 1;
} else {
$skip_logs = 0;
if (/^ *\*$/) {
$after_log = $_;
}
}
} elsif (/^\+.*\$($simple_keyword).*\$/) {
skip_line $_;
} elsif (/^\@\@.*/) {
flush_hunk;
init_hunk $_;
} elsif (/^diff/) {
flush_hunk;
return;
} elsif (/^-.*\$($simple_keyword).*\$/) {
# fake new hunk
skip_line $_;
} elsif (/^\+ *\*$/) {
$before_log = $_;
} elsif (/^([- \+]).*\$Log.*\$/) {
skip_line $_;
$skip_logs = 1;
} else {
add_line $_;
}
}
}
# This loop just shows everything before the first diff, and then hands
# over to check_file whenever it sees a line beginning with "diff".
while (<>) {
if (/^diff/) {
do {
check_file $_;
} while(/^diff/);
} else {
printf $_;
}
}
flush_hunk;
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-24 1:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <9e4733910707231743w759afabfvd43045ad2e2eba5a@mail.gmail.com>
On 7/23/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Thanks for working on this. I'd like to see it added to git toolkit.
> This diff is way easier to read now. I can see that it has SPI support
> backported from some future version.
>
> But... it still has some problems.
> For the phytec patch it's not getting the $Log changes in the qlogic
> files right.
>
> I'm checking the output diff line by line for problems. It's down to
> 11,528 lines from 88,787. That's a lot of junk removed, I'll have to
> make sure it isn't removing too much.
I forgot about newly added files, looks like only 20,000 lines of CVS noise.
The phytec patch has several ia64 files added to it, those are obvious
not part of the support and an ARM9 processor. Never noticed those
before.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-24 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707231933030.14781@racer.site>
Thanks for working on this. I'd like to see it added to git toolkit.
This diff is way easier to read now. I can see that it has SPI support
backported from some future version.
But... it still has some problems.
For the phytec patch it's not getting the $Log changes in the qlogic
files right.
I'm checking the output diff line by line for problems. It's down to
11,528 lines from 88,787. That's a lot of junk removed, I'll have to
make sure it isn't removing too much.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Nicolas Pitre @ 2007-07-24 0:36 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Al Viro, Linus Torvalds, Jan Engelhardt, Paul Mundt, Jon Smirl,
Git Mailing List, lkml
In-Reply-To: <46A54406.8020605@zytor.com>
On Mon, 23 Jul 2007, H. Peter Anvin wrote:
> Nicolas Pitre wrote:
> >
> > I have sanitized .tgz files that I use to stuff a Git repo with. I
> > recall that some of them were reconstructed through patching an earlier
> > or later kernel version because the original ones were corrupted. Some
> > patches were retrieved from other archival sites, etc. Then the result
> > was
> > cross checked with summary lists like this one:
> >
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.1/1684.html
> >
> > This was a while ago so I don't remember the exact steps, but that
> > wasn't always trivial.
> >
>
> Then there is 0.95a, 0.95c and 0.95c+, which as far as I know only ever
> existed as 0.95 + patches posted to alt.os.linux.
Indeed, already got those.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Robin Rosenberg @ 2007-07-24 0:23 UTC (permalink / raw)
To: Simon 'corecode' Schubert
Cc: Junio C Hamano, Jason Sewall, git, raa.lkml
In-Reply-To: <46A45EF4.9090305@fs.ei.tum.de>
måndag 23 juli 2007 skrev Simon 'corecode' Schubert:
> Junio C Hamano wrote:
> > It may be that we may want to fix this inside cvsexportcommit
> > itself, instead of working it around in the tests. If somebody
> > tries to push more than one commit from git using two
> > cvsexportcommit in a row, he would need to make sure that the
> > second run happens one or more seconds after the first run,
> > otherwise he will see the exact corruption in real life.
>
> Ah, now I see the problem. The timestamp in the CVS/Entries is the same (because it only has second granularity),
> so cvs commit won't consider it as changed.
>
> That's the reason why CVS usually waits until the second turns after a "update" (obviously not after a "commit").
> So we could either turn back the timestamp in the Entries file (ugly) or simply wait until the second turns. Given
> the overall cvs performance, this won't be a big issue, I guess.
>
> cheers
> simon
>
CVS sleeps after commit here. Can we bisect it? I have 1.12.3 (mandriva). The patch below I think
would work around the problem, rather than trying to fix the test. but I'd like to have the last CVS
revision where it does not work for the patch comment
Since the sleep is per invocation of cvsexportcommit it won't hurt too much since it is rarely invoked
on a huge number of git commits.
-- robin
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d6ae99b..6377408 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -277,6 +277,10 @@ if ($opt_c) {
# clean up
unlink(".cvsexportcommit.diff");
+# timestamp problems. Invoking this command on a machine that is too fast may result in
+# CVS not recognizing changed because the timestamp is unchanged
+sleep(1);
+
sub usage {
print STDERR <<END;
Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-m msgprefix] [ parent ] commit
^ permalink raw reply related
* Re: Git tree for old kernels from before the current tree
From: H. Peter Anvin @ 2007-07-24 0:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Al Viro, Linus Torvalds, Jan Engelhardt, Paul Mundt, Jon Smirl,
Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707231957450.6355@xanadu.home>
Nicolas Pitre wrote:
>
> I have sanitized .tgz files that I use to stuff a Git repo with. I
> recall that some of them were reconstructed through patching an earlier
> or later kernel version because the original ones were corrupted. Some
> patches were retrieved from other archival sites, etc. Then the result
> was
> cross checked with summary lists like this one:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.1/1684.html
>
> This was a while ago so I don't remember the exact steps, but that
> wasn't always trivial.
>
Then there is 0.95a, 0.95c and 0.95c+, which as far as I know only ever
existed as 0.95 + patches posted to alt.os.linux.
-hpa
^ permalink raw reply
* Re: Git tree for old kernels from before the current tree
From: Nicolas Pitre @ 2007-07-24 0:10 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, H. Peter Anvin, Jan Engelhardt, Paul Mundt,
Jon Smirl, Git Mailing List, lkml
In-Reply-To: <20070723234628.GN21668@ftp.linux.org.uk>
On Tue, 24 Jul 2007, Al Viro wrote:
> On Mon, Jul 23, 2007 at 03:06:09PM -0400, Nicolas Pitre wrote:
> > - v0.96 sources
> >
> > - v0.99.12 announcement
> >
> > - sources for v0.99.13{abcdefghij} (got k, don't know where the serie
> > ends) as well as announcements for all of them
> >
> > - all announcements for v0.99.14{a-z} except for pl14r
> >
> > - announcements for pl15c to pl15j, 1.0-pre1, and ALPHA-1.0.
> >
> > Otherwise the archive appears fairly complete with almost 3 years of
> > Linux development history captured in a 3MB pack file.
>
> Umm... IIRC, tar was unhappy with several tarballs on ftp.kernel.org.
> Do you have replacements (or instructions re combination of tar(1) options
> to make it eat them)?
I have sanitized .tgz files that I use to stuff a Git repo with. I
recall that some of them were reconstructed through patching an earlier
or later kernel version because the original ones were corrupted. Some
patches were retrieved from other archival sites, etc. Then the result
was
cross checked with summary lists like this one:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.1/1684.html
This was a while ago so I don't remember the exact steps, but that
wasn't always trivial.
Nicolas
^ permalink raw reply
* [PATCH] mailinfo: fix 'fatal: cannot convert from utf-8 to utf-8'
From: Johannes Schindelin @ 2007-07-24 0:03 UTC (permalink / raw)
To: git, gitster
For some reason, I got this error message. Maybe it does not make sense,
but then we should not really try to convert the text when it is not
necessary.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This bit me when I tried to apply the most recent Japanese
translation patch to git-gui-i18n.
builtin-mailinfo.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index a37a4ff..b4f6e91 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -529,6 +529,8 @@ static void convert_to_utf8(char *line, const char *charset)
return;
}
+ if (!strcmp(metainfo_charset, charset))
+ return;
out = reencode_string(line, metainfo_charset, charset);
if (!out)
die("cannot convert from %s to %s\n",
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* [PATCH] git am: skip pine's internal folder data
From: Johannes Schindelin @ 2007-07-24 0:02 UTC (permalink / raw)
To: git, gitster
Test if the From: line contains "Mail System Internal Data" and if
it is, skip this mail.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-am.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index bfd65dc..22d2b5c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -284,6 +284,12 @@ do
git mailinfo $keep $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
+
+ # skip pine's internal folder data
+ sed '/^$/q' < "$dotest"/info |
+ grep '^Author: Mail System Internal Data$' > /dev/null
+ && go_next && continue
+
test -s $dotest/patch || {
echo "Patch is empty. Was it split wrong?"
stop_here $this
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-23 23:57 UTC (permalink / raw)
To: Nix; +Cc: David Kastrup, git
In-Reply-To: <873azen1c7.fsf@hades.wkstn.nix>
On Tue, 24 Jul 2007, Nix wrote:
>
> On 23 Jul 2007, Linus Torvalds spake thusly:
> > So practically speaking, you want to track the *minimal* possible state,
> > not the maximal one.
>
> I think it depends on your use case. For source code and indeed anything
> with heavy merges, this is true
Yes, very obviously. Git is targeted towards source code and working in a
distributed manner across a very wide variety of users and setups, while
something that would be more targeted towards a special scenario and much
stricter usage would find that the "minimum" set is much bigger, and might
well include ACL's and usr information.
> but I'm increasingly using git as a sort of `merged historical tar' to
> store images of entire random filesystem trees across time, and gaining
> the benefit of the packer's lovely space-efficiency as well (doing this
> with svn would be a lost cause, twice the space usage before you even
> think about the repository). And in that case, preserving everything you
> can makes sense.
On the other hand, almost all the space-efficiency comes from things that
delta well, and change quickly. That includes the file data itself (and
very much the tree contents), but it doesn't necessarily include things
like permissions and user information - mainly because that doesn't
actually delta at all (not because it can't, but because it hardly ever
changes, and when it does change, it often changes all over the map).
To make an example of your "tar" situation: if you want to be space-
efficient in a tar-like setting, you should *not* make user information be
something that is per-file at all! Why? Because in 99% of all tar-files,
there is a single user name.
So even your usage *may* actually be much better off using git as a "data
backend", and using something totally different for "user/group"
information. Yes, you'd have to make a "shim layer" on top of git to hide
the fact that the user information is handled separately, but that
shouldn't be that hard per se.
> (Perhaps what I should be doing is tarring the directory tree up and
> storing the *tarball* in git. I'll try that and see what it does to pack
> sizes. These are version-controlled backups of my mother's magnum opus
> in progress so you can understand that I don't want to destroy them
> accidentally: I'd never hear the end of it! ;) )
You don't want to do this.
There's a few reasons, but the two big ones are:
- the git delta logic is strictly a "single delta base" thing.
Yes, git would be able to find the delta's between two tar-files (as
long as you don't compress them), and express one tar-file in terms of
the other, and it would probably save a fair amount of disk.
But it would not be able to do _nearly_ as well as it can if you store
individual files, and let git just find the best delta per-file (and
not just "one delta base for the whole tar-ball")
- git is very much optimized for "many small files". Yes, you can check
in large files, and it works fine, but quite frankly, all the design
and heavy optimizations have been about having trees with tens of
thousands of files, but the files individually reasonably small.
A lot of the speed advantages of git come from efficiently pruning away
whole sub-directory structures, for example, and not even touching the
data at all!
So if you track just one file that changes in every version, all the
things that make git fly are basically disabled, and you won't take
full advantage of what git does.
> Yes indeed: that's why I proposed doing this using a couple of new hooks
> driving entirely optional permissions-preservation stuff. Most use cases
> really won't want to track this, so this sort of stuff shouldn't impose
> upon the git core or upon anyone who doesn't want it. (However, the
> ability to have alternative file merging strategies *may* be useful
> elsewhere, perhaps.)
The ".gitattributes" file really could be used for some of that. Using it
to track ownership and full permissions would not be impossible, and it
could have interesting semantics (especially as .gitattibutes is path
pattern based - so you could literally do a "user" attribute, and say that
everything in a particular subdirectory is owned by a particular user).
That wouldn't be UNIX-like semantics, of course, but it can be very useful
for certain things.
Taking an example of something totally independent of git, look at how
"udev" handles permissions, for example. In situations like that, static
user information is useless, and it actually ends up setting up modes and
ownership based on name-based patterns rather than having each file have a
permission/user (because individual files appear and disappear, the
name-based patterns are the things that matter).
So if you *just* want to track a regular filesystem layout, that's not the
right thing, but "udev" does show an example of a totally different way of
describing ownership and permissions, and one which wouldn't actually be
at all foreign to git.
Linus
^ 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