* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vveam15w9.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 15:12 -0700, Junio C Hamano wrote:
> Josh England <jjengla@comcast.net> writes:
>
> > OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
> > many of the supplied functions will not work when called from within
> > $GIT_DIR.
>
> Sorry, "supplied functions"? Care to clarify with a patch?
I guess really just the cd_to_topdir() function. It will silently fail
when run from within $GIT_DIR.
-JE
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 22:28 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Andreas Ericsson, Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709071517n7e7e99ffl3dd351092e7f19d6@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> On 9/6/07, Andreas Ericsson <ae@op5.se> wrote:
>> They already have, but every now and then someone comes along and suggest
>> a complete rewrite in some other language. So far we've had Java (there's
>> always one...), Python and now C++.
>
> Since this "complete rewrite" was mentioned in multiple emails I'd
> like to rectify that:
> What I'm offering (for Git) is to use C++ as a "better C".
> Don't change any existing *working* code, but start introducing simple
> C++ constructs in the new code.
You are aware that the Linux kernel was kept compilable under g++ for
a while in its history? You'll need more than vague words to erase
the memories from that experiment...
Just compiling under C++, with no source changes, is likely to impact
performance and compile time rather badly, not to mention portability
(you need the C++ runtime, for one thing).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-07 22:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <46E0F04D.7040101@op5.se>
On 9/6/07, Andreas Ericsson <ae@op5.se> wrote:
> They already have, but every now and then someone comes along and suggest
> a complete rewrite in some other language. So far we've had Java (there's
> always one...), Python and now C++.
Since this "complete rewrite" was mentioned in multiple emails I'd
like to rectify that:
What I'm offering (for Git) is to use C++ as a "better C".
Don't change any existing *working* code, but start introducing simple
C++ constructs in the new code.
Git is simple enough to not require any high-level abstractions. But
some utility classes could make code much simpler.
And BTW, I don't even like C++ that much :-), I just like it much
better than C. I've been saying that C++ is a legacy language for
quite some time now. But we will use it for many years to come because
the size of this legacy code is huge, so there will be plenty of C++
developers available (to contribute to Git :-).
And C++ is the only way to move with existing C codebase.
--
- Dmitry
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 22:12 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189203064.15140.2.camel@beauty>
Josh England <jjengla@comcast.net> writes:
> OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
> many of the supplied functions will not work when called from within
> $GIT_DIR.
Sorry, "supplied functions"? Care to clarify with a patch?
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vhcm62lru.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 14:44 -0700, Junio C Hamano wrote:
> Josh England <jjengla@comcast.net> writes:
>
> > ... there doesn't seem to be a
> > good way to access the top of the working tree from within the GIT_DIR.
> > Since I now know that post-receive has a CWD in .git, I could just use
> > `pwd`/../ , but I was hoping for a better (read: consistent between
> > hooks) solution.
>
> I do not think it is a bad thing for _your_ script to have the
> knowledge that in _your_ repositories everywhere, the top of the
> work tree is $GIT_DIR/.. and there is no repository that lacks a
> work tree. Obviously that would not work for people with bare
> repositories, but they would not be using _your_ script in their
> bare repositories, so that is Ok.
OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
many of the supplied functions will not work when called from within
$GIT_DIR.
-JE
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Junio C Hamano @ 2007-09-07 22:08 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Keith Packard, Git Mailing List
In-Reply-To: <87r6lab0rw.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Fri, 07 Sep 2007 13:32:30 -0700, Junio C Hamano wrote:
>> So I am all for making an ambiguous refname an error in 1.5.4.
>
> If you do, then please also make it an error to create an ambiguous
> refname as well.
Yeah, didn't I also suggest that already?
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Carl Worth @ 2007-09-07 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Keith Packard, Git Mailing List
In-Reply-To: <7vejha43oh.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Fri, 07 Sep 2007 13:32:30 -0700, Junio C Hamano wrote:
> So I am all for making an ambiguous refname an error in 1.5.4.
If you do, then please also make it an error to create an ambiguous
refname as well.
For example, look at how late the warning comes out in this case, and
how changing it to an error at that point would not help anything:
$ git branch tmp
$ ...
$ git tag tmp # No warning here!
$ git show tmp
warning: refname 'tmp' is ambiguous.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: checkout and rm
From: Junio C Hamano @ 2007-09-07 22:00 UTC (permalink / raw)
To: Jeff Jenkins; +Cc: git
In-Reply-To: <4F2CF06E-CCC6-4597-A1BF-663BC36B9A94@ShopWiki.com>
Jeff Jenkins <Jeff@ShopWiki.com> writes:
> With stash in 1.5.3 the only reason I
> can think of to allow working directory changes to propagate is gone
This reasoning is utterly wrong.
We often begin exploring a solution while on one branch (perhaps
'master'), starting with small changes in the work tree, and
then realize that it needs to be worked on in a separate branch:
$ edit some work tree files
$ git branch new-topic
$ git checkout new-topic
Or maybe we would realize that the fix we started to work on
while on 'master' also applies to 'maint', and do the checkout
without creating a new branch:
$ edit some work tree files
$ git checkout maint
In either case, it is a _good_ thing that you can take your
local changes with you when you switch branches, without extra
stash/unstash sequence, and I do not think this is going to
change.
About the "lost remove", I think it is related to the fact that
we try to be usable in a sparsely checked out work tree, and
during a two-way merge (aka "switching branches") we consider a
missing file equivalent to an unmodified file and this might be
a bug in the logic to implement it there. I haven't checked
this conjecture and won't have time now to do the digging myself
(you're welcome to do the digging yourself in the meantime). It
may turn out to be a trivial change, but I dunno at this moment.
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 21:44 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189200421.12525.8.camel@beauty>
Josh England <jjengla@comcast.net> writes:
> ... there doesn't seem to be a
> good way to access the top of the working tree from within the GIT_DIR.
> Since I now know that post-receive has a CWD in .git, I could just use
> `pwd`/../ , but I was hoping for a better (read: consistent between
> hooks) solution.
I do not think it is a bad thing for _your_ script to have the
knowledge that in _your_ repositories everywhere, the top of the
work tree is $GIT_DIR/.. and there is no repository that lacks a
work tree. Obviously that would not work for people with bare
repositories, but they would not be using _your_ script in their
bare repositories, so that is Ok.
You can also configure core.worktree in $GIT_DIR/config and use
that from the hook script, I presume, although I haven't done it
(and do not see a need to do so) myself yet.
^ permalink raw reply
* [PATCH] (cvs|svn)import: Ask git-tag to overwrite old tags.
From: Michael Smith @ 2007-09-07 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzy2o46.fsf@gitster.siamese.dyndns.org>
If the tag was moved in CVS or SVN history, it will be moved in the
imported history as well. Tag history is not tracked.
---
git-cvsimport.perl | 2 +-
git-svnimport.perl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ba23eb8..2954fb8 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -779,7 +779,7 @@ sub commit {
$xtag =~ tr/_/\./ if ( $opt_u );
$xtag =~ s/[\/]/$opt_s/g;
- system('git-tag', $xtag, $cid) == 0
+ system('git-tag', '-f', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
print "Created tag '$xtag' on '$branch'\n" if $opt_v;
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 8c17fb5..d3ad5b9 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -873,7 +873,7 @@ sub commit {
$dest =~ tr/_/\./ if $opt_u;
- system('git-tag', $dest, $cid) == 0
+ system('git-tag', '-f', $dest, $cid) == 0
or die "Cannot create tag $dest: $!\n";
print "Created tag '$dest' on '$branch'\n" if $opt_v;
--
1.5.3.1.20.gb860
^ permalink raw reply related
* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v642m436q.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 13:43 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > In messsing around with hooks, I've discovered that not all hooks are
> > run in the same environment. In particular, the current working
> > directory in the post-receive hook (maybe others as well) is the GIT_DIR
> > (.git) directory, instead of the root of the working tree (as in
> > pre-commit).
>
> It is not even "instead of"; that's the only sane thing to do
> for post-receive, which is in response to git-push and usually
> used for a bare repository, i.e. without any work tree.
I thought there was probably a sane reason for it. That is perfectly
acceptable, but the problem still exists that there doesn't seem to be a
good way to access the top of the working tree from within the GIT_DIR.
Since I now know that post-receive has a CWD in .git, I could just use
`pwd`/../ , but I was hoping for a better (read: consistent between
hooks) solution.
-JE
^ permalink raw reply
* Re: [PATCH] introduce config core.binaryCheckFirstBytes for xdiff-interface
From: Junio C Hamano @ 2007-09-07 21:19 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070907191421.5526.qmail@f74fa18bc10c8f.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> xdiff-interface uses a hardcoded value of 8000 bytes to check from
> the top of data whether to handle it as binary content. If a NULL
> character appears after the first 8000 bytes, git won't notice,
If the user has to set this to suit git better for a particular
project, I think the same effort is better spent on setting up
the attribute for that file so that git does not have to guess
the type, no?
^ permalink raw reply
* Re: [PATCH] git-clone: better error message if curl program is missing
From: Junio C Hamano @ 2007-09-07 21:19 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070907171400.28590.qmail@d780fac1e27de6.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> If the curl program is not available, and git clone is started to clone a
> repository through http, this is the output
>
> Initialized empty Git repository in /tmp/puppet/.git/
> /usr/bin/git-clone: line 37: curl: command not found
Perhaps we should die at this point so that...
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
the user does not have to see this.
In other words, instead of this:
> http_fetch () {
> # $1 = Remote, $2 = Local
> + type curl >/dev/null 2>&1 ||
> + die "The curl program is not available"
> curl -nsfL $curl_extra_args "$1" >"$2"
> }
something like this, perhaps:
http_fetch () {
# $1 = remote, $2 = local
curl -nsfL $curl_extra_args "$1" >"$2" || exit
}
Then the shell would say "curl: command not found" and we would
stop.
I am just hestating to use "type" there (yeah, I know mergetool
has one but that one is not as close to the core of the workflow
as git-fetch is).
BTW, isn't it a packaging bug not to depend git-fetch on curl?
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Pierre Habouzit @ 2007-09-07 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Keith Packard, Git Mailing List
In-Reply-To: <7vabry43cg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Fri, Sep 07, 2007 at 08:39:43PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > I'd have added though that maybe update-ref should print a warning for
> > the references that do not match the restriction Junio added. This could
> > be done using the function Junio proposed un update_ref() in refs.c
>
> I would even suggest making it into an error, even if we do not
> error out on the reading side (being liberal when reading but
> more strict when creating, that is).
>
> That confused_ref() needs to be tightened further, by the way.
> It is called only when we are considering to tack the user
> string immediately below $GIT_DIR/ so the only valid cases are
> (1) the string begins with "refs/", or (2) the string is all
> uppercase (or underscore), especially without slash. The one in
> the proposed patch is not strict enough and does not enforce the
> former.
I reckon I didn't checked what the function did in detail, just the
code layout :) And I agree an error is event better, I just don't have
enough knowledge of the scripts that used refs in git for a long time
that such a change could break. I mean, I only use git since the 1.2
(maybe even 1.3) series :)
I'm always all for refusing dangerous layouts rather than trying too
hard to support cumbersome things that are 99% of the times issues :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Pierre Habouzit @ 2007-09-07 20:56 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbsd0g$gt6$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
On Fri, Sep 07, 2007 at 08:40:56PM +0000, Walter Bright wrote:
> Pierre Habouzit wrote:
> >And for that bit-fields are
> >a really really fast and simple way to describe things.
>
> I should point out that inline functions are inlined, and there is no
> speed difference in the result.
I know that, and that's why I said I was totally fine with the
bitfield notation to be only syntactic sugar on a template thingy if
that's the simplest way to have that it's OKay.
> > Not to mention that the usual C idiom:
> > union {
> > unsigned flags;
> > struct {
> > // many bitfields
> > };
> > };
> > Would need an explicit copy_flags(const my_struct foo) function to
> >work. Not pretty, not straightforward.
>
> I'm not following this. To copy a union, you just copy it with the
> assignment operator:
>
> U a, b;
> a = b; // copies all the bit fields, too!
That was the point indeed. But if you don't have bitfields, you can't
do the union. And if the bitfield is just syntactic sugar, it may be
unpossible to have such a union. But I may be wrong.
> >Right now, for D, only
> >gdc exists, it lags behind dmd quite a lot afaict, and there is no other
> >toolchain helpers yet.
>
> GDC was just released for D 1.020, which is behind D 1.021, but 1.021 was
> released just a couple days ago <g>.
Sure, but it does not works on amd64 properly (and it's the
architecture I care about) and is not ready for the current gcc (4.2,
only 4.1 builds) and so on. It's not as stable as DMD is. It does not
lags too much version-wise, it lags in maturity. But well, youth has a
cure: time :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] svnimport/cvsimport: force creation of tags that already exist.
From: Junio C Hamano @ 2007-09-07 20:54 UTC (permalink / raw)
To: Michael Smith; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709071125090.6203@juice.ott.cti.com>
Michael Smith <msmith@cbnco.com> writes:
> I understand moving tags is frowned upon in Git. I don't know how common
> the practise is in Subversion and CVS, or whether it makes sense to
> make the import scripts force tag creation by default.
I think the patch itself makes sense. If for some reason the
importer detects that the CVS or SVN history moved a tag, we
either:
(1) have a way to keep track of the versions of the tag; or
(2) allow it and make it "last one wins" semantics; or
(3) ignore it and make it "first one wins" semantics.
Erroring out complaining that the tag cannot be created, as the
current code does, does not make any sense.
The patch needs to be accompanied with a better commit log
description. I am guessing that with your change the semantics
would become (2) above (assuming that cvsps or whoever reads the
history of the other side gives events in chronological order),
but you should not force readers of your commit log message to
guess.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 20:49 UTC (permalink / raw)
To: git
In-Reply-To: <85wsv22ry8.fsf@lola.goethe.zz>
David Kastrup wrote:
> In my opinion there is basically one area which C has botched up
> seriously in order to be useful as a general purpose language, and
> that is conflating pointers and arrays, and allowing pointer
> arithmetic. The consequences are absolutely awful with regard to
> compilers being able to optimize, and it is pretty much the primary
> reason that Fortran is still quite in use for numerical work.
I agree. It's one of those things that probably sounded like a good idea
at the time. The consequences were not foreseen. All languages have a
few of these (C++ has the infamous use of < > for template arguments).
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 20:43 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189120800.6203.23.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
> In messsing around with hooks, I've discovered that not all hooks are
> run in the same environment. In particular, the current working
> directory in the post-receive hook (maybe others as well) is the GIT_DIR
> (.git) directory, instead of the root of the working tree (as in
> pre-commit).
It is not even "instead of"; that's the only sane thing to do
for post-receive, which is in response to git-push and usually
used for a bare repository, i.e. without any work tree.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <20070907194115.GA23483@artemis.corp>
Pierre Habouzit wrote:
> Well htod does that, but it's very impractical to write them from
> scratch.
True. I haven't tried yet (nobody else seems to care about it as much as
you do!), but I think this could be automated fairly easily with a template.
> And for that bit-fields are
> a really really fast and simple way to describe things.
I should point out that inline functions are inlined, and there is no
speed difference in the result.
> Not to mention that the usual C idiom:
>
> union {
> unsigned flags;
> struct {
> // many bitfields
> };
> };
>
> Would need an explicit copy_flags(const my_struct foo) function to
> work. Not pretty, not straightforward.
I'm not following this. To copy a union, you just copy it with the
assignment operator:
U a, b;
a = b; // copies all the bit fields, too!
>> D does come with htod, which converts C .h files to D files.
> Last time I checked it was only available on windows, and closed
> source, both are an impediment for many people.
You're right on both counts. It's because htod is built out of a fork of
the Digital Mars C compiler. Something similar could be done with gcc,
but I'm not the person to do it. I should also get off my lazy tail and
port htod to linux.
> Right now, for D, only
> gdc exists, it lags behind dmd quite a lot afaict, and there is no other
> toolchain helpers yet.
GDC was just released for D 1.020, which is behind D 1.021, but 1.021
was released just a couple days ago <g>.
> For the record I wasn't suggesting to rewrite git in D at all. I just
> happened to see your post, and being very interested in where D is going
> because I feel it's an excellent langage, and saw an opportunity to
> mention a few quirks I feel it has, so, well, I answered :)
And it's nice to hear your perspective, which is why I dropped by this
thread.
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Junio C Hamano @ 2007-09-07 20:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Sixt, Keith Packard, Git Mailing List
In-Reply-To: <20070907124253.GB27754@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> I'd have added though that maybe update-ref should print a warning for
> the references that do not match the restriction Junio added. This could
> be done using the function Junio proposed un update_ref() in refs.c
I would even suggest making it into an error, even if we do not
error out on the reading side (being liberal when reading but
more strict when creating, that is).
That confused_ref() needs to be tightened further, by the way.
It is called only when we are considering to tack the user
string immediately below $GIT_DIR/ so the only valid cases are
(1) the string begins with "refs/", or (2) the string is all
uppercase (or underscore), especially without slash. The one in
the proposed patch is not strict enough and does not enforce the
former.
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Junio C Hamano @ 2007-09-07 20:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0709071222270.21186@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> It seems to me that instead of introducing an incompatible (but probably
>> useful) change, a sensible option would be to have the ambiguous
>> reference be an error instead of a warning. One shouldn't be encouraged
>> to use names in .git that conflict with stuff in refs/heads anyway.
>
> I agree. IMHO the sensible thing to do is to always warn, and error out
> by default. I see no advantage for core.warnAmbiguousRefs=false other
> than allow the user to shoot himself in the foot someday. Instead, we
> should have core.allowAmbiguousRefs set to off by default.
Well, for about three weeks late November to early December
2005, we did make this an error. Since mid December 2005, we
reverted that change to the original "take first match, without
even attempting to detect ambiguity". I do not recall what the
discussion that led to that change was about, but it could have
been the issue Len had that confused "git merge" with a tag and
a branch named after bugzilla bug number. In any case, this
change most likely was because some people were actually using
the same name and the change to make it an error hurted them.
We then reintroduced the ambiguity detection late March 2006,
but only as a warning, again fearing that erroring out would
break people's existing setups. I think we also rewrote
examples in our documentation that said "create your own branch
v2.6.13 that fork from v2.6.13 tag" to read "create your own
brancy my-2.6.13..." to avoid encouraging the use of same name
to people.
I think the warning has been with us for a long time and by now
people know better not to confuse themselves.
So I am all for making an ambiguous refname an error in 1.5.4.
At the same time, I think it makes sense to forbid update-ref
outside refs/ if the refname is not special (say, with any
lowercase letters), and ignore names immediately below .git that
are not all-uppercase+underscore (e.g. "FETCH_HEAD" we read,
"description" we ignore).
Please make it so.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 20:27 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbsbul$dg0$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> void foo(int array[10])
> {
> for (int i = 0; i < 10; i++)
> { int value = array[i];
> ... do something ...
> }
> }
>
> to:
>
> void foo(int[] array)
> {
> foreach (value; array)
> {
> ... do something ...
> }
> }
>
> takes a lot of frankly unnecessary things away, each of which is a
> potential source of error when maintaining the code.
The problem is a toy problem: in real applications, you'll need to
access several data structures using the same index, and you'll need
to be able to assign index values to temporary variables and so on.
So being able to hide the type of an index in one very specific
application (looping through a single array completely) at one place
is not going to buy you much.
Anyway, D is pretty much irrelevant as a perspective for git, so you
should take it to a language advocacy group.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-svn 1.5.3 does not understand grafts?
From: Joakim Tjernlund @ 2007-09-07 20:23 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <1189183934.14841.18.camel@gentoo-jocke.transmode.se>
On Fri, 2007-09-07 at 18:52 +0200, Joakim Tjernlund wrote:
> On Fri, 2007-09-07 at 18:41 +0200, Joakim Tjernlund wrote:
> > svnadmin create /usr/local/src/TM/svn-tst/7720-svn/
> > svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk -m "Add trunk dir"
> > svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp -m "Add swp dir"
> >
> > In my git repo I do
> > git-svn init file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp
> > git-svn fetch
> > git branch svn remotes/git-svn
> > #make remotes/git-svn parent to the initial commit in my git tree
> > graftid=`git-show-ref -s svn`
> > echo da783cce390ce013b19f1d308ea6813269c6a6b5 $graftid > .git/info/grafts
> > #da783... is the initial commit in my git tree.
> > git-svn dcommit
> >
> > fails with:
> > Committing to file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp ...
> > Commit da783cce390ce013b19f1d308ea6813269c6a6b5
> > has no parent commit, and therefore nothing to diff against.
> > You should be working from a repository originally created by git-svn
> >
> >
> > Jocke
>
> Using filter-branch helps, but git-svn isn't too happy:
>
> git-svn init file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp
> git-svn fetch
> git branch svn remotes/git-svn
> #make remotes/git-svn parent to the initial commit in my git tree
> graftid=`git-show-ref -s svn`
> echo da783cce390ce013b19f1d308ea6813269c6a6b5 $graftid > .git/info/grafts
> #da783... is the initial commit in my git tree.
> git filter-branch $graftid..HEAD
> git-svn dcommit
>
> Now I get alot of complaints, but it commits to svn.
> It takes forever though:
> r3 = 55a489bd4f66dd1f641a4676359d7b8911dc7d83 (git-svn)
> W: HEAD and refs/remotes/git-svn differ, using rebase:
> :100644 100644 f85ae11af7715a224015582724cb2bab87ec914a
[SNIP]
Just wanted to add that 1.5.2.2 works with grafts and
that I suspect sub read_commit_parents in git-svn, but as I don't
do perl I am stuck.
Jocke
Oh, Eric W. CC:ed as well this time
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <85wsv26cv8.fsf@lola.goethe.zz>
David Kastrup wrote:
> Again, C won't keep you from shooting yourself in the foot.
Right, it won't. A good systems language should do what it can to
prevent the programmer from *inadvertently* shooting himself in the
foot, while allowing him to *deliberately* shoot himself in the foot.
In the example loop, the cases I pointed out were ones where, if one
changes part of the code (such as the array dimension, or the array
type, etc.), then there are multiple places in the source that must be
updated to reflect it. The reality of human programmers is we update one
or two places, and overlook the third place, and we now have a bug.
Saying that one should just be a better programmer and not make such
mistakes is a pipe dream.
Ideally, each facet of the design of the code should have a single point
where it can be changed, and then all dependencies on that design should
be automatically updated. That way, nothing gets overlooked. Doing this
in C, such as using a #define for the array dimension, involves extra work.
It's a truism that if it involves extra work, then it often gets omitted.
Doesn't "A design is perfect not when there is no longer anything you
can add to it, but if there is no longer anything you can take away."
apply here? Going from:
void foo(int array[10])
{
for (int i = 0; i < 10; i++)
{ int value = array[i];
... do something ...
}
}
to:
void foo(int[] array)
{
foreach (value; array)
{
... do something ...
}
}
takes a lot of frankly unnecessary things away, each of which is a
potential source of error when maintaining the code.
> No, because programmers get things wrong.
Exactly. That goes back to my point that a good language should help
prevent inadvertent errors, while still allowing deliberate choices. D
approaches this by making the correct approach essentially be the one
with minimal typing effort. To deliberately shoot yourself in the foot
usually requires extra typing. For our loop example, we can still write
the C style loop (with all its potential problems) in D, but it requires
extra effort to put in those potential problems. The easier, simpler way
doesn't have the problems.
(The issue I have with C++'s fixes to various problems is they require
extra typing (like the loop example), so guess what, people being people
tend to not use them. This results in endless attempts to try and push
C++ programmers into using the more verbose forms, a strategy I suspect
will be ultimately futile.)
> You can tell C compilers to
> check all array accesses, but that is a performance issue.
Runtime checking of arrays in D is a performance issue too, so it is
selectable via a command line switch. But more importantly,
1) Static type checking of fixed size arrays works, so errors can be
caught at compile time.
2) For dynamically sized arrays, the dimension of the array is carried
with the array, so loops automatically loop the correct number of times.
No runtime check is necessary, and it's easier for the code reviewer to
visually check the code for correctness.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Pierre Habouzit @ 2007-09-07 19:59 UTC (permalink / raw)
To: David Kastrup; +Cc: Walter Bright, git
In-Reply-To: <85odge2r0w.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Fri, Sep 07, 2007 at 07:51:11PM +0000, David Kastrup wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> [bit fields]
>
> > Really, I feel this is a big lack, for a language that aims at
> > simplicity, conciseness _and_ correctness.
> >
> > OK, maybe I'm biased, I work with networks protocols all day long, so
> > I often need bitfields, but still, a lot of people deal with network
> > protocols, it's not a niche.
>
> And strictly speaking, C bitfields are completely useless for that
> purpose since the compiler is free to use whatever method he wants for
> allocating bit fields. So if you want to write a portable program,
> you are back to making the masks yourself.
The point is (1) D is not C, (2) we all know that linux e.g. does that
in many places using the fact that it knows how the supported compilers
(gcc icc tcc maybe some other) do their packing.
The discussion is about D. D solves the infamous problem with longs
not having the same size everywhere, I don't see why it couldn't solve
the bitfield issue either.
> Where bit fields work reliably is when you are not interchanging data
> with other applications, but just laying out your internals.
Thank you for the _C_ lesson.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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