* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 11:17 UTC (permalink / raw)
To: Petr Baudis
Cc: Erik B?gfors, Aaron Bentley, Matthieu Moy, bazaar-ng,
Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <20061018110841.GS20017@pasky.or.cz>
Petr Baudis wrote:
> But somewhere else in the thread it's been said that bundles can also
> contain merges. Does that means that bundles can look like:
>
> 1
> / \
> 2 4
> | | _
> 3 5 |
> \ / | a bundle
> 6 |
> ~
>
> In that case [merge bundle], against what the big diff from 6 is done?
> 2? 4? Or even 1?
Or do you use equivalent of git combined diff format?
http://www.kernel.org/pub/software/scm/git/docs/git-diff-tree.html
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-18 11:19 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Aaron Bentley, Linus Torvalds, Carl Worth, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <20061018103220.GS75501@over-yonder.net>
Matthew D. Fuller wrote:
> On Wed, Oct 18, 2006 at 10:39:32AM +0200 I heard the voice of
> Andreas Ericsson, and lo! it spake thus:
>> So in essence, the revnos work wonderfully so long as there is a
>> central server to make them immutable?
>
>
> With a star config, revnos are useful locally and with reference to
> the "main" branch[es]. And, most of the world is star configs of one
> sort or another. Actually, one might say that practically ALL the
> world outside of linux-kernel is star-configs ;)
>
That might be the case today. However, since we introduced git at the
office, mini-projects are cropping up like mad, and pieces of toy-code
are being pushed around among the employees. When something is found to
be useful enough to attract management attention, it's given a spot at
the "master site". It doesn't need one. It's just that we have this one
place where gitweb is installed, which management likes whereas devs
don't have that on their laptop. It's also convenient to have one place
to find all changes rather than pulling from 1-to-N different people
just to have a look at what they've done.
The point I'm trying to make here is that the star config might be the
most common case today because
a) old scm's enforced this use case and it is therefor the most common
way just out of habit.
b) projects you actually *see* have gotten past the "Joe made some cool
changes, pull his 'jukebox-ui' branch".
> In many cases in the star setup, a revno (particularly along the
> 'trunk') is more directly useful than a UUID; consider particularly
> the case of somebody who's just mirroring/following, not actively
> developing. In some cases, the UUID is more useful. Certainly, using
> a revno in a case where the UUID is more appropriate is Bad, but
> that's just a matter of using the right tool.
>
I can easily imagine the use case Linus pointed out with BK. Because
revnos work wonderfully 80% of the time, people get confused, frustrated
and downright pissed off when they don't.
>
> With a uber-distributed full-mesh setup, revnos may be basically
> useless for anything except local lookups (which boils down to
> "useless for most anything you'd identify a revision for"). For that
> case, you'd practically always use the UUID, and pretend revnos don't
> exist.
>
But they *do* exist, and they *usually* work, so people are bound to try
them first. Teaching them when they work and when they don't (or rather,
when they should and when they shouldn't, cause they will work by
accident sometimes too) is bound to be a lot harder than sending them a
10 char irc message.
>
> The merge revno forms (123.5.2.17 and the like), I'm somewhat
> ambivalent about in many ways. But, you don't have to use them any
> more than you have to use "top-level" revnos. If either form of revno
> is Wrong for your case (whether it be because "I hate numbers
> wholesale", or because "Numbers don't cover this case usefully"), then
> you just use the UUID and pretend the number isn't there. If you
> wanted them completely out of sight, I wouldn't expect it to be very
> hard to talk bzr into never showing the revnos and just showing the
> UUID ("revid").
>
So what's the point in having them? You can't seriously tell me that you
think of 123.5.2.17 as something you can easily remember, do you? Count
the times, during one day, where you use the revnos and type them manually.
>
>
> [ I don't speak for bzr, despite the fact that I'm about to appear to ]
>
>>From where I sit, revnos are quite useful in the first 1.5 or 2 cases.
> Some would argue that they're not useless in the third case as well,
> but that's no necessary point to hash out; it certainly does no
> technical harm to have them there, since you can just ignore them if
> they don't help you. I think a good case could be made that the vast
> majority of VCS use in the world is a form of case 2.
>
> Git comes out of a world where case 3 is All, and the other cases are,
> if not actively ignored, at least far secondary considerations, so it
> can hardly be surprising that it doesn't have or want something that
> adds practically nothing to its case.
>
Not really. It's just that case 3 is the most flexible of them all. It's
trivial to enforce linear development in git. Just add a hook that
forbids merge commits. Set up a "master repo" and put the hook there and
you've turned it into CVS with off-line log-browsing (more or less).
Set up a master-server and enable the reflog there and you've turned it
into bazaar, more or less.
In git, the mothership repo is there for conveniance, because it's nice
to have one place to set up mailing-list hooks, gitweb, git-daemon and
the likes. Everything works *exactly* as it would have done without it
in all repos around the world.
> bzr, both in its own development schema, and in the expected audience,
> is overwhelmingly case 2 (of which case 1 is really just a degenerate
> version), but that doesn't mean case 3 is ignored or impossible. The
> UUID's are there for when you need them, and can be used anywhere you
> might use a number, and just as easily. It's a community convention
> to organize development in such a way that the number is "usually"
> useful, and when it is, it's certainly easier. That doesn't mean you
> HAVE to use it in cases where it doesn't fit, though. "bzr people
> like to avoid using UUID's" doesn't lead to "bzr can't handle the
> cases where UUID's are necessary".
>
Have a look at the list of things that CVS "can handle" and compare it
mentally to the things CVS "handles gracefully" and you'll see why
people have stopped using it.
>
>> Doesn't this mean that one of your key features doesn't actually
>> work in a completely distributed setup
>
> That's one way of phrasing it, I guess. I'd say rather "a particular
> feature isn't applicable to a completely distributed setup".
So how come it's in the same list of features as the "distributed
repository model", and both are marked as supported when they're
apparently mutually exclusive?
> I'm sure
> git has a lot of features that are key for somebody that "don't work"
> for someone else, just because they're doing something that person
> doesn't want done.
The main point, the *important* point about git is that everything it
shows always makes sense and works in exactly the same way no matter
which setup you use. There are no features in git that are mutually
exclusive, or only sane in one particular setup but not in others. You
can use them all or pick which ones you like. Whatever you choose, it
never comes at the expense of losing something else.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Markus Amsler @ 2006-10-18 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike McCormack, git
In-Reply-To: <7vejt53olg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Mike McCormack <mike@codeweavers.com> writes:
>
>> Junio C Hamano wrote:
>>> Markus Amsler <markus.amsler@oribi.org> writes:
>>>
>>>> Cyrus imap refuses messages with a 'From ' Header.
>>>>
>>>> Signed-off-by: Markus Amsler <markus.amsler@oribi.org>
>>> Do you know if this change does not upset other implementations
>>> of imap servers?
>>>
>>> Mike, are you Ok with this change?
>> Works for me with Courier IMAP. I'm no expert on mail headers either,
>> so no objections from me.
>>
>> Mike
>
> Thanks; then will apply.
>
> By the way, Markus, did you send the patch with imap-send? It
> had a funny whitespace corruptions.
No, I was too lazy to set up an imap config for one patch. So I used git
diff an copy pasted it into Thunderbird. Sorry.
Markus
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-18 12:43 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Aaron Bentley, Linus Torvalds, Carl Worth, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <45360DAE.8000702@op5.se>
On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of
Andreas Ericsson, and lo! it spake thus:
>
> It's just that we have this one place where gitweb is installed,
> which management likes whereas devs don't have that on their laptop.
> It's also convenient to have one place to find all changes rather
> than pulling from 1-to-N different people just to have a look at
> what they've done.
I think this just by itself lends support to:
> The point I'm trying to make here is that the star config might be
> the most common case today because
c) Stars work well as a mental model for humans.
Heck, in large, Linux is star-ish. There s "2.6.1", "2.6.2", etc;
that's a trunk. Any time you have releases, you're establishing a
"master" branch. For most people using Linux, there's a trunk,
whether it's the kernel.org trunk, or the "What Redhat ships" trunk,
etc. The closer you drill to the day-to-day work on the kernel, the
farther it gets from trunks, but if it were full-mesh at all levels I
don't think it would be nearly as usable for regular computing tasks
as it is.
Perhaps someday a heavy full-mesh setup will be the common case for
VCS usage. I find that very difficult to buy for various reasons, but
it could happen. If it does, bzr may well revisit the choice and
decide revnos contribute little enough marginal value as to be a loss,
and discard them. But that's not today.
> But they *do* exist, and they *usually* work, so people are bound to
> try them first. Teaching them when they work and when they don't (or
> rather, when they should and when they shouldn't, cause they will
> work by accident sometimes too) is bound to be a lot harder than
> sending them a 10 char irc message.
Perhaps, for some projects. And in those cases, perhaps you'd want to
flip a hypothetical "dump those numbers in the bin" switch. That
doesn't mean every project wants to, or that those projects who don't
and have no trouble and discernible gain from revno usage are
hypothetical.
> So what's the point in having them? You can't seriously tell me that
> you think of 123.5.2.17 as something you can easily remember, do
> you? Count the times, during one day, where you use the revnos and
> type them manually.
No, I don't. But I don't use merge revnos for various reasons, one of
the primary ones being that they don't currently intuitively follow
from me (and that intuitiveness is the major attraction of revnos in
the first place).
I rarely refer to non-mainline revisions at all, in fact. And I use
revnos for mainline revisions regularly. Heck, I communicate revnos
_verbally_; people handle that easily with numbers, not so easily with
hex strings. The vast majority of my branches are simple cases, and I
like simple tools that match simple mental models for them. For the
more intricate cases, revids provide a more rigorous tool, and I WANT
a VCS that lets me choose which is appropriate. If I wanted a
computer to tell me how to work, I'd run Windows ;)
> Not really. It's just that case 3 is the most flexible of them all.
Yes, but this doesn't necessarily mean everything you seem to try and
cover with it. The more rigorous tool will cover the simplest case
(those being just a degenerate form of the more complex after all),
but that doesn't mean it's the EASIEST way of handling that case.
> Everything works *exactly* as it would have done without it in all
> repos around the world.
And if you use the UUID's, the same applies to bzr.
That is, if you use git like you use git, the above is true. If you
use bzr like you use git, the above is ALSO true.
The difference is that bzr ALSO chooses to support and optimize for a
different case in the default UI presentation, because We[0] consider
that far and away the common case on the one hand, and that people
trying to use the more complex case are ipso facto more able to use a
behavior differing from the norm on the other.
[0] Note how adroitly I again speak for other people. Practice,
practice!
> >That's one way of phrasing it, I guess. I'd say rather "a
> >particular feature isn't applicable to a completely distributed
> >setup".
>
> So how come it's in the same list of features as the "distributed
> repository model", and both are marked as supported when they're
> apparently mutually exclusive?
I assume in this you're referring to the RcsComparisons page that
started the thread. First off, I don't agree with all the
characterizations on the page, so don't expect me to support it as
gospel. That said, they're not "mutually exclusive"; one is just
inapplicable in extreme cases of the other. "Plugins" is on the same
list as "distributed repository model" too. And you can't count on
other people having the same plugins as you, so it's just as "mutually
exclusive" with distributed.
> The main point, the *important* point about git is that everything
> it shows always makes sense and works in exactly the same way no
> matter which setup you use. There are no features in git that are
> mutually exclusive, or only sane in one particular setup but not in
> others.
I find it really hard to believe that that's strictly true, just as a
general rule. For that matter, I think it's demonstrably false: using
SHA1 hashes as revision identifiers in a simple linear tree with 5
revs doesn't strike me as "sane". But that aside...
I don't think of that as a positive thing. There are lots of things
that make sense in certain setups that don't in others. We have two
techniques, A and B, and two general cases, X and Y. A works really
well for X, and is useless with Y. B works ok for X, and handles Y
well. "Use A for X and B for Y" seems like a heck of a lot better
answer than "Only support B". You certainly CAN shape wood joints
with just a claw hammer, but I wouldn't want to. A jigsaw makes it
much easier, no matter how useless it may be for forging iron.
Your position seems to be, in essence, "This feature can be misused,
therefore it should be eliminated". And you should certainly use a
tool that provides the behavior you want. So, too, should other
people.
I don't want to use git for any number of reasons, which sum up
concisely if undescriptively as "It doesn't work for me", but it seems
to work great for the community it was built for, and that's
excellent. Not all aspects of that design work well for other people,
though, no matter how poorly some capability "fits" you
(non-specific), it can still fit others very well. This particular
item certainly seems one of those significant divides.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-18 13:02 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Andreas Ericsson, Aaron Bentley, Linus Torvalds, Carl Worth,
bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061018124320.GT75501@over-yonder.net>
On Wed, 18 Oct 2006 07:43:20 -0500
"Matthew D. Fuller" <fullermd@over-yonder.net> wrote:
> The difference is that bzr ALSO chooses to support and optimize for a
> different case in the default UI presentation, because We[0] consider
> that far and away the common case on the one hand, and that people
> trying to use the more complex case are ipso facto more able to use a
> behavior differing from the norm on the other.
>
> [0] Note how adroitly I again speak for other people. Practice,
> practice!
Just to be clear here, Git is also able to supports this model if
you so choose. It's quite easy for a server to generate Git tags
for every commit it gets.
It's just that this is basically a non issue in the Git world. People
who use Git aren't crying out for salvation from sha1 numbers. So I
think this entire discussion is a bit overblown.
But just to be clear, there is nothing in the Git model that prohibits
tagging every commit with something you find less objectionable than
sha1's. They can appear in the log listings and in gitk etc, and
everyone who pulls from the central server will get them. In fact,
for some imports of other VCS into Git, exactly that is done; so every
commit can be referenced by its sha1 _or_ the "friendly" number it was
known by in its original VCS.
Sean
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vu022gqji.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Ah, I misread the code that uses union actually checks the type
> > in struct delta_entry (which embeds the union). There won't be
> > any collision problem and you support both types at the same
> > time just fine.
> >
> > And your patch to compare only the first 20-bytes makes sense
> > (assuming ulong is always shorter than 20-bytes which I think is
> > safe to assume).
>
> Does this sound fair (the code is yours, just asking about the
> log message)?
>
> If we really wanted to be purist, we could run comparison with
> the union and obj->type as two keys, but I do not think it is
> worth it.
>
> -- >8 --
> From: Nicolas Pitre <nico@cam.org>
> Date: Tue, 17 Oct 2006 16:23:26 -0400
> Subject: [PATCH] index-pack: compare the first 20-bytes of the key.
>
> The "union delta_base" is a strange beast. It is a 20-byte
> binary blob key to search a binary searchable deltas[] array,
> each element of which uses it to represent its base object with
> either a full 20-byte SHA-1 or an offset in the pack. Which
> representation is used is determined by another field of the
> deltas[] array element, obj->type, so there is no room for
> confusion, as long as we make sure we compare the keys for the
> same type only with appropriate length. The code compared the
> full union with memcmp().
>
> When storing the in-pack offset, the union was first cleared
> before storing an unsigned long, so comparison worked fine.
>
> On 64-bit architectures, however, the union typically is 24-byte
> long; the code did not clear the remaining 4-byte alignment
> padding when storing a full 20-byte SHA-1 representation. Using
> memcmp() to compare the whole union was wrong.
>
> This fixes the comparison to look at the first 20-bytes of the
> union, regardless of the architecture. As long as ulong is
> smaller than 20-bytes this works fine.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Nicolas Pitre <nico@cam.org>
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-18 13:09 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, bazaar-ng, Linus Torvalds, Andreas Ericsson, git,
Jakub Narebski
In-Reply-To: <20061018110841.GS20017@pasky.or.cz>
On 10/18/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Oct 18, 2006 at 11:28:32AM CEST, I got a letter
> where Erik B?gfors <zindar@gmail.com> said that...
> > On 10/18/06, Petr Baudis <pasky@suse.cz> wrote:
> > >Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
> > >where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> > >> Petr Baudis wrote:
> > >> > Another aspect of this is that Git (Linus ;) is very focused on getting
> > >> > the history right, nice and clean (though it does not _mandate_ it and
> > >> > you can just wildly do one commit after another; it just provides tools
> > >> > to easily do it).
> > >>
> > >> Yes, rebasing is very uncommon in the bzr community. We would rather
> > >> evaluate the complete change than walk through its history. (Bundles
> > >> only show the changes you made, not the changes you merged from the
> > >> mainline.)
> > >>
> > >> In an earlier form, bundles contained a patch for every revision, and
> > >> people *hated* reading them. So there's definitely a cultural
> > >> difference there.
> > >
> > >BTW, I think what describes the Git's (kernel's) stance very nicely is
> > >what I call the Al Viro's "homework problem":
> > >
> > > http://lkml.org/lkml/2005/4/7/176
> > >
> > >If I understand you right, the bzr approach is what's described as "the
> > >dumbest kind" there? (No offense meant!)
> >
> > Yes and no, The bundle includes both the full final thing, and each
> > step along the way. Each step along the way is something you'll get
> > when you merge it.
> >
> > Once merged, it will be "next one" in the description above. It would
> > typically look something like this in "bzr log"(shortened) In this
> > example, doing C requires doing A and B as well...
> >
> > committer: foobar@foobar.com
> > message: merged in C
> > -------
> > committer: bar@bar.com
> > message: opps, fix bug in A
> > -------
> > committer: bar@bar.com
> > message: implement B
> > -------
> > committer: bar@bar.com
> > message: implement A
> >
> > So, you'll get full history, including errors made :) You can also
> > see who approved it to this branch (foobar) and who did the actual
> > work (bar)
>
> I see, that's what I've been missing, thanks. So it's the middle path
> (as any other commonly used VCS for that matter, expect maybe darcs?;
> patch queues and rebasing count but it's a hack, not something properly
> supported by the design of Git, since at this point the development
> cannot be fully distributed).
>
> I also assume that given this is the case, the big diff does really not
> serve any purpose besides human review?
>
> But somewhere else in the thread it's been said that bundles can also
> contain merges. Does that means that bundles can look like:
>
> 1
> / \
> 2 4
> | | _
> 3 5 |
> \ / | a bundle
> 6 |
> ~
>
> In that case, against what the big diff from 6 is done? 2? 4? Or even 1?
When you run the "bundle" command, you can tell it what you want the
bundle to be created against. So, If I just commited 5, I can run
"bzr bundle -r-1" to get the bundle against 4, or I can do "bzr bundle
path/to/other/branch" to get a bundle that relates to it.
To merge a bundle into a branch, the parrent of the first revision in
the bundle, has to exist in the branch is't being merged into. (well,
unless you use patch, but that's outside of bzr, and bzr wouldn't know
about each revision in them)
This command will find a common root and create a bundle that
corresponds to it. The "big diff" as you call it, would be the
changes between the point where the branch was created, and the last
commit.
In the case of just committing 5, and you want to create a bundle that
can be merged back at point 6, the "big diff" would be against 1 since
that's the branch point.
/Erik
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 13:10 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Andreas Ericsson, Aaron Bentley, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <20061018124320.GT75501@over-yonder.net>
Dnia środa 18. października 2006 14:43, Matthew D. Fuller napisał:
> On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of
> Andreas Ericsson, and lo! it spake thus:
> >
> > It's just that we have this one place where gitweb is installed,
> > which management likes whereas devs don't have that on their laptop.
> > It's also convenient to have one place to find all changes rather
> > than pulling from 1-to-N different people just to have a look at
> > what they've done.
>
> I think this just by itself lends support to:
>
> > The point I'm trying to make here is that the star config might be
> > the most common case today because
>
> c) Stars work well as a mental model for humans.
>
> Heck, in large, Linux is star-ish. There s "2.6.1", "2.6.2", etc;
> that's a trunk. Any time you have releases, you're establishing a
> "master" branch. For most people using Linux, there's a trunk,
> whether it's the kernel.org trunk, or the "What Redhat ships" trunk,
> etc. The closer you drill to the day-to-day work on the kernel, the
> farther it gets from trunks, but if it were full-mesh at all levels I
> don't think it would be nearly as usable for regular computing tasks
> as it is.
No, it is not. If you consider only published Linus repository, and
private repositories of other people, it usually is star-ish (although
mentioned situaltion where somebody else repository took place of center
of star-ish configuration wouldn't be possible in tru star-ish model).
But please take note of stable repository, -mm repository; the changes
are exchanged there and back again. And "What Redhat ships" is AFAIK
mix of different repositories and own patches.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 13:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0610181159050.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 18 Oct 2006, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> > +/*
> > + * Even if sizeof(union delta_base) == 24 on 64-bit archs, we really want
> > + * to memcmp() only the first 20 bytes.
> > + */
> > +#define UNION_BASE_SZ 20
>
> Excuse me for joining the game, but why don't you just use the
> recently introduced hashcmp() for that purpose? AFAIU you do exactly that,
> you compare hashes.
Yes, and that is what I did originally.
But that could lead to false assumptions (and this thread already proved
this code has its share of false assumption leads already). The thing
is that the memory chunk that is being compared is not always the same
kind of hash as usually used with hashcmp(). Throughout the code
hashcmp() is always used with a 20-byte sha1 digest. In this case it
can be either a 20-byte sha1 digest, or a long offset value. And by
using hashcmp() I would be afraid someone else could assume the hash is
always a sha1 digest which it is not.
Nicolas
^ permalink raw reply
* Re: [BUG] git-log shows first parent and repeated last for octopus merge
From: Johannes Schindelin @ 2006-10-18 13:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eh5242$rar$1@sea.gmane.org>
Hi,
On Wed, 18 Oct 2006, Jakub Narebski wrote:
> When trying to find how many merges and how many octopus merges (merges with
> more than two parents) are in git.git repository I have encountered the
> following strange output of git-log:
>
> 1000:jnareb@roke:~/git> git log --parents --full-history --max-count=1 \
> 211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
> commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e <last parent repeated>
> Merge: d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b...
> [...]
This happens because a//b rewrites the history, i.e. the parents are
edited. IMHO it makes no sense at all to show the parents in such a case,
since they are bogus.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] git-log shows first parent and repeated last for octopus merge
From: Jakub Narebski @ 2006-10-18 14:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610181551150.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Wed, 18 Oct 2006, Jakub Narebski wrote:
>
> > When trying to find how many merges and how many octopus merges (merges with
> > more than two parents) are in git.git repository I have encountered the
> > following strange output of git-log:
> >
> > 1000:jnareb@roke:~/git> git log --parents --full-history --max-count=1 \
> > 211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
> > commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e <last parent repeated>
> > Merge: d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b...
> > [...]
>
> This happens because a//b rewrites the history, i.e. the parents are
> edited. IMHO it makes no sense at all to show the parents in such a case,
> since they are bogus.
Or rather it has no sense to _repeat_ rewritten parent the number of times
the commit has parents originally. Compare git-log and git-rev-list results:
1010:jnareb@roke:~/git> git rev-list --full-history --header --parents \
--max-count=2 211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
211232bae64bcc60bbf5d1b5e5b2344c22ed767e d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f
tree cdafa88fa4ed7fcc7bb6c64d62e2d7c4d3b65e42
parent fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc
parent 9e30dd7c0ecc9f10372f31539d0122db97418353
parent c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a
parent 660265909fc178581ef327076716dfd3550e6e7b
parent b28858bf65d4fd6d8bb070865518ec43817fe7f3
author Junio C Hamano <junkio@cox.net> 1115335014 -0700
committer Junio C Hamano <junkio@cox.net> 1115335014 -0700
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f 54c26fb9d0cdff94c7717125d0a222b324bfea8a
[...]
1014:jnareb@roke:~/git> PAGER= git log --full-history --parents \
--max-count=2 211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f
Merge: d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b...
Author: Junio C Hamano <junkio@cox.net>
Date: Thu May 5 16:16:54 2005 -0700
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit d0d0d0bd3c2c4591ffbc292d7e082e8ad8f2057f 54c26fb9d0cdff94c7717125d0a222b324bfea8a 54c26fb9d0cdff94c7717125d0a222b324bfea8a
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] When rewriting parents, cull duplicates
From: Johannes Schindelin @ 2006-10-18 14:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610181602.36856.jnareb@gmail.com>
Earlier, when calling
git log --parents some-ref -- path/file
it was possible that in case of merges, multiple parents would be
rewritten as the _same_ commit, which would happily be printed
multiple times.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Subject: Re: [BUG] git-log shows first parent and repeated last
for octopus merge
On Wed, 18 Oct 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
> > On Wed, 18 Oct 2006, Jakub Narebski wrote:
> >
> > > When trying to find how many merges and how many octopus
> > > merges (merges with more than two parents) are in git.git
> > > repository I have encountered the following strange output
> > > of git-log:
> > >
> > > 1000:jnareb@roke:~/git> git log --parents --full-history \
> > > --max-count=1 211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
> > > commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e <...>
> > > Merge: d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b...
> > > [...]
> >
> > This happens because a//b rewrites the history, i.e. the
> > parents are edited. IMHO it makes no sense at all to show the
> > parents in such a case, since they are bogus.
>
> Or rather it has no sense to _repeat_ rewritten parent the
> number of times the commit has parents originally.
Here you are.
revision.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 280e92b..8a2ca52 100644
--- a/revision.c
+++ b/revision.c
@@ -1086,12 +1086,23 @@ static int rewrite_one(struct rev_info *
}
}
+static int parent_is_duplicate(struct commit_list *parents,
+ struct commit_list *current)
+{
+ for (; parents != current; parents = parents->next)
+ if (parents->item == current->item)
+ return 1;
+ return 0;
+}
+
static void rewrite_parents(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp = &commit->parents;
while (*pp) {
struct commit_list *parent = *pp;
- if (rewrite_one(revs, &parent->item) < 0) {
+ if (rewrite_one(revs, &parent->item) < 0 ||
+ /* cull duplicates */
+ parent_is_duplicate(commit->parents, parent)) {
*pp = parent->next;
continue;
}
--
1.4.2.4.g21cef-dirty
^ permalink raw reply related
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-18 14:52 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061018053647.GA3507@coredump.intra.peff.net>
On Wed, 18 Oct 2006, Jeff King wrote:
>
> I never used BK, but my understanding is that it was based on
> changesets, so a bundle was a group of changesets.
Yes.
> Because a git commit represents the entire tree state, how can we avoid
> sending the entire tree in each bundle?
That's not the problem. That's easy to handle - and we already do. That's
the whole point of the wire-transfer protocol (ie sending deltas, and only
sending enough to actually matter).
> The interactive protocols can ask "what do you have?" but an email
> bundle is presumably meant to work without a round trip.
Right, but they can do exactly what bk did: you have to have a reference
to what the other side has. In git, that's usually even simpler: you'd do
git send origin..
and that "origin" is what the other end is expected to already have.
Of course, if you send an unconnected bundle (ie you give an origin that
the other end _doesn't_ have), you're screwed.
In other words, to get such a pack, we'd _literally_ just do something
like
git-rev-list --objects-edge origin.. |
git-pack-objects --stdout |
uuencode
and that would be it. You'd still need to add a "diffstat" to the thing,
and tell the other end what the current HEAD is (so that it knows what
it's supposed to fast-forward to), but it _literally_ is that simple.
"plug-in architecture" my ass. "I recognize this - it's UNIX!".
Linus
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-18 14:56 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610172242430.17253@alien.or.mcafeemobile.com>
On Tue, 17 Oct 2006, Davide Libenzi wrote:
>
> Ehm, I think there's a little bit of confusion. The incorrect golden ratio
> prime selection for 64 bits machines was coalescing hash indexes into a
> very limited number of buckets, hence creating very bad performance on diff
> operations. The result of the diff would have been exacly the same, just
> coming out after the time for a cup of coffee and a croissant ;)
But my point is, you would have been better off _without_ an algorithm
that cared about the word-size at all, or with just using "uint32_t".
See? Yes, a "unsigned long" has more bits for hashing on a 64-bit
architecture. But that's totally the wrong way of thinking about it. YOU
DO NOT WANT MORE BITS! You want the same damn answer regardless of
architecture!
A diff algorithm that gives different answers on a 32-bit LE architecture
than on a 64-bit BE architecture is BROKEN. If I run on x86-64, I want the
same answers I got on x86-32, and the same ones I get on ppc32. Anything
else is SIMPLY NOT ACCEPTABLE!
So the whole idea that you should have used 64-bit values was broken,
broken, broken. You should never have had anything that cared, because
anything that cares is by definition buggy.
This is why we should use the _low_ bits. Never the high bits.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-18 15:31 UTC (permalink / raw)
To: Robert Collins; +Cc: Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <1161147348.3423.24.camel@localhost.localdomain>
On Wed, 18 Oct 2006, Robert Collins wrote:
>
> More commonly though, like git users have 'origin' and 'master'
> branches, bzr users tend to have a branch that is the 'origin' (for bzr
> itself this is usually called bzr.dev), as well as N other branches for
> their own work, which is probably why we haven't seen the need to have a
> ui command to spit out the revnos for an arbitrary branch.
You mis-understand.
git doesn't have a "ui command to spit out the revnos for an arbitrary
branch" either.
Normally, you'd just use the branch-name. Nobody ever uses the SHA1's
directly.
What git does (and does very well) is to be _scriptable_. It was designed
that way. I'm a UNIX guy. I think piping is very powerful. And when you
script things, your scripts pass SHA1's around internally.
So for example, to repack a git archive, you'd normally do
git repack -a -d
and you don't have any "UI" with SHA1 numbers. But internally, this used
to be
git-rev-list --all --objects |
git-pack-objects
where "git-rev-list" is the one that lists all object names (which are the
SHA1 numbers), and "git-pack-objects" is the one that takes a list of
objects and packs them.
(These days, since our internal C libraries have become so much better,
the object traversal is done internally to packing, so we don't actually
use the pipe any more for repacking an archive, but that's just an
implementation detail)
You seem to think that we use SHA1 names as _humans_. We don't. The SHA1
names are used internally, and humans just use the branch names.
The only case you'd (as a human) use the SHA1 name is when you want to
pass it on to another person that may have a different archive (ie you
mail somebody a revision that is problematic). It would obviously be
totally unworkable to say "it's the grand-parent of my current HEAD
commit", since that's a local description. So instead, you'd say "it's
commit 9550e59c4587f637d9aa34689e32eea460e6f50c".
So I think people (totally incorrectly) think that git users use a lot of
SHA1 names, just because they see the git users on the kernel mailing list
sending each others SHA1 names. But that's because you see only the case
where you _want_ to communicate a stable revision name to another side.
Sending a number like 1.57.8.312 to describe what commit broke would be a
_bug_, because a person who has a differently shaped tree wouldn't even
_have_ that revision.
But normally? You'd be hard-pressed to find anything but the branch (and
tag) names on a command line.
See?
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-18 15:38 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45359B2A.1070102@utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 3786 bytes --]
On Tue, 17 Oct 2006 23:10:34 -0400, Aaron Bentley wrote:
> If B merges A before this, nothing happens, because B is already a
> superset of A.
>
> If B merges afterward, we get this:
Wow. Thanks for elucidating---again I was making some incorrect
assumptions about the system, so your answer was surprising and
appreciated.
So, am I correct in my understanding now that it's impossible for two
users to establish identical code history on both sides through merge?
If the two kept merging back and forth the history would pick up a new
commit each time even though there were no code changes. Right?
That's a startling property. I'm surprised to learn that the
generally-used mechanism for getting new changes doesn't have a mode
where it says "you're already up to date---doing nothing".
I do understand that there's a separate "pull" that does allow for
correct synchronization of a local repository with a remote
repository, and it does have the "up to date---doing nothing"
behavior. But as you already said, it's often avoided specifically
because it destroys locally-created revision numbers.
Another way of describing bzr's "pull" is that it establishes a
master-slave relationship between the remote and local repository,
(his numbers are more important than mine, so I'll throw mine away).
I think Linus already provided a good argument in this thread about
why that kind of asymmetry is bad for software projects and why tools
should not provide it.
So there are some aspects of the bzr design that rob from its ability
to function as a distributed version control system. It really does
bias itself toward centralization, (the so called "star topoloogy" as
opposed to something "fully" distributed).
And by the way, some people seem to have the opinion that there's
something unique about the way the linux kernel is developed that
allows is to benefit from a fully distributed system. The assumption
seems to be that projects with a central tree won't benefit the same
way, and don't really need the full set of features of a distributed
system. That's not true in my experience.
With cairo, for example, we had been using cvs. Obviously, it imposes
a centralized model, but most of the active developers had been using
rsync or other repository synchronization so that we could at least do
offline history browsing. So even with cvs we had as much of a star
topology as possible, (but we didn't have offline commits to our
roaming repositories, nor did we have any sharing between them).
Now, after the switch from cvs to git, we still do have a central
repository that all developers share and push into, (this is distinct
from how linux or the git project itself use git). And git supports
this kind of shared central repository perfectly well.
But a lot of the big advantages the cairo project gets from git come
from our ability to now easily share branches among ourselves without
going through the central repository. We only push fully-cooked
branches to the central tree. But now, with everyone owning their own
publicly-visible repository with all their work in it, we can now
easily share the half-baked ideas we have with all their history. One
person can start an idea, and others can easily pick it up, (without
having to drop down to a mega-patch like we would have done with
cvs). And people actually have the ability to collaborate on turning
an answer into a solution, (in Al Viro's terminology).
So even a project that's very oriented around a single, central tree
can get a lot of benefit from being able to share things arbitrarily
between any two given repositories. And I think that any project will
naturally start doing more of this kind of sharing, (and benefitting
considerably from it), as it adopts tools that support it well.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 15:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robert Collins, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610180820210.3962@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 18 Oct 2006, Robert Collins wrote:
>>
>> More commonly though, like git users have 'origin' and 'master'
>> branches, bzr users tend to have a branch that is the 'origin' (for bzr
>> itself this is usually called bzr.dev), as well as N other branches for
>> their own work, which is probably why we haven't seen the need to have a
>> ui command to spit out the revnos for an arbitrary branch.
>
> You mis-understand.
>
> git doesn't have a "ui command to spit out the revnos for an arbitrary
> branch" either.
>
> Normally, you'd just use the branch-name. Nobody ever uses the SHA1's
> directly.
With the exception of having sometimes commit-ids in the commit messages,
for example "Fixes bug introduced by aabbcc00" (although usually you just
write "Fixes bug in some_function in some_file"), and automatically
generated
This reverts d119e3de13ea1493107bd57381d0ce9c9dd90976 commit.
(in addition to 'Revert "<Commit title>") for git-revert generated
commit messages.
And it is true that you usually use branchname, or branchname~n syntax.
Git even has git-name-rev to convert from sha1 to temporary, local
ref^m~n... syntax.
By the way, git has very powerfull syntax to get revisions, and
revision lists. For example "git-rev-list foo bar ^baz" means
"list all the commits which are included in foo and bar lineage,
but not in baz", or more useful "git log origin..next".
How's that in bzr?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Linus Torvalds @ 2006-10-18 15:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eh4sfr$3ej$1@sea.gmane.org>
On Wed, 18 Oct 2006, Jakub Narebski wrote:
>
> Doesn't xdiff library git uses have diff3/merge equivalent?
Nope. It has something it calls "merge", but it's really just "apply the
diff from the common base to the other end".
IOW, if "a" is your common ancestor, and "b1" and "b2" are the branches,
it's literally
diff a b1 | patch b2
and not actually a real 3-way merge.
As to why git uses "merge" - I have this strong memory of having seen
machines that had one but not the other, and that, along with the fact
that I've used "merge" personally, is why we call "merge" rather than
diff3.
In Linux systems, "merge" usually comes with the RCS package, and "diff3"
is usually from "diffutils". It may be that "diff3" is more common. I'm
not sure what the history is, and what the situation would tend to be like
on other systems..
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-18 16:07 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: bazaar-ng, Andreas Ericsson, Carl Worth, git, Jakub Narebski
In-Reply-To: <20061018124320.GT75501@over-yonder.net>
On Wed, 18 Oct 2006, Matthew D. Fuller wrote:
> On Wed, Oct 18, 2006 at 01:19:10PM +0200 I heard the voice of
> Andreas Ericsson, and lo! it spake thus:
> >
> > It's just that we have this one place where gitweb is installed,
> > which management likes whereas devs don't have that on their laptop.
> > It's also convenient to have one place to find all changes rather
> > than pulling from 1-to-N different people just to have a look at
> > what they've done.
>
> I think this just by itself lends support to:
>
> > The point I'm trying to make here is that the star config might be
> > the most common case today because
>
> c) Stars work well as a mental model for humans.
I really don't think that's even true.
Most projects do tend to have a star-like setup, but I think that's
largely due to historical tools, not mental models.
For example, I used CVS professionally for too long a few years ago, and
the thing I _really_ hated was exactly how it forced people who were
working on "experimental stuff" to be so tightly organized around the
central repository (and how they had to do things that were visible and
annoying to the mainline).
And I think that's where the "star-like" situation breaks down: when you
have a group of people who go off to do something experimental. Suddenly
the "mainline" in that case isn't the central and most important
repository any more, and instead you really have another second (and
third, fourth etc) "centerpoint" that another group works around.
Now, what does that mean? It means that whenever you look at a big project
from the outside, you tend to see a star-like thing: there's the "big
common thing", and you won't even be _seeing_ the off-shoots, because they
tend to be used by developers to try out new ideas etc. So it looks like a
star, but it really isn't, and shouldn't be.
An SCM should support the _developers_, not the users. The users don't
need an SCM, they just need a place to fetch the "standard" thing
(preferably with a vendor that supports them or at least makes them feel
comfy). But an SCM really should support the off-shoots, because that's
where the exciting stuff happens.
Btw, this is also why distribution is so fundamentally important:
Most of the off-shoots tend to be failures, but that is as it should be.
Again, this is where SVN and CVS and other centralized models fail
_miserably_. Because branches are in a centralized repository, the cost of
failure is visible to all, and thus people don't like creating branches
for things that don't look "obviously viable" to the people around the
central repository.
In contrast, in a truly distributed environmen, a failed branch is
something that people don't even KNOW about. Anybody can take the kernel
git tree, start his own development line (with ten other people) and try
to improve it. And if it fails, I'd never even know: there is literally
_zero_ cost to everybody else from failed branches. And if they succeed,
they'll just say "hey, pull this, it works, and it makes Xyz go five times
faster".
Linus
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Davide Libenzi @ 2006-10-18 16:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610180752500.3962@g5.osdl.org>
On Wed, 18 Oct 2006, Linus Torvalds wrote:
> On Tue, 17 Oct 2006, Davide Libenzi wrote:
> >
> > Ehm, I think there's a little bit of confusion. The incorrect golden ratio
> > prime selection for 64 bits machines was coalescing hash indexes into a
> > very limited number of buckets, hence creating very bad performance on diff
> > operations. The result of the diff would have been exacly the same, just
> > coming out after the time for a cup of coffee and a croissant ;)
>
> But my point is, you would have been better off _without_ an algorithm
> that cared about the word-size at all, or with just using "uint32_t".
Yes. At the time I picked Knuth's hash function because it was simple and
fast enough. But it needed special handling for different word sizes,
exactly like kernel's hash_long() does.
> A diff algorithm that gives different answers on a 32-bit LE architecture
> than on a 64-bit BE architecture is BROKEN. If I run on x86-64, I want the
> same answers I got on x86-32, and the same ones I get on ppc32. Anything
> else is SIMPLY NOT ACCEPTABLE!
Speaking in general, seen at the hash function level, of course an interface
should not give different result for different word sizes or word endianess.
Considering the diff algorithm as interface, as I said, the output was
unaffected by the 64 bits word size. It was just very slow.
- Davide
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-18 16:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git, Robert Collins
In-Reply-To: <200610181750.32888.jnareb@gmail.com>
On Wed, 18 Oct 2006, Jakub Narebski wrote:
> >
> > Normally, you'd just use the branch-name. Nobody ever uses the SHA1's
> > directly.
>
> With the exception of having sometimes commit-ids in the commit messages,
> for example "Fixes bug introduced by aabbcc00" (although usually you just
> write "Fixes bug in some_function in some_file"), and automatically
> generated
> This reverts d119e3de13ea1493107bd57381d0ce9c9dd90976 commit.
Yes. But in both cases, that's usually because you literally ended up
having the commit name because somebody else (which _can_ be you) searched
for it (with something like "bisect") and gave it to you.
So even that case is really about communicating a stable name from one
place (the "find the bug") to another (the "revert the buggy commit").
So yes, _communication_ should always happen by full SHA1's, because those
are the only thing that always remain stable.
(The fact that "gitk" and I think "gitweb" can then turn them into
hyperlinks in the commit message is obviously one reason we then tend to
give them such prominent visibility - they actually end up being very
useful later on).
In bzr, either you don't get the hyperlinks, or you need to use the
non-simple name in the commit messages, since the simple names don't
actually work. Either way, it's an inferior setup.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 16:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: Carl Worth, Petr Baudis, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git, Matthieu Moy
In-Reply-To: <200610181120.49749.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>
>>Carl Worth wrote:
>>>There are even more important reasons to prefer a series of
>>>micro-commits over a mega-patch than just ease of merging.
>>
>>A bundle isn't a mega-patch. It contains all the source revisions. So
>>when you merge or pull it, you get all the original revisions in your
>>repository.
>
>
> But what patch reviewer see is a mega-patch showing the changeset
> of a whole "bundle", isn't it?
> [...]
Yes. Carl was saying that, aside from the issue of what a reviewer
sees, a bundle is bad for other reasons. I am saying those other
reasons don't apply. I wasn't addressing the issue of what a reviewer sees.
To me, seeing the individual patches is like reading a book where every
page has a different word on it, and so it's hard to put it together
into a full sentence. I'm not saying my way is The Right Way, just my
personal preference.
For larger pieces of work, we try to split them up into logical units,
and merge those units independently.
The Bundle format can also support a patch-by-patch output, but we don't
have UI to select that.
> I think it is much better to review series of patches commit by commit;
> besides it allows to correct some inner patches before applying the whole
> series or drop one of patches in series (and it happened from time to time
> on git mailing list).
It's important to remember that bundles represent revisions, not
patches. When you merge a bundle, you
1. install those revisions into your repository. These revisions are
latent, as though they were on another branch.
2. merge the head revision of the bundle into your branch.
Virtually any merge selection process that works with branches would
also work with bundles. So tweaking before merging is really a matter
of replacing the UI for 2.
> So if git introduces bundles, I think they would take form of series
> of "patch" mails + introductory email with series description (currently
> it is not saved anywhere), shortlog, diffstat and perhaps more metainfo
> like bundle parent (which I think should be email form of branch really),
> tags introduced etc.
The parent in a bundle revision is the revision-id of the parent of that
revision in the branch. I don't think it's possible to change that
parent id into something else, without changing the meaning of a bundle.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNlb40F+nu1YWqI0RAnxxAJ9ETibey1Qyvz/zVxdGipaHGtnddgCfTtzt
CQUZ2dK64BS5K5WYecFAsfM=
=bJxq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [BUG] git-log shows first parent and repeated last for octopus merge
From: A Large Angry SCM @ 2006-10-18 16:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eh5242$rar$1@sea.gmane.org>
Jakub Narebski wrote:
> When trying to find how many merges and how many octopus merges (merges with
> more than two parents) are in git.git repository I have encountered the
> following strange output of git-log:
Maybe the following will find what you're looking for:
git-rev-list master --parents \
|sed -e 's/[0-9a-f]\{40\}//' -e 's/ [0-9a-f]\{40\}/*/g' \
|sort \
|uniq -c
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-18 16:52 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610180845040.18388@alien.or.mcafeemobile.com>
On Wed, 18 Oct 2006, Davide Libenzi wrote:
>
> Speaking in general, seen at the hash function level, of course an interface
> should not give different result for different word sizes or word endianess.
> Considering the diff algorithm as interface, as I said, the output was
> unaffected by the 64 bits word size. It was just very slow.
Well, even the output may actually be affected, in the case of _real_ hash
collisions (as opposed to just the hash _list_ collision that XDL_HASHLONG
caused).
So I actually think it would be better to have "uint32_t" as the hash
value - because that would mean that all diffs (or, in the case of the
block-algorithm, the deltas) are guaranteed to give the same results
regardless of architecture.
Right now, we actually generate a 64-bit hash value (BUT: for short lines,
it's likely only _interesting_ in the low bits, so the high bits tend to
have a very high likelihood of being zero). So hash collisions are
different: on a 32-bit architecture, two lines may have the same hash,
while on a 64-bit one, they are different.
And together with some of the limiters we have (eg XDL_MAX_EQLIMIT) hash
collisions can sometimes affect the output.
Admittedly, in _practice_ this is really unlikely to affect anything
(you'd get a valid diff in either case, they'd just possibly be subtly
different, and the input data must be _really_ strange to even see that
case), but I do think that the hash algorithm can matter.
NOTE! I'm not talking about XDL_HASHLONG(), I'm talking about the
xdl_hash_record() hash, which returns differently-sized hash results on
32-bit and 64-bit. And there are cases where we _only_ compare the hashes,
and don't actually double-check the contents.
So I think that in _practice_ you can't see differences between a 32-bit
version and a 64-bit one, but the possibility is there. Using "uint32_t"
instead of "unsigned long" to keep track of hashes would avoid that
theoretical problem (and might actually make for better performance on
64-bit archtiectures, if only because of denser data structures and thus
better cache behaviour).
Linus
^ permalink raw reply
* Re: [RFH] git-svn documentation
From: Seth Falcon @ 2006-10-18 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <20061016183101.GL27128@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Anybody willing to supply patches for better documentation? I'll be
> quite busy with other projects the next two weeks, asciidoc is quite
> slow for me; but I'd like to have better docs for git-svn in 1.4.3.
I'm starting to use git-svn more and would be willing to attempt to
contribute some additional docs. What I have in mind is a howto use
git-svn sort of document (unless that isn't seen as useful)
... unfortunately, as I use git-svn more I'm encountering some
questions which will need resolution before I can have much confidence
in my howto :-\
Will post some howto and questions separately.
+ seth
^ 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