* Re: C++ *for Git*
From: Marco Costalba @ 2007-09-22 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Git
In-Reply-To: <Pine.LNX.4.64.0709221348180.28395@racer.site>
On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> We don't want C++. Why is that so hard to accept?
>
Dmitry, I think what Johannes says in the above line is 100% the core
point of this (sad) discussion.
You cannot force/convince someone to use something he hates. That's
it. And there's no point in trying to do this.
git developers were also kind enough to give explanations on 'why' C++
is not a good language for them. Do you don't agree? do you find the
arguments not totally satisfying for you? That's not their problem.
I like C++ (a my little git related GUI tool called qgit is done in
C++) and at the same time I understand also much of the concerns that
where expressed in the list.
Your position will never be successful for a number of reasons, some
clear expressed other less clear but at the same time, perhaps more
important. So I really don't understand why you insist.
Thanks
Marco
P.S: The example you show is a pity for C++, it's like to advertise a
1000cc 200Hp motorbike saying "...and you will no have problems in
parking in your box."
^ permalink raw reply
* Re: C++ *for Git*
From: Kyle Rose @ 2007-09-22 15:15 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
You know, git *is* free software. Feel free to fork it and add all the
C++ code you want.
FWIW, I am of the opinion that Python or Ruby (or god forbid, Perl)
would have been a better choice for something like git that does lots of
text processing... furthermore, I think the exception handling, garbage
collection, and implicit object destruction provided by those languages
(and by C++, as overwrought as it is) makes any codebase easier to
understand and maintain.
But that's irrelevant: git is written in C. That's the way it is, and
you should accept that or fork.
Kyle
Dmitry Kakurin wrote:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.
> In no way I want to restart it.
^ permalink raw reply
* Re: fromcvs installation [was: cvsimport bug on branches [was: conversion to git]]
From: Simon 'corecode' Schubert @ 2007-09-22 15:08 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Robin Rosenberg, Johannes Schindelin, Git Mailing List
In-Reply-To: <86B33DFE-65E6-4F8D-8483-509ACA4FA2F8@zib.de>
Steffen Prohaska wrote:
> Nonetheless a more detailed description how to install fromcvs
> would be helpful. I remember it was not obvious to me.
[..]
> I think a step by step explanation how to proceed would have helped me.
Could you write down what you had to do and where the problems are as an
extension to the current README?
Thanks,
simon
^ permalink raw reply
* Re: C++ *for Git*
From: Johannes Schindelin @ 2007-09-22 12:48 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
Hi,
On Sat, 22 Sep 2007, Dmitry Kakurin wrote:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.
I think "pointless" is more to the point.
We don't want C++. Why is that so hard to accept?
Ciao,
Dscho
^ permalink raw reply
* Re: Git as a filesystem
From: Johannes Schindelin @ 2007-09-22 12:06 UTC (permalink / raw)
To: Eric Wong; +Cc: Nicolas Pitre, Peter Stahlir, git
In-Reply-To: <20070922020632.GB8327@muzzle>
Hi,
On Fri, 21 Sep 2007, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Fri, 21 Sep 2007, Eric Wong wrote:
> > >
> > > On a similar note, has anybody experimented with using git to store
> > > maildirs or news spools? I'd imagine the quoted portions of most
> > > message threads could be delta-compressed quite efficiently.
> >
> > I store all my mail in a git repository. Works beautifully. Except
> > that the buffers on my laptop are constantly full :-( So a simple
> > commit takes some waiting.
> >
> > Should be no issue on normal (desktop) machines.
>
> D'oh. I already have maildir performance problems on my laptop.
Umm. Regular operation is not affected, since I (add and) commit only
when I weeded out all those spams and other unwanted mail.
> I wonder how well only having an index and no commits (no versioning),
> and manual packing with pack-objects would work. Packing could be
> optimized to order objects based on the Message-Id, References, and
> In-Reply-To headers, too.
The most efficient way would be to have a mailer backend accessing the
database, and then not have a working directory, methinks (especially with
these amounts of mail I am juggling ATM).
Time forbids working on this, though.
Ciao,
Dscho
^ permalink raw reply
* Re: C++ *for Git*
From: David Kastrup @ 2007-09-22 11:11 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++
> *in general*.
> In no way I want to restart it.
Then don't.
> Just a very straight-forward usage of only 3 C++ features:
> 1. Constructors
> 2. Destructors
> 3. Better syntax (ext_header.append_ext_header
> vs. strbuf_append_ext_header(&ext_header, )
>
> The generated code will be exactly the same.
It won't. It will _do_ exactly the same (modulo the tenfold
likelihood of compiler bugs) but hardly using the same code.
> Yet the source code becomes more readable and MUCH less error
> prone. How is this not a win?
Because it is just your claim that this is more readable.
> One (sensible) argument that I've heard in the previous discussion
> was: you let a little bit of C++ in and then it gets more and more
> complex and the code quality decreases.
> This problem is solved by having "quality gates".
> Again, *for Git* these quality gates already exist: only few people
> have "commit access".
> If/when somebody tries to be too fancy, what stops Junio from replying
> "we don't use Library-X/C++-feature-Y in Git, please change your code
> and resubmit" and throwing that fix away? Nothing.
Well, what stops him from replying "we don't use C++ in Git, please
change your code and resubmit"?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-22 11:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4wbgp9t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>>
>>>> That is, what does the shell say if you do this?
>>>>
>>>> case Ultra in
>>>> Super)
>>>> false ;;
>>>> Hyper)
>>>> true ;;
>>>> esac &&
>>>> echo case returned ok
>>>
>>> It says 'case returned ok', so I will try to understand why it
>>> works here and does not work in the 'while' construct.
>>
>> What you actually need to do is
>>
>> false
>> case Ultra in
>> Super)
>> false ;;
>> Hyper)
>> true ;;
>> esac && echo case returned ok
>
> AHHHHHH.
>
> Is "case" supposed to be transparent?
Not that I would know. It is basically a revival of the
false
if false then : ; fi || echo "this fails!?!"
bug that probably has been fixed by now. For obvious reasons,
conditionals without a taken branch are considered to have an exit
code of 0.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* C++ *for Git*
From: Dmitry Kakurin @ 2007-09-22 10:42 UTC (permalink / raw)
To: Git
We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
general*.
In no way I want to restart it. But *very specifically*, and *for Git*:
We already have strbuf "class" to do string/buffer manipulations.
Kudos to Pierre Habouzit for doing the refactoring work!
Now, what I fail to understand is how this:
static void write_global_extended_header(const unsigned char *sha1)
{
struct strbuf ext_header;
strbuf_init(&ext_header, 0);
strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
strbuf_release(&ext_header);
}
is better than this:
static void write_global_extended_header(const unsigned char *sha1)
{
strbuf ext_header;
ext_header.append_ext_header("comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
}
?
Note, there is no Boost/multiple inheritance/template
metaprogramming/std::string/whatever-else-scares-you-in-C++ in the second
piece of code.
Just a very straight-forward usage of only 3 C++ features:
1. Constructors
2. Destructors
3. Better syntax (ext_header.append_ext_header vs.
strbuf_append_ext_header(&ext_header, )
The generated code will be exactly the same.
Yet the source code becomes more readable and MUCH less error prone. How is
this not a win?
One (sensible) argument that I've heard in the previous discussion was: you
let a little bit of C++ in and then it gets more and more complex and the
code quality decreases.
This problem is solved by having "quality gates".
Again, *for Git* these quality gates already exist: only few people have
"commit access".
If/when somebody tries to be too fancy, what stops Junio from replying "we
don't use Library-X/C++-feature-Y in Git, please change your code and
resubmit" and throwing that fix away? Nothing.
- Dmitry
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Karl Hasselström @ 2007-09-22 9:06 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20070921082348.GA5152@mayonaise>
On 2007-09-21 01:23:48 -0700, Eric Wong wrote:
> The @REV and -rREV distinction/ambiguity has always confused me in svn,
> too. It always seems that it needed to be one way sometimes, the other
> way at other times, and even _both_ at other times...
-rREV specifies the operative revision, and @REV specifies the peg
revision. See the clear but dreadfully long explanation here:
http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
In short, it's a way to manage the complexity that comes from
considering files (and directories!) to have an identity that is
preserved across copies and renames.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Michal Vitecek @ 2007-09-22 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vk5qjixqy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>>>>>> I made it because I want to use my own pretty format which currently
>>>>>> only allows '%s' for subject and '%b' for body. But '%b' is
>>>>>> substituted with <undefined> if the body is "missing" which I
>>>>>> obviously don't like :)
>>>>> Then you should fix %b not to show "<undefined>".
>>>> I'll do it if it is okay. Shall I do the same for the other
>>>> placeholders as well?
>>> Yeah. Don't know why I did it that way.
>> Here comes the big patch :)
>
> Now, this breaks t6006 which needs this patch.
Oops - I'm sorry about that. I ran the test suite (1.5.3.1) but it
failed in 2 tests before the patch and in 2 tests after it so I
considered it okay.
> Looking at this patch, I am not sure if your change is really a
> desirable one --- shouldn't it be removing the line itself, not
> just <unknown> token?
This sounds as the best solution. I'll look into it. Thanks for your time.
--
fuf (fuf@mageo.cz)
^ permalink raw reply
* [StGit PATCH 3/4] Properly remove all config for a deleted branch
From: Karl Hasselström @ 2007-09-22 8:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Aneesh Kumar, Karl Hasselström
In-Reply-To: <20070922084334.29884.60506.stgit@yoghurt>
This uses "git-config --remove-section", which was first released in
git 1.5.1-rc1. I'm not sure if this is later than what we used to
depend on; we already use "git-config --rename-section", but that's
been in since git 1.5.0-rc0.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/config.py | 7 +++++++
stgit/stack.py | 9 ++-------
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/stgit/config.py b/stgit/config.py
index 799e1d7..51818bd 100644
--- a/stgit/config.py
+++ b/stgit/config.py
@@ -76,6 +76,13 @@ class GitConfig:
).returns([0, 1]).run()
self.__cache.clear()
+ def remove_section(self, name):
+ """Remove a section in the config file. Silently do nothing if
+ the section doesn't exist."""
+ Run('git-repo-config', '--remove-section', name
+ ).returns([0, 1]).discard_stderr().discard_output()
+ self.__cache.clear()
+
def set(self, name, value):
Run('git-repo-config', name, value).run()
self.__cache[name] = value
diff --git a/stgit/stack.py b/stgit/stack.py
index d6f6a6e..adfff25 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -744,13 +744,8 @@ class Series(PatchSet):
except GitException:
out.warn('Could not delete branch "%s"' % self.get_name())
- # Cleanup parent informations
- # FIXME: should one day make use of git-config --section-remove,
- # scheduled for 1.5.1
- config.unset('branch.%s.remote' % self.get_name())
- config.unset('branch.%s.merge' % self.get_name())
- config.unset('branch.%s.stgit.parentbranch' % self.get_name())
- config.unset(self.format_version_key())
+ config.remove_section('branch.%s' % self.get_name())
+ config.remove_section('branch.%s.stgit' % self.get_name())
def refresh_patch(self, files = None, message = None, edit = False,
show_patch = False,
^ permalink raw reply related
* [StGit PATCH 4/4] Add simple test for "stg branch --delete"
From: Karl Hasselström @ 2007-09-22 8:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Aneesh Kumar, Karl Hasselström
In-Reply-To: <20070922084334.29884.60506.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1005-branch-delete.sh | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100755 t/t1005-branch-delete.sh
diff --git a/t/t1005-branch-delete.sh b/t/t1005-branch-delete.sh
new file mode 100755
index 0000000..7a0872e
--- /dev/null
+++ b/t/t1005-branch-delete.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='Attempt to delete branches'
+
+. ./test-lib.sh
+
+stg init
+
+test_expect_success 'Create a branch (and switch to it)' '
+ stg branch --create foo
+ '
+
+test_expect_success 'Delete a branch' '
+ stg branch --delete master
+ '
+
+test_expect_success 'Make sure the branch ref was deleted' '
+ [ -z "$(git show-ref | grep master | tee /dev/stderr)" ]
+ '
+
+test_expect_success 'Make sure the branch config was deleted' '
+ [ -z "$(git config -l | grep branch\\.master | tee /dev/stderr)" ]
+ '
+
+test_expect_success 'Make sure the branch files were deleted' '
+ [ -z "$(find .git -type f | grep master | tee /dev/stderr)" ]
+ '
+
+test_done
^ permalink raw reply related
* [StGit PATCH 1/4] Don't special-case the "master" branch during branch delete
From: Karl Hasselström @ 2007-09-22 8:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Aneesh Kumar, Karl Hasselström
In-Reply-To: <20070922084334.29884.60506.stgit@yoghurt>
It's unintuitive, unsymmetric and doesn't work if there is no
"master". Instead, prohibit deletion of the current branch.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/branch.py | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index 2d491d5..8c99936 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -96,17 +96,10 @@ def __delete_branch(doomed_name, force = False):
out.start('Deleting branch "%s"' % doomed_name)
if __is_current_branch(doomed_name):
- check_local_changes()
- check_conflicts()
- check_head_top_equal()
-
- if doomed_name != 'master':
- git.switch_branch('master')
+ raise CmdException('Cannot delete the current branch')
doomed.delete(force)
-
- if doomed_name != 'master':
- git.delete_branch(doomed_name)
+ git.delete_branch(doomed_name)
out.done()
^ permalink raw reply related
* [StGit PATCH 2/4] Don't try to delete the branch twice
From: Karl Hasselström @ 2007-09-22 8:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Aneesh Kumar, Karl Hasselström
In-Reply-To: <20070922084334.29884.60506.stgit@yoghurt>
We already delete it in Stack.delete(), so don't do it here too.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/branch.py | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index 8c99936..c16fc69 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -99,7 +99,6 @@ def __delete_branch(doomed_name, force = False):
raise CmdException('Cannot delete the current branch')
doomed.delete(force)
- git.delete_branch(doomed_name)
out.done()
^ permalink raw reply related
* [StGit PATCH 0/4] Fix "stg branch --delete"
From: Karl Hasselström @ 2007-09-22 8:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Aneesh Kumar
In-Reply-To: <20070921094830.GB26307@diana.vm.bytemark.co.uk>
This fixes the two issues Aneesh reported (failed branch deletion,
leftover config stuff), and adds a test. The test is added after the
fixes this time, so the test suite passes at every step.
Also available from
git://repo.or.cz/stgit/kha.git safe
---
Karl Hasselström (4):
Add simple test for "stg branch --delete"
Properly remove all config for a deleted branch
Don't try to delete the branch twice
Don't special-case the "master" branch during branch delete
stgit/commands/branch.py | 10 +---------
stgit/config.py | 7 +++++++
stgit/stack.py | 9 ++-------
t/t1005-branch-delete.sh | 29 +++++++++++++++++++++++++++++
4 files changed, 39 insertions(+), 16 deletions(-)
create mode 100755 t/t1005-branch-delete.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Junio C Hamano @ 2007-09-22 8:32 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070922035434.GA99140@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
> are working and they are not Bash. But I would not tell that
> the shell is broken now -- I had not seen the POSIX specification.
> Does it specifies how the shell should work in this case?
I have always been assuming it to be the case (this construct is
not my invention but is an old school idiom I just inherited
from my mentor) and never looked at the spec recently, but I
re-read it just to make sure. The answer is yes.
Visit http://www.opengroup.org/onlinepubs/000095399/ and follow
"Shell and Utilities volume (XCU)" and then "Case conditional
construct".
Exit Status
The exit status of case shall be zero if no patterns are
matched. Otherwise, the exit status shall be the exit status of
the last command executed in the compound-list.
So, as David suggests, if
false
case Ultra in
Super) false ;;
Hyper) true ;;
esac && echo case returned ok
does not say "case returned ok", then the shell has a bit of
problem.
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Vineet Kumar @ 2007-09-22 7:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4wbgp9t.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano (gitster@pobox.com) [070921 23:58]:
> David Kastrup <dak@gnu.org> writes:
>
> > Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> >
> >>> That is, what does the shell say if you do this?
> >>>
> >>> case Ultra in
> >>> Super)
> >>> false ;;
> >>> Hyper)
> >>> true ;;
> >>> esac &&
> >>> echo case returned ok
> >>
> >> It says 'case returned ok', so I will try to understand why it
> >> works here and does not work in the 'while' construct.
> >
> > What you actually need to do is
> >
> > false
> > case Ultra in
> > Super)
> > false ;;
> > Hyper)
> > true ;;
> > esac && echo case returned ok
>
> AHHHHHH.
>
> Is "case" supposed to be transparent?
That doesn't seem to be the case (no pun intended) on either bash or
dash. Here's what I tested on bash (apologies for the long lines; these
are verbatim pastes from my shell):
vineet@sprocket:~$ false
vineet@sprocket:~$ case Super in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
super
vineet@sprocket:~$ false
vineet@sprocket:~$ case Hyper in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
hyper
case returned ok
vineet@sprocket:~$ false
vineet@sprocket:~$ case Ultra in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
case returned ok
vineet@sprocket:~$
and on dash:
vineet@sprocket:~$ dash
$ false
$ case Super in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
super
$ false
$ case Hyper in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
hyper
case returned ok
$ false
$ case Ultra in Super) echo super ; false ;; Hyper) echo hyper ; true ;; esac && echo case returned ok
case returned ok
$
So it seems like a "case" statement isn't special; it returns a status
like any other statement.
Vineet
--
http://www.doorstop.net/
^ permalink raw reply
* fromcvs installation [was: cvsimport bug on branches [was: conversion to git]]
From: Steffen Prohaska @ 2007-09-22 8:07 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Johannes Schindelin, Git Mailing List,
Simon 'corecode' Schubert
In-Reply-To: <200709220116.26369.robin.rosenberg.lists@dewire.com>
On Sep 22, 2007, at 1:16 AM, Robin Rosenberg wrote:
> fredag 21 september 2007 skrev Johannes Schindelin:
>> No, it's yet another dependency. And the quality of the code still
>> depends on the programmer, not the language.
>
> I think I can agree there, on both counts. But, if you want a good
> incremental
> CVS importer and have access to the rcs files, that's the one there
> is.
>
> git-cvsimport has a dependency on cvsps, which isn't included. You
> have to
> to look it up yourself chooing among a dozen unequally bad versions.
> Installing ruby isn't any harder.
>
> The dependency excludes it from being included with Git, but it
> does not
> disqualify it as a tool on it's own.
Nonetheless a more detailed description how to install fromcvs
would be helpful. I remember it was not obvious to me.
The README of fromcvs only says
'''
Prerequisites:
- ruby (1.8.5 known working)
- fromcvs, <http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs>
- rcsparse, <http://ww2.fs.ei.tum.de/~corecode/hg/rcsparse> (ruby
module)
- Ruby/RBTree, <http://raa.ruby-lang.org/project/ruby-rbtree/>
- for git: git-fast-import, part of git 1.5
- for db/commitset: sqlite3 + sqlite3-ruby (available as gem)
'''
I didn't use ruby before and had no idea how to install a ruby module
or what 'available as gem' means. And by the way, it was not obvious
for me that I can download the tip of the mercurial branch by clicking
on the 'gz' link at the top of the page.
I think a step by step explanation how to proceed would have helped me.
Steffen
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Junio C Hamano @ 2007-09-22 6:58 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86tzpnwdha.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>
>>> That is, what does the shell say if you do this?
>>>
>>> case Ultra in
>>> Super)
>>> false ;;
>>> Hyper)
>>> true ;;
>>> esac &&
>>> echo case returned ok
>>
>> It says 'case returned ok', so I will try to understand why it
>> works here and does not work in the 'while' construct.
>
> What you actually need to do is
>
> false
> case Ultra in
> Super)
> false ;;
> Hyper)
> true ;;
> esac && echo case returned ok
AHHHHHH.
Is "case" supposed to be transparent?
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Junio C Hamano @ 2007-09-22 6:54 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070922035434.GA99140@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> By the way, my FreeBSD is 7-CURRENT, but I'll test on 6-STABLE
> and perhaps on 4-STABLE on Monday.
> ...
>> That is, what does the shell say if you do this?
>>
>> case Ultra in
>> Super)
>> false ;;
>> Hyper)
>> true ;;
>> esac &&
>> echo case returned ok
>
> It says 'case returned ok', so I will try to understand why it
> works here and does not work in the 'while' construct.
I vaguely recall somebody else had exactly this issue and he
concluded that the shell was busted. I do not recall the
details of the story but interestingly, if he did something that
accesses "$#" before the problematic "while case $# in ..." the
shell behaved for him in his experiments.
Just to make sure you do not misunderstand me, I am not trying
to be difficult. I am trying to assess (1) if it is sensible to
support that broken shell, and (2) if so what the exact breakage
is, especially because as the above shows the breakage does not
look like what your "fix" literally suggests, and what is
involved in working it around.
Also by my comment about "/bin/sh and bash not being the only
shells available on FreeBSD", I did not mean that you should
change your /bin/sh. You can build git with SHELL_PATH make
varilable pointing at a non-broken shell, which does not have to
be installed as /bin/sh.
^ permalink raw reply
* [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Shawn O. Pearce @ 2007-09-22 5:04 UTC (permalink / raw)
To: Junio C Hamano, Paul Mackerras; +Cc: git
If TCLTK_PATH points at a pure Win32 Tcl/Tk implementation but you
are running git (and thus gitk) from within Cygwin the value of
$0 is a UNIX style Cygwin path which the native Tcl/Tk is unable
to open and parse. In such a situation we need to switch to using
the Windows style path by running $0 through cygpath.
This doesn't have a negative impact when using the Cygwin based
Tcl/Tk build as that is still close enough to a native Win32
application that it can read the Windows style path when sourcing
gitk. On any other platform we don't want gitk to do anything
different so we keep argv0=$0.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Yes, I admit this is an odd patch. I can certainly carry it in
my own tree (I already carry some other patches) but I wonder if
we shouldn't include it as some users may actually try to do this,
just like I did. Latest git-gui `master` already has changes to its
Makefile and shell startup boilerplate to handle this weird case.
Makefile | 6 +++++-
gitk | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 0055eef..4fc6eb3 100644
--- a/Makefile
+++ b/Makefile
@@ -386,6 +386,7 @@ EXTLIBS =
#
# Platform specific tweaks
#
+gitk_argv0 := $$0
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
@@ -443,6 +444,7 @@ ifeq ($(uname_O),Cygwin)
NO_MMAP = YesPlease
NO_IPV6 = YesPlease
X = .exe
+ gitk_argv0 := `cygpath --windows --absolute "$(gitk_argv0)"`
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
@@ -763,7 +765,9 @@ strip: $(PROGRAMS) git$X
gitk-wish: gitk GIT-GUI-VARS
$(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
+ sed -e '1,30s|^argv0=$$0|argv0=$(gitk_argv0)|' \
+ -e '1,4s|^exec .* "$$argv0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$argv0"|' \
+ <gitk >$@+ && \
chmod +x $@+ && \
mv -f $@+ $@
diff --git a/gitk b/gitk
index 300fdce..2366911 100755
--- a/gitk
+++ b/gitk
@@ -1,6 +1,7 @@
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
-exec wish "$0" -- "$@"
+argv0=$0; \
+exec wish "$argv0" -- "$@"
# Copyright (C) 2005-2006 Paul Mackerras. All rights reserved.
# This program is free software; it may be used, copied, modified
--
1.5.3.2.1036.gcd14a
^ permalink raw reply related
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-22 4:06 UTC (permalink / raw)
To: git
In-Reply-To: <20070922035434.GA99140@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>> That is, what does the shell say if you do this?
>>
>> case Ultra in
>> Super)
>> false ;;
>> Hyper)
>> true ;;
>> esac &&
>> echo case returned ok
>
> It says 'case returned ok', so I will try to understand why it
> works here and does not work in the 'while' construct.
What you actually need to do is
false
case Ultra in
Super)
false ;;
Hyper)
true ;;
esac && echo case returned ok
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Eygene Ryabinkin @ 2007-09-22 3:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x6zinjf.fsf@gitster.siamese.dyndns.org>
Junio, good day.
Fri, Sep 21, 2007 at 04:52:52PM -0700, Junio C Hamano wrote:
> > Option parsing in the Git shell scripts uses the construct 'while
> > case "$#" in 0) break ;; esac; do ... done'. This is neat, because
> > it needs no external commands invocation. But in the case when
> > /bin/sh is not GNU Bash (for example, on FreeBSD) this cycle will
> > not be executed at all.
>
> I do not doubt that "while case $# in 0) break ;; esac" does not
> work for your shell. But I think the above comment is grossly
> misleading.
>
> Don't mention bash there. You sound as if you are blaming
> bashism, but the thing is, your shell is simply broken.
OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
are working and they are not Bash. But I would not tell that
the shell is broken now -- I had not seen the POSIX specification.
Does it specifies how the shell should work in this case?
> You have other choices than bash on BSD don't you?
Did not understand the question, sorry. The thing is that
FreeBSD has /bin/sh that is derived from the original Berkeley
shell. And it is desirable to have it working with Git
script, since I don't want to make bash (or whatever shell
that is not /bin/sh) a dependency for the port.
> My quick test shows that ksh, pdksh and dash seem to work
> correctly. This idiom is what I picked up around late 80's from
> somebody, and kept using on many variants of Unices. I would
> find quite surprising that something that claims to be a shell
> does not work correctly. Even /bin/sh that comes with Solaris
> seems to work correctly, which should tell you something.
>
> OpenBSD's /bin/sh seems to be Ok; I do not know whose shell they
> use, but it seems to be hard-linked to /bin/ksh which is pdksh.
OK, I think I need to find out why FreeBSD's /bin/sh behaves
like this, because the test you propose on your next message
works. See below.
By the way, my FreeBSD is 7-CURRENT, but I'll test on 6-STABLE
and perhaps on 4-STABLE on Monday.
Fri, Sep 21, 2007 at 07:33:21PM -0700, Junio C Hamano wrote:
> I am assuming that this works around _a_ bug in that /bin/sh; I
> would make sure I understand the nature of the bug. Is it Ok to
> understand that with that shell, after this construct runs:
>
> case <some word> in
> <case arm #1>)
> something ;;
> <case arm #2>)
> something else ;;
> esac
>
> the status from the whole case statement is false, when <some word>
> does not match any of the glob patterns listed in any of the case arm?
>
> That is, what does the shell say if you do this?
>
> case Ultra in
> Super)
> false ;;
> Hyper)
> true ;;
> esac &&
> echo case returned ok
It says 'case returned ok', so I will try to understand why it
works here and does not work in the 'while' construct.
Thanks for the pointer!
--
Eygene
^ permalink raw reply
* Re: Git as a filesystem
From: Sam Vilain @ 2007-09-22 3:09 UTC (permalink / raw)
To: Martin Langhoff
Cc: Dmitry Potapov, Peter Stahlir, Karl Hasselström,
Johannes Schindelin, git
In-Reply-To: <46a038f90709211656n5b23783eu330e8b655cd42aa8@mail.gmail.com>
Martin Langhoff wrote:
> On 9/22/07, Dmitry Potapov <dpotapov@gmail.com> wrote:
>
>> used to create the original file. So, if you put any .deb file in such
>> a system, you will get back a different .deb file (with a different SHA1).
>> So, aside high CPU and memory requirements, this system cannot work in
>> principle unless all users have exactly the same version of a compressor.
>>
>
> Was thinking the same - compression machinery, ordering of the files,
> everything. It'd be a nightmare to ensure you get back the same .deb,
> without a single different bit.
>
> Debian packaging toolchain could be reworked to use a more GIT-like
> approach - off the top of my head, at least
>
> - signing/validating the "tree" of the package rather than the
> completed package could allow the savings in distribution you mention,
> decouple the signing from the compression, and simplify things like
> debdiff
>
> - git or git-like strategies for source packages
>
Nightmare indeed. I actually wrote a proof of concept for this idea for
gzip.
http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=archive-blobs
(see also
http://planet.catalyst.net.nz/blog/2006/07/17/samv/xteddy_caught_consuming_rampant_amounts_of_disk_space)
I usually warn people that this undertaking is "slightly insane".
My implementation was designed to be called like "git-hash-object".
What it did was look at the input stream, and detect quickly whether it
looked like a gzip stream. If it was, it would decompress it and then
try to compress the first few blocks using different compression
libraries and settings to determine what settings were used. If it
could find the right settings for the first meg or so, then it would
bank on the rest being identical as well, record which compressor and
what settings were used and write the uncompressed object, as well as
the information needed to reconstruct the gzip header, to a new type of
object called an "archive" object. If the stream could not be
reproduced then it would save the raw stream instead. For something
like a Debian archive, it is very likely that all compressed streams
will be reproducible, because they will almost all be compressed using
the same implementation of gzip.
For tar and .ar files, this can be slightly more deterministic of
course. It doesn't even need to be particularly savvy of what all the
fields are - just locate the files in the .tar, write out a tree, and
then write a TOC that lists tree entries and contains any extra data (ie
headers, etc).
In hindsight, making a new object type was probably a mistake. If I
were to re-undertake this I would not go down that path, though I'd
certainly consider using tag objects for the extra data, and throwing
them in the tree like submodules. It would also be essential in a
"real" solution to bundle reference copies of the zlib and gzip
compressors (yes, their output streams differ with longer inputs and
even some short ones).
Sam.
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Junio C Hamano @ 2007-09-22 2:33 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070921214346.GF97288@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> Good day.
>
> I had found that FreeBSD's /bin/sh refuses to work with git 1.5.3.2.
> correctly: no flags are recognized.
> @@ -109,7 +109,7 @@ dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary=
> resolvemsg= resume=
> git_apply_opt=
>
> -while case "$#" in 0) break;; esac
> +while case "$#" in 0) break;; *) : ;; esac
> do
I am assuming that this works around _a_ bug in that /bin/sh; I
would make sure I understand the nature of the bug. Is it Ok to
understand that with that shell, after this construct runs:
case <some word> in
<case arm #1>)
something ;;
<case arm #2>)
something else ;;
esac
the status from the whole case statement is false, when <some word>
does not match any of the glob patterns listed in any of the case arm?
That is, what does the shell say if you do this?
case Ultra in
Super)
false ;;
Hyper)
true ;;
esac &&
echo case returned ok
The reason I ask is because
while case $# in 0) ... esac
do
...
done
is not the only place the status from "case" itself matters in
our scripts. There are places that do
something &&
case ... in
...
esac &&
something else
and we would need to add no-op match-everything arm to all of
such case statements in our scripts.
Besides test scripts, there is one in git-ls-remote.sh which you
seem to have missed.
^ 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