* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-07 3:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709070212300.5626@evo.linux-foundation.org>
On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> >
> > As it is right now, it's too hard to see the high-level logic thru
> > this endless-busy-work of micro-managing strings and memory.
>
> Total BS. The string/memory management is not at all relevant. Look at the
> code (I bet you didn't). This isn't the important, or complex part.
Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).
Let me snip "C is better than C++" part ...
> [ snip ]
... and explain where I'm coming from:
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
The fact that Git is written in C does not really contribute to that goal.
Suggestion to use C++ is the only alternative with existing C codebase.
So while C++ may not be the best choice "academically speaking" it's
pretty much the only practical choice.
"Democracy is the worst form of government except for all those others
that have been tried." - Winston Churchill
Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
People who carry the main weight of developing and maintaining Git
should make the call.
--
- Dmitry
^ permalink raw reply
* checkout and rm
From: Jeff Jenkins @ 2007-09-07 2:59 UTC (permalink / raw)
To: git
I couldn't find a thread in the archive about this. Here's the
abbreviated scenario:
$ git add bar.c
$ git-rm foo.c
rm 'foo.c'
$ git-status
# On branch FOO
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bar.c
# deleted: foo.c
#
$ git-checkout master
M bar.c
Switched to branch "master"
$ git-status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bar.c
#
When I change branches:
- the modified files in the index/working directory stay there
(that's fine)
- the *removed* files are re-added to the working directory when the
branch changes
- the remove entries aren't in the index anymore
There was no warning about any the lost changes, and if the intent
was to commit these changes to master because you were in FOO by
accident, then only some would be committed if you weren't paying
close attention. If working directory/index changes are going to be
kept when a branch switch is done, then the remove changes should be
propagated as well.
Ideally there would be a config setting which would stop checkouts if
the working directory or index were dirty (and a flag on checkout
which overrode the setting). With stash in 1.5.3 the only reason I
can think of to allow working directory changes to propagate is gone
(though i haven't tested how stash works with rm'd files). At the
very least, there should be a warning and a prompt if some of the
changes are going to vanish by a user action
-Jeff Jenkins
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Shawn O. Pearce @ 2007-09-07 4:07 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin, Nix,
Steven Grimm, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0709061942320.21186@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> I would have concatenated all packs provided on the command line into a
> single one, simply by reading data from existing packs and writing it
> back without any processing at all. The offset for OBJ_OFS_DELTA is
> relative so a simple concatenation will just work.
>
> Then the index for that pack can be created just as easily by reading
> existing pack index files and storing the data into an array of struct
> pack_idx_entry, adding the appropriate offset to object offsets, then
> call write_idx_file().
>
> All data is read once and written once making it no more costly than a
> simple file copy. On the flip side it wouldn't get rid of duplicated
> objects (I don't know if that matters i.e. if something might break with
> the same object twice in a pack).
Yea, that's a really quick repack. :-) Plus its actually something
that can be easily halted in the middle and resumed later. Just need
to save the list of packfiles you are concatenating so you can pick
up later when you get more time.
There shouldn't be a problem with having duplicates in the packfile.
You can do one of two things:
a) Omit the duplicates from the .idx when you merge the .idx tables
together to produce the new one. Just take the object with the
earliest offset.
b) Leave the duplicates in the final .idx. In this case the
binary search may pick any of them, but it wouldn't matter
which it finds.
About the only process that might care about duplicates would be
index-pack. I don't think it makes sense to run index-pack on a
packfile you already have a .idx for. I don't think it would have
a problem with the duplicate SHA-1s either, but it wouldn't be hard
to make it do something reasonable when it finds them.
> > To consolidate all packs that are smaller than a megabytes into
> > one, you would use it in its current form like this:
> >
> > $ old=$(find .git/objects/pack -type f -name '*.pack' -size 1M)
> > $ new=$(echo "$old" | git merge-pack | git pack-objects pack)
> > $ for p in $old; do rm -f $p ${p%.pack}.idx; done
> > $ for s in pack idx; do mv pack-$new.$s .git/objects/pack/; done
>
> You might want to move the new pack before removing the old ones though.
Not might, *must*. If you delete the old ones before the new
ones are ready then readers can run into problems trying to access
the objects. We've spent some effort trying to make these sorts
of operations safe. No sense in destroying that by getting the
order wrong here. :)
--
Shawn.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Paul Wankadia @ 2007-09-07 4:06 UTC (permalink / raw)
To: git
In-Reply-To: <D7BEA87D-1DCF-4A48-AD5B-0A3FDC973C8A@wincent.com>
Wincent Colaiuta <win <at> wincent.com> writes:
> > I just wanted to get a sense of how many people share this "Git should
> > be in pure C" doctrine.
>
> Count me as one of them. Git is all about speed, and C is the best
> choice for speed, especially in context of Git's workload.
I concur, but I also feel that D, Clean and OCaml are viable alternatives.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Nicolas Pitre @ 2007-09-07 4:30 UTC (permalink / raw)
To: Paul Wankadia; +Cc: git
In-Reply-To: <loom.20070907T055946-637@post.gmane.org>
On Fri, 7 Sep 2007, Paul Wankadia wrote:
> Wincent Colaiuta <win <at> wincent.com> writes:
>
> > > I just wanted to get a sense of how many people share this "Git should
> > > be in pure C" doctrine.
> >
> > Count me as one of them. Git is all about speed, and C is the best
> > choice for speed, especially in context of Git's workload.
>
> I concur, but I also feel that D, Clean and OCaml are viable alternatives.
I happen to have zero experience with any of those, so if Git
development was done with one of them, you'd have to count me out.
C is simply the lingua franca when it comes to programming, and it
happens to be the fastest amongst portable languages too.
Nicolas
^ permalink raw reply
* Re: very slow cherry-pick'ing (old-2.6-bkcvs tree)
From: Shawn O. Pearce @ 2007-09-07 4:42 UTC (permalink / raw)
To: Erez Zadok; +Cc: git
In-Reply-To: <200709062351.l86NpnAK004807@agora.fsl.cs.sunysb.edu>
Erez Zadok <ezk@cs.sunysb.edu> wrote:
> Our group maintains Unionfs on the latest -rc kernel, but we also maintain
> several backports going all the way to 2.6.9. Once we complete the
> development and testing of a feature/fix in -latest, we cherry-pick those
> commits to older backports, and test those. When I cherry-pick from -latest
> to my 2.6.{22,21,20,19,18} repositories, it works reasonably fast. But when
> I cherry-pick to my 2.6.9 tree, it runs about 20 times slower! Why? Is
> there anything I can do to inspect what's going on and perhaps speed up the
> cherry-picking process?
I'm guessing its due to rename detection.
git-cherry-pick is implemented in terms of git-merge-recursive,
which always does rename detection when files are deleted or added.
This can take some considerable time if there's a lot of files that
have been added/deleted.
What would probably be faster would be to dump the patches in
question using git-format-patch and then apply them using git-am.
This bypasses the rename detection as it is using strictly a diff
and an apply.
--
Shawn.
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Junio C Hamano @ 2007-09-07 4:43 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Johannes Schindelin, Nix, Steven Grimm,
Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0709061942320.21186@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I would have concatenated all packs provided on the command line into a
> single one, simply by reading data from existing packs and writing it
> back without any processing at all. The offset for OBJ_OFS_DELTA is
> relative so a simple concatenation will just work.
As I was planning to do this outside of pack-objects, I did not
want to write something that intimately knows the details of
packfile format, but see below.
> All data is read once and written once making it no more costly than a
> simple file copy. On the flip side it wouldn't get rid of duplicated
> objects (I don't know if that matters i.e. if something might break with
> the same object twice in a pack).
I do not think duplicates create problems, as long as the pack
idx remains sane. But a bigger issue is for people who fetch
over dumb protocols, from a repository that repacks with "-a -d"
every once in a while. There, many duplicates are norm.
> In fact, since we want to _also_ perform a repack of loose objects in
> the context of automatic repacking, I wonder why we wouldn't use that
> --unpacked= argument to also repack smallish packs at the same time in
> only one pack-objects pass. Or maybe I'm missing something?
I think this is a much better idea. You obviously need some
twist to the pack-objects, and being lazy that was the reason I
did not want to do this that way.
When a new parameter, perhaps --lossless, is given, together
with the --unpacked= parameters, we can change pack-objects to
iterate over all objects in the --unpacked= packs, and add the
ones that are not marked for inclusion to the set of objects to
be packed, after doing the usual "objects to be packed"
discovery.
I am not sure --lossless is a good option name from marketing
point of view, though.
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Shawn O. Pearce @ 2007-09-07 4:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Nicolas Pitre, Nix, Steven Grimm,
Linus Torvalds, Git Mailing List
In-Reply-To: <7vk5r3adlx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 5 Sep 2007, Junio C Hamano wrote:
> >> static int aggressive_window = -1;
> >> +static int gc_auto_threshold = 6700;
> >
> > Please don't do that.
> >
> > When you share objects with another git directory, git-gc --auto can get
> > rid of the objects when some objects go away in the referenced repository.
>
> I thought the whole point of "gc --auto" was to have something
> that does not lose/prune any objects, even the ones that do not
> seem to be referenced from anywhere. That is why invocations of
> "git gc --auto" do not say --prune as you saw the second patch,
> and the repack command "gc --auto" runs is "repack -d -l"
> instead of "repack -a -d -l", which means that it does run
> git-prune-packed after repacking but not git-prune.
>
> Maybe I am missing something...
No, you aren't Junio. `gc --auto` as you defined it is safe.
It won't delete objects from the database. So it won't impact shared
repositories, or readers that are actively running in parallel with
the gc. Both of which are important.
--
Shawn.
^ permalink raw reply
* Re: Significant performance waste in git-svn and friends
From: Shawn O. Pearce @ 2007-09-07 4:55 UTC (permalink / raw)
To: Eric Wong; +Cc: Mike Hommey, git
In-Reply-To: <20070906070407.GA19624@soma>
Eric Wong <normalperson@yhbt.net> wrote:
> Making git-svn use fast-import would be very nice. I've got a bunch
> of other git-svn things that I need to work on, but having git-svn
> converted to use fast-import would be nice. Or allowing Git.pm
> to access more of the git internals...
>
> However, how well/poorly would fast-import work for incremental
> fetches throughout the day?
It would work just fine. git-p4 uses fast-import and runs it in
incremental mode all of the time.
What will happen is you will get a packfile per git-svn fetch, so
if you fetch 5 times that day you will get 5 packfiles that day.
But you could also get 5 packfiles from git-fetch if each of those
fetches brought in 100 or more new objects. So it really is not
that big of a deal.
At some point the number of packfiles gets out of control, but so
does the number of loose objects. Repacking is the obvious fix in
both cases.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] git-tag -s must fail if gpg is broken and cannot sign tags
From: Shawn O. Pearce @ 2007-09-07 4:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, git
In-Reply-To: <7vd4wwe2n5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> >> If the user has misconfigured `user.signingkey` in their .git/config
> >> or just doesn't have any secret keys on their keyring and they ask
> >> for a signed tag with `git tag -s` we better make sure the resulting
> >> tag was actually signed by gpg.
>
> This seems to fail the test depending on the order processes
> happen to be scheduled. I haven't looked at it closely yet.
That's not good. I noticed stepping through the code last night
that if gpg is misconfigured (e.g. set a bad user.signingkey in
.git/config) it will terminate and send SIGPIPE to git-tag, which
makes it terminate.
All my change did was implement proper error handling. So if you
are seeing failures now then we probably have a problem with the
code without my patch too...
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] git-gui/Makefile: Replace libdir with gitgui_libdir
From: Shawn O. Pearce @ 2007-09-07 5:01 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070906100012.GC6665@basalt.office.altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > > On GNU/Linux, libdir is used to mean "/usr/lib or /usr/lib64"
> > > depending on architecture. Different libdir meaning breaks
> > > idiomatic expressions like rpm specfile "make libdir=%_libdir".
>
> The idea is that git-gui's libdir is not a traditional arch-dependent
> libdir's subdirectory, but rather arch-independent datadir's subdirectory.
> That is, I see no reason to call it libdir even in standalone project.
Call it datadir then? I see you point, and now agree with you.
Mind resending a patch to call it 'datadir'?
--
Shawn.
^ permalink raw reply
* PATCH to add a button to perform a meld on the current file
From: Pierre Marc Dumuid @ 2007-09-07 4:46 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
Here's a dodgy [not that good] patch to perform a GUI comparison on a file.
It is dodgy because it assumes cogito is installed, and you want to use
meld, and it doesn't remove the temporary files.
Not expecting this to go into main branch, but I find it handy for my
own purposes nether-the-less.
Pierre
[-- Attachment #2: gitk_addGUIdiff01.patch --]
[-- Type: text/x-patch, Size: 1166 bytes --]
--- /usr/bin/gitk 2007-08-06 07:55:41.000000000 +0930
+++ /home/pmdumuid/bin/gitkpmd 2007-09-07 14:09:28.000000000 +0930
@@ -609,7 +609,9 @@
-command changediffdisp -variable diffelide -value {0 1}
radiobutton .bleft.mid.new -text "New version" \
-command changediffdisp -variable diffelide -value {1 0}
- pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
+ button .bleft.top.meld -text "GUI diff" -command doguidiff \
+ -font $uifont
+ pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new .bleft.top.meld -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
-state disabled -font $textfont \
@@ -4564,6 +4566,19 @@
}
}
+proc doguidiff {} {
+ global cflist sha1string
+
+ set taglist [$cflist tag ranges highlight]
+ set from [lindex $taglist 0]
+ set to [lindex $taglist 1]
+
+ set fname [$cflist get $from $to]
+ exec cg-admin-cat -r $sha1string^ $fname > .gitk_diffolder
+ exec cg-admin-cat -r $sha1string $fname > .gitk_diffnewer
+ exec meld .gitk_diffolder .gitk_diffnewer &
+}
+
proc dosearch {} {
global sstring ctext searchstring searchdirn
^ permalink raw reply
* Re: Significant performance waste in git-svn and friends
From: Mike Hommey @ 2007-09-07 5:41 UTC (permalink / raw)
To: git
In-Reply-To: <20070905184710.GA3632@glandium.org>
On Wed, Sep 05, 2007 at 08:47:10PM +0200, Mike Hommey <mh@glandium.org> wrote:
> Some notes about git-svn:
> - A few lines above the patched zone, the file is already read once to
> do the MD5 sum. It should be possible to do SHA-1, MD5 sums and
> deflate in just one pass.
FWIW, I tried, and it doesn't make it much quicker to do everything in one pass.
99% of the speedup comes from not using git-hash-object.
Mike
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Symonds @ 2007-09-07 5:48 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709062009x59a41cb7re6051739c11e370c@mail.gmail.com>
On 07/09/07, Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:
> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.
> The fact that Git is written in C does not really contribute to that goal.
That's just it -- Git's goal isn't to make it as easy as possible for
Git _users_ to fix it (thought that is a nice thing to have). Git's
goal is to be a very good, very fast SCM. Bugs should be found and
fixed, but that can most effectively be done by the people who are
already knowledgeable about Git's codebase (i.e. its developers), not
its users.
Dave.
^ permalink raw reply
* Re: [PATCH] basic threaded delta search
From: Martin Koegler @ 2007-09-07 6:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.9999.0709061014280.21186@xanadu.home>
On Thu, Sep 06, 2007 at 10:48:06AM -0400, Nicolas Pitre wrote:
> On Thu, 6 Sep 2007, Junio C Hamano wrote:
> > Also how would this interact with the LRU
> > delta base window we discussed a week or two ago?
>
> This is completely orthogonal.
Maybe we should adjust the split point of the the object list so, that
objects with the same name hash are processed by one thread, as the LRU
could provide the most benefit for these objects.
I think of something like (totally untested):
for (i = 0; i < NR_THREADS; i++) {
unsigned sublist_size = list_size / (NR_THREADS - i);
+ while (sublist_size < list_size && list[0]->hash == list[1]->hash)
+ sublist_size++;
p[i].list = list;
p[i].list_size = sublist_size;
p[i].window = window;
p[i].depth = depth;
p[i].processed = processed;
ret = pthread_create(&p[i].thread, NULL,
threaded_find_deltas, &p[i]);
if (ret)
die("unable to create thread: %s", strerror(ret));
list += sublist_size;
list_size -= sublist_size;
}
mfg Martin Kögler
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Theodore Tso @ 2007-09-07 6:15 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709062009x59a41cb7re6051739c11e370c@mail.gmail.com>
On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:
> > Total BS. The string/memory management is not at all relevant. Look at the
> > code (I bet you didn't). This isn't the important, or complex part.
>
> Not only have I looked at the code, I've also debugged it quite a bit.
> Granted most of my problems had to do with handling paths on Windows
> (i.e. string manipulations).
I consider string manipulation to be one of the places where C++ is a
total disaster. It's way to easy for idiots to do something like this:
a = b + "/share/" + c + serial_num;
where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators (good God, you can
overload the comma operator in C++!!!), and then when something like
that ends up in an inner loop, the result is a disaster from a
performance point of view, and it's not even obvious *why*!
> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.
Yes, and if you contribute something the shortest time possible, and
it ends up being crap, who gets to rewrite it and fix it? I've seen
too many C++ programs which get this kind of crap added, and it's not
noticed right away (because C++ is really good at hiding such
performance killers so they are not visible), and then later on, it's
even harder to find the performance problems and fix them.
> Now, I realize that I'm a very infrequent contributor to Git, but I
> want my opinion to be heard.
And if git were written in C++, it's precisely the infrequent
contributors (who are in a hurry, who only care about the quick hack
to get them going, and not about the long-term maintainability and
performance of the package) that are be in the position to do the
most damage...
- Ted
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-07 6:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Dmitry Kakurin, Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <D7BEA87D-1DCF-4A48-AD5B-0A3FDC973C8A@wincent.com>
Wincent Colaiuta wrote:
> El 7/9/2007, a las 2:21, Dmitry Kakurin escribió:
>
>> I just wanted to get a sense of how many people share this "Git should
>> be in pure C" doctrine.
>
> Count me as one of them. Git is all about speed, and C is the best
> choice for speed, especially in context of Git's workload.
>
Nono, hand-optimized assembly is the best choice for speed. C is just
a little more portable ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Significant performance waste in git-svn and friends
From: Steven Grimm @ 2007-09-07 6:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Eric Wong, Mike Hommey, git
In-Reply-To: <20070907045557.GY18160@spearce.org>
Shawn O. Pearce wrote:
> What will happen is you will get a packfile per git-svn fetch, so
> if you fetch 5 times that day you will get 5 packfiles that day.
> But you could also get 5 packfiles from git-fetch if each of those
> fetches brought in 100 or more new objects. So it really is not
> that big of a deal.
>
> At some point the number of packfiles gets out of control, but so
> does the number of loose objects. Repacking is the obvious fix in
> both cases.
This dovetails nicely with the "git gc --auto" work in progress,
particularly the recent patch to pack small packfiles together when
there get to be too many of them; run that at the end of every git-svn
fetch and the problem goes away.
-Steve
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-07 6:31 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709062009x59a41cb7re6051739c11e370c@mail.gmail.com>
Dmitry Kakurin wrote:
> On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
>>> As it is right now, it's too hard to see the high-level logic thru
>>> this endless-busy-work of micro-managing strings and memory.
>> Total BS. The string/memory management is not at all relevant. Look at the
>> code (I bet you didn't). This isn't the important, or complex part.
>
> Not only have I looked at the code, I've also debugged it quite a bit.
> Granted most of my problems had to do with handling paths on Windows
> (i.e. string manipulations).
>
> Let me snip "C is better than C++" part ...
>> [ snip ]
> ... and explain where I'm coming from:
> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.
> The fact that Git is written in C does not really contribute to that goal.
Coupled with what you said in an earlier mail, namely
---%<---%<---
> Obviously C++ developers can contribute C code. But assuming that they
> prefer it that way is wrong.
>
> I was coding in Assembly when there was no C.
> Then in C before C++ was created.
> Now days it's C++ and C#, and I have never looked back.
---%<---%<---
Considering C appeared in 1972, and C++ appeared in 1985, you have been
writing C code for 13 years. And you're telling me that git being written
in C prevents you from contributing?
If you want to do something useful in C++ for git, make it easy for C++
programmers to write apps for it.
>
> Now, I realize that I'm a very infrequent contributor to Git, but I
> want my opinion to be heard.
> People who carry the main weight of developing and maintaining Git
> should make the call.
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++.
It happens to all projects, sooner or later. The funny thing is that all those
people that want their favourite software to be rewritten in their favourite
programming language always wants someone else to rewrite it for them.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: David Kastrup @ 2007-09-07 6:36 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <46E08DE9.4060701@11011.net>
Douglas Stockwell <doug@11011.net> writes:
> David Kastrup wrote:
>> If anybody is as fortunate as to actually have Vista available, it
>> would be nice if he corroborated that relative links under Vista are
>> indeed (as Microsoft appears to claim) relative with regard to the
>> current work directory rather than the directory containing the link.
>
> I believe the wording "resolves the path relative to the current
> directory" actually refers to the creation of links, not to their use.
>
> C:\stest>ver
>
> Microsoft Windows [Version 6.0.6000]
[Examples]
Good. So we will ultimately be able to support symlinks on some
Windows versions.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: David Symonds @ 2007-09-07 6:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, jnareb, ltuikov
In-Reply-To: <ee77f5c20708312246u37f9c1bahe2211117abd05790@mail.gmail.com>
On 01/09/2007, David Symonds <dsymonds@gmail.com> wrote:
> On 31/08/07, David Symonds <dsymonds@gmail.com> wrote:
> > On 31/08/2007, Petr Baudis <pasky@suse.cz> wrote:
> > > Please feel encouraged to make random forks for your development
> > > efforts, or push your random patches (preferrably just bugfixes,
> > > something possibly controversial should be kept in safe containment like
> > > a fork or separate branch) to the mob branch.
> >
> > Sorry, I'm still relatively new to git, and couldn't work out how to
> > push to the mob branch, so it's inline below. It's fairly minor, just
> > adding <span title="foo">..</span> around author names when they get
> > abbreviated.
>
> Okay, I worked out how to push to the mob branch: it's commit 37c8546.
> I can refactor this somewhat if that's an issue.
Has anyone taken a look at this? If it's bad/unwanted, just tell me
and I'll drop it.
Dave.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 6:47 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061721r537b153eu1b0bb3c27fb7bd51@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> In other words: the choice of C is the only sane choice. I know
>> Miles Bader jokingly said "to piss you off", but it's actually
>> true. I've come to the conclusion that any programmer that would
>> prefer the project to be in C++ over C is likely a programmer that
>> I really *would* prefer to piss off, so that he doesn't come and
>> screw up any project I'm involved with.
>
> As dinosaurs (who code exclusively in C) are becoming extinct, you
> will soon find yourself alone with attitude like this.
As long as TeX, Emacs and vi are around, I would not worry too much
about dinosaurs in general. But C++ is a cancerous dinosaur. It has
growths that just don't belong on a C body.
> I was coding in Assembly when there was no C. Then in C before C++
> was created. Now days it's C++ and C#, and I have never looked
> back. Bad developers will write bad code in any language. But
> penalizing good developers for this illusive reason of repealing bad
> contributors is nonsense.
The problem with C++ is that every C++ developer has his own style,
and reuse is an illusion within that style. Take a look at classes
implementing matrix arithmetic: there are as many around as the day is
long, and all of them are incompatible with one another.
With regard to programming styles, C++ does not support multiple
inheritance. For a single project grown from a single start, you can
get reasonable solutions. But combining stuff is creating maintenance
messes.
With C, the situation is not dissimilar, but you spent less time
fighting the illusion that you don't need to reimplement, anyway.
> I just wanted to get a sense of how many people share this "Git
> should be in pure C" doctrine.
What nonsense. Large parts of git already are shell scripts, so
obviously there is no such doctrine. Just because C++ is not a sane
proposition does not mean that others might not work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 6:50 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061808q85cf75co75f2331dc2bdbcbe@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> I'll give you reasons why to use C++ for Git (not why C++ is better
> for any project in general, as that again would be pointless):
>
> 1. Good String class will make code much more readable (and
> significantly shorter)
> 2. Good Buffer class - same reason
> 3. Smart pointers and smart handles to manage memory and
> file/socket/lock handles.
But all of those are incompatible with another and require major
headaches and/or interface code to get to run with one another. And
then might use different interface styles, anyway.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 6:52 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709062009x59a41cb7re6051739c11e370c@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> ... and explain where I'm coming from:
> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.
> The fact that Git is written in C does not really contribute to that goal.
> Suggestion to use C++ is the only alternative with existing C codebase.
> So while C++ may not be the best choice "academically speaking" it's
> pretty much the only practical choice.
Sorry, but for fixing things in C, I can look and work locally. For
fixing things in C++, I first need to understand the class
hierarchies used in the project.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: rebase from ambiguous ref discards changes
From: Pierre Habouzit @ 2007-09-07 6:55 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <1189133898.30308.58.camel@koto.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]
On Fri, Sep 07, 2007 at 02:58:18AM +0000, Keith Packard wrote:
> On Thu, 2007-09-06 at 16:26 -0700, Junio C Hamano wrote:
>
> > Perhaps you have ".git/master" by mistake?
>
> oops.
>
> $ find .git -name master
> ..git/master
> ..git/refs/heads/master
> ..git/refs/remotes/kyle/master
> ..git/refs/remotes/origin/master
> ..git/refs/remotes/otc/master
> ..git/logs/refs/heads/master
> ..git/logs/refs/remotes/fdo/master
> ..git/logs/refs/remotes/kyle/master
> ..git/logs/refs/remotes/origin/master
> ..git/logs/refs/remotes/otc/master
>
> So, I think that explains where the ambiguous master came from. Seems
> like rebase should be able to bail out before breaking things though.
Actually if I get this right, it didn't broke anything, it just
rebased your ".git/master" :) It just chose the wrong desambiguation for
some reason.
--
·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