* 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
* [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: 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
* 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: 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: [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: 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: 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: [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: 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: 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: [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: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: 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: [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: Wincent Colaiuta @ 2007-12-19 11:55 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20071219114823.GA28273@hashpling.org>
El 19/12/2007, a las 12:48, Charles Bailey escribió:
> 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.
Ah, ok. Seems like we were working with different definitions of "hard-
coded". When I said "hard-coded" I meant "determined by you and not
overrideable by the user doing the build without hand-editing the
source file".
> A raw 'perl' in a shell script is dynamic during script run.
Sure, and seeing as you're only doing a simple find/replace any
version of perl installed on the path is probably fine.
But if you are going to provide an absolute path then you should at
least make it user-configurable like all the other perl paths.
Cheers,
Wincent
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-19 12:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Wincent Colaiuta, Git Mailing List
In-Reply-To: <46a038f90712182346t5309448egebfd3726f4d493c5@mail.gmail.com>
Hi,
On Wed, 19 Dec 2007, Martin Langhoff wrote:
> On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > El 19/12/2007, a las 0:41, Martin Langhoff escribi?:
> >
> > > On Dec 19, 2007 4:42 AM, J?rg Sommer <joerg@alea.gnuu.de> wrote:
> > >> I vote for stash print the list, because I dropped in the pitfall.
> > >
> > > I've dropped there myself, and work with a large team where we are
> > > both fans of stash, and scarred by it. Any newcomer to git that
> > > "discovers" stash gets hit by it a dozen times, this is completely
> > > unnecesary.
> >
> > I may be missing something here, but what's the danger here? An
>
> Surprise. Your working directory has *just* changed under your feet.
> Maybe you have an editor with further unsaved changes that is about to
> act confused whether you undo the stash or not.
The funny thing: why do you call stash with unsaved changes anyway? I
mean, come on, even if you were planning to see the usage of stash (which
you would get with -h), you undoubtedly wanted to either stash or unstash
some changes. Otherwise you would not _need_ to see the usage to begin
with.
> > unexpected stash is incredibly easy to revert, unless I'm missing
>
> Once you know about it, yes it is. Once you know about the reflog, you
> can sing and dance and never be worried. But for starting users, it's
> a dangerous command.
No.
Reflogs have nothing to do with it.
If you want to stash changes, you _got_ to know how to unstash those
changes. Otherwise "git reset --hard" would have been your friend.
And so, I cannot help but believe that all users of stash -- even the new
ones -- know about the fundamental concept of stashing/unstashing, and
therefore it is more something like this:
$ git stash
[no usage? What the heck... Oh, it stashed the changes. I did
not want to stash them just yet. Okay:]
$ git unstash
No such command
[Oh, maybe I should have read the man page. Oh, well, the usage
should do...]
$ git stash -h
...
Yes, if you start "git stash" blindly, believing that it does what "git
stash -h" does, you will be bitten by it once.
But as I said, you will be bitten by a plenty commands if you are not
familiar with the concept that "-h" shows the synopsis, "--help" the man
page, and that there is a default action where possible.
But stash really is about things like
$ git stash
$ git pull
$ git stash apply
I do not _want_ to see the stash list in _most_ cases, because I do not
stash away million dirty changes.
And that workflow was what "git stash" was designed for.
> > And nobody commented on the idea I posted earlier which seems to
> > address the concerns about newbies not knowing what "git stash" with
> > no params does:
>
> I agree with making stash more verbose -- if the unlucky new user is
> paying close attention, they'll have instructions on to how to get out
> of trouble. But I agree more with making it "just verbose, no action"
> by default. There are two strong hints:
>
> - all other state-changing commands take parameters
What about "git commit", "git reset", "git fetch"? These definitely
change state of the repository.
> - quite a few people in this list have gotten burned with it
Okay, let's have a little calculation: IIRC 3 people (let's make it 10, to
be conservative) have said that they had this problem. I must assume that
all other people did not have the problem, or at least saw why the default
action of "git stash" is what it is.
That said, if you _have_ to have the default changed, then I'll probably
implement a "git push" and "git pop" alias here, so that I cannot get
annoyed by stash's "new and improved" behaviour.
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Wincent Colaiuta @ 2007-12-19 12:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712191150240.23902@racer.site>
El 19/12/2007, a las 13:01, Johannes Schindelin escribió:
> But stash really is about things like
>
> $ git stash
> $ git pull
> $ git stash apply
>
> I do not _want_ to see the stash list in _most_ cases, because I do
> not
> stash away million dirty changes.
>
> And that workflow was what "git stash" was designed for.
+1.
Wincent
^ permalink raw reply
* Re: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-19 12:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gerald Gutierrez, 'Junio C Hamano', git
In-Reply-To: <vpqtzmfvz1d.fsf@bauges.imag.fr>
Hi,
On Wed, 19 Dec 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Here's what the git-commit manpage on kernel.org says: "git-commit -
> >> Record changes to the repository".
> >
> > Yes. Changes, as in "take this _file_ instead". Not "edit this file,
> > remove those lines, add these here, etc.".
>
> That said, I think the wording of the man page could be better.
> Perhaps "Record new snapshot to the repository" or "Record current
> state of the working tree to the repository".
How about "record a new revision"?
Ciao,
Dscho
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 12:10 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712190340p23341dd8lb9ebbbce9b29cb8e@mail.gmail.com>
On 2007-12-19 11:40:41 +0000, Catalin Marinas wrote:
> 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'.
Ah, right.
> 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.
True.
> > 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.
We should probably use cat-file or something instead.
> > It wouldn't keep being the latest git version, though.
>
> Yes, but at least initially it should be pretty recent.
:-)
> > 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.
Jolly good! My stack was getting unwieldy ...
> > 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.
Yes, with David's conflict series.
> At some point, we could make it safe for 'git rebase' but I think we
> need the DAG patches.
I wouldn't resurrect the DAG patches for this; I'd just invoke "stg
repair" automatically when we detect that top != HEAD.
But I think that for "git rebase", we'd want to teach "repair" to
detect that the patches' commits have been changed, rather than just
marking them unapplied.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-19 12:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, 'Junio C Hamano', git
In-Reply-To: <Pine.LNX.4.64.0712191209140.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 19 Dec 2007, Matthieu Moy wrote:
>
>> That said, I think the wording of the man page could be better.
>> Perhaps "Record new snapshot to the repository" or "Record current
>> state of the working tree to the repository".
>
> How about "record a new revision"?
Sounds good, yes.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
From: Johannes Schindelin @ 2007-12-19 12:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071219064500.GB8915@spearce.org>
Hi,
On Wed, 19 Dec 2007, Shawn O. Pearce wrote:
> This has also bitten me a few times. :-\
Sorry to hear that. Both patches look sensible to me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <20071219115319.GA29184@hashpling.org>
Now that I think about it, this replacement patch has invalidated the
original comment to some extent. A replacement patch follows, with a
more consistent comment.
Charles.
^ permalink raw reply
* [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <20071219122308.GA32088@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..ad0723c 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"
+ # Use the configured full path to perl to match the generated
+ # scripts' 'hashpling' line
+ "$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
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply related
* [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Johannes Schindelin @ 2007-12-19 13:40 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
When you are in a deeply-nested directory structure, and just want
to reference a blob in a past revision, it can be pretty slow to
type out "HEAD~29:/bla/blub/.../that-file".
This patch makes "HEAD~29:./that-file" substitute the current prefix
for "./". If there is not working directory, the prefix is empty.
Note that this patch does not handle "../", and neither do I plan to.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 18 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*.
Okay, this is a proposed patch. It leaves the existing
"HEAD:<path>" handling alone, and only touches "HEAD:./<path>",
which would have been invalid anyway (except if you hacked your
objects database to include a tree named ".").
Note: this patch is not meant for application directly. It should
be split into get_current_prefix() as one patch, and the
sha1_name.c stuff as the second. (Not only to boost my ohloh
statistics, but because they are logically two separate things.)
Note, too: this is a quick and little-bit-dirty patch, not well
tested. Particularly, I was unable to trigger the "No <path> in
<rev>" error path, so I am not confident that this handling is
correct.
Note also: in contrast to Alex' approach, this will not only work
for git-show, but for all callers of get_sha1().
cache.h | 1 +
setup.c | 16 +++++++++++++---
sha1_name.c | 17 ++++++++++++++---
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index 39331c2..83a2c31 100644
--- a/cache.h
+++ b/cache.h
@@ -225,6 +225,7 @@ extern char *get_index_file(void);
extern char *get_graft_file(void);
extern int set_git_dir(const char *path);
extern const char *get_git_work_tree(void);
+extern const char *get_current_prefix(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/setup.c b/setup.c
index b59dbe7..fb9b680 100644
--- a/setup.c
+++ b/setup.c
@@ -3,6 +3,12 @@
static int inside_git_dir = -1;
static int inside_work_tree = -1;
+static const char *current_prefix;
+
+const char *get_current_prefix()
+{
+ return current_prefix;
+}
const char *prefix_path(const char *prefix, int len, const char *path)
{
@@ -267,6 +273,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
/* config may override worktree */
if (check_repository_format_gently(nongit_ok))
return NULL;
+ current_prefix = retval;
return retval;
}
if (check_repository_format_gently(nongit_ok))
@@ -279,7 +286,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
- return retval;
+ current_prefix = retval;
+ return current_prefix;
}
if (nongit_ok) {
*nongit_ok = 1;
@@ -339,7 +347,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
offset++;
cwd[len++] = '/';
cwd[len] = 0;
- return cwd + offset;
+ current_prefix = cwd + offset;
+ return current_prefix;
}
int git_config_perm(const char *var, const char *value)
@@ -396,7 +405,8 @@ const char *setup_git_directory(void)
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
- return rel && *rel ? strcat(rel, "/") : NULL;
+ current_prefix = rel && *rel ? strcat(rel, "/") : NULL;
+ return current_prefix;
}
return retval;
diff --git a/sha1_name.c b/sha1_name.c
index 13e1164..6f61d26 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -712,9 +712,20 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp-name, tree_sha1)) {
+ const char *prefix;
+ if (!prefixcmp(cp + 1, "./") &&
+ (prefix = get_current_prefix())) {
+ unsigned char subtree_sha1[20];
+ if (get_tree_entry(tree_sha1, prefix,
+ subtree_sha1, mode))
+ return error("No '%s' in '%.*s'",
+ prefix, cp-name, name);
+ memcpy(tree_sha1, subtree_sha1, 20);
+ cp += 2;
+ }
+ return get_tree_entry(tree_sha1, cp+1, sha1, mode);
+ }
}
return ret;
}
--
1.5.4.rc0.72.g536e9
^ permalink raw reply related
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