* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy6dzf25.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Bryan Larsen <bryan@larsen.st> writes:
>
>> The perl scripts start with "#!/usr/bin/perl". There is a mechanism
>> PERL_PATH in the Makefile to change this, but it currently doesn't work
>> with PERL_PATH="/usr/bin/env perl".
>
> I do not get this whole business. Why would you even want to
> support that to begin with?
>
> The purpose of PERL_PATH is for you to tell git the path you
> have your Perl at. It is not about supplying a small shell
> script that lets "env" to figure it out.
>
Maybe PERL_PATH should be renamed PERL_SHEBANG or something. Because if
you pass in something that doesn't work on a shebang line (longer than
32 characters, say), it just won't work.
I was under the impression that "#!/usr/bin/env perl" was the "right"
way to invoke perl. But I'm not doing this because I want to do the
"right" thing. I'm doing this because it makes this scenario work:
$ sudo port install git-core
installing openssl...
installing openssh...
installing curl...
installing expat...
$ ...
$ git-send-email ...
$ ...
$ sudo port install git-svn
installing apr...
installing subversion...
installing perl...
installing p5-svn-simple...
git-core works fine with stock perl, and we don't want to install extra
megabytes of unneeded stuff if it really isn't needed.
Certainly there are other ways of making this work. But they're all
uglier than doing the "right" thing of "/usr/bin/env perl".
cheers,
Bryan
P.S.
On Linux, "#!/usr/bin/env perl -w" doesn't work. On OS X it works fine.
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Jakub Narebski @ 2007-05-03 23:36 UTC (permalink / raw)
To: git
In-Reply-To: <200705031216.19817.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> torsdag 03 maj 2007 skrev Johannes Schindelin:
>> On Thu, 3 May 2007, Florian Weimer wrote:
>>> * Jakub Narebski:
>>>
>>>> What I'm really concerned about is branch switch and merging branches,
>>>> when one of the branches is an old one (e.g. unxsplash branch), which
>>>> takes 3min (!) according to the benchmark. 13-25sec for commit is also
>>>> bit long, but BRANCH SWITCHING which takes 3 MINUTES!?
>>>
>>> IIRC, GIT accesses every file in the tree, not just the ones that need
>>> updating. How many files were actually updated when you changed
>>> branches in your experiment?
>>
>> No. Git does not access every file, but rather all stats. That is a huge
>> difference. And it should not take _that_ long for ~64000 files. Granted,
>> it will cause a substantial delay, but not in the range of minutes.
>
> It's worse... On my laptop the switch took ~ten minutes, not three.
> A diff --stat takes over six minutes!! For reference, dd:in the pack
> file with my disk takes ~50 seconds.
>
> The reason is simple. I have a lousy one gigabyte RAM only, while
> git wants 1.7GB virtual to do the diff-stat, and 800 MB resident.
> The swap is having a party,
That is nice to know where the culprit is: 197000 files and 24000
directories (132 projects), i.e. huge tree and not enogh memory.
This is yet another reason for splitting OOo repository into subprojects.
I do wonder if git can be more conservative in memory usage...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Robin Rosenberg @ 2007-05-03 23:31 UTC (permalink / raw)
To: Yann Dirson
Cc: Josef Sipek, Michael S. Tsirkin, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <200705040110.34697.robin.rosenberg.lists@dewire.com>
fredag 04 maj 2007 skrev Robin Rosenberg:
> torsdag 03 maj 2007 skrev Yann Dirson:
> [...]
> > As for publishing, I use the following config entries to publish my
> > own stack of patches to stgit. You can see at
> > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly
> > the structure of the stack (even though things could surely be made
> > better).
> >
> > I use "git push -f" to publish - maybe the "+" refspec syntax would
> > work with push, I'll try it next time :)
> >
> > [remote "orcz"]
> > url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git
> > push = refs/heads/master:refs/heads/master
> > push = refs/patches/master/*:refs/patches/master/*
>
> Beautiful!!
>
Would it be possible to push only applied patches, and drop unapplied
ones? It would only matter when one wants to prune the remote repo
so it may not be terribly important, but it seems I pushed quite a
lot of references from old patches that I haven't decided what to do
with yet and those will get new commit id's anyway.
-- robin
^ permalink raw reply
* Re: Submitting patches to the User's Manual.
From: Jari Aalto @ 2007-05-03 23:23 UTC (permalink / raw)
To: git
In-Reply-To: <200705040052.11932.johan@herland.net>
Johan Herland <johan@herland.net> writes:
>
> Is the answer as simple as the master branch on git.git (i.e. "git clone
> git://git.kernel.org/pub/scm/git/git.git")?
To put shortly: yes.
See http://git.or.cz/ => bottom => topic "Git by git"
Jari
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Robin Rosenberg @ 2007-05-03 23:10 UTC (permalink / raw)
To: Yann Dirson
Cc: Josef Sipek, Michael S. Tsirkin, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net>
torsdag 03 maj 2007 skrev Yann Dirson:
[...]
> As for publishing, I use the following config entries to publish my
> own stack of patches to stgit. You can see at
> http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly
> the structure of the stack (even though things could surely be made
> better).
>
> I use "git push -f" to publish - maybe the "+" refspec syntax would
> work with push, I'll try it next time :)
>
> [remote "orcz"]
> url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git
> push = refs/heads/master:refs/heads/master
> push = refs/patches/master/*:refs/patches/master/*
Beautiful!!
I needed to change the update commit though for git to recognize the
refs/patches heads. Or is that only because I had initialized the repos
using v1.5.0 ?
-- robin
^ permalink raw reply
* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Junio C Hamano @ 2007-05-03 23:02 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <463A6930.8090603@larsen.st>
Bryan Larsen <bryan@larsen.st> writes:
> The perl scripts start with "#!/usr/bin/perl". There is a mechanism
> PERL_PATH in the Makefile to change this, but it currently doesn't work
> with PERL_PATH="/usr/bin/env perl".
I do not get this whole business. Why would you even want to
support that to begin with?
The purpose of PERL_PATH is for you to tell git the path you
have your Perl at. It is not about supplying a small shell
script that lets "env" to figure it out.
^ permalink raw reply
* [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 23:00 UTC (permalink / raw)
To: git
The perl scripts start with "#!/usr/bin/perl". There is a mechanism
PERL_PATH in the Makefile to change this, but it currently doesn't work
with PERL_PATH="/usr/bin/env perl". This is causing problems in
MacPorts, where we wish to work with the MacPorts perl if it is
installed, but fall back to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
perl/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 17d004e..2832cb4 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -33,7 +33,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
+ $(PERL_PATH) $< PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
^ permalink raw reply related
* [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 22:58 UTC (permalink / raw)
To: git
The perl scripts start with "#!/usr/bin/perl". There is a mechanism
PERL_PATH in the Makefile to change this, but it currently doesn't work
with PERL_PATH="/usr/bin/env perl". This is causing problems in
MacPorts, where we wish to work with the MacPorts perl if it is
installed, but fall back to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
perl/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 17d004e..2832cb4 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -33,7 +33,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
+ $(PERL_PATH) $< PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
--
1.5.1.3
^ permalink raw reply related
* Re: [PATCH] Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 22:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070503212618.GC16538@spearce.org>
Shawn O. Pearce wrote:
> Bryan Larsen <bryan@larsen.st> wrote:
>> The perl scripts start with "#!/usr/bin/perl". There is a mechanism
>> PERL_PATH in the Makefile to change this, but it currently doesn't work
>> with PERL_PATH="/usr/bin/env perl". This is causing problems in
>> MacPorts, where we wish to work with the MacPorts perl if it is
>> installed, but fall back to the system perl if it isn't.
>>
>> Signed-off-by: Bryan Larsen <bryan@larsen.st>
>> ---
>> perl/Makefile | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/perl/Makefile b/perl/Makefile
>> index 17d004e..2832cb4 100644
>> --- a/perl/Makefile
>> +++ b/perl/Makefile
>> @@ -33,7 +33,7 @@ $(makfile): ../GIT-CFLAGS Makefile
>> echo ' echo $(instdir_SQ)' >> $@
>> else
>> $(makfile): Makefile.PL ../GIT-CFLAGS
>> - '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
>> + $(PERL_PATH_SQ) $< PREFIX='$(prefix_SQ)'
>> endif
>
> This will break if someone actually had ' in their PERL_PATH:
>
> PERL_PATH="/path'to'perl"
>
> as PERL_PATH_SQ tries to close the single quoted string you don't
> open anymore. That is because it is defined to be PERL_PATH,
> but with all ' replaced by '\''.
Actually, we should just use $(PERL_PATH) with no _SQ and no quotes.
The user is passing in something that is designed to go in a shebang
line: their funny characters are going to be interpreted by the
interactive shell to load the perl interpreter; we want "make" to do the
same thing.
>
> This change also breaks for anyone who had spaces in their PERL_PATH.
Actually a space didn't work before, but with my patch it works like
you'd expect in a shebang line, as the delimiter between the command and
it's arguments.
>
> Can I ask why you can't just supply a small wrapper shellscript
> with MacPorts
>
> cat >perl <<EOF
> #!/bin/sh
> exec env perl "$@"
> EOF
> chmod a+x perl
>
> ? Or better yet, supply Git the correct Perl path? If/when we ever
> go to native Perl libraries again a Git Perl library compiled for
> the system perl may not work later when the user installs a newer
> MacPorts perl. Switching automatically to the MacPorts perl without
> recompiling the native extensions is a little evil...
>
At that point we just add a single line "depends_lib port:perl5.8" to
the Portfile and everything magically works for the user. Right now
it's only in the git-svnimport part of the Portfile, which is nice: the
user doesn't get multiple megabytes worth of perl unless we also need to
install p5-svn-simple.
An even better fix can be to drop PERL_PATH from the Makefile and
replace the shebang line with "#!/usr/bin/env perl". Much simpler, and
the right thing to do, in my opinion.
cheers,
Bryan
^ permalink raw reply
* Submitting patches to the User's Manual.
From: Johan Herland @ 2007-05-03 22:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
This is probably the most stupid question you've seen on this list in a
while...
I'm currently reading the Git User's Manual (
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html ), and
I have a couple of changes I'd like to suggest. Where can I find the
authoritative repo I should clone and base my patches on?
Is the answer as simple as the master branch on git.git (i.e. "git clone
git://git.kernel.org/pub/scm/git/git.git")?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-fast-export hg mutt (24M vs 184M)
From: Pierre Habouzit @ 2007-05-03 22:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <20070503211824.GB16538@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
On Thu, May 03, 2007 at 05:18:24PM -0400, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > On Thu, May 03, 2007 at 09:17:16PM +0200, Thomas Glanzmann wrote:
> > > Hello,
> > > git-repack -a -d -f got it down to 19M. I missed the -f parameter
> > > before. Sorry for the noise.
> >
> > You may want to use git gc that does that (and a bit more) for you.
>
> Actually, in this case, no.
>
> git-gc by default doesn't use the -f option. -f to git-repack
> means "no reuse deltas". That particular feature of git-repack is
> basically required to be used after running git-fast-import with
> anything sizeable.
okay, so why git fast-import does not let some note somewhere (to be
picked by git gc later) "a fast-import has been run, use -f for next
repack if you want best compression" ?
I'd think that would make a lot of sense, and that users that now
naively (like me) think git-gc would always be enough would not be
dramatically wrong ? :)
I mean it's nothing *very* important but some
`touch $GIT_DIR/info/unpacked-fast-import` in fast-import then:
if test -f $GIT_DIR/info/unpacked-fast-import; then
REPACK_OPTIONS=$REPACK_OPTIONS\ -f
fi
// do the repack
rm -f $GIT_DIR/info/unpacked-fast-import
would do the trick, wouldn't it ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with case-insensitive file cleanup
From: James Youngman @ 2007-05-03 21:40 UTC (permalink / raw)
To: Jim Meyering; +Cc: bug-findutils mailing list, bug-gnulib, Eric Blake, git
In-Reply-To: <87odl2dnbk.fsf@rho.meyering.net>
On 5/3/07, Jim Meyering <jim@meyering.net> wrote:
> > Earlier this week, I reported a problem when two case-insensitive files
> > were created, which is a no-no for checkouts on Mac HFS+ or Windows-based
> > platforms [1]. The problem was quickly corrected in CVS (note that
> > _Exit.texi now lives in the attic [2]). But somehow the git repository
> > still thinks that _Exit.texi belongs to the current tree [3], which leads
> > to this confusing state on a case-insensitive clone:
>
> I've just removed that file manually and pushed the result.
> I suppose that happened because something went wrong with the
> automated git-cvsimport run.
>
> The current procedure is to rsync the CVS repository,
> use that via git-cvsimport into an existing .git repository,
> and then to push the result to savannah.
>
> Obviously, before we do the final CVS-to-GIT switch, I'll rerun
> git-cvsimport from scratch, rather relying on the incrementally-built-up one.
I have had related problems using git-cvsimport with the GNU findutils
source base and was eventually reduced to deleting the git repository
into which I was pushing the git-cvsimport result. I had added a
directory to the CVS repository (findutils/build-aux) and it was not
showing up in the target git repository (i.e. the local directory I
was specifying as the argument of -C).
Fortunately since git is content-oriented (has foo-nature, whatever,
insert hand-wave here), once I have repeated the entire cvsimport
operation, pushing the regenerated result to the public git repository
only required an incremental amount of work (bandwdth).
But suffice to say, I do not believe that git-cvsimport is very
reliable. People more familiar with git than I point the finger at
cvsps, but to be honest I don't know enough about either program to
arbitrate.
People also pointed me at alternatives to git-cvsimport but they all
had one or more of these drawbacks:
1. No support for incremental import
2. No support for tags
3. No support for branches
James.
^ permalink raw reply
* Re: [PATCH] Allow PERL_PATH="/usr/bin/env perl"
From: Shawn O. Pearce @ 2007-05-03 21:26 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <463A472D.5000007@larsen.st>
Bryan Larsen <bryan@larsen.st> wrote:
> The perl scripts start with "#!/usr/bin/perl". There is a mechanism
> PERL_PATH in the Makefile to change this, but it currently doesn't work
> with PERL_PATH="/usr/bin/env perl". This is causing problems in
> MacPorts, where we wish to work with the MacPorts perl if it is
> installed, but fall back to the system perl if it isn't.
>
> Signed-off-by: Bryan Larsen <bryan@larsen.st>
> ---
> perl/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index 17d004e..2832cb4 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -33,7 +33,7 @@ $(makfile): ../GIT-CFLAGS Makefile
> echo ' echo $(instdir_SQ)' >> $@
> else
> $(makfile): Makefile.PL ../GIT-CFLAGS
> - '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
> + $(PERL_PATH_SQ) $< PREFIX='$(prefix_SQ)'
> endif
This will break if someone actually had ' in their PERL_PATH:
PERL_PATH="/path'to'perl"
as PERL_PATH_SQ tries to close the single quoted string you don't
open anymore. That is because it is defined to be PERL_PATH,
but with all ' replaced by '\''.
This change also breaks for anyone who had spaces in their PERL_PATH.
Can I ask why you can't just supply a small wrapper shellscript
with MacPorts
cat >perl <<EOF
#!/bin/sh
exec env perl "$@"
EOF
chmod a+x perl
? Or better yet, supply Git the correct Perl path? If/when we ever
go to native Perl libraries again a Git Perl library compiled for
the system perl may not work later when the user installs a newer
MacPorts perl. Switching automatically to the MacPorts perl without
recompiling the native extensions is a little evil...
--
Shawn.
^ permalink raw reply
* Re: git-fast-export hg mutt (24M vs 184M)
From: Shawn O. Pearce @ 2007-05-03 21:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <20070503210112.GE3260@artemis>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Thu, May 03, 2007 at 09:17:16PM +0200, Thomas Glanzmann wrote:
> > Hello,
> > git-repack -a -d -f got it down to 19M. I missed the -f parameter
> > before. Sorry for the noise.
>
> You may want to use git gc that does that (and a bit more) for you.
Actually, in this case, no.
git-gc by default doesn't use the -f option. -f to git-repack
means "no reuse deltas". That particular feature of git-repack is
basically required to be used after running git-fast-import with
anything sizeable.
The reason you need -f is git-fast-import does not write optimally
compressed blobs (file revisions) when it creates the packfile.
Instead it does a reasonable best effort while using a minimum
amount of memory. The Git packfiles get most of their compression
benefits from being able to see all of a project's data at once;
this is impossible in fast-import as we're only seeing a small part
of the incoming data stream at any single point in time.
If you had a lot of tags imported you might want to also use `git
pack-refs` (one of the chores that git-gc does), or `git pack-refs
--all` if you have a lot of dangling branches imported. The other
chores in git-gc aren't actually useful after running fast-import
(reflog expire, prune, rerere gc).
--
Shawn.
^ permalink raw reply
* Re: git-fast-export hg mutt (24M vs 184M)
From: Pierre Habouzit @ 2007-05-03 21:01 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070503191716.GB11817@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Thu, May 03, 2007 at 09:17:16PM +0200, Thomas Glanzmann wrote:
> Hello,
> git-repack -a -d -f got it down to 19M. I missed the -f parameter
> before. Sorry for the noise.
You may want to use git gc that does that (and a bit more) for you.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Yann Dirson @ 2007-05-03 20:58 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Josef Sipek, Michael S. Tsirkin, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <200704252337.05851.robin.rosenberg.lists@dewire.com>
On Wed, Apr 25, 2007 at 11:37:05PM +0200, Robin Rosenberg wrote:
> onsdag 25 april 2007 skrev Josef Sipek:
> > On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
> [...]
> > > I am concerned that publishing a git branch managed by stg/guilt
> > > would present problems: it seems that every time patches are re-ordered,
> > > a patch is re-written or removed, or we update from upstream,
> > > everyone who pulls the tree branch will have a hard-to-resolve conflict.
> > >
> > > Is that really a problem? If so, would it be possible to work around this
> > > somehow?
> >
> > I thought about this problem a while back when I was trying to decide how to
> > manage the Unionfs git repository. I came to the conclusion, that there was
> > no clean way of doing this (at least not using guilt - I can't really speak
> > for stgit, as I don't know how it does things exactly).
>
> StGit has the same problem. Publishing such a branch is only for viewing if
> you want to publish the tip, like the pu branch in the Git repo. You shouldn't
> merge from pu either.
You are right, in that what can be done with such branches is limited.
BUT you can safely "stg branch --create" off any remote stgit stack.
Then you can "stg rebase origin/master" to port your stack to the new
tip of the remote stack.
The next stgit release will allow you to declare the pull-policy for
your stack as "rebase", so when you "stg pull" it will indeed rebase
to the new tip of the parent branch.
As for publishing, I use the following config entries to publish my
own stack of patches to stgit. You can see at
http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly
the structure of the stack (even though things could surely be made
better).
I use "git push -f" to publish - maybe the "+" refspec syntax would
work with push, I'll try it next time :)
[remote "orcz"]
url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git
push = refs/heads/master:refs/heads/master
push = refs/patches/master/*:refs/patches/master/*
Maybe we should provide some degree of automation in stgit itself
(eg. "stg branch --publish" or something).
Hope this helps,
--
Yann.
^ permalink raw reply
* Re: how to filter a pull
From: Alex Riesen @ 2007-05-03 20:37 UTC (permalink / raw)
To: marc zonzon; +Cc: Junio C Hamano, git
In-Reply-To: <71295b5a0705031232l3dc6a61dh7c0d7f993536fab7@mail.gmail.com>
marc zonzon, Thu, May 03, 2007 21:32:52 +0200:
> I need in my packages to produce rc scripts and udev conf, hotplug
> scripts. They depends of the base rc functions of openwrt (int etc),
> the config system (in lib/config), and the hotplug scripts
> (/etc/hotplug.d), and I need to patch some of these scripts.
> I would like to stay in sync with the development of openwrt, the
> change in the patched files are quite frequent but usualy merge
> easily. Of course this is only one part of my dependencies, the main
> tree that is imported in my project is the original package that I
> modify to tailor it to openwrt.
It looks like you need neither subproject nor partial checkouts
(another Git-specific feature which is just about to come into
existence). Just manage everything in one repo. Git deals with large,
big and even huge repos splendidly. It's the monstrous repos which
still make problems, but people working on them.
^ permalink raw reply
* [PATCH] Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 20:33 UTC (permalink / raw)
To: git
The perl scripts start with "#!/usr/bin/perl". There is a mechanism
PERL_PATH in the Makefile to change this, but it currently doesn't work
with PERL_PATH="/usr/bin/env perl". This is causing problems in
MacPorts, where we wish to work with the MacPorts perl if it is
installed, but fall back to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
perl/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 17d004e..2832cb4 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -33,7 +33,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
+ $(PERL_PATH_SQ) $< PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
--
1.5.1.3
^ permalink raw reply related
* Re: FFmpeg considering GIT
From: david @ 2007-05-03 20:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Uwe Kleine-König, Panagiotis Issaris, git
In-Reply-To: <20070503200013.GG4489@pasky.or.cz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2190 bytes --]
On Thu, 3 May 2007, Petr Baudis wrote:
> On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote:
>
> I believe that the development scheme is largely independent on the
> version control system, except that git makes the "both ways" equally
> easy. But that doesn't mean that the "multiple people with commit
> access" scheme is wrong or anything. It has important upsides as well -
> there's no single human point of failure (_yes_, if the maintainer gets
> stuck in hospital for two months you can fork and maintain own
> repository, but then it's again just you and it is complicated socially
> etc.), the load of the maintainer is significantly lowered, and in many
> projects there is simply no "single maintainer" but a team of people
> where decisions are made by consensus.
>
> Still, if this kind of bogus change checkins happens at any frequent
> rate in the ffmpeg project, there is a serious problem somewhere. :-)
> But I think the git way of alleviating this problem would be to have a
> way to hint the pickaxe and blame tools to ignore changes in given
> commits. So, you don't _cover up_ the messy things that happened during
> the history, but avoid in getting in the way in your view. You can still
> look it up (with git log or something) in case you'd need to (perhaps
> the revert patch was a bit complicated because of conflicting with some
> other changes, and a subtle bug was introduced; this would be thousand
> times harder to track down if you would've rewritten the history).
>
> Would crafting up a patch to implement something like this help ffmpeg
> people in their decision?
is this needed?
wouldn't you do something like
a--b--c--d
oops, b was really bad
rebase c b
a--b--c--d
\
c'--d'--e--f
and you just start tagging d', e, f as the releases, logicly changing
things to
a--b--c'--d'--e--f
\
c--d dead branch
the only thing that this costs is space. unless it's a 'mess up all the
whitespace in the entire tree' type of thing (and if it was, whoever
did the commit would see the _huge_ diffstat and probably catch it) it's
not likely to be a significant amount of space in the overall history.
David Lang
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Petr Baudis @ 2007-05-03 20:13 UTC (permalink / raw)
To: david; +Cc: Uwe Kleine-König, Panagiotis Issaris, git
In-Reply-To: <Pine.LNX.4.64.0705031302110.26172@asgard.lang.hm>
On Thu, May 03, 2007 at 10:05:34PM CEST, david@lang.hm wrote:
> On Thu, 3 May 2007, Petr Baudis wrote:
> > Would crafting up a patch to implement something like this help ffmpeg
> >people in their decision?
>
> is this needed?
>
> wouldn't you do something like
>
> a--b--c--d
>
> oops, b was really bad
>
> rebase c b
..snip..
This is immensely problematic, but I think I've fully covered all my
reservations in the other mail in this thread; if anything there was
unclear or you disagree with something I said, please reply to it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Petr Baudis @ 2007-05-03 20:00 UTC (permalink / raw)
To: Uwe Kleine-König, Panagiotis Issaris, git
In-Reply-To: <20070503180016.GB21333@informatik.uni-freiburg.de>
Hi,
On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote:
> Panagiotis Issaris wrote:
> > There are some other things the FFmpeg maintainer mentions, namely:
> > * He wants to be able to revert a commit in some way without "wiping" history.
> > That is without committing a patch which reverses the broken commit, as this
> > would pollute "git blame". The maintainer sees this as critical feature for
> > switching to git as it apparently can be doing using Subversion:
> > "in svn we can do this with svn cp from a specific
> > revission git and mercurial lack proper copy support"
> To add more context, Michael Niedermayer (=FFmpeg maintainer) wrote (in
> [1]):
>
> let me explain a little bit why this is critically needed
> think of someone misstakely commiting the whole ffmpeg
> reindented or mistakely commiting a old ffmpeg version over the
> new or another total messup, these things do happen, and
> especially if they cannot be corrected and at the time where
> none of the developers is around
>
> For me this sounds like: I don't want people with commit access doing
> this, and if they do, I want to be able to revert it.
>
> If FFmpeg used a development scheme similar to the linux kernel, there
> should be no need for revert: The upstream maintainer only needs to pay
> attention to the things he does directly (he probably does in any case)
> and check the patches he applies and the trees he pulls. As git gives a
> diffstat on pull and he reviews patches before applying the problem is
> maybe gone?
>
> Commit access is simply different in a distributed environment, see
> http://thread.gmane.org/gmane.comp.version-control.git/45849/focus=45956
I believe that the development scheme is largely independent on the
version control system, except that git makes the "both ways" equally
easy. But that doesn't mean that the "multiple people with commit
access" scheme is wrong or anything. It has important upsides as well -
there's no single human point of failure (_yes_, if the maintainer gets
stuck in hospital for two months you can fork and maintain own
repository, but then it's again just you and it is complicated socially
etc.), the load of the maintainer is significantly lowered, and in many
projects there is simply no "single maintainer" but a team of people
where decisions are made by consensus.
Still, if this kind of bogus change checkins happens at any frequent
rate in the ffmpeg project, there is a serious problem somewhere. :-)
But I think the git way of alleviating this problem would be to have a
way to hint the pickaxe and blame tools to ignore changes in given
commits. So, you don't _cover up_ the messy things that happened during
the history, but avoid in getting in the way in your view. You can still
look it up (with git log or something) in case you'd need to (perhaps
the revert patch was a bit complicated because of conflicting with some
other changes, and a subtle bug was introduced; this would be thousand
times harder to track down if you would've rewritten the history).
Would crafting up a patch to implement something like this help ffmpeg
people in their decision?
Let's say you have .git/info/reverts with one "revert pair" (two
commit ids, one for the bogus change and one for reverting it) per line,
and the blame/pickaxe tools take it into account. The downside is that
this isn't preserved over clones and fetches. That's a pretty big one.
Another way might be to have say a magic "Reverts: commitid" line at
the last paragraph of a commit message recognized by git. The downside
is that the body of commit message might have magic meaning for some
non-core plumbing; I'm not sure how big a downside that is. For adding
it to commit header it might be a little bit too non-core, I might meet
with Linus' ethernal fury, and I'm not sure how big of a compatibility
problem would it be.
Ideas?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: how to filter a pull
From: marc zonzon @ 2007-05-03 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwszpzs33.fsf@assigned-by-dhcp.cox.net>
On 5/3/07, Junio C Hamano <junkio@cox.net> wrote:
> If I were doing this 6 months from now, I would probably use
> subproject to host the whole tree of other projects somewhere,
> adjust the build procedure of the primary project to borrow the whole of these other
> projects not just subtree -- or have appropriate symlinks in the
> superproject that point into relevant subtrees in the
> subprojects.
>
> If I were doing this today, I would probably use separate
> repositories, next to the primary project, to host the whole
> tree of other projects, adjust the build procedure of the
> primary project to borrow the whole of these other projects not
> just subtree -- and/or have appropriate symlinks in the primary
> project that point into relevant subtrees in the neighbouring
> repositories that host these other projects.
>
Thank you for your explanations, I'm not sure to truly understand what
you propose, (I told you I'm a beginner and not amonq the clever
ones!)
Do you mean that I have to do the patches I do on the fellow project
in the mirror directory, as to keep it as a link? It could be possible
when the project is managed by git (with the drawback of adding an
extra complexity to dereference the links in the repository when
archiving a release, and a lot of problem to export to a public
repository) but is not a possibility when the other project is managed
by an other scm.
I don't understand neither the first solution 'borrow the whole project'.
To better explain the problem I give a practical case.
I'm working to package software for openwrt arm-mipsel system. The
whole openwrt buildsystem is available under subversion, it is a big
tree (not so huge than the kernel you are accustomed to!)
I need in my packages to produce rc scripts and udev conf, hotplug
scripts. They depends of the base rc functions of openwrt (int etc),
the config system (in lib/config), and the hotplug scripts
(/etc/hotplug.d), and I need to patch some of these scripts.
I would like to stay in sync with the development of openwrt, the
change in the patched files are quite frequent but usualy merge
easily. Of course this is only one part of my dependencies, the main
tree that is imported in my project is the original package that I
modify to tailor it to openwrt.
My problem is how to deal with this neither major nor minor dependency.
Thanks for taking time to answer.
Marc
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Junio C Hamano @ 2007-05-03 19:26 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git, Jakub Narebski
In-Reply-To: <200705032222.37387.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
>> But at the same time I wonder why should the callers be feeding
>> an already decoded string to to_utf8(). It might be that some
>> callers needs fixing.
>
> Is the patch OK do you want more investigation? Asking because its still not
> in git.git.
I would say that the patch is an improvement from the current
code so it should hit 'master'; I was a bit busy lately and then
am sick, and also we are post -rc1 freeze now and I was being
cautious, just in case some nacks from more informed parties
arrive late.
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Ismail Dönmez @ 2007-05-03 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7v8xc85ill.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
Hi,
On Wednesday 02 May 2007 00:39:34 Junio C Hamano wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Ok found out the reason. decode() tries to decode data that is already
> > UTF-8 and borks.
> >
> > This is from Encode.pm :
> >
> > sub decode_utf8($;$) {
> > my ( $str, $check ) = @_;
> > return $str if is_utf8($str); <--- Checks if the $str is already
> > UTF-8 if ($check) {
> > return decode( "utf8", $str, $check ); <--- Else do what gitweb
> > does [...]
> >
> > So my patch is indeed correct.
>
> Ok, I think that makes it an improvement from the current code,
> so I'd apply.
>
> But at the same time I wonder why should the callers be feeding
> an already decoded string to to_utf8(). It might be that some
> callers needs fixing.
Is the patch OK do you want more investigation? Asking because its still not
in git.git.
Regards,
ismail
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-fast-export hg mutt (24M vs 184M)
From: Thomas Glanzmann @ 2007-05-03 18:56 UTC (permalink / raw)
To: GIT
Hello,
I just tried to vendor track / import the mutt hg repository into git.
git-fast-export-hg is quiet amazing but the resulting git repository
blows up in size and I have not the slightes clue why.
git clone git://repo.or.cz/fast-export.git
hg clone http://dev.mutt.org/hg/mutt
Could someone have a look at this? I used Debian Etch with a git version
I build myself using an ugly script. I had to upgrade mecurial as well
because the version didn't had the cmdlog.py. I used the unstable debian
package for that.
(thinkpad) [~/work/mutt] git-init-db
Initialized empty Git repository in .git/
(thinkpad) [~/work/mutt] ~/work/fast-export/hg-fast-export.sh -r /tmp/mutt
git version 1.5.2.rc0.56.g6169a
Thomas
^ 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