* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 11:53 UTC (permalink / raw)
To: git
In-Reply-To: <20071219114823.GA28273@hashpling.org>
git-instaweb relied on a pipe in a sed script, but this is not supported
by MacOS X sed when using BREs. git-instaweb relies on a working perl
in any case, and perl re are more consistent between platforms, so
replace sed invocation with an equivalent perl invocation.
Also, fix the documented -b "" to work without giving a spurious 'command
not found' error.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Makefile | 1 +
git-instaweb.sh | 15 +++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 617e5f5..d6d3d65 100644
--- a/Makefile
+++ b/Makefile
@@ -880,6 +880,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
+ -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 42d8d7f..9f86709 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -3,6 +3,7 @@
# Copyright (c) 2006 Eric Wong
#
+PERL='@@PERL@@'
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC="\
git-instaweb [options] (--start | --stop | --restart)
@@ -232,16 +233,18 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'$(dirname "$fqgitdir")'";#
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
-s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+s#^(my|our) \$projectroot =.*#$1 \$projectroot = "'$(dirname "$fqgitdir")'";#;
+s#(my|our) \$gitbin =.*#$1 \$gitbin = "'$GIT_EXEC_PATH'";#;
+s#(my|our) \$projects_list =.*#$1 \$projects_list = \$projectroot;#;
+s#(my|our) \$git_temp =.*#$1 \$git_temp = "'$fqgitdir/gitweb/tmp'";#;'
gitweb_cgi () {
cat > "$1.tmp" <<\EOFGITWEB
@@GITWEB_CGI@@
EOFGITWEB
- sed "$script" "$1.tmp" > "$1"
+ # The generated scripts assume that perl is /usr/bin/perl
+ # so the assumption here should be no more harmful
+ "$PERL" -p -e "$script" "$1.tmp" > "$1"
chmod +x "$1"
rm -f "$1.tmp"
}
@@ -273,4 +276,4 @@ esac
start_httpd
url=http://127.0.0.1:$port
-"$browser" $url || echo $url
+test -n "$browser" && "$browser" $url || echo $url
--
1.5.4.rc0
^ permalink raw reply related
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 11:48 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <CA30F61D-4AE1-4100-A632-20B5587EB4D0@wincent.com>
On Wed, Dec 19, 2007 at 12:43:12PM +0100, Wincent Colaiuta wrote:
> El 19/12/2007, a las 12:36, Charles Bailey escribió:
>
> >
> >I agree completely, but all the generated scripts output hard coded
> >paths so it would seem inconsistent not to qualify the path in this
> >case too.
>
> It's not hard-coded, it's dynamic. Witness:
>
It's *output* hardcoded, it's dynamic during script generation.
A raw 'perl' in a shell script is dynamic during script run.
> $ make PERL_PATH=/Volumes/Clon/usr/bin/perl
> $ head -1 git-add--interactive
> #!/Volumes/Clon/usr/bin/perl -w
>
> > Would @@PERL_PATH@@perl -p -e work, do you know?
>
> I don't think so, but judging from the following section of the
> Makefile, I think @@PERL@@ would. Why don't you give it a try?
>
> $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
> $(QUIET_GEN)$(RM) $@ $@+ && \
> sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
> -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
> -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
> -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
> -e 's|@@HTMLDIR@@|$(htmldir_SQ)|g' \
> $@.sh >$@+ && \
> chmod +x $@+ && \
> mv $@+ $@
>
git-instaweb is treated specially, so the answer is 'no, not yet', but
I have a patch on the way.
Charles.
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 11:47 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, David Kågedal, git
In-Reply-To: <20071219114021.GB5565@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> You and others like what "stg resolved" does,
> but I don't want it in StGit because it's a generic git enhancement
> that has nothing to with patch stacks. People who don't use StGit
> would presumably like it as well.
The --reset option would never be added to git, at least not with the
same name for arguments since git doesn't manage patches. As I said, I
would have to remember what stage my 'patched' file is in.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Wincent Colaiuta @ 2007-12-19 11:43 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20071219113617.GA26520@hashpling.org>
El 19/12/2007, a las 12:36, Charles Bailey escribió:
> On Wed, Dec 19, 2007 at 12:28:04PM +0100, Wincent Colaiuta wrote:
>>
>> I think it's a bad idea to hard-code the perl path there; the
>> generated scripts only assume /usr/bin/perl if the user hasn't
>> overridden it at build time:
>>
>> PERL_PATH=/foo/perl make ...
>>
>> Using just this should work fine anyway:
>>
>> perl -p -e ...
>>
>
> I agree completely, but all the generated scripts output hard coded
> paths so it would seem inconsistent not to qualify the path in this
> case too.
It's not hard-coded, it's dynamic. Witness:
$ make PERL_PATH=/Volumes/Clon/usr/bin/perl
$ head -1 git-add--interactive
#!/Volumes/Clon/usr/bin/perl -w
> Would @@PERL_PATH@@perl -p -e work, do you know?
I don't think so, but judging from the following section of the
Makefile, I think @@PERL@@ would. Why don't you give it a try?
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's|@@HTMLDIR@@|$(htmldir_SQ)|g' \
$@.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
Cheers,
Wincent
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 11:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071219112035.GA5565@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 10:09:40 +0000, Catalin Marinas wrote:
>
> > For the 'status --reset', I'll keep it if we have a separate
> > 'resolved' command.
>
> ?
It needs to call the resolved_all to remove checked-out stages if
stgit.keeporig == 'yes'. Maybe it could also do some sanity check if
HEAD != top. With 'git reset --hard', people might easily add an
argument and break the whole stack.
> > In the past, StGIT only used the core git functionality and stayed
> > away from the porcelain scripts. We now started to use some of the
> > built-in commands more and more and I think it is fine but the git
> > scripts look more volatile to me than the C code (look at the many
> > variants the git merging went through, from shell scripts to python
> > and only now seems to be stabilised with the recursive merge as a
> > built-in command).
>
> Hmm? Have we started to use more porcelain lately?
I think Yann was complaining about using git-show since it looks more
like a porcelain command.
> > Adding the functionality I need to git-mergetool would also mean
> > always using the latest GIT with StGIT.
>
> It wouldn't keep being the latest git version, though.
Yes, but at least initially it should be pretty recent.
> > Anyway, if you like git-mergetool, I think you can easily change the
> > StGIT configuration to
>
> I don't use interactive merging at all. What I wanted was to get rid
> of StGit's own interactive merging.
I use it quite often and I even invoke it automatically
(stgit.autoimerge). I'll push some patches tonight together with most
of your safe branch and we can alter them afterwards.
> So you want StGit to do two things: patch stacks, and fix some git UI
> warts. Hey, I can live with that. :-) But I firmly believe that the
> wart fixing parts of StGit should be (1) optional, so that the same
> job can easily be done with just git; and (2) as thin as possible, to
> make them easy to explain in terms of git, and cheap to maintain.
Unless you need the keeporig functionality, you can now always use
plain git for solving merges, add/rm/cp, 'reset --hard' etc. At some
point, we could make it safe for 'git rebase' but I think we need the
DAG patches.
> > That's not the case with 'resolved'.
>
> No, I see.
As I said, if you don't need keeporig, just use git-add (or stg-add
when I'll add the alias).
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 11:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, David Kågedal, git
In-Reply-To: <200712191144.59747.jnareb@gmail.com>
On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
> On Wed, 19 Dec 2007, Karl Hasselström wrote:
>
> > On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> >
> > > I also would like to have this command kept (and shown in 'stg
> > > help'!). Contrary to 'git add' it can check and add to index /
> > > update index only for files with conflict; we have -r
> > > (ancestor|current|patched) to choose one side, and we could add
> > > --check to check if there are no conflict markers with files
> > > (useful with -a/--all).
> >
> > This too sounds like stuff that could profitably be added to "git
> > add". Except for the ancestor/current/patched words, it is not
> > specific to patch stacks, so the implementation should be in git
> > and not in stg.
>
> No it cannot, at least the '-r (ancestor|current|patched)' part for
> resetting file to given version, even if we change the wording to
> ancestor, ours and theirs. The git-add command is about adding
> contents, which updates index, which almost as a intended
> side-effect clears merge state, i.e. stages; and not about resetting
> to stage.
git checkout-index --stage=1|2|3 <filename>
does what you want. But "git cat-file" knows this handy syntax for
getting at particular index stages:
:stage:<filename>
It would be very convenient to be able to do
git checkout :stage:<filename>
but it doesn't seem to work currently. Does anyone know the "best" way
of manually checking out a particular index stage in git?
> Besides with "stg resolved" you can update index _only_ for files
> which were in the conflict, also for -a/--all, and not all the files
> not only those which were in the conflict like "git add -u" does.
This sounds like a straightforward addition to "git add".
> "stg resolved --check" could happily ignore things that only look
> like conflict markers, but must have been intended, because they are
> in files not in conflict.
git knows about conflicting files too.
> Unless you are talking about adding "resolve"/"resolved" command to
> git-core, as a porcelain wrapper around git-update-index, like "git
> add"...
Yes, that's what I want. You and others like what "stg resolved" does,
but I don't want it in StGit because it's a generic git enhancement
that has nothing to with patch stacks. People who don't use StGit
would presumably like it as well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
From: Haavard Skinnemoen @ 2007-12-19 11:40 UTC (permalink / raw)
To: Chip Coldwell
Cc: linux, kernel, linux-kernel, Andrew Victor, Remy Bohmer,
linux-arm-kernel, git
In-Reply-To: <alpine.LFD.0.9999.0712181318300.27475@localhost.localdomain>
On Tue, 18 Dec 2007 13:19:39 -0500 (EST)
Chip Coldwell <coldwell@redhat.com> wrote:
> > On Tue, 18 Dec 2007 18:06:14 +0100
> > Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
> >
> > > From: Remy Bohmer <hskinnemoen@atmel.com>
> >
> > Heh. That's obviously wrong. Wonder what happened there?
> >
> > Looks like Chip's address got mangled too.
>
> You can find me at <coldwell@gmail.com> or <coldwell@redhat.com> these
> days, although <coldwell@frank.harvard.edu> still works for the time
> being.
Thanks. I'll update the broken commits.
Btw, the funny thing is that, looking at my shell history, I think I
actually did the right thing when committing your patches:
git commit -s --author 'Remy Bohmer <linux@bohmer.net>'
git commit -s --author 'Chip Coldwell <coldwell@frank.harvard.edu>'
But for some reason only your names stuck, not your e-mail addresses...
Haavard
^ permalink raw reply
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 11:36 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <23306E3C-24F1-4626-A956-02531644B786@wincent.com>
On Wed, Dec 19, 2007 at 12:28:04PM +0100, Wincent Colaiuta wrote:
>
> I think it's a bad idea to hard-code the perl path there; the
> generated scripts only assume /usr/bin/perl if the user hasn't
> overridden it at build time:
>
> PERL_PATH=/foo/perl make ...
>
> Using just this should work fine anyway:
>
> perl -p -e ...
>
I agree completely, but all the generated scripts output hard coded
paths so it would seem inconsistent not to qualify the path in this
case too. Would @@PERL_PATH@@perl -p -e work, do you know?
Charles.
^ permalink raw reply
* Re: Question about git-svn import
From: Pascal Obry @ 2007-12-19 11:29 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git list
In-Reply-To: <20071218153159.GA12549@alea.gnuu.de>
Jörg,
> It's not as complicated as you might think.
Ok, thanks for the pointers. I'll have a look.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Wincent Colaiuta @ 2007-12-19 11:28 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20071219105752.GA23932@hashpling.org>
El 19/12/2007, a las 11:57, Charles Bailey escribió:
> - sed "$script" "$1.tmp" > "$1"
> + # The generated scripts assume that perl is /usr/bin/perl
> + # so the assumption here should be no more harmful
> + /usr/bin/perl -p -e "$script" "$1.tmp" > "$1"
I think it's a bad idea to hard-code the perl path there; the
generated scripts only assume /usr/bin/perl if the user hasn't
overridden it at build time:
PERL_PATH=/foo/perl make ...
Using just this should work fine anyway:
perl -p -e ...
Cheers,
Wincent
^ permalink raw reply
* Re: Problem with git-svn
From: Pascal Obry @ 2007-12-19 11:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20071219082751.GA17787@muzzle>
Hi Eric,
> Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/'?
$ svn log -v -r9458 svn+ssh://myserver/
------------------------------------------------------------------------
r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
Changed paths:
A /importfromcvs
A /importfromcvs/branches
A /importfromcvs/tags
A /importfromcvs/trunk
New repository initialized by cvs2svn.
------------------------------------------------------------------------
> So did svn+ssh://importfromcvs/trunk/file.el at r9458? If so, git-svn
> is behaving as expected. If not, can you tell me where "file.el" was at
> r9458?
file.el was not imported at r9458 but at r9459, just after the creation
of the /importfromcvs directories above.
------------------------------------------------------------------------
r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
Changed paths:
A /importfromcvs/trunk/file.el
Initial revision
------------------------------------------------------------------------
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Jakub Narebski @ 2007-12-19 11:23 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Johannes Schindelin, Alex Riesen, git
In-Reply-To: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
On Wed, 19 Dec 2007, Dana How wrote:
> On Dec 18, 2007 5:16 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Tue, 18 Dec 2007, Dana How wrote:
>>
>>> The cases we are talking about are all subtrees of the working tree.
>>> There is a useful cwd suffix.
>>
>> No.
>>
>> The cases we're talking of are *not* subtrees of the working tree.
>>
>> The SHA1 of a commit may well be a totally disjoint tree. Try it in the
>> git repository with something like
>
> Agreed, but note you wrote *may*.
>
> I'd like to move some stuff currently in a p4 repository into git.
> The directory structure within the repo is 13 levels deep;
> I didn't design it nor can I change it.
>
> For the majority of the cases of interest to me git already accepts
> relative paths. However, one thing people do often in p4 (or any SCM)
> is look at (or compare, etc) specific revisions. Unfortunately, these are
> not part of branches or commits, they are just file-specific revisions
> (don't get me started on p4 "branches"). The equivalent in git is
> to use a commit name (or a tag) and then name the file. The
> basic commit:file syntax doesn't accept relative paths. I am not
> specifically hung up on the commit:./path syntax; I just want some
> notation that will get those 13 directories from $cwd instead of
> making me type them again. Yes, sometimes that might not make
> sense to request.
[...]
I think new feature like this should be postponed after 1.5.4 is out;
we are now in feature freeze (only bugfixes are accepted).
That said, does git-showrel solution proposed by Johannes Schindelin
in
Message-ID: <Pine.LNX.4.64.0712182250040.23902@racer.site>
http://permalink.gmane.org/gmane.comp.version-control.git/68840
work for you?
Below version of git-showrel script which uses proposed 'commit:./relpath'
syntax (it could be improved, of course):
cat > git-showrel <<\EOF
#!/bin/sh
rel=$(git rev-parse --show-prefix 2>/dev/null)
git show $(echo "$@" | sed -e "s!:./!:${rel}!")
EOF
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 11:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712190209y485bc2f8w806bd2cad309e74b@mail.gmail.com>
On 2007-12-19 10:09:40 +0000, Catalin Marinas wrote:
> For the 'status --reset', I'll keep it if we have a separate
> 'resolved' command.
?
> In the past, StGIT only used the core git functionality and stayed
> away from the porcelain scripts. We now started to use some of the
> built-in commands more and more and I think it is fine but the git
> scripts look more volatile to me than the C code (look at the many
> variants the git merging went through, from shell scripts to python
> and only now seems to be stabilised with the recursive merge as a
> built-in command).
Hmm? Have we started to use more porcelain lately?
> Adding the functionality I need to git-mergetool would also mean
> always using the latest GIT with StGIT.
It wouldn't keep being the latest git version, though.
> Anyway, if you like git-mergetool, I think you can easily change the
> StGIT configuration to
I don't use interactive merging at all. What I wanted was to get rid
of StGit's own interactive merging.
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
> >
> > > I also don't find 'git add' to be meaningful for marking a
> > > conflict as solved.
> >
> > So maybe let "stg resolved" be an alias for "git add"?
>
> It's not a simple alias, if you use 'stg resolved -a'. Now, if we
> allow stgit.keeporig, it needs even more functionality.
Hmm, yes.
(I still don't quite like it, because I think that if there's anything
that "stg resolved" does that "git add" can't do, then "git add"
should learn to do it. But until it has learned it, it's a
hypothetical argument.)
> > I think it'd be more productive to let stg do one thing -- patch
> > stacks -- and do it well, and rely on git for everything else.
>
> In principle, yes, but I have some minor problems with the UI of GIT
> (like resolved == add). I think there is also a fundamental
> difference between 'git commit' and 'stg refresh'. The former
> requires explicit marking of the files to commit (or use the -a
> option) while the latter always adds all the local changes to the
> current patch. Maybe GIT users are more used to running 'git add'
> after fixing a conflict but I use StGIT almost exclusively.
So you want StGit to do two things: patch stacks, and fix some git UI
warts. Hey, I can live with that. :-) But I firmly believe that the
wart fixing parts of StGit should be (1) optional, so that the same
job can easily be done with just git; and (2) as thin as possible, to
make them easy to explain in terms of git, and cheap to maintain.
> > Of course, if stuff like "stg add" and "stg resolved" are really
> > implemented as three-line wrappers around git commands, we don't
> > have that problem.
>
> For add/rm/cp, they should just be a generic wrapper which doesn't
> even parse the command line options.
OK.
> That's not the case with 'resolved'.
No, I see.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 10:57 UTC (permalink / raw)
To: git
git-instaweb relied on a pipe in a sed script, but this is not supported
by MacOS X sed when using BREs. git-instaweb relies on a working perl
in any case, and perl re are more consistent between platforms, so
replace sed invocation with an equivalent perl invocation.
Also, fix the documented -b "" to work without giving a spurious 'command
not found' error.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-instaweb.sh | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 42d8d7f..3565734 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -232,16 +232,18 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'$(dirname "$fqgitdir")'";#
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
-s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+s#^(my|our) \$projectroot =.*#$1 \$projectroot = "'$(dirname "$fqgitdir")'";#;
+s#(my|our) \$gitbin =.*#$1 \$gitbin = "'$GIT_EXEC_PATH'";#;
+s#(my|our) \$projects_list =.*#$1 \$projects_list = \$projectroot;#;
+s#(my|our) \$git_temp =.*#$1 \$git_temp = "'$fqgitdir/gitweb/tmp'";#;'
gitweb_cgi () {
cat > "$1.tmp" <<\EOFGITWEB
@@GITWEB_CGI@@
EOFGITWEB
- sed "$script" "$1.tmp" > "$1"
+ # The generated scripts assume that perl is /usr/bin/perl
+ # so the assumption here should be no more harmful
+ /usr/bin/perl -p -e "$script" "$1.tmp" > "$1"
chmod +x "$1"
rm -f "$1.tmp"
}
@@ -273,4 +275,4 @@ esac
start_httpd
url=http://127.0.0.1:$port
-"$browser" $url || echo $url
+test -n "$browser" && "$browser" $url || echo $url
--
1.5.4.rc0
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Jakub Narebski @ 2007-12-19 10:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, David Kågedal, git
In-Reply-To: <20071219093816.GB4361@diana.vm.bytemark.co.uk>
On Wed, 19 Dec 2007, Karl Hasselström wrote:
> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> > "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> >
> > > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > >
> > > > Remove "stg resolved"
> > >
> > > I'd like to keep this command. git-mergetool doesn't support the
> > > tool I use (emacs + ediff and more stgit-specific file extensions
> > > like current, patch etc.). I also don't find 'git add' to be
> > > meaningful for marking a conflict as solved.
> >
> > I also would like to have this command kept (and shown in 'stg
> > help'!). Contrary to 'git add' it can check and add to index /
> > update index only for files with conflict; we have -r
> > (ancestor|current|patched) to choose one side, and we could add
> > --check to check if there are no conflict markers with files (useful
> > with -a/--all).
>
> This too sounds like stuff that could profitably be added to "git
> add". Except for the ancestor/current/patched words, it is not
> specific to patch stacks, so the implementation should be in git and
> not in stg.
No it cannot, at least the '-r (ancestor|current|patched)' part for
resetting file to given version, even if we change the wording to
ancestor, ours and theirs. The git-add command is about adding contents,
which updates index, which almost as a intended side-effect clears
merge state, i.e. stages; and not about resetting to stage.
Besides with "stg resolved" you can update index _only_ for files
which were in the conflict, also for -a/--all, and not all the files
not only those which were in the conflict like "git add -u" does.
"stg resolved --check" could happily ignore things that only look
like conflict markers, but must have been intended, because they are
in files not in conflict.
Unless you are talking about adding "resolve"/"resolved" command
to git-core, as a porcelain wrapper around git-update-index, like
"git add"...
P.S. I have just noticed that 'git-checkout' [<tree-ish>] <paths>...
form of operation is not documented; you can derive what it do
only from examples.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 10:19 UTC (permalink / raw)
To: David Kågedal; +Cc: Jakub Narebski, git, Karl Hasselström
In-Reply-To: <87bq8nkoma.fsf@lysator.liu.se>
On 19/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> > I'd also like to re-add the stgit.keeporig option and additional
> > functionality so that the *.{ancestor,current,patched} can be left in
> > the working tree. Some people might use them when manually fixing
> > conflicts (I have a look at them from time to time when the emacs +
> > ediff shows a hard to understand conflict).
>
> Since all the information is in git, it is of course easy to recreate
> it. But the important question to ask is: how do you use these extra
> files? git.el provides a way to diff against both parent versions, and
> maybe that is actually what you need.
>
> I don't mind that you want these files, but they are mostly clutter to
> me.
You can set stgit.keeporig to 'no' if you don't want these files.
For people not using emacs + git.el, the files might be useful. As you
said, you could use 'git diff -2/-3' but, in various occasions I just
wanted to copy a block of code from one of the checked-out stages.
Without this feature, I would have to use plain git and remember what
stage corresponds to my patch.
Note that there are other users (apart from me) that use StGIT almost
exclusively. I really don't like forcing them to use more and more
plain git commands (at some point, they might even discover 'git
rebase -i' to be good enough and give up on StGIT :-)).
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 10:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071219093400.GA4361@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
>
> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > "stg status --reset" is not needed anymore
> >
> > I would keep this as an alias for 'git reset --hard' (see below as
> > well).
> >
> > > Remove "stg add"
> > > Remove "stg rm"
> > > Remove "stg cp"
> >
> > I plan to add a generic command for these kind of aliases. The
> > reason is that I don't really like mixing GIT and StGIT commands (I
> > think at some point I'll get confused and try to run stg commands
> > with git).
>
> How should these aliases be presented in the documentation etc.? I
> suggest making it very clear that they are only aliases.
Yes, 'stg help' should clearly mark them as aliases of git commands.
I'm not sure how I'll do this yet. For the 'status --reset', I'll keep
it if we have a separate 'resolved' command.
> > > Remove "stg resolved"
> >
> > I'd like to keep this command. git-mergetool doesn't support the
> > tool I use (emacs + ediff and more stgit-specific file extensions
> > like current, patch etc.).
>
> So why have a separate command instead of fixing git-mergetool?
In the past, StGIT only used the core git functionality and stayed
away from the porcelain scripts. We now started to use some of the
built-in commands more and more and I think it is fine but the git
scripts look more volatile to me than the C code (look at the many
variants the git merging went through, from shell scripts to python
and only now seems to be stabilised with the recursive merge as a
built-in command).
Adding the functionality I need to git-mergetool would also mean
always using the latest GIT with StGIT. Anyway, if you like
git-mergetool, I think you can easily change the StGIT configuration
to
> > I also don't find 'git add' to be meaningful for marking a conflict
> > as solved.
>
> So maybe let "stg resolved" be an alias for "git add"?
It's not a simple alias, if you use 'stg resolved -a'. Now, if we
allow stgit.keeporig, it needs even more functionality.
> This is all our usual disagreement: You want stg to be a fairly
> standalone tool, and I want it to be a tool to use side by side with
> git. The problem I see with your approach is that stg risks ending up
> like Cogito: it'll provide inspiration for improving git, but will
> itself become obsolete because of the simple fact that git has so much
> more development manpower.
If GIT would have all the functionality I need for my workflow, I
wouldn't mind giving up StGIT (I started StGIT because I needed easier
patch management on top of GIT and modifying Quilt would've been too
intrusive).
> I think it'd be more productive to let stg
> do one thing -- patch stacks -- and do it well, and rely on git for
> everything else.
In principle, yes, but I have some minor problems with the UI of GIT
(like resolved == add). I think there is also a fundamental difference
between 'git commit' and 'stg refresh'. The former requires explicit
marking of the files to commit (or use the -a option) while the latter
always adds all the local changes to the current patch. Maybe GIT
users are more used to running 'git add' after fixing a conflict but I
use StGIT almost exclusively.
> Of course, if stuff like "stg add" and "stg resolved" are really
> implemented as three-line wrappers around git commands, we don't have
> that problem.
For add/rm/cp, they should just be a generic wrapper which doesn't
even parse the command line options. That's not the case with
'resolved'.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 9:50 UTC (permalink / raw)
To: Catalin Marinas, Jakub Narebski; +Cc: Karl Hasselström, git
In-Reply-To: <87bq8nkoma.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
>> On 18/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>>> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>>>
>>> > Thanks again for maintaining these branches.
>>> >
>>> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>>> > > git://repo.or.cz/stgit/kha.git safe
>>>
>>> > > Remove "stg resolved"
>>> >
>>> > I'd like to keep this command. git-mergetool doesn't support the tool
>>> > I use (emacs + ediff and more stgit-specific file extensions like
>>> > current, patch etc.). I also don't find 'git add' to be meaningful for
>>> > marking a conflict as solved.
>>>
>>> I also would like to have this command kept (and shown in 'stg help'!).
>>> Contrary to 'git add' it can check and add to index / update index
>>> only for files with conflict; we have -r (ancestor|current|patched)
>>> to choose one side, and we could add --check to check if there are
>>> no conflict markers with files (useful with -a/--all).
>>
>> I'd also like to re-add the stgit.keeporig option and additional
>> functionality so that the *.{ancestor,current,patched} can be left in
>> the working tree. Some people might use them when manually fixing
>> conflicts (I have a look at them from time to time when the emacs +
>> ediff shows a hard to understand conflict).
>
> Since all the information is in git, it is of course easy to recreate
> it. But the important question to ask is: how do you use these extra
> files? git.el provides a way to diff against both parent versions, and
> maybe that is actually what you need.
Note that I'm talking about the kha/experimental branch here. The
point of my patches there are to make sure that the git index is left
in the unmerged state so that normal git tools can be used. This
means that git diff-files -2 and -3 does what you want.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Junio C Hamano @ 2007-12-19 9:45 UTC (permalink / raw)
To: Marco Roeland; +Cc: git, Pierre Habouzit, Kristian Høgsberg
In-Reply-To: <20071219091515.GA20707@fiberbit.xs4all.nl>
Thanks. That indeed was embarrassing.
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 9:41 UTC (permalink / raw)
To: Jakub Narebski, Catalin Marinas; +Cc: git, Karl Hasselström
In-Reply-To: <b0943d9e0712180852y62c5bea2x61463b235b26ca04@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 18/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>>
>> > Thanks again for maintaining these branches.
>> >
>> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> > > git://repo.or.cz/stgit/kha.git safe
>>
>> > > Remove "stg resolved"
>> >
>> > I'd like to keep this command. git-mergetool doesn't support the tool
>> > I use (emacs + ediff and more stgit-specific file extensions like
>> > current, patch etc.). I also don't find 'git add' to be meaningful for
>> > marking a conflict as solved.
>>
>> I also would like to have this command kept (and shown in 'stg help'!).
>> Contrary to 'git add' it can check and add to index / update index
>> only for files with conflict; we have -r (ancestor|current|patched)
>> to choose one side, and we could add --check to check if there are
>> no conflict markers with files (useful with -a/--all).
>
> I'd also like to re-add the stgit.keeporig option and additional
> functionality so that the *.{ancestor,current,patched} can be left in
> the working tree. Some people might use them when manually fixing
> conflicts (I have a look at them from time to time when the emacs +
> ediff shows a hard to understand conflict).
Since all the information is in git, it is of course easy to recreate
it. But the important question to ask is: how do you use these extra
files? git.el provides a way to diff against both parent versions, and
maybe that is actually what you need.
I don't mind that you want these files, but they are mostly clutter to
me.
--
David Kågedal
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 9:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, David Kågedal, git
In-Reply-To: <m3hcigot3h.fsf@roke.D-201>
On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Remove "stg resolved"
> >
> > I'd like to keep this command. git-mergetool doesn't support the
> > tool I use (emacs + ediff and more stgit-specific file extensions
> > like current, patch etc.). I also don't find 'git add' to be
> > meaningful for marking a conflict as solved.
>
> I also would like to have this command kept (and shown in 'stg
> help'!). Contrary to 'git add' it can check and add to index /
> update index only for files with conflict; we have -r
> (ancestor|current|patched) to choose one side, and we could add
> --check to check if there are no conflict markers with files (useful
> with -a/--all).
This too sounds like stuff that could profitably be added to "git
add". Except for the ancestor/current/patched words, it is not
specific to patch stacks, so the implementation should be in git and
not in stg.
IMHO, of course. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-svn fix for broken symlinks
From: Junio C Hamano @ 2007-12-19 9:37 UTC (permalink / raw)
To: Eric Wong; +Cc: Sverre Johansen, git
In-Reply-To: <20071219084853.GB17787@muzzle>
Thanks. I was about to ask you about some patches I saw on the list
from you.
Pulled; will push out tomorrow.
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 9:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712180809l4d2d01b8j32ab2a410885cc5e@mail.gmail.com>
On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > "stg status --reset" is not needed anymore
>
> I would keep this as an alias for 'git reset --hard' (see below as
> well).
>
> > Remove "stg add"
> > Remove "stg rm"
> > Remove "stg cp"
>
> I plan to add a generic command for these kind of aliases. The
> reason is that I don't really like mixing GIT and StGIT commands (I
> think at some point I'll get confused and try to run stg commands
> with git).
How should these aliases be presented in the documentation etc.? I
suggest making it very clear that they are only aliases.
> > Remove "stg resolved"
>
> I'd like to keep this command. git-mergetool doesn't support the
> tool I use (emacs + ediff and more stgit-specific file extensions
> like current, patch etc.).
So why have a separate command instead of fixing git-mergetool?
> I also don't find 'git add' to be meaningful for marking a conflict
> as solved.
So maybe let "stg resolved" be an alias for "git add"?
This is all our usual disagreement: You want stg to be a fairly
standalone tool, and I want it to be a tool to use side by side with
git. The problem I see with your approach is that stg risks ending up
like Cogito: it'll provide inspiration for improving git, but will
itself become obsolete because of the simple fact that git has so much
more development manpower. I think it'd be more productive to let stg
do one thing -- patch stacks -- and do it well, and rely on git for
everything else.
Of course, if stuff like "stg add" and "stg resolved" are really
implemented as three-line wrappers around git commands, we don't have
that problem.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Marco Roeland @ 2007-12-19 9:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit, Kristian Høgsberg
Due to a subtle typo in a shell case pattern neither alternative worked.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
This is a regression in 'next', introduced on Nov 4th by commit 94362599
"Migrate git-clone to use git-rev-parse --parseopt". Added Kristian as
he works on the builtin version; perhaps nice for a test case (!).
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 9a160ee..b4e858c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -152,7 +152,7 @@ do
die "clones are always made with separate-remote layout" ;;
--reference)
shift; reference="$1" ;;
- -o,--origin)
+ -o|--origin)
shift;
case "$1" in
'')
--
1.5.4.rc0.1162.g3bfea
^ permalink raw reply related
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Johannes Sixt @ 2007-12-19 9:21 UTC (permalink / raw)
To: Andreas Ericsson, Pascal Obry; +Cc: Pascal Obry, git
In-Reply-To: <4768DC78.9010304@op5.se>
Andreas Ericsson schrieb:
> Pascal Obry wrote:
>> Andreas Ericsson a écrit :
>>> Pascal Obry wrote:
>>>> int thread = 0;
>>>> + int no_name_prefix = 0;
>>> Do we not need no double negations, yes?
>>
>> Not sure, looks clearer to use variable name corresponding to the option
>> name to me...
Sure. Only that the option name is --name-prefix, and the no- part of it
is just the negation (that many other long option names also offer).
> Perhaps. We just had this discussion on the list where multiple people had
> extended a negative-sounding option. Personally I find it hard to parse
> and bug-prone to write (and edit) something like
>
> if (!no_prefix)
> add_the_prefix();",
>
> but perhaps that's just me.
Oh, no, you are not alone!
Johannes "We-don't-need-no-steenkin'-duuble-negations" Sixt
^ 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