* 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
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 3:06 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061721r537b153eu1b0bb3c27fb7bd51@mail.gmail.com>
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.
Cheers,
Wincent
^ permalink raw reply
* Re: rebase from ambiguous ref discards changes
From: Keith Packard @ 2007-09-07 2:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, Git Mailing List
In-Reply-To: <7vsl5r8jer.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
On Thu, 2007-09-06 at 16:26 -0700, Junio C Hamano wrote:
> We haven't touched this area for a long time (like "v1.3.0" or
> "since March 2006"). I wish you told us about this earlier.
I would have were I certain that it wasn't user-error last time. I took
a few minutes this time to verify precisely what I saw and reproduce it.
> I'd like to reproduce this, but I need to be sure what your
> "ambiguous" situation is really like. What ambiguous "master"s
> do you have? IOW, what does:
>
> git show-ref | grep master
$ git show-ref | grep master
286f5df0b62f571cbb4dbf120679d3af029b8775 refs/heads/master
1feb733eb8b09a8b07b7a6987add5149c53b0157 refs/heads/master-guitar
d957c6b8e1dde8e11c1db3431e0ff58c5d984880 refs/heads/master-i830
0fd3ba0518b3cde9ca0e4e2fc1854c00d8a43d5c refs/remotes/kyle/master
e25f8e145f4f73b62c32389b922291fd561af9d2 refs/remotes/origin/lg3d-master
286f5df0b62f571cbb4dbf120679d3af029b8775 refs/remotes/origin/master
e25f8e145f4f73b62c32389b922291fd561af9d2 refs/remotes/otc/lg3d-master
6781575f734f05547d7d5ceef4116fc157bba44d refs/remotes/otc/master
so, nothing obviously amiss here.
> 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.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Distributing revisions to patches in a series
From: Daniel Barkalow @ 2007-09-07 2:34 UTC (permalink / raw)
To: git
I was wondering if anybody's got a good process for the following
situation: I've just rebased a series onto the new origin/next. In the
afterwards, I determined that some of the intermediate merges weren't
right (the patch to split bundle-handling out of builtin-bundle didn't
pick up fixes to builtin-bundle). I also found and fixed a warning added
by my series. I want to take these changes, split them into individual
hunks, and apply each hunk to the appropriate commit from the series
before that commit, generating a new series.
I know how to do it by figuring out where the hunk should go myself and
branching, fixing, and rebasing, but I was wondering if there was a magic
script to just do it. It seems like it should be an automatable operation
(take the last commit as a set of hunks, and walk back up the history,
leaving each one at the oldest commit to which it applies cleanly; when
all of the hunks are allocated, generate a new history by amending
commits).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Nicolas Pitre @ 2007-09-07 2:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, Nix, Steven Grimm,
Git Mailing List
In-Reply-To: <7v7in38ce6.fsf@gitster.siamese.dyndns.org>
On Thu, 6 Sep 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I wonder if this is the best way to go. In the context of a really fast
> > repack happening automatically after (or during) user interactive
> > operations, the above seems a bit heavyweight and slow to me.
>
> Honestly, I do not believe in that mode of operation that much.
>
> "While the user is waiting for the EDITOR"?
>
> Because you do not know how much time you will be given before
> you start, unless
>
> (1) your process can be snapshotted and you can restart at the
> next chance; or
>
> (2) it is so cheap and you can afford to abort and start over
> from scratch at the next chance; or
>
> (3) it is so quick that you can simply have the user wait until
> you are done without adding too much latency to be annoying,
> when you cannnot finish before the EDITOR come back;
I think we have to aim for #3. "Automatic" certainly doesn't imply "can
be slow". It should be reasonably instantaneous, otherwise it'll become
annoying quickly enough. If it can't be (almost) instantaneous in 99%
of normal cases, then I think it simply should be remain asynchronously
througha manual invokation of 'git gc' and we only need to teach/remind
people about it more strongly.
> >> An obvious next steps that can be done in parallel by interested
> >> parties would be:
> >>
> >> (1) come up with a way to give "name" aka "clustering cue" (I
> >> think this is very hard);
> >
> > It is, and IMHO not worth it. If you do it separately from the usual
> > pack-objects process you'll perform extra IO and decompression when
> > walking tree objects just to reconstruct those paths, becoming really
> > slow by the context definition I provided above.
>
> Well, I said "name" in quotes because you do _NOT_ have to give
> the real name. I was not thinking about doing the actual tree
> traversal at all. What you need to do is to come up with a
> token that is the same for the objects in the same deltification
> chain so that they cluster together, and that should be doable
> by looking at the delta chain patterns inside a packfile.
Obviously! Sorry for being slow.
But I still think that a single repack pass should already be able to
pick loose objects and selected (small) packs, and produce a pack with
them all. No need for a separate merge-pack I'd say.
Nicolas
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Junio C Hamano @ 2007-09-07 1:58 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 wonder if this is the best way to go. In the context of a really fast
> repack happening automatically after (or during) user interactive
> operations, the above seems a bit heavyweight and slow to me.
Honestly, I do not believe in that mode of operation that much.
"While the user is waiting for the EDITOR"?
Because you do not know how much time you will be given before
you start, unless
(1) your process can be snapshotted and you can restart at the
next chance; or
(2) it is so cheap and you can afford to abort and start over
from scratch at the next chance; or
(3) it is so quick that you can simply have the user wait until
you are done without adding too much latency to be annoying,
when you cannnot finish before the EDITOR come back;
I think that is a false sense of "ok, we will be able to do
something else in the background meantime", which is not so
useful in practice.
>> An obvious next steps that can be done in parallel by interested
>> parties would be:
>>
>> (1) come up with a way to give "name" aka "clustering cue" (I
>> think this is very hard);
>
> It is, and IMHO not worth it. If you do it separately from the usual
> pack-objects process you'll perform extra IO and decompression when
> walking tree objects just to reconstruct those paths, becoming really
> slow by the context definition I provided above.
Well, I said "name" in quotes because you do _NOT_ have to give
the real name. I was not thinking about doing the actual tree
traversal at all. What you need to do is to come up with a
token that is the same for the objects in the same deltification
chain so that they cluster together, and that should be doable
by looking at the delta chain patterns inside a packfile.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: alan @ 2007-09-07 1:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org>
On Fri, 7 Sep 2007, Linus Torvalds wrote:
> IOW, C++ is in that inconvenient spot where it doesn't help make things
> simple enough to be truly usable for prototyping or simple GUI
> programming, and yet isn't the lean system programming language that C is
> that actively encourags you to use simple and direct constructs.
Not to mention try finding two C++ compilers that support the same
language features. C is a known quantity. C++ depends on whos compiler
you use and what class libraries you use. Trying to make those things
work crossplatform is not an easy task. (Harder than it is in C at
least.)
A number of years ago, a programmer who will not be named (and is not me),
tried to port Perl to C++. It was a disaster. He found that every
compiler handled something differently.
If you stuck to one compiler, it might work. But trying to get GCC to
work like MS C++ or Borland C++ or whatever is just asking for pain.
--
Refrigerator Rule #1: If you don't remember when you bought it, Don't eat it.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Linus Torvalds @ 2007-09-07 1:27 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061808q85cf75co75f2331dc2bdbcbe@mail.gmail.com>
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.
> IMHO Git has a brilliant high-level design (object database, using
> hashes, simple and accessible storage for data and metadata). Kudos to
> you!
> The implementation: a mixture of C and shell scripts, command line
> interface that has evolved bottom-up is so-so.
The only really important part is the *design*. The fact that some of it
is in a "prototyping language" is exactly because it wasn't the core
parts, and it's slowly getting replaced. C++ would in *no* way have been
able to replace the shell scripts or perl parts.
And C++ would in no way have made the truly core parts better.
> > and comparing C to assembler just shows that you don't have a friggin idea
> > about what you're talking about.
>
> I don't see myself comparing assembler to C anywhere.
You made a very clear "assembler -> C -> C++/C#" progression nin your
life, comparing my staying with C as a "dinosaur", as if it was some
inescapable evolution towards a better/more modern language.
With zero basis for it, since in many ways C is much superior to C++ (and
even more so C#) in both its portability and in its availability of
interfaces and low-level support.
> I was pointing out that I've been programming in different languages
> (many more actually) and observed bad developers writing bad code in
> all of them. So this quality "bad developer" is actually
> language-agnostic :-).
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
The very fact that you come in as a newbie, point to some absolutely
*trivial* patches, and use that as an argument for a language that the
original author doesn't like, is a sign of you being a person who should
be disabused on any idiotic notions as soon as possible.
The things that actually *matter* for core git code is things like writing
your own object allocator to make the footprint be as small as possible in
order to be able to keep track of object flags for a million objects
efficiently. It's writing a parser for the tree objects that is basically
fairly optimal, because there *is* no abstraction. Absolutely all of it is
at the raw memory byte level.
Can those kinds of things be written in other languages than C? Sure. But
they can *not* be written by people who think the "high-level"
capabilities of C++ string handling somehow matter.
The fact is, that is *exactly* the kinds of things that C excels at. Not
just as a language, but as a required *mentality*. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
Linus
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Linus Torvalds @ 2007-09-07 1:12 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709070135361.5626@evo.linux-foundation.org>
On Fri, 7 Sep 2007, Linus Torvalds wrote:
>
> The fact is, git is better than the other SCM's. And good taste (and C) is
> one of the reasons for that.
To be very specific:
- simple and clear core datastructures, with *very* lean and aggressive
code to manage them that takes the whole approach of "simplicity over
fancy" to the extreme.
- a willingness to not abstract away the data structures and algorithms,
because those are the *whole*point* of core git.
And if you want a fancier language, C++ is absolutely the worst one to
choose. If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make things
simple enough to be truly usable for prototyping or simple GUI
programming, and yet isn't the lean system programming language that C is
that actively encourags you to use simple and direct constructs.
Linus
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-07 1:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709070135361.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 dinosaurs (who code exclusively in C) are becoming extinct, you
> > will soon find yourself alone with attitude like this.
>
> Unlike you, I actually gave reasons for my dislike of C++, and pointed to
> examples of the kinds of failures that it leads to.
As I said, it's a matter of believes. As such, any reasoning and
arguing will be endless and pointless, as for any other religious
issue.
> You, on the other hand, have given no sane reasons *for* using C++.
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.
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.
> The fact is, git is better than the other SCM's. And good taste (and C) is
> one of the reasons for that.
IMHO Git has a brilliant high-level design (object database, using
hashes, simple and accessible storage for data and metadata). Kudos to
you!
The implementation: a mixture of C and shell scripts, command line
interface that has evolved bottom-up is so-so.
> and comparing C to assembler just shows that you don't have a friggin idea
> about what you're talking about.
I don't see myself comparing assembler to C anywhere.
I was pointing out that I've been programming in different languages
(many more actually) and observed bad developers writing bad code in
all of them. So this quality "bad developer" is actually
language-agnostic :-).
--
- Dmitry
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Nicolas Pitre @ 2007-09-07 0:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, Nix, Steven Grimm,
Git Mailing List
In-Reply-To: <7v1wdb9ymf.fsf_-_@gitster.siamese.dyndns.org>
On Thu, 6 Sep 2007, Junio C Hamano wrote:
> This is a beginning of "git-merge-pack" that combines smaller
> packs into one. Currently it does not actually create a new
> pack, but pretends that it is a (dumb) "git-rev-list --objects"
> that lists the objects in the affected packs. You have to pipe
> its output to "git-pack-objects".
>
> The command reads names of pack-*.pack files from the standard
> input, outputs the objects' names in the order they are stored
> in the original packs (i.e. the offset order). This sorting is
> done in order to emulate the traversal order the original
> "git-rev-list --objects" that was used to create the existing
> pack listed the objects.
>
> While this approach would give the resulting packfile very
> similar locality of access as the original, it does not give the
> "name" component you would see in "git-rev-list --objects"
> output. This information is used as the clustering cue while
> computing delta, and the lack of it means you can get horrible
> delta selection. You do _not_ want to run the downstream
> "git-pack-objects" without the optimization/heuristics to reuse
> delta. IOW, do not run it with --no-reuse-delta.
I wonder if this is the best way to go. In the context of a really fast
repack happening automatically after (or during) user interactive
operations, the above seems a bit heavyweight and slow to me.
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).
> 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.
> An obvious next steps that can be done in parallel by interested
> parties would be:
>
> (1) come up with a way to give "name" aka "clustering cue" (I
> think this is very hard);
It is, and IMHO not worth it. If you do it separately from the usual
pack-objects process you'll perform extra IO and decompression when
walking tree objects just to reconstruct those paths, becoming really
slow by the context definition I provided above.
If you really want to do it then the best way might simply to reverse
your find result above, in order to use pack-objects as if the larger
packs, i.e. the ones that you don't want to merge, simply had an
associated .keep file.
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?
Nicolas
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Linus Torvalds @ 2007-09-07 0:38 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061721r537b153eu1b0bb3c27fb7bd51@mail.gmail.com>
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
>
> As dinosaurs (who code exclusively in C) are becoming extinct, you
> will soon find yourself alone with attitude like this.
Unlike you, I actually gave reasons for my dislike of C++, and pointed to
examples of the kinds of failures that it leads to.
You, on the other hand, have given no sane reasons *for* using C++.
The fact is, git is better than the other SCM's. And good taste (and C) is
one of the reasons for that.
It has nothing to do with dinosaurs. Good taste doesn't go out of style,
and comparing C to assembler just shows that you don't have a friggin idea
about what you're talking about.
Linus
^ permalink raw reply
* Re: [PATCH] git-svn: always use --first-parent
From: Eric Wong @ 2007-09-07 0:37 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <11891232082570-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> This makes git-svn unconditionally invoke git-log with --first-parent when
> it is trying to discover its upstream subversion branch and collecting the
> commit ids which should be pushed to it with dcommit. The reason for always
> using --first-parent is to make git-svn behave in a predictable way when the
> ancestry chain contains merges with other git-svn branches.
>
> Since git-svn now always uses 'git-log --first-parent' there is no longer
> any need for the --first-parent option to git-svn, so this is removed.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> I'd like to add a '--upstream <revspec>' option, just for completeness, but
> that will also require a new test script and now it's way past my bedtime.
Sure thing. We can work on getting --upstream another time, but for now
this is probably the best way to allow merges to work with git-svn.
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: Git's database structure
From: Martin Langhoff @ 2007-09-07 0:33 UTC (permalink / raw)
To: Jon Smirl
Cc: Julian Phillips, Andreas Ericsson, Theodore Tso, Junio C Hamano,
Git Mailing List
In-Reply-To: <9e4733910709050912i57ed7137o6abb02ee741d394b@mail.gmail.com>
On 9/6/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Use blame for an example. Blame has to crawl every commit to see if it
Sure. Build a quick dedicated index for that and measure
- cost (size and commit/fetch costs)
- benefit
- frequency of usage
git is a special-purpouse DB that does great for certain access
patterns. Have a look at monotone for a design that looks a lot like
git but is backed by a general purpouse DB and does equally poorly for
all access patterns ;-)
> It keeps doing this until it figures out the last
> author for every line in the file. Worse case blame has to crawl every
> commit in the data store.
Yep. Can we get a minimal-cost index with just enough hints that can
speed up blame, and perhaps git log with/very/deep/path? Probably!
That's worth pursuing sure.
martin
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Lars Hjemli @ 2007-09-07 0:23 UTC (permalink / raw)
To: Peter Baumann; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <20070906235516.GC4538@xp.machine.xx>
On 9/7/07, Peter Baumann <waste.manager@gmx.de> wrote:
> Wouldn't it be much more pleasant to say something like
>
> git-svn dcommit --on the_branch
>
> whereas 'the_branch' is the name of the upstream branch as specified
> in the fetch/branch section in the git config?
Well, git-svn extracts the svn url, revision and repo uuid from the
commit message, while your proposal only specifies the url. But I'm
still not certain that there is a need for --upstream or anything
similar if git-svn always uses 'git log --first-parent' (see
http://article.gmane.org/gmane.comp.version-control.git/57951).
--
larsh
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-07 0:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org>
On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> >
> > When I first looked at Git source code two things struck me as odd:
> > 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> > it's BS.
>
> *YOU* are full of bullshit.
nice
> C++ is a horrible language. It's made more horrible by the fact that a lot
> of substandard programmers use it, to the point where it's much much
> easier to generate total and utter crap with it. Quite frankly, even if
> the choice of C were to do *nothing* but keep the C++ programmers out,
> that in itself would be a huge reason to use C.
>
> 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.
Measuring number of people who contributed to Git is incorrect metric.
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.
Bad developers will write bad code in any language. But penalizing
good developers for this illusive reason of repealing bad contributors
is nonsense.
Anyway I don't mean to start a religious C vs. C++ war. It's a matter
of beliefs and as such pointless.
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
--
- Dmitry
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Peter Baumann @ 2007-09-06 23:55 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <8c5c35580709061514n1de6f141v5e596074cfa9fb42@mail.gmail.com>
On Fri, Sep 07, 2007 at 12:14:30AM +0200, Lars Hjemli wrote:
> On 9/6/07, Eric Wong <normalperson@yhbt.net> wrote:
> > Wait, actually. --upstream won't ever populate the refs array in
> > working_head_info for dcommit
>
> Sorry, I didn't realize that working_head_info() collected commit-ids
> later used by dcommit. But to implement --upstream we could maybe do
> something like this:
>
> sub working_head_info {
> my ($head, $refs) = @_;
>
> if (defined $_upstream) {
> working_head_info_traverse($head, \$refs);
> return working_head_info_traverse($_upstream, undef);
> }
>
> return working_head_info_traverse($head, \$refs);
> }
>
> sub working_head_info_traverse {
> my ($head, $refs) = @_;
> my ($fh, $ctx) = command_output_pipe('log', '--no-color',
> '--first-parent', $head);
> ...
>
>
> (This was written straight into firefox, late at night, by a perl
> illiterate. Please be gentle...)
>
Sorry, but isn't --upstream just the wrong way to do what you want?
Why should I specify a GIT commit to leat git-svn figure out on what
upstream SVN branch I want to commit? To me, this seems a little
backwards. Wouldn't it be much more pleasant to say something like
git-svn dcommit --on the_branch
whereas 'the_branch' is the name of the upstream branch as specified
in the fetch/branch section in the git config? If I do a dcommit I know
*exactly* on which svn branch it should go, so why can't I specify it on
the cmdline? ... or did I miss something obvious?
-Peter
^ permalink raw reply
* [PATCH] git-svn: always use --first-parent
From: Lars Hjemli @ 2007-09-07 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
This makes git-svn unconditionally invoke git-log with --first-parent when
it is trying to discover its upstream subversion branch and collecting the
commit ids which should be pushed to it with dcommit. The reason for always
using --first-parent is to make git-svn behave in a predictable way when the
ancestry chain contains merges with other git-svn branches.
Since git-svn now always uses 'git-log --first-parent' there is no longer
any need for the --first-parent option to git-svn, so this is removed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
I'd like to add a '--upstream <revspec>' option, just for completeness, but
that will also require a new test script and now it's way past my bedtime.
Documentation/git-svn.txt | 10 ----------
git-svn.perl | 17 +++++------------
2 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 42d7b82..be2e34e 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -317,16 +317,6 @@ This is only used with the 'dcommit' command.
Print out the series of git arguments that would show
which diffs would be committed to SVN.
---first-parent::
-
-This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and
-'show-ignore' commands.
-
-These commands tries to detect the upstream subversion branch by means of
-the embedded 'git-svn-id' line in commit messages. When --first-parent is
-specified, git-svn only follows the first parent of each commit, effectively
-ignoring commits brought into the current branch through merge-operations.
-
--
ADVANCED OPTIONS
diff --git a/git-svn.perl b/git-svn.perl
index d21eb7f..badcd33 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
- $_prefix, $_no_checkout, $_verbose, $_first_parent);
+ $_prefix, $_no_checkout, $_verbose);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -119,14 +119,12 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'no-rebase' => \$_no_rebase,
- 'first-parent' => \$_first_parent,
%cmt_opts, %fc_opts } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
'show-ignore' => [ \&cmd_show_ignore, "Show svn:ignore listings",
- { 'revision|r=i' => \$_revision,
- 'first-parent' => \$_first_parent
+ { 'revision|r=i' => \$_revision
} ],
'multi-fetch' => [ \&cmd_multi_fetch,
"Deprecated alias for $0 fetch --all",
@@ -147,20 +145,16 @@ my %cmd = (
'non-recursive' => \$Git::SVN::Log::non_recursive,
'authors-file|A=s' => \$_authors,
'color' => \$Git::SVN::Log::color,
- 'pager=s' => \$Git::SVN::Log::pager,
- 'first-parent' => \$_first_parent
+ 'pager=s' => \$Git::SVN::Log::pager
} ],
'find-rev' => [ \&cmd_find_rev, "Translate between SVN revision numbers and tree-ish",
- {
- 'first-parent' => \$_first_parent
- } ],
+ {} ],
'rebase' => [ \&cmd_rebase, "Fetch and rebase your working directory",
{ 'merge|m|M' => \$_merge,
'verbose|v' => \$_verbose,
'strategy|s=s' => \$_strategy,
'local|l' => \$_local,
'fetch-all|all' => \$_fetch_all,
- 'first-parent' => \$_first_parent,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
'Commit a diff between two trees',
@@ -818,8 +812,7 @@ sub cmt_metadata {
sub working_head_info {
my ($head, $refs) = @_;
- my @args = ('log', '--no-color');
- push @args, '--first-parent' if $_first_parent;
+ my @args = ('log', '--no-color', '--first-parent');
my ($fh, $ctx) = command_output_pipe(@args, $head);
my $hash;
my %max;
--
1.5.3.1.g0e33-dirty
^ permalink raw reply related
* very slow cherry-pick'ing (old-2.6-bkcvs tree)
From: Erez Zadok @ 2007-09-06 23:51 UTC (permalink / raw)
To: git; +Cc: ezk
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?
Some info:
My 2.6.{18,19,20,21,22} trees were cloned from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.<N>.y.git
My 2.6.9 tree, however, was cloned from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
after which, I truncated the tree (git-reset) to Linus commit which read
"Linux 2.6.9-final".
BTW, I first git-clone --bare to my git server, and then I clone from it to
my test machine.
BTW2, I do git-repack and prune-packed every week.
Thanks,
Erez.
^ permalink raw reply
* [StGit PATCH] Discard stderr when determining if a patch is already applied
From: Karl Hasselström @ 2007-09-06 23:50 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
An error from git-apply just means that the patch isn't applied.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Somewhere in my subprocess refactoring, the discarding of stderr got
lost. This patch adds it back to the only place I have discovered so
far that actually needs it.
stgit/git.py | 3 ++-
stgit/run.py | 9 ++++++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index f847cce..181e10d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -628,7 +628,8 @@ def apply_diff(rev1, rev2, check_index = True, files = None):
diff_str = diff(files, rev1, rev2)
if diff_str:
try:
- GRun('git-apply', *index_opt).raw_input(diff_str).no_output()
+ GRun('git-apply', *index_opt).raw_input(
+ diff_str).discard_stderr().no_output()
except GitRunException:
return False
diff --git a/stgit/run.py b/stgit/run.py
index 29f8f71..7986f3b 100644
--- a/stgit/run.py
+++ b/stgit/run.py
@@ -43,6 +43,7 @@ class Run:
self.__good_retvals = [0]
self.__env = None
self.__indata = None
+ self.__discard_stderr = False
def __log_start(self):
if _log_mode == 'debug':
out.start('Running subprocess %s' % self.__cmd)
@@ -65,11 +66,14 @@ class Run:
try:
p = subprocess.Popen(self.__cmd, env = self.__env,
stdin = subprocess.PIPE,
- stdout = subprocess.PIPE)
+ stdout = subprocess.PIPE,
+ stderr = subprocess.PIPE)
outdata, errdata = p.communicate(self.__indata)
self.exitcode = p.returncode
except OSError, e:
raise self.exc('%s failed: %s' % (self.__cmd[0], e))
+ if errdata and not self.__discard_stderr:
+ out.err_raw(errdata)
self.__log_end(self.exitcode)
self.__check_exitcode()
return outdata
@@ -87,6 +91,9 @@ class Run:
def returns(self, retvals):
self.__good_retvals = retvals
return self
+ def discard_stderr(self, discard = True):
+ self.__discard_stderr = discard
+ return self
def env(self, env):
self.__env = dict(os.environ)
self.__env.update(env)
^ permalink raw reply related
* Re: Subject: [PATCH] git-merge-pack
From: Linus Torvalds @ 2007-09-06 23:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Nicolas Pitre, Nix, Steven Grimm,
Git Mailing List
In-Reply-To: <7v1wdb9ymf.fsf_-_@gitster.siamese.dyndns.org>
On Thu, 6 Sep 2007, Junio C Hamano wrote:
>
> This is a beginning of "git-merge-pack" that combines smaller
> packs into one. Currently it does not actually create a new
> pack, but pretends that it is a (dumb) "git-rev-list --objects"
> that lists the objects in the affected packs. You have to pipe
> its output to "git-pack-objects".
Ok, so I had to double-check that builtin-pack-objects then deals properly
with duplicate object names (which it does seem to do), so maybe it's
worth adding a comment to that effect.
But ACK, this seems to be the right thing to do to generate a single
bigger pack from many smaller ones.
Linus
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Douglas Stockwell @ 2007-09-06 23:31 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85bqcfbvpe.fsf@lola.goethe.zz>
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]
C:\stest>echo test > file
C:\stest>mkdir links
C:\stest>cd links
C:\stest\links>echo links > file
C:\stest\links>mklink relative file
symbolic link created for relative <<===>> file
C:\stest\links>mklink dotted .\file
symbolic link created for dotted <<===>> .\file
C:\stest\links>mklink parent ..\file
symbolic link created for parent <<===>> ..\file
C:\stest\links>mklink rooted \stest\links\file
symbolic link created for rooted <<===>> \stest\links\file
C:\stest\links>mklink absolute c:file
symbolic link created for absolute <<===>> c:file
C:\stest\links>dir
07/09/2007 08:09 AM <DIR> .
07/09/2007 08:09 AM <DIR> ..
07/09/2007 08:09 AM <SYMLINK> absolute [C:\stest\links\file]
07/09/2007 08:09 AM <SYMLINK> dotted [.\file]
07/09/2007 08:09 AM 8 file
07/09/2007 08:09 AM <SYMLINK> parent [..\file]
07/09/2007 08:09 AM <SYMLINK> relative [file]
07/09/2007 08:09 AM <SYMLINK> rooted [\stest\links\file]
C:\stest\links>cd ..
C:\stest>type links\relative
links
C:\stest>type links\dotted
links
C:\stest>type links\parent
test
C:\stest>type links\rooted
links
C:\stest>type links\absolute
links
C:\stest>mkdir a
C:\stest>echo a > a\file
C:\stest>move links a
1 dir(s) moved.
C:\stest>type a\links\relative
links
C:\stest>type a\links\dotted
links
C:\stest>type a\links\parent
a
C:\stest>type a\links\rooted
The system cannot find the path specified.
C:\stest>type a\links\absolute
The system cannot find the path specified.
^ permalink raw reply
* Re: rebase from ambiguous ref discards changes
From: Junio C Hamano @ 2007-09-06 23:26 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1189115308.30308.9.camel@koto.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> So, I started with a very simple repository
>
> ---*--- master
> \
> -- origin/master
>
> From master, I did
>
> $ git-rebase origin/master
> warning: refname 'master' is ambiguous.
> First, rewinding head to replay your work on top of it...
> HEAD is now at 2a8592f... Fix G33 GTT stolen mem range
> Fast-forwarded master to origin/master.
> ...
> Seems like there's something going on when 'master' is ambiguous, or
> perhaps some other problem.
>
> This is all from version 1.5.3, but I think I've seen this on 1.5.2 as
> well.
We haven't touched this area for a long time (like "v1.3.0" or
"since March 2006"). I wish you told us about this earlier.
I'd like to reproduce this, but I need to be sure what your
"ambiguous" situation is really like. What ambiguous "master"s
do you have? IOW, what does:
git show-ref | grep master
say? I have 11 lines of output from the above and I have never
seen a problem like this.
Perhaps you have ".git/master" by mistake?
^ permalink raw reply
* how to access working tree from .git dir?
From: Josh England @ 2007-09-06 23:20 UTC (permalink / raw)
To: Git Mailing List
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).
This wouldn't be so bad, but it seems that `git rev-parse --show-cdup`
does not show anything valid if your current working directory is inside
the .git dir. This creates a scenario where there is no consistent way
to access the root of the working tree from within a hook. To make
things worse, the behavior changes subtly whether $GIT_DIR is defined or
not.
I've got a patch that changes the current working directory before
calling the post-receive hook, but that's more of a workaround than a
fix. I'd like to be able to run `git rev-parse --show-cdup` from with
a .git directory and have it produce a valid result.
So: I'm poking around around and trying to find the right answer but
some things look weird. If anyone knows the quick-and-easy answer here
please let me know. Otherwise, I'll continue to poke around some more.
Thanks,
-JE
^ permalink raw reply
* Re: [PATCH 4/3] archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR"
From: Junio C Hamano @ 2007-09-06 23:17 UTC (permalink / raw)
To: René Scharfe
Cc: Johannes Schindelin, Andreas Ericsson, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <46E068BB.5080202@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Just noticed: if the memcmp() above finds a difference, the code should
> *not* break out of the loop. Ahem. Perhaps I should first add memmem()
> after all...
That sounds like a sensible thing to do.
Will drop this copy and use updated 4/3 and 3.5/3; thanks.
^ 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