* Re: testsuite problems
From: René Scharfe @ 2007-09-18 14:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070917220408.GG19019@genesis.frugalware.org>
Miklos Vajna schrieb:
> On Mon, Sep 17, 2007 at 11:50:32PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> The failing tests check ZIP file creation, not tar file creation.
>> Perhaps your unzip command works a bit differently from Info-ZIP's?
>
> $ zip -v
> Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
> This is Zip 2.32 (June 19th 2006), by Info-ZIP.
>
> should this version be ok?
Info-ZIP zip and unzip are two different programs, each with their
own version numbers.
>> Also, what is the difference between t/trash/a and t/trash/d/a after
>> running the test script (that's what test 21 is comparing)?
>
> $ diff -Naur t/trash/a t/trash/d/a
> diff -Naur t/trash/a/l1 t/trash/d/a/l1
> --- t/trash/a/l1 2007-09-17 23:10:03.000000000 +0200
> +++ t/trash/d/a/l1 2007-09-17 23:10:03.000000000 +0200
> @@ -1 +1 @@
> -simple textfile
> +a
> \ No newline at end of file
Ah! l1 is a symlink to a. The target of a symlink is stored as file
content in a ZIP archive and marked with a special flag. An unzipper
that doesn't understand this flag would create a file containing the
link target's name instead of a symlink pointing to the target.
The unzip on my system says:
$ unzip -v
UnZip 5.52 of 28 February 2005, by Ubuntu. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) for Unix (Linux ELF) on Mar 31 2007.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.9 of 05 May 2000]
I suspect you need SET_DIR_ATTRIB in order to extract symlinks.
René
^ permalink raw reply
* Re: [PATCH 3/5] Correct handling of branch.$name.merge in builtin-fetch
From: Daniel Barkalow @ 2007-09-18 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070918085453.GC5390@spearce.org>
On Tue, 18 Sep 2007, Shawn O. Pearce wrote:
> My prior bug fix for git-push titled "Don't configure remote "." to
> fetch everything to itself" actually broke t5520 as we were unable
> to evaluate a branch configuration of:
>
> [branch "copy"]
> remote = .
> merge = refs/heads/master
>
> as remote "." did not have a "remote...fetch" configuration entry to
> offer up refs/heads/master as a possible candidate available to be
> fetched and merged. In shell script git-fetch and prior to the above
> mentioned commit this was hardcoded for a url of "." to be the set of
> local branches.
Ah, right. When you removed that, I remembered there being some reason I'd
put it in, but I couldn't remember what it was, and knew you'd turn it up
before I would.
> Chasing down this bug led me to the conclusion that our prior behavior
> with regards to branch.$name.merge was incorrect. In the shell script
> based git-fetch implementation we only fetched and merged a branch if
> it appeared both in branch.$name.merge *and* in remote.$r.fetch, where
> $r = branch.$name.remote. In other words in the following config file:
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = refs/heads/master:refs/remotes/origin/master
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "pu"]
> remote = origin
> merge = refs/heads/pu
>
> Attempting to run `git pull` while on branch "pu" would always give
> the user "Already up-to-date" as git-fetch did not fetch pu and thus
> did not mark it for merge in .git/FETCH_HEAD. The configured merge
> would always be ignored and the user would be left scratching her
> confused head wondering why merge did not work on "pu" but worked
> fine on "master".
>
> If we are using the "default fetch" specification for the current
> branch and the current branch has a branch.$name.merge configured
> we now union it with the list of refs in remote.$r.fetch. This
> way the above configuration does what the user expects it to do,
> which is to fetch only "master" by default but when on "pu" to
> fetch both "master" and "pu".
And store master, but don't store pu. This looks like the right solution
to me.
> This uncovered some breakage in the test suite where old-style Cogito
> branches (.git/branches/$r) did not fetch the branches listed in
> .git/config for merging and thus did not actually merge them if the
> user tried to use `git pull` on that branch. Junio and I discussed
> it on list and felt that the union approach here makes more sense to
> DWIM for the end-user than silently ignoring their configured request
> so the test vectors for t5515 have been updated to include for-merge
> lines in .git/FETCH_HEAD where they have been configured for-merge
> in .git/config.
Ah, okay. This is one of the things I'd changed, to make it obey the merge
configuration (which meant that it didn't get anything to merge), which
had previously been ignored. So there's nothing that's expecting exactly
the behavior that you're changing away from, except for that test case.
This whole series looks good to me.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 7/7] Implement git commit as a builtin command.
From: Kristian Høgsberg @ 2007-09-18 15:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181453220.28586@racer.site>
On Tue, 2007-09-18 at 14:58 +0100, Johannes Schindelin wrote:
> Hi,
>
> very nice!
>
> Four nits, though, and a half:
>
> - it would be nicer to put the option parsing it option.[ch] (you would
> also need to pass the usage line then, instead of hardwiring it to
> "git_commit_usage"),
Yes, good point.
> - it seems more logical to me to call it "parse_option()" than
> "scan_options()", since that is what it does,
Yup.
> - you might want to rename OPTION_NONE to OPTION_BOOLEAN, and maybe even
> allow "--no-<option>" in that case for free,
Agree.
> - wt_status_prepare() could take a parameter "index_file", which would
> default to git_path("index") when passed as NULL, and
Yeah, the way I did it, I preserved the API, but that's not really a
concern, I guess.
> - launch_editor() is defined in builtin-tag.c, which is not part of the
> library, and therefore it would be technically more correct to either
> move the function to editor.c (my preferred solution), or declare it in
> builtin.h instead of strbuf.h.
Yeah, and we should move the stripspace code there too. Or maybe we
should rename that strbuf_stripspace and put it in strbuf.c.
> As you can see, my nits are really minor, which means that I am pretty
> happy with your work!
Great, I hope we can get it in soon :)
Kristian
^ permalink raw reply
* Latest builtin-commit series
From: Kristian Høgsberg @ 2007-09-18 15:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Hi,
I sent out a new builtin-commit patch series last night, and figured I
should have written a cover letter to describe the changes there.
Better late than never:
* rebase to Pierres strbuf changes. Note, there is still some
strbuf tweaking required, to let stripspace work on a strbuf.
Also, I changed the semantics of stripspace to always add a
newline if the last line doesn't have one. I believe the
current odd semantics (always remove the last newline) comes
from not being able to easily add a newline, but now that it's a
strbuf, that's easy.
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 15:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070918132940.GC12120@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Tue, Sep 18, 2007 at 09:29:40AM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > 2) does this worth adding to the documentation? maybe to a .txt under
> > Documentation/howto? or to git-submodule.txt?
>
> Could you add it as a new chapter to user-manual.txt (probably just
> after the "git concepts" chapter), and then add links to that chapter
> from git-submodule(1) and gitmodules(5)?
hm, i did not know about the wiki page Michael created yesterday. so i
don't know what's the rule in case: if something is already in the wiki
then should or should not it be added to the 'official docs'?
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Latest builtin-commit series
From: Kristian Høgsberg @ 2007-09-18 15:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Hi,
I sent out a new builtin-commit patch series last night, and figured I
should have written a cover letter to describe the changes there.
Better late than never:
* rebase to Pierres strbuf changes. Note, there is still some
strbuf tweaking required, to let stripspace work on a strbuf.
Also, I changed the semantics of stripspace to always add a
newline if the last line doesn't have one. I believe the
current odd semantics (always remove the last newline) comes
from not being able to easily add a newline, but now that it's a
strbuf, that's easy.
* Fixing the last bug that caused trouble in the test suite: even
if run_status says there's nothing to commit, proceed if we're
doing a merge.
* Set the test suite default editor to '/bin/true' instead of ':'.
Since we're not exec'ing the editor from shell anymore, ':'
won't work. Maybe we should special case ':' in launch_editor
or perhaps make launch_editor use system(3). Not sure.
* The first few patches are good to go, and if we can get them
committed to next, we can focus on the builtin-commit patch.
Specifically:
0001-Enable-wt-status-output-to-a-given-FILE-pointer.patch
0002-Enable-wt-status-to-run-against-non-standard-index-f.patch
0003-Introduce-entry-point-for-launching-add-interactive.patch
0004-Clean-up-stripspace-a-bit-use-strbuf-even-more.patch
0005-Add-strbuf_read_file.patch
0006-Export-rerere-and-launch_editor.patch
(edit our "and launch_editor" from the title)
should all be fine and easy to review, whereas
0007-Implement-git-commit-as-a-builtin-command.patch
will probably need some careful reviewing. That said, it is
feature complete, the code is nice enough and it passes the test
suite. It's just a very important part of git :)
cheers,
Kristian
(sorry about the duplicate mail)
^ permalink raw reply
* Re: State of Perforce importing.
From: David Brown @ 2007-09-18 15:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git
In-Reply-To: <46EF7DD1.9090301@vilain.net>
On Tue, Sep 18, 2007 at 07:27:13PM +1200, Sam Vilain wrote:
>I'm pretty close to giving a newer one a spin, that actually imports
>from the raw perforce back-end files without needing the perforce
>server. I am hoping that this should give a very clean import and will
>be very fast and efficient, sending files that share ancestry to gfi in
>sequence so that the on-the-fly delta system works.
Unfortunately, this isn't something I'm going to be able to use. The
Perforce server will remain live, and resides on a machine I don't have
access to.
>It could possibly be adapted to use the p4 client (though I'd expect
>that to be relatively slow per-revision), and possibly be extended to be
>bidirectional as all of the upstream change number information is
>recorded, a la git-svn.
I was able to get 'git-p4' to work a lot better by using @all, but it still
has some problems, at least bad interactions with P4.
- It doesn't use any client spec. Our P4 server space is a complete
mismash and has to be fixed up to get a sane directory layout. For
example, some revisions have hundred-MB tar files sitting in the root
directory and I don't want that in the repo. I also need to exclude
directories, and in some cases completely rearrange the directory
layout.
- Our P4 server is set to be case insensitive. 'git-p4' ignores paths
that come back from the server that are specified using a different
case. Unfortunately, this means that a handful of files just get
randomly dropped from each revision.
I tried importing a client path instead of a depot path, but the names
that come back from 'p4 files' are depot based so none ever match. I
end up with a nice revision history of entirely empty trees.
I'm probably going to end up writing an importer that uses an actual client
workspace to let Perforce do the client mapping. I'm also going to have to
put some work into some code to clean up the log messages, since most of
our changes have as a first line "New Features:", which makes for a rather
uninformative shortlog.
But, I did learn about 'p4 -G' from git-p4 so that will help in getting
information from the repository.
Thanks,
David
^ permalink raw reply
* Re: testsuite problems
From: Miklos Vajna @ 2007-09-18 15:52 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <46EFE75D.7000805@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On Tue, Sep 18, 2007 at 04:57:33PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Info-ZIP zip and unzip are two different programs, each with their
> own version numbers.
ah, my bad.
> >> Also, what is the difference between t/trash/a and t/trash/d/a after
> >> running the test script (that's what test 21 is comparing)?
> >
> > $ diff -Naur t/trash/a t/trash/d/a
> > diff -Naur t/trash/a/l1 t/trash/d/a/l1
> > --- t/trash/a/l1 2007-09-17 23:10:03.000000000 +0200
> > +++ t/trash/d/a/l1 2007-09-17 23:10:03.000000000 +0200
> > @@ -1 +1 @@
> > -simple textfile
> > +a
> > \ No newline at end of file
>
> Ah! l1 is a symlink to a. The target of a symlink is stored as file
> content in a ZIP archive and marked with a special flag. An unzipper
> that doesn't understand this flag would create a file containing the
> link target's name instead of a symlink pointing to the target.
>
> The unzip on my system says:
>
> $ unzip -v
> UnZip 5.52 of 28 February 2005, by Ubuntu. Original by Info-ZIP.
>
> Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
> see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
>
> Compiled with gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) for Unix (Linux ELF) on Mar 31 2007.
>
> UnZip special compilation options:
> ACORN_FTYPE_NFS
> COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
> SET_DIR_ATTRIB
> TIMESTAMP
> USE_EF_UT_TIME
> USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
> USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
> VMS_TEXT_CONV
> WILD_STOP_AT_DIR
> [decryption, version 2.9 of 05 May 2000]
>
> I suspect you need SET_DIR_ATTRIB in order to extract symlinks.
$ unzip -v
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler.
Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
details.
Latest sources and executables are at
ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 for Unix (Linux ELF) on May 9 2007.
UnZip special compilation options:
ASM_CRC
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
[decryption, version 2.9 of 05 May 2000]
if i'm not wrong then these options should be ok. :S
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [rfc] git submodules howto
From: J. Bruce Fields @ 2007-09-18 15:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918154734.GP19019@genesis.frugalware.org>
On Tue, Sep 18, 2007 at 05:47:34PM +0200, Miklos Vajna wrote:
> On Tue, Sep 18, 2007 at 09:29:40AM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > 2) does this worth adding to the documentation? maybe to a .txt under
> > > Documentation/howto? or to git-submodule.txt?
> >
> > Could you add it as a new chapter to user-manual.txt (probably just
> > after the "git concepts" chapter), and then add links to that chapter
> > from git-submodule(1) and gitmodules(5)?
>
> hm, i did not know about the wiki page Michael created yesterday. so i
> don't know what's the rule in case: if something is already in the wiki
> then should or should not it be added to the 'official docs'?
It should. We also need submodules documentation for the "official"
documentation.
If you want to base that work off of that wiki page instead of your
original email, that's fine. Just make sure you get Michael's
permission first.
--b.
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 16:11 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Michael Smith
In-Reply-To: <20070918155529.GD18476@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
[ adding Michael to CC. ]
On Tue, Sep 18, 2007 at 11:55:29AM -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > hm, i did not know about the wiki page Michael created yesterday. so i
> > don't know what's the rule in case: if something is already in the wiki
> > then should or should not it be added to the 'official docs'?
>
> It should. We also need submodules documentation for the "official"
> documentation.
okay.
> If you want to base that work off of that wiki page instead of your
> original email, that's fine. Just make sure you get Michael's
> permission first.
Michael, i think the wiki version is better as my example does not
contain any extra to the wiki version. is it ok if i would send a patch
to include your work in the official docs?
i'm not sure how should i mention you, maybe in the commit message?
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: testsuite problems
From: René Scharfe @ 2007-09-18 17:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Junio C Hamano
In-Reply-To: <20070918155214.GQ19019@genesis.frugalware.org>
Miklos Vajna schrieb:
> $ unzip -v
> UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler.
> Send
> bug reports using http://www.info-zip.org/zip-bug.html; see README for
> details.
>
> Latest sources and executables are at
> ftp://ftp.info-zip.org/pub/infozip/ ;
> see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
>
> Compiled with gcc 4.1.2 for Unix (Linux ELF) on May 9 2007.
>
> UnZip special compilation options:
> ASM_CRC
> COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
> SET_DIR_ATTRIB
> TIMESTAMP
> USE_EF_UT_TIME
> USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
> USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
> VMS_TEXT_CONV
> [decryption, version 2.9 of 05 May 2000]
>
> if i'm not wrong then these options should be ok. :S
Well, looks OK to me at least. The Debian package (and thus Ubuntu's
too) has a symlink related fix, from Christian Spieler, no less:
http://packages.debian.org/changelogs/pool/main/u/unzip/unzip_5.52-9/changelog
http://ftp.de.debian.org/debian/pool/main/u/unzip/unzip_5.52-9.diff.gz
Perhaps this is missing from your version?
Let's check if the ZIP file on our machines match. In order for
this to succeed we need to first take out any randomness. Please
apply the patch at the end of the mail, which sets GIT_AUTHOR_DATE
to a fixed value instead of using the current time, run the test
and then this:
$ md5sum t/trash/d.zip # run just after t5000-tar-tree.sh
35f6183b7816960cadfc6cac74530640 t/trash/d.zip
The test passes just fine here, so if the checksums match then your
unzip is most likely to blame. In this case you can work around
your problem by commenting out the "ln -s" in t5000-tar-tree.sh.
René
--- snip! ---
archive: make test repeatable
Set GIT_AUTHOR_DATE to a fixed value, just like it's already done
for GIT_COMMITTER_DATE. This makes the test repeatable, and
resulting archive files can by compared on mailing lists simply by
comparing their checksums.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 42e28ab..f341451 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -50,7 +50,7 @@ test_expect_success \
treeid=`git write-tree` &&
echo $treeid >treeid &&
git update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
- git commit-tree $treeid </dev/null)'
+ GIT_AUTHOR_DATE="2007-09-18 19:00:00" git commit-tree $treeid </dev/null)
test_expect_success \
'git archive' \
^ permalink raw reply related
* Re: State of Perforce importing.
From: Reece Dunn @ 2007-09-18 17:53 UTC (permalink / raw)
To: Sam Vilain, Git
In-Reply-To: <20070918154918.GA19106@old.davidb.org>
On 18/09/2007, David Brown <git@davidb.org> wrote:
> On Tue, Sep 18, 2007 at 07:27:13PM +1200, Sam Vilain wrote:
>
> >I'm pretty close to giving a newer one a spin, that actually imports
> >from the raw perforce back-end files without needing the perforce
> >server. I am hoping that this should give a very clean import and will
> >be very fast and efficient, sending files that share ancestry to gfi in
> >sequence so that the on-the-fly delta system works.
>
> Unfortunately, this isn't something I'm going to be able to use. The
> Perforce server will remain live, and resides on a machine I don't have
> access to.
I use git-p4 in the same way. The best approach would be to have both
tools and to use whichever one best matches your needs.
> >It could possibly be adapted to use the p4 client (though I'd expect
> >that to be relatively slow per-revision), and possibly be extended to be
> >bidirectional as all of the upstream change number information is
> >recorded, a la git-svn.
>
> I was able to get 'git-p4' to work a lot better by using @all, but it still
> has some problems, at least bad interactions with P4.
I have also seen this.
> - It doesn't use any client spec. Our P4 server space is a complete
> mismash and has to be fixed up to get a sane directory layout. For
> example, some revisions have hundred-MB tar files sitting in the root
> directory and I don't want that in the repo. I also need to exclude
> directories, and in some cases completely rearrange the directory
> layout.
The directory exclusion you could do the other way, if git-p4
supported multiple directory paths.
The main issues with using client workspaces is that they require you
to use `p4 sync`, whereas git-p4 uses `p4 print` and that they may
change as the repository changes, but Perforce does not track these
changes.
That said, something like what workspaces are doing (allowing you to
specify multiple paths and where they are to go) would be useful.
> - Our P4 server is set to be case insensitive. 'git-p4' ignores paths
> that come back from the server that are specified using a different
> case. Unfortunately, this means that a handful of files just get
> randomly dropped from each revision.
It is worse than this. If you have:
p4 integrate foo Foo
p4 delete foo
then git-p4 will completely remove the file foo from the repository! I
reported this a while back, but did not get a reply.
This is something I want to fix, as doing an '@all', rebase or sync is
broken in this case when dealing with renamed files as above when
importing a repository on a case insensitive system.
The alternative is to do the importing from Perforce on a Linux
machine and then clone/pull/rebase from it on a Windows machine.
> I tried importing a client path instead of a depot path, but the names
> that come back from 'p4 files' are depot based so none ever match. I
> end up with a nice revision history of entirely empty trees.
Ideally, git-p4 should bail out here with an error about the path
needing to be specified as a depot path.
> I'm probably going to end up writing an importer that uses an actual client
> workspace to let Perforce do the client mapping.
As eluded to above, I want to extend git-p4 to support a
workspace-like importer map file to use instead of a specific depot
path (with a single depot path being supported as well for backward
compatibility and simplicity if the repository you are importing from
has a simple layout).
There is no need to create yet another Perforce importing tool, git-p4
works well in most cases. If we focus on improving git-p4, extending
it to support the functionality mentioned here, fix the issues that
there are with it, then that will be more beneficial to the community
as they will not have to learn another tool with a different set of
bugs and issues.
> I'm also going to have to
> put some work into some code to clean up the log messages, since most of
> our changes have as a first line "New Features:", which makes for a rather
> uninformative shortlog.
I would not do that. It is a good idea to keep the original log
messages, even if it does make for an uninformative shortlog. Look at
some of the CVS/SVN imported logs!
- Reece
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Michael Smith @ 2007-09-18 18:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918161112.GR19019@genesis.frugalware.org>
On Tue, 18 Sep 2007, Miklos Vajna wrote:
> Michael, i think the wiki version is better as my example does not
> contain any extra to the wiki version. is it ok if i would send a patch
> to include your work in the official docs?
Thanks, that would be great.
> i'm not sure how should i mention you, maybe in the commit message?
Maybe signed-off-by is appropriate? Otherwise, don't worry about it.
Mike
^ permalink raw reply
* Re: [EGIT PATCH] Add feature and plugin.
From: Robin Rosenberg @ 2007-09-18 19:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Ben Konrath, git
In-Reply-To: <46EF81BD.7010609@op5.se>
tisdag 18 september 2007 skrev Andreas Ericsson:
> Ben Konrath wrote:
> > Hi,
> >
> > I made a feature and associated branding plugin for Egit. Including
> > these two plugins allows us to build Egit for Fedora but it also makes
> > it easy to create an update site for Egit.
>
>
>
> > These two plugins also add an
> > entry for Egit in Help -> About Eclipse -> Feature Details.
> >
>
> When you start writing "also" in your commit messages, it's a pretty good
> sign that you should have made many smaller commits rathern than one large.
Seems it is a hint about what can be done later. That's generally something to
put in cover messages.
The ability to create an update site encouraged me to create one too. It makes
updating all my eclipses much easier. Thanks Ben.
I've merged and pushed the earlier version before receiving this version whose
content comes as a follow up commit.
-- robin
^ permalink raw reply
* Re: testsuite problems
From: Miklos Vajna @ 2007-09-18 19:35 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Junio C Hamano
In-Reply-To: <46F0054F.8060503@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
On Tue, Sep 18, 2007 at 07:05:19PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Well, looks OK to me at least. The Debian package (and thus Ubuntu's
> too) has a symlink related fix, from Christian Spieler, no less:
>
> http://packages.debian.org/changelogs/pool/main/u/unzip/unzip_5.52-9/changelog
> http://ftp.de.debian.org/debian/pool/main/u/unzip/unzip_5.52-9.diff.gz
>
> Perhaps this is missing from your version?
that was the problem. using vanilla unzip works fine, or after applying
the two security fixes a small patch is needed.
for the archives, here is the small patch that fixed the problem:
http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=commit;h=c27277b2354b9ed4d6b0fbdb988643ad203f73c8
so the problem is not git-related
sorry for the noise and thanks for your help :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Problem with merge when renaming
From: David Euresti @ 2007-09-18 20:34 UTC (permalink / raw)
To: git
Hi,
I think I found a problem when you move a file into a directory of the
same name. Here's what I did.
In a repository I created a directory with a file in it. Commit it.
Then I move the file into a tmp name, make a directory with that name,
and move it into the directory.
git-mv dir/foo dir/foo.bin
mkdir dir/foo
git-mv dir/foo.bin dir/foo/foo.bin
Then in another branch I make a completely unrelated change. I create
a file in another directory.
If I try to merge in the changes from the other branch or if the other
branch tries to merge in these changes I get this error:
dir/foo/foo.bin: unmerged (257cc5642cb1a054f08cc83f2d943e56fd3ebe99)
fatal: git-write-tree: error building trees
Merge with strategy recursive failed.
This is the script I've been using
#!/bin/bash
#
# Make sure it's all clean
rm -rf git-repo
mkdir git-repo
pushd git-repo
git-init
mkdir dir
git-add dir
pushd dir
echo foo > foo
git-add foo
popd
git-commit -a -m "one"
popd
# Developer A moves file into dir of same name
pushd git-repo
git-checkout -b branch-a
git-mv dir/foo dir/foo.bin
mkdir dir/foo
git-mv dir/foo.bin dir/foo/foo.bin
git-commit -a -m "File renamed"
git-checkout master
popd
# Developer B makes completely unrelated changes.
pushd git-repo
git-checkout -b branch-b
echo baz > foo.txt
echo bar > bar.txt
git-add bar.txt
git-add foo.txt
git-commit -a -m "unrelated changes"
git-checkout master
popd
# Developer A wants to merge changes from B
pushd git-repo
#git-merge branch-a
echo
#git-merge branch-b
#popd
^ permalink raw reply
* Re: [PATCH] instaweb: added support Ruby's WEBrick server
From: Eric Wong @ 2007-09-18 20:40 UTC (permalink / raw)
To: mike dalessio; +Cc: git
In-Reply-To: <20070918121634.E8EFF814635@cyrano>
mike dalessio <mike@csa.net> wrote:
> running the webrick server with git requires Ruby and Ruby's YAML and
> Webrick libraries (both of which come standard with Ruby). nice for
> single-user standalone invocations.
>
> the --httpd=webrick option generates a ruby script on the fly to read
> httpd.conf options and invoke the web server via library call. this
> script is placed in the .git/gitweb directory. it also generates a
> shell script in a feeble attempt to invoke ruby in a portable manner,
> which assumes that 'ruby' is in the user's $PATH.
>
> Signed-off-by: Mike Dalessio <mike@csa.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> Documentation/git-instaweb.txt | 3 +-
> git-instaweb.sh | 44 +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
> index cec60ee..914fc4c 100644
> --- a/Documentation/git-instaweb.txt
> +++ b/Documentation/git-instaweb.txt
> @@ -27,7 +27,8 @@ OPTIONS
> The HTTP daemon command-line that will be executed.
> Command-line options may be specified here, and the
> configuration file will be added at the end of the command-line.
> - Currently, lighttpd and apache2 are the only supported servers.
> + Currently, lighttpd, apache2 and webrick are the only supported
> + servers.
> (Default: lighttpd)
>
> -m|--module-path::
> diff --git a/git-instaweb.sh b/git-instaweb.sh
> index b79c6b6..803a754 100755
> --- a/git-instaweb.sh
> +++ b/git-instaweb.sh
> @@ -37,7 +37,9 @@ start_httpd () {
> else
> # many httpds are installed in /usr/sbin or /usr/local/sbin
> # these days and those are not in most users $PATHs
> - for i in /usr/local/sbin /usr/sbin
> + # in addition, we may have generated a server script
> + # in $fqgitdir/gitweb.
> + for i in /usr/local/sbin /usr/sbin $fqgitdir/gitweb
> do
> if test -x "$i/$httpd_only"
> then
> @@ -137,6 +139,43 @@ GIT_DIR="$fqgitdir"
> export GIT_EXEC_PATH GIT_DIR
>
>
> +webrick_conf () {
> + # generate a standalone server script in $fqgitdir/gitweb.
> + cat > "$fqgitdir/gitweb/$httpd.rb" <<EOF
> +require 'webrick'
> +require 'yaml'
> +options = YAML::load_file(ARGV[0])
> +options[:StartCallback] = proc do
> + File.open(options[:PidFile],"w") do |f|
> + f.puts Process.pid
> + end
> +end
> +options[:ServerType] = WEBrick::Daemon
> +server = WEBrick::HTTPServer.new(options)
> +['INT', 'TERM'].each do |signal|
> + trap(signal) {server.shutdown}
> +end
> +server.start
> +EOF
> + # generate a shell script to invoke the above ruby script,
> + # which assumes _ruby_ is in the user's $PATH. that's _one_
> + # portable way to run ruby, which could be installed anywhere,
> + # really.
> + cat > "$fqgitdir/gitweb/$httpd" <<EOF
> +#! /bin/sh
> +ruby $fqgitdir/gitweb/$httpd.rb \$*
> +EOF
> + chmod +x "$fqgitdir/gitweb/$httpd"
> +
> + cat > "$conf" <<EOF
> +:Port: $port
> +:DocumentRoot: "$fqgitdir/gitweb"
> +:DirectoryIndex: ["gitweb.cgi"]
> +:PidFile: "$fqgitdir/pid"
> +EOF
> + test "$local" = true && echo ':BindAddress: "127.0.0.1"' >> "$conf"
> +}
> +
> lighttpd_conf () {
> cat > "$conf" <<EOF
> server.document-root = "$fqgitdir/gitweb"
> @@ -237,6 +276,9 @@ case "$httpd" in
> *apache2*)
> apache2_conf
> ;;
> +webrick)
> + webrick_conf
> + ;;
> *)
> echo "Unknown httpd specified: $httpd"
> exit 1
> --
> 1.5.2.5
>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Mention that 'push .. master' is in explicit form master:refs/heads/master
From: Junio C Hamano @ 2007-09-18 20:54 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <wsuomgyu.fsf@blue.sea.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
> ---
> Documentation/git-push.txt | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 7b8e075..71ac450 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -105,7 +105,9 @@ git push origin master::
> Find a ref that matches `master` in the source repository
> (most likely, it would find `refs/heads/master`), and update
> the same ref (e.g. `refs/heads/master`) in `origin` repository
> - with it.
> + with it. The following would be exactly same command:
> +
> + git push origin master:refs/heads/master
They _might_ be exactly the same.
The reason people often explicitly write
$ git push $URL refs/heads/master:refs/heads/master
in their insns for newbies is because this form would not be
affected by the random factors at $URL repository (or your
repository) and will consistently get the same result.
$ git push $URL foo
may push branch head 'foo' or tag 'foo' depending on which one
you have locally. Having both is not encouraged, but spelling
the insn out explicitly as refs/heads/foo makes it clear the
command is talking about the branch even when there is a tag
with the same name.
^ permalink raw reply
* Re: [EGIT PATCH] Add feature and plugin.
From: Ben Konrath @ 2007-09-18 21:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <46EF81BD.7010609@op5.se>
On Tue, 2007-09-18 at 09:43 +0200, Andreas Ericsson wrote:
> Ben Konrath wrote:
> > Hi,
> >
> > I made a feature and associated branding plugin for Egit. Including
> > these two plugins allows us to build Egit for Fedora but it also makes
> > it easy to create an update site for Egit.
>
>
>
> > These two plugins also add an
> > entry for Egit in Help -> About Eclipse -> Feature Details.
> >
>
> When you start writing "also" in your commit messages, it's a pretty good
> sign that you should have made many smaller commits rathern than one large.
Ok thanks. I think that I could have split this up into two commits.
I'll take that into consideration for future work.
Cheers, Ben
^ permalink raw reply
* Re: Latest builtin-commit series
From: Alex Riesen @ 2007-09-18 21:39 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1190129009.23692.24.camel@hinata.boston.redhat.com>
Kristian Høgsberg, Tue, Sep 18, 2007 17:23:29 +0200:
> * Set the test suite default editor to '/bin/true' instead of ':'.
> Since we're not exec'ing the editor from shell anymore, ':'
> won't work. Maybe we should special case ':' in launch_editor
> or perhaps make launch_editor use system(3). Not sure.
Special case "" (empty string)? MinGW may have problems with
/bin/true, any future exotic ports notwithstanding (OS/2, anyone?).
^ permalink raw reply
* [PATCH] Extend t6020 with another test for d/f interactions
From: Alex Riesen @ 2007-09-18 22:12 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, David Euresti
In-Reply-To: <95b3d0af0709181334y1e21507ey485860e4d45aa26f@mail.gmail.com>
A test for a merge when one of the trees has a file moved into a
directory with the same name (not just file replaced by a directory).
The problem noticed and reported by David Euresti
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t6020-merge-df.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
David Euresti, Tue, Sep 18, 2007 22:34:53 +0200:
> If I try to merge in the changes from the other branch or if the other
> branch tries to merge in these changes I get this error:
>
> dir/foo/foo.bin: unmerged (257cc5642cb1a054f08cc83f2d943e56fd3ebe99)
> fatal: git-write-tree: error building trees
> Merge with strategy recursive failed.
I extended the d/f merge test with the case. Have no idea how to fix
it yet though.
diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh
index a19d49d..c081d3f 100755
--- a/t/t6020-merge-df.sh
+++ b/t/t6020-merge-df.sh
@@ -10,6 +10,7 @@ test_expect_success 'prepare repository' \
'echo "Hello" > init &&
git add init &&
git commit -m "Initial commit" &&
+git branch init &&
git branch B &&
mkdir dir &&
echo "foo" > dir/foo &&
@@ -22,4 +23,20 @@ git commit -m "File: dir"'
test_expect_code 1 'Merge with d/f conflicts' 'git merge "merge msg" B master'
+test_expect_success 'file moved into a dir of same name' '
+ git reset --hard &&
+ git checkout -b d1 init &&
+ mkdir dir &&
+ mv init dir/init &&
+ mv dir init &&
+ git add . &&
+ git commit -a -m"init moved into init/init" &&
+ git checkout -b d2 init &&
+ echo file >file &&
+ git add file &&
+ git commit -m"unrelated change" &&
+ git checkout d1 &&
+ git merge d2
+'
+
test_done
--
1.5.3.1.173.g9a67
^ permalink raw reply related
* Re: diffcore-rename performance mode
From: Linus Torvalds @ 2007-09-18 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070918082321.GA9883@coredump.intra.peff.net>
On Tue, 18 Sep 2007, Jeff King wrote:
>
> With this patch:
>
> diff --git a/diffcore-rename.c b/diffcore-rename.c
> index 6bde439..531a844 100644
> --- a/diffcore-rename.c
> +++ b/diffcore-rename.c
> @@ -362,10 +362,7 @@ void diffcore_rename(struct diff_options *options)
> m->score = estimate_similarity(one, two,
> minimum_score);
> m->name_score = basename_same(one, two);
> - diff_free_filespec_data(one);
> }
> - /* We do not need the text anymore */
> - diff_free_filespec_data(two);
> dst_cnt++;
> }
> /* cost matrix sorted by most to least similar pair */
>
> My 20-minute diff becomes a 2-minute diff.
I think this is a reasonable patch, but only now *after* we limit the
rename matrix.
The whole reason for freeing the filespec data was to avoid exploding the
memory usage, but now that we aggressively limit the number of renames in
flight anyway, I think we can probably remove the code that frees the file
data in between all the rename similarity analysis.
Linus
^ permalink raw reply
* [EGIT PATCH] Remove src dir and entry in build.properties.
From: Ben Konrath @ 2007-09-18 22:20 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Hi Robin,
This is just a small clean up patch for the branding plugin.
CHeers, Ben
Signed-off-by: Ben Konrath <bkonrath@redhat.com>
---
org.spearce.egit/build.properties | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
delete mode 100644 org.spearce.egit/src/.gitignore
diff --git a/org.spearce.egit/build.properties b/org.spearce.egit/build.properties
index 2a21c05..22d4e45 100644
--- a/org.spearce.egit/build.properties
+++ b/org.spearce.egit/build.properties
@@ -1,5 +1,3 @@
-source.. = src/
-output.. = bin/
bin.includes = META-INF/,\
egit.png,\
about.ini
diff --git a/org.spearce.egit/src/.gitignore b/org.spearce.egit/src/.gitignore
deleted file mode 100644
index e69de29..0000000
--
1.5.2.4
^ permalink raw reply related
* [EGIT PATCH] Change to simplified icon.
From: Ben Konrath @ 2007-09-18 22:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Hi Robin,
Here's a patch that changes the icon to something that is a little more
aesthetically pleasing than the one I iniitially submitted. Feel free to
use the one you like best.
Cheers, Ben
Signed-off-by: Ben Konrath <bkonrath@redhat.com>
---
org.spearce.egit/egit.png | Bin 305 -> 226 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit/egit.png b/org.spearce.egit/egit.png
index 6e231c2c78068d313500afd0192962de8c8028d5..6782d4ab9b757aaa2c3d5edad42215ea02456836 100644
GIT binary patch
delta 128
zc$@)%0Du3n0^$LXK?o5MJ0{fucRrCxENxgxL_t(Y$L*B44FDhv17pNqjD{GE$xJ~P
zx*(py?zrZRNB~JYnPi6}fdmqmWq0m?BZUm`dpCgoqL=^;XxQg39(gUo$^d^orn8sp
i65v`i2_%r<6Ttw60WCp3d$>IS0000<MNUMnLSTZ2z%jJ|
delta 208
zc$@*y05AXI0kHy*K?n>MDJ}#O78sF9EPtm-L_t(Y$L&;G4!|G?6SI5mXvU-MWZege
zOB9Ki`S{Q;t(bz85&$=Hc{g|sC%C#_QY79WU<g4YYd?XW_(#bqO3c~g4CgB`xQyg0
zFV@9K?UxZyrk{c7I9H}(nSaW(v2QkAiA`2oS2kIRM*uZ?QR7&d2dySw^A{aA-95;z
zAIc?o10DFh3XY082`G|iI97Z`lTEg&;HzcId6nL2#m}H^LGS`$*mx<?D@u<50000<
KMNUMnLSTZEmRRfn
--
1.5.2.4
^ permalink raw reply
* Re: Latest builtin-commit series
From: Johannes Schindelin @ 2007-09-18 22:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Kristian Høgsberg, Git Mailing List, Junio C Hamano
In-Reply-To: <20070918213903.GA14488@steel.home>
Hi,
On Tue, 18 Sep 2007, Alex Riesen wrote:
> Kristian H?gsberg, Tue, Sep 18, 2007 17:23:29 +0200:
> > * Set the test suite default editor to '/bin/true' instead of ':'.
> > Since we're not exec'ing the editor from shell anymore, ':'
> > won't work. Maybe we should special case ':' in launch_editor
> > or perhaps make launch_editor use system(3). Not sure.
>
> Special case "" (empty string)? MinGW may have problems with
> /bin/true, any future exotic ports notwithstanding (OS/2, anyone?).
No problem. At least in msysGit.
Ciao,
Dscho
^ 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