* Re: Make the ftplugin right wrt gitdir
From: Pierre Habouzit @ 2006-10-18 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061018070239.GD3507@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Le mer 18 octobre 2006 09:02, Jeff King a écrit :
> On Wed, Oct 18, 2006 at 02:47:25AM +0200, Pierre Habouzit wrote:
> > sorry for the mess, I'm a bit tired :)
> > Here is a third patch to fix the plugin to find the git-dir
> > properly.
> >
> > Also add a nice shortcut to quit that buffer.
>
> Looks like the patch is missing (more sleep required?).
err, the patch is here:
<1161132446703-git-send-email-madcoder@debian.org>
at least I see it on the list for my part
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-18 7:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpqlknem8bi.fsf@ecrins.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > The origin branch is considered readonly (though Git does
> > not enforce it) and only mirrors the branch in the remote repository.
>
> By curiosity, what happens if you accidentally commit to it?
It will quietly accept the commit.
Later when you attempt to run `git fetch` to download any changes
from the remote repository to your local origin branch the fetch
command will fail as it won't be a strict fast-forward due to
there being changes in origin which aren't in the remote repository
being downloaded.
The user can force those changes to be thrown away with `git fetch
--force`, though they probably would want to first examine the
branch with `git log origin` to see what commits (if any) should
be saved, and either extract them to patches for reapplication or
create a holder branch via `git branch holder origin` to allow them
to later merge the holder branch (or parts thereof) after the fetch
has forced origin to match the remote repository.
So in short by default Git stops and tells the user something fishy
is going on, but the error message isn't obvious about what that
is and how they can resolve it easily.
There has been discussion about marking these branches that we
know the user fetches into as read-only, to prevent `git commit`
from actually committing to such a branch (we also have the same
case with the special bisect branch), but I don't think anyone has
stepped forward with the complete implementation of that yet.
Like anything I think people get used to the idea that those branches
are strictly for fetching and shouldn't be used for anything else.
There's really no reason to checkout a fetched into branch anyway;
temporary branches are less than 1 second away with
`git checkout -b tmp origin` (for example).
--
Shawn.
^ permalink raw reply
* Re: Make the ftplugin right wrt gitdir
From: Jeff King @ 2006-10-18 7:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11611324463754-git-send-email-madcoder@debian.org>
On Wed, Oct 18, 2006 at 02:47:25AM +0200, Pierre Habouzit wrote:
> sorry for the mess, I'm a bit tired :)
> Here is a third patch to fix the plugin to find the git-dir properly.
>
> Also add a nice shortcut to quit that buffer.
Looks like the patch is missing (more sleep required?).
-Peff
^ permalink raw reply
* Re: [PATCH] be more vim-ish, and also syntax hilight Signed-off-by lines.
From: Jeff King @ 2006-10-18 6:59 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11611319762395-git-send-email-madcoder@debian.org>
On Wed, Oct 18, 2006 at 02:39:35AM +0200, Pierre Habouzit wrote:
> +if exists("b:current_syntax")
> + finish
> +endif
I think this is a good change (along with commenting), but please write
a more descriptive commit message than "be more vim-ish" (I wouldn't
mind seeing this and the highlighting change broken into two patches,
since they are functionally completely unrelated).
> +syn region gitSignedOff start=/^Signed-off-by:/ end=/$/ contains=gitAuthor,gitEmail
> +syn region gitAuthor contained start=/\s/ end=/$/
You mention gitEmail but never define it. Are people using other things
besides Signed-off-by? I think we might do better to simply write:
syn region gitCommentHeader start=/^[^ ]\+:/ end=/$/ contains=gitCommentValue
syn region gitCommentValue contained start=/\s/ end=/$/
Highlighting only the header is inconsistent with other highlighting
(e.g., all of "new file: foo" is highlighted), but it looks so ugly to
highlight the whole line, so I think this is fine.
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-18 6:44 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <20061018011147.GN20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> The origin branch is considered readonly (though Git does
> not enforce it) and only mirrors the branch in the remote repository.
By curiosity, what happens if you accidentally commit to it?
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-18 6:33 UTC (permalink / raw)
To: Sean; +Cc: Aaron Bentley, Johannes Schindelin, Jakub Narebski, bazaar-ng,
git
In-Reply-To: <20061017062341.8a5c8530.seanlkml@sympatico.ca>
On Tue, Oct 17, 2006 at 06:23:41AM -0400, Sean wrote:
> The "bzr missing" command sounds like a handy one.
>
> Someone on the xorg mailing list was recently lamenting that git does not
> have an easy way to compare a local branch to a remote one. While this
> turns out to not be a big problem in git, it might be nice to have such
> a command.
What's wrong with:
git-fetch
gitk master...origin
The git model is to do operations on local refs and objects, so the
fetch is a natural part of that. The only downside I see is that you
actually end up fetching the data rather than simply peeking at where
the remote is. But a useful comparison will include at least grabbing
the commit objects, and probably the tree objects (to do diffs) anyway.
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-18 6:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610172351.17377.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>>> Fast-forward is a really good idea. Perhaps you could implement it,
>>> if it is not hidden under different name?
>>
>> We support it as 'pull', but merge doesn't do it automatically, because
>> we'd rather have merge behave the same all the time, and because 'pull'
>> throws away your local commit ordering.
>
> I smell yet another terminology conflict (although this time fault is
> on the git side), namely that in git terminology "pull" is "fetch"
> (i.e. getting changes done in remote repository since laste "fetch"
> or since "clone") followed by merge. pull = fetch + merge.
AAUI, the initial claim was that after a rebase, git can do a
fast-forward, but Aaron has missed the /after a rebase/ part.
And yes, it the bzr terminology, bzr can do a "pull" after a "graft".
I don't think there's a fundamental difference here.
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Davide Libenzi @ 2006-10-18 6:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171959180.3962@g5.osdl.org>
On Tue, 17 Oct 2006, Linus Torvalds wrote:
> > Does this mean that, with your own change to xdiff that has just been
> > committed, you actually created a "problem"? Because this is a change
> > that creates different behaviors whether a 32-bit or 64-bit architecture
> > is used, Right?
>
> If you go back to that discussion, I actually pointed out several times
> that the whole bug _was_ actually introduced exactly because the xdiff
> code used things that behave differently depending on word-size.
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 ;)
> So the bug in xdiff was _exactly_ that somebody - totally incorrectly -
> thought it should work "better" on 64-bits.
Haha, not exactly. I had just forgot about the incoming 64 bits world at
the time.
- Davide
^ permalink raw reply
* Re: [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Junio C Hamano @ 2006-10-18 6:04 UTC (permalink / raw)
To: Markus Amsler; +Cc: git, Mike McCormack
In-Reply-To: <452EBF77.7040301@oribi.org>
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?
---
imap-send.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 362e474..16804ab 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1226,6 +1226,14 @@ split_msg( msg_data_t *all_msgs, msg_dat
if (msg->len < 5 || strncmp( data, "From ", 5 ))
return 0;
+ p = strchr( data, '\n' );
+ if (p) {
+ p = &p[1];
+ msg->len -= p-data;
+ *ofs += p-data;
+ data = p;
+ }
+
p = strstr( data, "\nFrom " );
if (p)
msg->len = &p[1] - data;
^ permalink raw reply related
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-18 5:57 UTC (permalink / raw)
To: Jeff King
Cc: Jakub Narebski, Aaron Bentley, Andreas Ericsson, bazaar-ng, git,
Linus Torvalds
In-Reply-To: <20061018053647.GA3507@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We could always make a guess ("git send --remote-has master~10") but
> that seems awfully error-prone. I assume a changeset-oriented system
> would implicitly keep some concept of "I think Linus is at master~10"
> and do it automatically.
We could always anchor at a well known point ("git send v2.6.18..").
If you as the recipient do not have the preimage, the "bundle" would
identify what the assumed common ancestor is and you can fetch
it before proceeding.
^ permalink raw reply
* Re: VCS comparison table
From: Robert Collins @ 2006-10-18 5:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: bazaar-ng, git
In-Reply-To: <20061017233305.GG20017@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
On Wed, 2006-10-18 at 01:33 +0200, Petr Baudis wrote:
>
> BTW, I think it's fine to build a system optimized for small-scale
> projects (if that's the intent), simplifying some things in favour of
> mostly straight histories instead of more complicated merge situations
> (although I tend to agree with Linus that if you don't behave in the
> way the users are used to in 100% cases, the more frequently you
> behave so the worse it comes back to bite in the rare cases you do).
> Just as RCS is fine when maintaining individual files for personal
> usage (I still actually occassionaly use it for few files).
revnos visibly change as your work is merged into the mainline - we've
been doing this for years without trouble: ones own commits to a branch
get '3', '4', '5' etc as revnos, and when they are merged to the
mainline they used to stop having revnos at all, but now they will be
given this dotted decimal revno. If you pull from the mainline after the
merge, you see the new numbers, and when you look at mainline you can
see the difference. So while I agree that the surprise the user gets is
inversely related to the frequency with which they see the behaviour, I
think our users see it a lot, so are not surprised much.
FWIW, we're not optimising for mostly straight histories as I understand
such things : our own history has 3 commits on branches to every one on
the mainline.
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-18 5:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jakub Narebski, Aaron Bentley, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610171610270.3962@g5.osdl.org>
On Tue, Oct 17, 2006 at 04:16:15PM -0700, Linus Torvalds wrote:
> It would be easy to send the exact same data as the native git protocol
> sends over ssh (or the git port) as an email encoding. We did that a few
> times with BK (there it's called "bk send" and "bk receive" to pack and
[...]
> That said, "bundles" certainly wouldn't be _hard_ to do. And as long as
> nobody tries to send _me_ any of them, I won't mind ;)
I never used BK, but my understanding is that it was based on
changesets, so a bundle was a group of changesets. Because a git commit
represents the entire tree state, how can we avoid sending the entire
tree in each bundle? The interactive protocols can ask "what do you
have?" but an email bundle is presumably meant to work without a round
trip.
We could always make a guess ("git send --remote-has master~10") but
that seems awfully error-prone. I assume a changeset-oriented system
would implicitly keep some concept of "I think Linus is at master~10"
and do it automatically.
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Robert Collins @ 2006-10-18 4:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <4534AB8B.8030505@op5.se>
[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]
On Tue, 2006-10-17 at 12:08 +0200, Andreas Ericsson wrote:
> Robert Collins wrote:
> > On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:
> >> ---- time --->
> >>
> >> --*--*--*--*--*--*--*--*--*-- <branch>
> >> \ /
> >> \-*--X--*--/
> >>
> >> The branch it used to be on is gone...
> >
> > In bzr 0.12 this is :
> > 2.1.2
> >
>
> Would it be a different number in a different version of bazaar?
The dotted decimal display has only been introduced in bzr 0.12
> > (assuming the first * is numbered '1'.)
> >
> > These numbers are fairly stable, in particular everything's number in
> > the mainline will be the same number in all the branches created from it
> > at that point in time, but a branch that initially creates a revision or
> > obtains it before the mainline will have a different number until they
> > syncronise with the mainline via pull.
> >
>
> So basically anyone can pull/push from/to each other but only so long as
> they decide upon a common master that handles synchronizing of the
> number part of the url+number revision short-hands?
Anyone can push and pull from each other - full stop. Whenever they
'pull' in bzr terms, they get fast-forward happening (if I understand
the git fast-forward behaviour correctly). After a fast-forward, the
dotted decimal revision numbers in the two branches are identical - and
they remain immutable until another fast forward occurs. Push always
fast forwards, so the public copy of ones own repository that others
pull or merge from is identical to your own. In a 'collection of
branches with no mainline' scenario, people usually have fast forward
occur from time to time, keeping the numbers consistent from the point
your branch was last pulled by someone else, or you pulled them.
> One thing that's been nagging me is how you actually find out the
> url+number where the desired revision exists. That is, after you've
> synced with master, or merged the mothership's master-branch into one of
> your experimental branches where you've done some work that went before
> mothership's master's current tip, do you have to have access to the
> mothership's repo (as in, do you have to be online) to find out the
> number part of url+number shorthand, or can you determine it solely from
> what you have on your laptop?
You can determine it locally - if you know any of the motherships
revisions locally, we can generate the dotted-revnos that the
motherships master-branch would have from the local data - and the last
merge of mothership you did will have given you that details. I dont
think we have a ui command to spit this out just yet, but it will be
trivial to whip one up.
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.
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-18 5:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds
In-Reply-To: <7v64eii7hh.fsf@assigned-by-dhcp.cox.net>
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>
---
index-pack.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index fffddd2..56c590e 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -23,6 +23,12 @@ union delta_base {
unsigned long offset;
};
+/*
+ * 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
+
struct delta_entry
{
struct object_entry *obj;
@@ -211,7 +217,7 @@ static int find_delta(const union delta_
struct delta_entry *delta = &deltas[next];
int cmp;
- cmp = memcmp(base, &delta->base, sizeof(*base));
+ cmp = memcmp(base, &delta->base, UNION_BASE_SZ);
if (!cmp)
return next;
if (cmp < 0) {
@@ -232,9 +238,9 @@ static int find_delta_childs(const union
if (first < 0)
return -1;
- while (first > 0 && !memcmp(&deltas[first - 1].base, base, sizeof(*base)))
+ while (first > 0 && !memcmp(&deltas[first - 1].base, base, UNION_BASE_SZ))
--first;
- while (last < end && !memcmp(&deltas[last + 1].base, base, sizeof(*base)))
+ while (last < end && !memcmp(&deltas[last + 1].base, base, UNION_BASE_SZ))
++last;
*first_index = first;
*last_index = last;
@@ -312,7 +318,7 @@ static int compare_delta_entry(const voi
{
const struct delta_entry *delta_a = a;
const struct delta_entry *delta_b = b;
- return memcmp(&delta_a->base, &delta_b->base, sizeof(union delta_base));
+ return memcmp(&delta_a->base, &delta_b->base, UNION_BASE_SZ);
}
static void parse_pack_objects(void)
--
1.4.2.4.gf9fe
^ permalink raw reply related
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-18 4:16 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610172209070.1971@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> but if somebody did so then it would mean a disaster to have an
>> accidental collision of an 8-byte offset value plus 12-byte traiing
>> NUL and another base object whose object name happens to match that
>> pattern.
>
> Not really. The only effect that would have on the sorted list of
> delta entries -- such sorting used to bring all deltas with the same
> base object contigously -- is that those deltas might not be perfectly
> contigous wrt their base object. This is why there is a test to skip
> deltas if they happen not to be of the expected type.
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).
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-18 3:35 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45357CC3.4040507@utoronto.ca>
On Tue, 17 Oct 2006, Aaron Bentley wrote:
>
> > That doesn't matter...
>
> It has significant UI impact.
Right. You have to do it your way, because of the "simple revision
numbers".
Which gets us back to where we started: "simple" is in the eye of the
beholder. I personally think that git revision naming is a lot simpler,
exactly because it doesn't impose arbitrary rules on users.
For example, what happens is that:
- you like the simple revision numbers
- that in turn means that you can never allow a mainline-merge to be done
by anybody else than the main maintainer
- that in turn means that the whole situation is no longer distributed,
it's more like a "disconnected access to a central repository"
The "main trunk matters" mentality (which has deep roots in CVS - don't
get me wrong, I don't think you're the first one to do this) is
fundamentally antithetical to truly distributed system, because it
basically assumes that some maintainer is "more important" than others.
That special maintainer is the maintainer whose merge-trunk is followed,
and whose revision numbers don't change when they are merged back.
That may even be _true_ in many cases. But please do realize that it's a
real issue, and that it has real impact - it does two things:
- it impacts the technology and workflow directly itself: "pull" and
"merge" are different: a central maintainer would tend to do a "merge",
and one more in the outskirts would tend to do more of a "pull",
expecting his work to then be merged back to the "trunk" at some later
point)
- it will result in _psychological_ damage, in the sense that there's
always one group that is the "trunk" group, and while you can pass the
baton around (like the perl people do), it's always clear who sits
centrally.
Maybe this is fine. It's certainly how most projects tend to work.
I'll just point out that one of my design goals for git was to make every
single repository 100% equal. That means that there MUST NOT be a "trunk",
or a special line of development. There is no "vendor branch". It's
something that a lot of people on the git lists understand now, but it
took a while for it to sink in - people used to believe that the "first
parent" of a merge was somehow special, and I had to point out several
times on the git list that no, that's not how it works - because the merge
might have been done by somebody _else_ than the person who you think of
as being "on the trunk".
So when I say that your "simple" revision numbers are totally broken and
horrible, I say that not because I think a number like "1.45.3.17" is
ugly, but because I think that the deeper _implications_ of using a number
like that is ugly. It implies one of two things:
- the numbers change all the time as things get merged both ways
OR
- people try to maintain a "trunk" mentality
and I think both of those situations are simply not good situations.
In git, the fact that everybody is on an equal footing is something that I
think is really good. For example, when I was away for effectively three
weeks during August, all the git-level merging for the kernel was done by
Greg KH.
And realize that he didn't use "my tree". No baton was passed. I emailed
with him (and some others) before-hand, so that everybody knew that I
expected to be just pull from Greg when I came back, but it was _his_ tree
that he merged in, and he just worked the same way I did.
And when I did come back, I did a "pull" from his tree. At no point is
there a big merge-commit with a sign saying
"I now merged all the work that Greg did while I was away"
No. Because the way git works, my pull just fast-forwarded my tree,
because while I was away, Greg's tree _was_ the main tree, thanks to the
fact that git believes that everybody is 100% equal.
So it's actually a big conceptual thing.
I'm actually very happy with the design of git, and a large part of that
is that I think the data structures and the basic design was really good.
Now, I know I'm smarter than anybody else ("Bow down before me, you
worthless scum"), but the thing is, the way to do good basic design isn't
actually to be really smart about it, but to try to have a few basic
concepts.
And the "every repository is equal" is one such concept. The naming
follows from that - you simply _cannot_ use numbers if everybody is on the
same footing (at least not _stable_ numbers).
Btw, BK did get this right. I didn't _like_ the naming in BK, and it was
numbers, but it worked. But it only worked when people understood that the
numbers were ephemeral, and it _did_ cause confusion. But hey, the
confusion wasn't _that_ big of a problem.
> Even if I agreed that the revision was meaningless, the cost of such a
> revision is miniscule.
No. The _cost_ of the revision is the "trunk mentality". THAT is the true
cost. The belief that there is one "main line of development".
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 3:27 UTC (permalink / raw)
To: Carl Worth
Cc: Jakub Narebski, Petr Baudis, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git, Matthieu Moy
In-Reply-To: <87zmbucs86.wl%cworth@cworth.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Worth wrote:
> On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:
>> Isn't it easier to review than "bundle", aka. mega-patch?
>
> 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.
> We have great tools like bisect to identify commits that introduce
> bugs. I know that I'd be delighted to see bisect comes back pointing
> at some minimal commit as causing a bug, (which would make finding the
> bug so much easier).
Bisect should work equally well with revisions pulled or merged from a
bundle as revisions re-committed from patches.
> But it's also been my experience that the largest commits are also the
> most likely to be the things returned by bisect. Big commits really do
> introduce bugs more frequently than small commits.
The number of changes shown in the diff has nothing to do with the
number of changes made per commit.
> Now, I do admit that it is often useful to take the overall view of a
> patch series being submitted. This is often the case when a patch
> series is in some sub-module of the code for which I don't have as
> much direct involvement. In cases like that I will often do review
> only of the diff between the tips of the mainline and the branch of
> interest, (or if I trust the maintainer enough, perhaps just the
> diffstat between the two). But I'm still very glad that what lands in
> the history is the series of independent changes, and not one mega
> commit.
So the difference here is that bundles preserve the original commits the
changes came from, so even though it's presented as an overview, you
still have a series of independent changes in your history.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNZ820F+nu1YWqI0RAjNyAJ90HMCAiopuAMvkKlcCEdc4F6QKLwCdGEWI
VOZThAQrvqybe5z93eC44BY=
=xBZM
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Ryan Anderson @ 2006-10-18 3:25 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45357411.20500@utoronto.ca>
On 10/17/06, Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> > In other words, the empty merge is totally semantically empty even in the
> > bazaar world. Why does it exist?
>
> It exists because it is useful. Because it makes the behavior of bzr
> merge uniform. Because in some workflows, commits show that a person
> has signed off on a change.
In the Git world that happens via "git tag -s", i.e, a
cryptographically strong "signoff".
(There's also the secondary convention of appending Signed-off-by: to
email-applied patches, but that's something that would translate
effectively to any other system, since it's outside the SCM.)
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-18 3:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610172140270.1971@xanadu.home>
On Tue, 17 Oct 2006, Nicolas Pitre wrote:
>
> But there _is_ a flag for damn sake. Did you at least try to understand
> the code and not just skim over it from 10000 feet above?
I only looked at it from the patches, and the actual data structure,
and they didn't have it, so..
> There is _no_ confusion possible.
Ok. Good.
> Does this mean that, with your own change to xdiff that has just been
> committed, you actually created a "problem"? Because this is a change
> that creates different behaviors whether a 32-bit or 64-bit architecture
> is used, Right?
If you go back to that discussion, I actually pointed out several times
that the whole bug _was_ actually introduced exactly because the xdiff
code used things that behave differently depending on word-size.
My suggestion for a _proper_ fix was to not use "unsigned long" for that,
and the patch I suggested (and eventually got merged) was to use the _low_
bits of the hash, exactly because the low bits are the ones that act the
same, regardless of wordsize.
> But of course not. We want it to behave differently on 64-bit than
> 32-bit.
No, we actually don't. Not for xdiff, at least. The last thing you want is
for different architectures to get different results. It's horrible. It
means that bugs are hard to reproduce, and it means that even code that is
"tested" is actually tested only for a particular architecture.
So the bug in xdiff was _exactly_ that somebody - totally incorrectly -
thought it should work "better" on 64-bits.
> Please just try to understand why I'm claming this is not important in
> this very case. Please do me this favor.
Maybe the code is fine. Maybe the particular detail wasn't important. But
the original code didn't have _any_ dependencies on things like structure
alignment that caused it to do strange things.
And dammit, the fact is, I think the new format is just worse. I think it
was a good thing to have the full SHA1 in the pack-file. I think the code
got less understandable, and had more special cases, just because now we
have two totally different kinds of deltas. So maybe I'm reacting to the
fact that I think the bug happened in the first place for a very simple
reason: the data structure wasn't unambiguous any more.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-18 3:10 UTC (permalink / raw)
To: Carl Worth
Cc: Jakub Narebski, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <871wp6e7o9.wl%cworth@cworth.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Worth wrote:
> Aaron, thanks for carrying this thread along and helping to bridge
> some communication gaps. For example, when I saw your original two two
> diagrams I was totally mystified how you were claiming that appending
> a couple of nodes and edges to a DAG could change the "order" of the
> DAG.
>
> I think I understand what you're describing with the leftmost-parent
> ordering now. But it's definitely an ordering that I would describe as
> local-only. That is, the ordering has meaning only with respect to a
> particular linearization of the DAG and that linearization is
> different from one repository to the next.
Well, the linarization for any particular head is well-defined, but
since different branches have different heads...
> If in practice, nobody does the mirroring "pull" operation then how
> are the numbers useful? For example, given your examples above, if
> I'm understanding the concepts and terminology correctly, then if A
> and B both "merge" from each other (and don't "pull") then they will
> each end up with identical DAGs for the revision history but totally
> distinct numbers. Correct?
The DAGs will be different. If A merges B, we get:
a
|
b
|\
c d
|\|
| e
|/
f
If B merges A before this, nothing happens, because B is already a
superset of A.
If B merges afterward, we get this:
a
|
b
|\
d c
|/|
e |
|\|
| f
|/
g
> So in that situation the numbers will not help A and B determine that
> they have identical history or even identical working trees.
They don't really have identical history.
> So what good are the numbers?
They are good for naming mainline revisions that introduced particular
changes.
> I can see that the numbers would have applicability with reference to
> a single repository, (or equivalently a mirror of that repository),
> but no utility as soon as there is any distributed development
> happening.
Well, there's distributed, and then there's *DISTRIBUTED*. We don't
quasi-randomly merge each others' branches. We have a star topology
around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNZsp0F+nu1YWqI0RAkmWAJ9PkrkubIHVgAn5Wbdkg9IBAHCviACdFx2x
6ClmK4GmC1pRuRQACcSijNM=
=SM1Y
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 2:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac3uif6i.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> The part you pointed out to me about "accidental collision"
> still bothers me somewhat.
I'll try to clear them away.
> Right now we do not produce ref-delta and ofs-delta in the same
> stream,
It is fully supported nevertheless.
> but if somebody did so then it would mean a disaster to have an
> accidental collision of an 8-byte offset value plus 12-byte traiing
> NUL and another base object whose object name happens to match that
> pattern.
Not really. The only effect that would have on the sorted list of
delta entries -- such sorting used to bring all deltas with the same
base object contigously -- is that those deltas might not be perfectly
contigous wrt their base object. This is why there is a test to skip
deltas if they happen not to be of the expected type.
> I am actually Ok if we say the code assumes one stream has only
> ref-delta or ofs-delta and never both.
I'm perfectly OK with both types completely randomized.
> But then I suspect the first pass of parse_pack_objects() should
> make sure that assumption holds true for the pack being
> inspected and barf if it is not.
This is an unnecessary restriction though.
> Also the second pass do not have to run two find_delta_childs() calls
> per delta object because by that time we know which kind would never
> appear in the packfile.
True, but the flexibility is worth having I think. It makes the thing
more robust instead of less.
> By the way can we call that find_delta_children() pretty please?
I have no problem with that.
Nicolas
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-18 2:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171754040.3962@g5.osdl.org>
On Tue, 17 Oct 2006, Linus Torvalds wrote:
>
>
> On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> > >
> > > .. and it sorts _differently_ on a big-endian vs little-endian thing,
> > > doesn't it?
> >
> > Sure. But who cares? The sorting is just there to 1) perform binary
> > searches on the list of deltas based from a given object, and 2) find a
> > list of all deltas with the same base object.
>
> _I_ care.
OK, So I do.
> The new code is messy. It's fragile, and already showed one very
> fundamental bug which depended on architectures.
My stance is that it is not fragile. Sure it had one bug that depended
on an architecture difference, but so was commit ac58c7b18e about.
The code also has many consistency checks all over so that it doesn't
write out garbage if such bugs arise. And that fundamental bug was
actually a trivial one that was caught right away by such consistency
check.
> These things matter. We have had very few bugs in git, and one of the
> reasons is (I believe) that we haven't had ad-hoc code. I get _very_
> nervous when you mix up SHA1 names with somethign totally different
> without even a flag to say which one it is. That's just nasty.
But there _is_ a flag for damn sake. Did you at least try to understand
the code and not just skim over it from 10000 feet above?
It is really simple:
- if the found union content matches with a reference union initialized
through the sha1 member then deltas[j].obj->type == OBJ_REF_DELTA
must be true.
- if the found union content matches with a reference union initialized
through the sha1 member then deltas[j].obj->type == OBJ_OFS_DELTA
must be true.
- For all deltas with deltas[j].obj->type == OBJ_REF_DELTA there can
not be more than one of them with the same union value.
- For all deltas with deltas[j].obj->type == OBJ_OFS_DELTA there can
not be more than one of them with the same union value.
There is _no_ confusion possible.
> The fact that the code then behaves (and behave_d_) differently on
> different architectures is just a sign of the problem.
Does this mean that, with your own change to xdiff that has just been
committed, you actually created a "problem"? Because this is a change
that creates different behaviors whether a 32-bit or 64-bit architecture
is used, Right?
But of course not. We want it to behave differently on 64-bit than
32-bit. My code is in the _same_ camp since I explicitly want it to
sort numbers differently whether it is a little endian or big endian
machine.
So this is not a problem this is a feature, and very by design.
> "Who cares?" is not a good question to ask for a SCM.
Please just try to understand why I'm claming this is not important in
this very case. Please do me this favor.
Nicolas
^ permalink raw reply
* Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)
From: Petr Baudis @ 2006-10-18 2:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610180358.03669.jnareb@gmail.com>
Dear diary, on Wed, Oct 18, 2006 at 03:58:03AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> You can have paginated graph (diagram). Although it is more natural
> to have diagram on the first page only, just like gitk --max-count=100.
Of course you _can_ have it, but you're going to have a lot of trouble
following the threads over page boundaries, especially if some branch
has no commits whatsoever at some page(s).
> The idea is for gitweb to generate (short)log, perhaps with pagination
> turned off (CSS overflow: scroll), and git-browser part to generate
> diagram and add it to log.
What's missing there is the scary AJAXish thing for fetching more
commits. You do not want to load the whole kernel history at once, but
instead on demand fetch more revisions.
BTW, I'm most probably not the one going to hack git-browser to fit in
this. My javascript knowledge is barely enough to implement a web
browser support for it. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Integrating gitweb and git-browser (was: Re: VCS comparison table)
From: Jakub Narebski @ 2006-10-18 1:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061018015211.GP20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Oct 18, 2006 at 03:36:36AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Petr Baudis wrote:
>>
>>> so that you can add your own views, so that git-browser can
>>> integrate to it more reasonably. (Currently it has completely different
>>> UI and you have to patch gitweb in order to get the proper links at
>>> proper places.) Sure, git-browser might get fully integrated to gitweb
>>> later but that needs to be done sensitively so that people are not
>>> scared by the horrible javascript blobs, etc.; currently git-browser is
>>> very experimental, and adding it would be quite intrusive.
>>
>> I was thinking about adding using JavaScript, in shortlog (and perhaps
>> shortlog-extended, i.e. with date and author) views one extra "diagram"
>> column, with width set using JavaScript generated embedded style, and use
>> only part of git-browser that generates diagram to draw it there.
>
> Shortlog is paginated and that's not very practical for diagrams, I
> think - you need to gradually extend it instead in that case. But yes,
> keeping the _visual_ difference of git-browser and gitweb as small as
> possible has been the main reason for me to think about integrating it
> more tightly.
You can have paginated graph (diagram). Although it is more natural
to have diagram on the first page only, just like gitk --max-count=100.
The idea is for gitweb to generate (short)log, perhaps with pagination
turned off (CSS overflow: scroll), and git-browser part to generate
diagram and add it to log.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Petr Baudis @ 2006-10-18 1:57 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660610171448h53de5e40wf55f19d6458127ef@mail.gmail.com>
Dear diary, on Tue, Oct 17, 2006 at 11:48:51PM CEST, I got a letter
where Christian MICHON <christian.michon@gmail.com> said that...
> I'd like particularly to know if a git-explorer type of plugin makes
> sense for (g)vim and would like in this case be part of the team
> developping it... using git of course :)
See also
http://news.gmane.org/find-root.php?message_id=<20051124093322.GA3899@mail.yhbt.net>
Personally, I'd say "just use tig". :-)
If you insist on living instide vim, that particular script comes from
the age before git-show and git-cat-file -p so it would probably make
sense to move the bulk of the functionality there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ 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