* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 14:19 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP10F617306F1477E66FA441AE0E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> Ah, okay. Well Git can definitely manage this. Just means you have to
> rebase any local changes before pushing. This will keep the history
> linear and make sure that no merges are needed in the case you were asking
> about.
Sure. As I said before, the little add-on of checkouts is that you say
once "I don't want to do local commit here", and bzr reminds you this
each time you commit. Well, where it can make a difference is that it
does it in a transactional way, that is, you don't have that little
window between the time you pull and the time you push your next
commit. But this would really be bad luck ;-).
> So far, it sounds to me like bazaar and git are more alike than they are
> different. Each have a few commands the other doesn't but all in all
> they sound very similar.
Sure. And at least, if you want to prove that your decentralized SCM
is the best, you'd better look at features other than the ability to
commit on a local branch ;-). If you want a _real_ flamewar, better
talk about rename management or revision identity.
The thing is that most people migrated from CVS/svn, so they found
their new SCM to be incredibly better the existing. But it's generally
not _so_ much better than the other modern alternatives ;-). (and
don't forget to thank Darcs and Monotone who brought most of the good
ideas you and I are using)
> But i'm a Git fanboy so I aint switching now ;o)
Probably not going to switch either, but that might happen.
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 14:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4534E246.10105@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Now I'm really confused. Does bazaar have both "clone" (git-style
> fetching a full repo and all the branches) and "checkout" (cvs-style
> fetching only the working tree)?
Yes, it has both. That's "bzr branch" (git clone) and "bzr checkout"
(cvs checkout).
Difference between "bzr branch" and "git clone" is that bzr doesn't
fetch all the branches. It fetches one "branch" (succession of
revisions) with all the ancestors of the revisions of the branch.
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 14:34 UTC (permalink / raw)
To: Aaron Bentley
Cc: Andreas Ericsson, Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <4534E335.8070203@utoronto.ca>
On Tue, 17 Oct 2006 10:05:41 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> No, you don't. They may have each pulled from a different repository.
>
> Take revision 00aabbcc, created by Linus. Linus has it because he
> committed it. I have it because I pulled Linus' repository. You have
> it because Andrew Morton pulled Linus' repository, and you pulled Andrew
> Morton's repository.
Well his point was that they have pulled from each other directly or
indirectly. You can safely say that rev 00aabbcc.. in _any_ repository
is the same rev. This discussion started because of doubt expressed
by some here on the list that the "simple" numbering scheme used by
bzr can offer the same guarantee. That is, rev 1.2.1 may be completely
different commits in different repos in bazaar.
> With most SCMs that store the repository in the root of the tree,
> disentangling the tree and repository requires care. OTOH, this is just
> as easy with Arch, CVS and SVN as it is with Bazaar.
Just in case it wasn't clear, this is drop dead easy in Git too.
> No, I *want* the working tree files. I run bzr from a checkout of bzr.dev.
Why? Uncommitted changes shouldn't be propagated. Once you have cloned
the repo, you can checkout your own copy of the working tree files.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 14:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <vpqr6x711cm.fsf@ecrins.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> While email can be used to exchange patches (git-format-patch to
>> generate patches, git-send-mail to send patches if you don't want to
>> use ordinary email client, git-am to apply patches) it cannot be used
>> to exchange all information (one cannot send for example tags, or
>> merge commits).
>
> In bzr, the "bundle" appears like a patch, but it actually contain the
> same information as the revision(s) it contains (I believe this
> applies to hg and Darcs too). A bundle can be used almost like a
> branch. That's a key point, since revision identity is not based on
> content's hash, so applying a patch is very different from merging a
> bundle.
The patch generated by git-format-patch has author information (in
"From:" header), original commit date (in "Date:" header), commit
message (first line in "Subject:", rest in message body), place for
comments which are not to be included in commit message, diffstat for
easier patch review, and git extended diff (with information about
renames detection, mode changes, 7-characters wide shortcuts of file
contents identifiers). It does not record parent information, original
comitter and comitter date, which branch we are on etc. You can quite
easily provide ordering of patches.
Sending patches via email prohibits first line of commit message to be
enclosed in brackets (subject usually is "[PATCH] Commit description"
or "[PATCH n/m] Commit description") and enforces git convention of
commit message to consist of first line describing commit shortly,
separated by empty line from the longer description and signoff lines.
"Bundle" equivalent, although binary in nature, would be thin pack.
>> It is very usefull tool to have for "accidental" developer.
>
> That's the key point, but patch review for non-accidental developpers
> is also good :-).
How very true...
>> BTW. git can provide binary patch for binary files (e.g. adding
>> favicon for gitweb in git.git).
>
> Bazaar's bundle use base64 encoding for binaries. I don't think that's
> efficient binary diff (xdelta-like) though. Aaron has been fighting
> quite a lot with MUA and MTA mixing up the patches (line ending in
> particular) ...
If I remember correctly git binary diff format is xdiff based, and uses
kind of ascii85 encoding (PostScript).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCHv2] git-branch: Set branch properties
From: Santi Béjar @ 2006-10-17 14:47 UTC (permalink / raw)
To: Git Mailing List
Added a flag to git-branch (-c) that makes git-branch to write the
config (branch properties) for the new branch so it will pull the same
branch it branched from.
If you want to work in the 'next' branch of git.git:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git branch -c mynext origin next
$ tail -n 3 .git/config
[branch "mynext"]
remote = origin
merge = refs/heads/next
$ git branch -c secondnext next
$ tail -n 3 .git/config
[branch "secondnext"]
remote = .
merge = next
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Hi,
it needs the get_ref_for_remote_branch function in
git-parse-remote.sh that is with the patch:
[RFC/PATCH] git-fetch: Use already fetched branch with the --local
flag
Also, this does not apply cleanly in next, the change in next is and
the resolution trivial:
< rm -f "$GIT_DIR/logs/refs/heads/$branch_name"
< rm -f "$GIT_DIR/refs/heads/$branch_name"
> git update-ref -d "refs/heads/$branch_name" "$branch"
What I have to do? Send the postimage or what?
Another questions is about rerere: Can it be done at the hunk level? We
could record the git-patch-id of the conflict and the postimage.
Documentation/git-branch.txt | 12 ++++++++++--
git-branch.sh | 30 +++++++++++++++++++++++++++---
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d43ef1d..77bbf81 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git-branch' [-r]
-'git-branch' [-l] [-f] <branchname> [<start-point>]
+'git-branch' [-l] [-f] [-c] <branchname> [<start-point> | <remote> <remotebranch>]
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
@@ -18,7 +18,8 @@ With no arguments given (or just `-r`) a
will be shown, the current branch will be highlighted with an asterisk.
In its second form, a new branch named <branchname> will be created.
-It will start out with a head equal to the one given as <start-point>.
+It will start out with a head equal to the one given as <start-point>,
+or from branch <remotebranch> of the repository <remote>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
@@ -26,9 +27,16 @@ With a `-d` or `-D` option, `<branchname
specify more than one branch for deletion. If the branch currently
has a ref log then the ref log will also be deleted.
+With a `-c` option, the branch properties `branch.<branchname>.remote`
+and `branch.<branchname>.merge` will be set.
+
OPTIONS
-------
+-c::
+ Write the branch properties `branch.<branchname>.remote`
+ and `branch.<branchname>.merge`.
+
-d::
Delete a branch. The branch must be fully merged.
diff --git a/git-branch.sh b/git-branch.sh
index 4f31903..afd768a 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,9 +1,10 @@
#!/bin/sh
-USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
+USAGE='[-l] [(-d | -D) <branchname>] | [[-f] [-c] <branchname> [<start-point> | <remote> <remotebranch>]] | -r'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
-If two arguments, create a new branch <branchname> based off of <start-point>.'
+If two arguments, create a new branch <branchname> based off of <start-point>.
+If three arguments, create a new branch <branchname> based off the branch <remotebranch> of the repository <remote>.'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -44,6 +45,8 @@ If you are sure you want to delete it, r
esac
rm -f "$GIT_DIR/logs/refs/heads/$branch_name"
rm -f "$GIT_DIR/refs/heads/$branch_name"
+ git repo-config --unset branch."$branchname".remote
+ git repo-config --unset-all branch."$branchname".merge
echo "Deleted branch $branch_name."
done
exit 0
@@ -71,6 +74,9 @@ do
-f)
force="$1"
;;
+ -c)
+ config="yes"
+ ;;
-l)
create_log="yes"
;;
@@ -101,9 +107,21 @@ case "$#" in
done
exit 0 ;;
1)
+ remote="."
+ remote_branch="$headref"
head=HEAD ;;
2)
+ remote="."
+ remote_branch="$2"
head="$2^0" ;;
+3)
+ remote="$2"
+ remote_branch="$3"
+ . git-parse-remote
+ ref=$(get_ref_for_remote_branch "$remote" "$remote_branch")
+ [ -z "$ref" ] && remote_branch="refs/heads/$remote_branch" && \
+ ref=$(get_ref_for_remote_branch "$remote" "$remote_branch")
+ head="$ref^0";;
esac
branchname="$1"
@@ -137,4 +155,10 @@ then
mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
touch "$GIT_DIR/logs/refs/heads/$branchname"
fi
-git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
+git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev || exit $?
+
+if test "$config" = "yes"
+then
+ git repo-config branch."$branchname".remote "$remote"
+ git repo-config branch."$branchname".merge "$remote_branch"
+fi
--
1.4.2.4.g687a-dirty
^ permalink raw reply related
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-17 15:03 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <45345AEF.6070107@utoronto.ca>
On Tue, 17 Oct 2006, Aaron Bentley wrote:
>
> But tags have local meaning only, unless someone has access to your
> repository, right?
Ehh. Exactly like the bzr numbers? You have to have access to the original
repo to name it.
So your point is?
If you do
git log v2.6.17
in a kernel repository, you'll see exactly what I see - because you'll
have gotten the tags, aka the "easy revision names".
Now, I'm obviously biased, but the thing is, git really does do this
right. No meaningless numbers. You give _meaningful_ revision names, and
they can be extremely powerful.
And no, it's not just tags or the raw SHA1 numbers. You can do
relationships like
git log HEAD~5..
which means "show the log for everything since five parents ago" (which is
_not_ the same as "show the last five revisions", because one of them may
have been a merge, and brought in a lot more of new commits).
Or, you can say
git diff mybranch@{2.days.ago}..nextbranch
which says exactly what you'd read it as: show the diff between what
"mybranch" looked like 2 days ago and what "nextbranch" looks like right
now.
Or, since the namespace is the same for commit history _and_ for actual
file contents, and since some commands don't need commits, you can decide
to name not a revision, but a specific file or subdirectory in a revision,
and do things like
git -p grep -1 request_irq v2.6.17~2:drivers/char
where the "revision" is not a commit revision at all, it's a _tree_
revision, because we've looked up the revision for "v2.6.17~2" (which
means "the grandparent of the tag 2.6.17"), and then within that commit we
looked up the tree "drivers/char", and then we grepped (recursively) for
the string "request_irq" within that subtree (with one line of context),
and then we paginated the output through "less" (or whatever your pager is
set to).
In other words, yes, the above does _exactly_ what you'd expect it to do.
The fact is, nobody ever uses the SHA1 names directly in their normal
work. You'd use the branch names, tag-names, or some relationship operator
like "this long ago" or "the parent of" or similar).
The only time you use actual SHA1 names is when you tell somebody _else_
something. Or when you use "gitk" to look something up, and select a
commit, and then paste that commit name into "git show" (which is
obviously telling "somebody else" - it's communicating between two
programs).
There's simply no reason to ever use the SHA1 names directly normally. But
they are there, and they are the _real_ revision numbers, and they
actually have real meaning between different repositories.
So that "git grep" example above is actually 100% equivalent to
git -p grep -1 request_irq 3ff4e205e1
but why would I ever write that? That's just insane. But in case you care,
the way I got that "3ff4e205e1" number, it was just by doing
git rev-parse v2.6.17~2:drivers/char
and cutting-and-pasting the first ten hex-digits to make sure I had
enough of a name to make it unique.
So the SHA1 names always exist, and they are what git _internally_ uses,
but you'd normally not use them that much in your daily life.
They are great for explaining things, though. For example, when somebody
reports a bug, and has used "git bisect" to figure out where the bug
started happening, that's when the "real name" matters - since we normally
didn't tag that commit as being buggy when we created it ;)
So that's when you'd say: "I bisected the problem, and it started
happening in commit 0123456789abcdef". And now everybody with a git
repository of the kernel can just look it up locally by
cutting-and-pasting that one number.
> The key thing about a checkout is that it's stored in a different
> location from its repository. This provides a few benefits:
Actually, git does something even better.
Git allows the repository to be split up.
You can get a git repository on a CD or DVD, and do
git clone -l -s /mount/cdrom myrepo
and that "-s" means that the new "myrepo" actually is linked to the
original CDROM repository, and you can now _commit_ stuff and make changes
in myrepo, even though all the old history is on that CD-ROM. It won't add
any unnecessary stuff at all to the new repo.
Or, you could do the "totally naked" checkout, so that the whole
repository is somewhere else (if that "somewhere else" is the CD-ROM, you
obviously cannot change anything ;)
Or you can have <n> different repositories that are all related, and all
contain just the part that _they_ care about.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-17 15:05 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <4534E335.8070203@utoronto.ca>
Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andreas Ericsson wrote:
>> Aaron Bentley wrote:
>
>>> When two people have copies of the same revision, it's usually because
>>> they are each pulling from a common branch, and so the revision in that
>>> branch can be named. Bazaar does use unique ids internally, but it's
>>> extremely rare that the user needs to use them.
>>>
>> Well, if two people have the same revision in git, you *know* they have
>> pulled from each other
>
> No, you don't. They may have each pulled from a different repository.
>
I realized it as I read it now. What I meant was that you know you have
the exact same revision as the original author once committed.
>
>>> But tags have local meaning only, unless someone has access to your
>>> repository, right?
>>>
>> I imagine the bazaar-names with url+number only has local meaning unless
>> someone has access to your repository too.
>
> Yes. That phrasing was from Linus' description of revnos.
>
>> One of the great benefits of
>> git is that each revision is *always exactly the same* no matter in
>> which repository it appears. This includes file-content, filesystem
>> layout and, last but also most important, history.
>
> In Bazaar, a revision id always refers to the same logical entity, but
> it may be stored in different formats in different repositories.
>
This I don't understand. Let's say Alice has revision-154 in her repo,
located at alice.example.com. Let's say that commit is accessible with
the url "alice.example.com:revision-154". Bob pulls from her repo into
his own, which is located at bob.example.com.
Lots of questions here, so I'll split them up. Feel free to delete the
non-applicable ones.
Will the commit in Bob's repo be accessible at
"bob.example.com:revision-154"?
If it's not, how can you backtrack from old bugreports and find the
error being discussed?
If it is, how does that work if Bob suddenly wants to commit things
before Alice is done working with her changes?
Also, suppose they both push to a master-repo where Caesar has pushed
his changes and nicked the slot for revision-154. Does the master repo
re-organize everything and then invalidate Bob's and Alice's changes, or
does it tell Alice and Bob that they need to update and then reorganize
their repos before they're allowed to push?
I really can't get my head around the usefulness of revision-numbers
hopping around which is probably why I'm having such a trouble groking
how it works.
>
>>> - - you can use a checkout to maintain a local mirror of a read-only
>>> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
>>>
>> Check. Well, actually, you just clone it as usual but with the --bare
>> argument and it won't write out the working tree files.
>
> No, I *want* the working tree files. I run bzr from a checkout of bzr.dev.
>
You get the working tree files by default. Use --bare if you don't want
them to be checked out (i.e. written to the working tree) after the
clone is complete.
>>> You can operate that way in bzr too, but I find it nicer to have one
>>> checkout for each active branch, plus a checkout of bzr.dev. Our switch
>>> command also rewrites only the changed part of the working tree.
>>>
>> Works in git as well, but each "checkout" (actually, locally referenced
>> repository clone) gets a separate branch/tag namespace.
>
> In our terminology, if it can diverge from the original, it's a branch,
> not a checkout.
>
This clears things up immensely. bazaar checkout != git checkout.
I still fail to see how a local copy you can't commit to is useful, but
it doesn't really matter to me as I've already found a tool that does
everything I want wrt scm needs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 15:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpqlknf10u5.fsf@ecrins.imag.fr>
On Tue, 17 Oct 2006 16:19:46 +0200
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Sure. As I said before, the little add-on of checkouts is that you say
> once "I don't want to do local commit here", and bzr reminds you this
> each time you commit. Well, where it can make a difference is that it
> does it in a transactional way, that is, you don't have that little
> window between the time you pull and the time you push your next
> commit. But this would really be bad luck ;-).
Yeah, it would be bad luck, but Git wouldn't actually let the push
succeed if someone had changed the upstream repo in that small window.
It would complain that your push wasn't a fast forward and ask you
to update before pushing.
> Sure. And at least, if you want to prove that your decentralized SCM
> is the best, you'd better look at features other than the ability to
> commit on a local branch ;-). If you want a _real_ flamewar, better
> talk about rename management or revision identity.
>
> The thing is that most people migrated from CVS/svn, so they found
> their new SCM to be incredibly better the existing. But it's generally
> not _so_ much better than the other modern alternatives ;-). (and
> don't forget to thank Darcs and Monotone who brought most of the good
> ideas you and I are using)
Heh, true enough. And the fact is they're all "borrowing" the
best ideas from one another. All of a sudden the others are all
getting git-like bisect and gitk guis. And of course Linus has
said that he got quite a bit of inspiration from Monotone
originally.
Beyond the distributed offline nature of using Git, the killer
"feature" for me is its raw speed and flexibility[1]. It's
really nice to be able to branch in under a second and try
out a line of development etc. Maybe this is just as easy
in Bazaar but it's not true of say Mercurial. Honestly, I
just can't imagine any other SCM meeting my needs better than
Git. So I have a hard time taking complaints about rename
management or revision identity seriously.
While they don't affect my usage, IMHO the two biggest failings
of Git are its lack of a shallow clone and its reliance on shell
and other scripting languages so there is no native Windows version.
I'm sure both of these areas are handled better by Bazaar and/or
some of the other new SCMs where they'd be a better choice than
Git.
Sean
[1] As an aside, I don't understand why bazaar pushes the idea
of "plugins". For instance someone mentioned that bazaar has
a bisect "plugin". Well Git was able to add a bisect "command"
without needing a plugin architecture.. so i'm at a loss as
to why plugins are seen as an advantage.
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 15:32 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4534F133.1090003@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> This I don't understand. Let's say Alice has revision-154 in her repo,
> located at alice.example.com. Let's say that commit is accessible with
> the url "alice.example.com:revision-154". Bob pulls from her repo into
> his own, which is located at bob.example.com.
Another equation can help.
Revision Identity != Revision Number.
$ bzr log --show-ids
------------------------------------------------------------
revno: 1
revision-id: Matthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d
committer: Matthieu Moy <Matthieu.Moy@imag.fr>
branch nick: foo
timestamp: Tue 2006-10-17 17:20:29 +0200
message:
some message
See, bzr has this unique revision identifier (not based on a hashsum).
The design choice of bzr is to hide it as much as possible from the
user interface.
Then, if I'm in the branch in which I typed this command, I can reffer
to this revision with simply
bzr whatever -r 1
In the general case, I can access it with
bzr whatever -r revid:Matthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d
(There's currently a lack in the UI to specify a remote revision-id,
but that's not a problem in the model itself)
bzr's internal use almost exclusively revision ID (ancestry
information is all about revision id), and revno are a UI layered on
top of it.
I don't have strong needs in revision control, but I actually never
encountered a case where I had to access a revision by providing its
ID. So, for people like me, revision numbers are sufficient, and they
are simple (for example, I can tell without running any command that
revision 42 is older than revision 56 in a particular branch).
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7rfsfqa.fsf@assigned-by-dhcp.cox.net>
On Mon, 16 Oct 2006, Junio C Hamano wrote:
> I'm still a bit under the weather and do not have enough
> concentration to dig into the problem tonight, but I noticed
> that something in "next", most likely the delta-base-offset
> patchset, broke git-index-pack:
>
> $ X=ec0c3491753e115e1775256f6b7bd1bce4dea7cd
> $ wget http://www.kernel.org/pub/scm/git/git.git/objects/pack/pack-$X.pack
> $ ~/git-master/bin/git-index-pack pack-$X.pack
> ec0c3491753e115e1775256f6b7bd1bce4dea7cd
> $ git-index-pack pack-$X.pack
> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has unresolved deltas
Using the tip of the "next" branch (git version 1.4.2.4.gf9fe) I just
cannot reproduce this problem at all. I always get a good index and
ec0c3491753e115e1775256f6b7bd1bce4dea7cd back.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-17 15:37 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061017141953.GA689@dspnet.fr.eu.org>
Olivier Galibert <galibert@pobox.com> writes:
> You're not telling us bzr still follows the utterly stupid
> update-before-commit model, right? Right?
One last time:
bzr _CAN_ follow the utterly stupid update-before-commit model.
It doesn't force you to do so, obviously.
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-17 16:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610171134130.1971@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 16 Oct 2006, Junio C Hamano wrote:
>
>> I'm still a bit under the weather and do not have enough
>> concentration to dig into the problem tonight, but I noticed
>> that something in "next", most likely the delta-base-offset
>> patchset, broke git-index-pack:
>>
>> $ X=ec0c3491753e115e1775256f6b7bd1bce4dea7cd
>> $ wget http://www.kernel.org/pub/scm/git/git.git/objects/pack/pack-$X.pack
>> $ ~/git-master/bin/git-index-pack pack-$X.pack
>> ec0c3491753e115e1775256f6b7bd1bce4dea7cd
>> $ git-index-pack pack-$X.pack
>> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has unresolved deltas
>
> Using the tip of the "next" branch (git version 1.4.2.4.gf9fe) I just
> cannot reproduce this problem at all. I always get a good index and
> ec0c3491753e115e1775256f6b7bd1bce4dea7cd back.
Hmph. I just got exactly the same breakage; could this be
another 64-bit breakage? My breakage was on x86-64.
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Junio C Hamano @ 2006-10-17 16:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0610160929450.17085@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sun, 15 Oct 2006, Linus Torvalds wrote:
>
>> Quite frankly, I wonder if the pure "copy size extension" (aka "v3") thing
>> is really worth it at all.
>>
>> I mean, seriously, how much does it buy us? A couple of bytes per every
>> 64kB of delta copied? And the downside is that you can't re-use the deltas
>> with old clients and/or you have to re-create a "v2" delta at run-time
>> from a v3 delta by inflating, fixing and deflating it.
>
>...
> In the mean time, if Junio adds the patch I posted yesterday advertising
> the pack version capability over the native protocol then it'll help us
> make things forward compatible if ever we decide to go with generating
> packs v3 sooner.
I've thought about this, but we hopefully would have ofs-delta
capability exchanged soon after 1.4.3, and that would be an
enough advertisement that the client is recent enough; although
it is technically incorrect to tie these two independent
features together, the improvement between v2 and v3 is dubious
so maybe that is the easiest.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-17 16:41 UTC (permalink / raw)
To: Robert Collins; +Cc: Jakub Narebski, Aaron Bentley, bazaar-ng, git
In-Reply-To: <1161078035.9020.73.camel@localhost.localdomain>
On Tue, 17 Oct 2006, 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
>
> (assuming the first * is numbered '1'.)
>
> These numbers are fairly stable
And here, by "fairly stable", you really mean "totally idiotic", don't
you?
Guys, let's be blunt here, and just say you're wrong. The fact is, I've
used a system that uses the same naming bzr does, and I've used it likely
longer and with a bigger project than anybody has likely _ever_ used bzr
for.
It sounds like bzr is doing _exactly_ what bitkeeper did.
Those "simple" numbers are totally idiotic. And when I say "totally
idiotic", please go back up a few sentences, and read those again. I know
what I'm talking about. I know probably better than anybody in the bzr
camp.
Those "simple" numbers are anything but. They may be short, most of the
time, but when you bandy things like "-r 56" around, what you're ignoring
is that for a _real_ project you actually get numbers like "1.517.3.57",
which isn't really any simpler or shorter than saying "7786ce19". You
still want to cut-and-paste it.
And the "simple" numbers have a real downside, which is that THEY CHANGE.
What happens is that somebody else started _another_ branch at revision 2,
and did important work, and and they also had a "2.1.2" revision, and then
they merged your work, and you merged their merge back, that "simple"
revision number changed, didn't it? Suddenly "2.1.2" means something
different for one of the users.
We had people in the bitkeeper world that _never_ actually understood that
the numbers changed. The "simple" numbers were stable enough that a lot of
people thought they were real revisions, and then they were really
_really_ confused when a number like "1.517.3.57" suddenly went away after
a merge, and became something else instead.
And yes, bitkeeper had a "real key" internally too. If you actually wanted
to give a real revision, you had to give something that looked a lot like
what the bzr internal revision numbers look like.
Of course, most users didn't even _know_ or understand those revision
numbers, so as a result, you had tons of people who used the "simple"
thing (which was what "bk log" and all other tools would show), and since
it worked quite often, they thought it was ok. And then sometimes it
didn't work at all, or it "worked" by giving the wrong commit, and it was
just a total disaster.
Something that works "most of the time" is not simple to use. It's just a
way to make people _believe_ it is simple, and then be really confused
when it doesn't work.
So trust me, naming things so that the name depend on the local shape of
the history is idiotic. I _know_. Been there, done that.
The thing is, when I designed git, I actually had years of experience
working with a big project in a truly distributed manner. I _knew_ that
handling renames specially is a bad idea (not that you should even need to
have used BK to know that).
And I _knew_ that the simple revision numbers aren't real and just cause
confusion.
Linus
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-17 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vodsakjkg.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Sun, 15 Oct 2006, Linus Torvalds wrote:
> >
> >> Quite frankly, I wonder if the pure "copy size extension" (aka "v3") thing
> >> is really worth it at all.
> >>
> >> I mean, seriously, how much does it buy us? A couple of bytes per every
> >> 64kB of delta copied? And the downside is that you can't re-use the deltas
> >> with old clients and/or you have to re-create a "v2" delta at run-time
> >> from a v3 delta by inflating, fixing and deflating it.
> >
> >...
> > In the mean time, if Junio adds the patch I posted yesterday advertising
> > the pack version capability over the native protocol then it'll help us
> > make things forward compatible if ever we decide to go with generating
> > packs v3 sooner.
>
> I've thought about this, but we hopefully would have ofs-delta
> capability exchanged soon after 1.4.3, and that would be an
> enough advertisement that the client is recent enough; although
> it is technically incorrect to tie these two independent
> features together, the improvement between v2 and v3 is dubious
> so maybe that is the easiest.
Fair enough.
Nicolas
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 17:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslhnj58e.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Mon, 16 Oct 2006, Junio C Hamano wrote:
> >
> >> I'm still a bit under the weather and do not have enough
> >> concentration to dig into the problem tonight, but I noticed
> >> that something in "next", most likely the delta-base-offset
> >> patchset, broke git-index-pack:
> >>
> >> $ X=ec0c3491753e115e1775256f6b7bd1bce4dea7cd
> >> $ wget http://www.kernel.org/pub/scm/git/git.git/objects/pack/pack-$X.pack
> >> $ ~/git-master/bin/git-index-pack pack-$X.pack
> >> ec0c3491753e115e1775256f6b7bd1bce4dea7cd
> >> $ git-index-pack pack-$X.pack
> >> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has unresolved deltas
> >
> > Using the tip of the "next" branch (git version 1.4.2.4.gf9fe) I just
> > cannot reproduce this problem at all. I always get a good index and
> > ec0c3491753e115e1775256f6b7bd1bce4dea7cd back.
>
> Hmph. I just got exactly the same breakage; could this be
> another 64-bit breakage? My breakage was on x86-64.
I've been suspecting that since then as well. I indeed tested on i386.
But reviewing the code I just can't find any obvious spot where 64-bit
would be an issue, especially since your pack does not have any
OFS_DELTA objects.
Could you instrument the code at the end of
index-pack.c:parse_pack_objects() to display how many deltas were
actually resolved and how many were not? IOW is it a case of all or
nothing, or is there an isolated case of corruption lurking somewhere?
Nicolas
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-10-17 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvemjmlo2.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> * The 'maint' branch has this fix and produced 1.4.2.4 release.
>
> Linus Torvalds (1):
> Fix hash function in xdiff library
There's two things to note about this:
- the libxdiff dependencies are broken, so it's likely that you need to
do a "make clean; make" to actually see the result of this.
We really should fix this. I was bitten by this _again_ when I wanted
to do some performance testing, and was scratching my head about why it
didn't seem to matter.
I haven't looked into which part of the Makefile is broken yet, so I
really don't know what's broken, but maybe somebody who likes makefiles
could take a look? Basically, doing a
touch xdiff/xmacros.h
should cause a recompile of a lot more than it causes.
- while the hash function problem _can_ cause really huge slowdowns in
some unlucky situations, it actually causes noticeable performance
issues even for normal situations.
For example, for me on a 2GHz merom machine in the current git
directory:
Before:
[torvalds@merom git]$ time ./git log -p | wc -l
746211
real 0m27.223s
user 0m26.894s
sys 0m0.424s
After:
[torvalds@merom git]$ time ./git log -p | wc -l
746211
real 0m9.638s
user 0m9.329s
sys 0m0.468s
so there's a factor-of-three difference here even on a "normal" load
like git itself. You don't need a huge file with tons of changes to see
the effect of this.
So we should fix the makefile to add whatever proper header file
dependencies, but we should also make sure that whoever builds binaries
has done a "make clean", otherwise the fix is potentially hidden.
Linus
^ permalink raw reply
* [PATCH] add proper dependancies on the xdiff source
From: Andy Whitcroft @ 2006-10-17 18:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610171005370.3962@g5.osdl.org>
We are not rebuilding the xdiff library when its header files change.
Add dependancies for those to the main Makefile.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/Makefile b/Makefile
index 932bcb9..3e54f75 100644
--- a/Makefile
+++ b/Makefile
@@ -768,6 +768,8 @@ git-http-push$X: revision.o http.o http-
rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
+$(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
+ xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
$(XDIFF_LIB): $(XDIFF_OBJS)
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
^ permalink raw reply related
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-17 18:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610171251210.1971@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > On Mon, 16 Oct 2006, Junio C Hamano wrote:
>> >
>> >> I'm still a bit under the weather and do not have enough
>> >> concentration to dig into the problem tonight, but I noticed
>> >> that something in "next", most likely the delta-base-offset
>> >> patchset, broke git-index-pack:
>> >>
>> >> $ X=ec0c3491753e115e1775256f6b7bd1bce4dea7cd
>> >> $ wget http://www.kernel.org/pub/scm/git/git.git/objects/pack/pack-$X.pack
>> >> $ ~/git-master/bin/git-index-pack pack-$X.pack
>> >> ec0c3491753e115e1775256f6b7bd1bce4dea7cd
>> >> $ git-index-pack pack-$X.pack
>> >> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has unresolved deltas
>> >
>> > Using the tip of the "next" branch (git version 1.4.2.4.gf9fe) I just
>> > cannot reproduce this problem at all. I always get a good index and
>> > ec0c3491753e115e1775256f6b7bd1bce4dea7cd back.
>>
>> Hmph. I just got exactly the same breakage; could this be
>> another 64-bit breakage? My breakage was on x86-64.
>
> I've been suspecting that since then as well. I indeed tested on i386.
> But reviewing the code I just can't find any obvious spot where 64-bit
> would be an issue, especially since your pack does not have any
> OFS_DELTA objects.
>
> Could you instrument the code at the end of
> index-pack.c:parse_pack_objects() to display how many deltas were
> actually resolved and how many were not? IOW is it a case of all or
> nothing, or is there an isolated case of corruption lurking somewhere?
fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has
18915 unresolved ref-deltas and 0 ofs-deltas among 21205
By the way, "Gaaaah". Is this find_delta() called from
find_delta_children() doing the right thing? I wonder if this
is open to accidental collisions?. If you have an object name
whose last 12-bytes are all NUL and you have a pack offset whose
bytes happens to be a good prefix for an object, what happens?
^ permalink raw reply
* Re: What's in git.git
From: Davide Libenzi @ 2006-10-17 18:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171005370.3962@g5.osdl.org>
On Tue, 17 Oct 2006, Linus Torvalds wrote:
> - while the hash function problem _can_ cause really huge slowdowns in
> some unlucky situations, it actually causes noticeable performance
> issues even for normal situations.
Yes, using a 32 bits multiplier on a 64 bits machine transform the almost
O(1) hash performance to a crappy O(N) list performance. you notice that
in every diff operation, independently from the content.
- Davide
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-10-17 18:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610171005370.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> There's two things to note about this:
>
> - the libxdiff dependencies are broken, so it's likely that you need to
> do a "make clean; make" to actually see the result of this.
Eh, stupid-and-obvious like this perhaps.
---
diff --git a/Makefile b/Makefile
index 2c7c338..3fed480 100644
--- a/Makefile
+++ b/Makefile
@@ -237,6 +237,7 @@ PYMODULES = \
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
+$(XDIFF_LIB): $(wildcard xdiff/*.[ch])
LIB_H = \
archive.h blob.h cache.h commit.h csum-file.h delta.h grep.h \
^ permalink raw reply related
* Re: [PATCH] add proper dependancies on the xdiff source
From: Ryan Anderson @ 2006-10-17 18:22 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <2ffb978570666d608b8a58c39e30b9d1@pinky>
On 10/17/06, Andy Whitcroft <apw@shadowen.org> wrote:
> We are not rebuilding the xdiff library when its header files change.
> Add dependancies for those to the main Makefile.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Ryan Anderson <ryan@google.com>
(I had a different variation on the same change just about ready to
mail, but the dependencies match. For a simple verification, "gcc -MM
xdiff.c" is a good tool.)
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqoake1v.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Could you instrument the code at the end of
> > index-pack.c:parse_pack_objects() to display how many deltas were
> > actually resolved and how many were not? IOW is it a case of all or
> > nothing, or is there an isolated case of corruption lurking somewhere?
>
> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has
> 18915 unresolved ref-deltas and 0 ofs-deltas among 21205
Hmmm.... Interesting.
Is it possible that sizeof(union delta_base) might not be equal to 20
for you?
> By the way, "Gaaaah". Is this find_delta() called from
> find_delta_children() doing the right thing? I wonder if this
> is open to accidental collisions?. If you have an object name
> whose last 12-bytes are all NUL and you have a pack offset whose
> bytes happens to be a good prefix for an object, what happens?
It is filtered out later thusly:
...
for (j = ref_first; j <= ref_last; j++)
if (deltas[j].obj->type == OBJ_REF_DELTA)
resolve_delta(&deltas[j], data, ...);
So if a collision happens the object won't be of the right type and it
is simply skipped.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: J. Bruce Fields @ 2006-10-17 18:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aaron Bentley, git
In-Reply-To: <7v64ejqx3a.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 16, 2006 at 11:23:53PM -0700, Junio C Hamano wrote:
> Aaron Bentley <aaron.bentley@utoronto.ca> writes:
>
> > Johannes Schindelin wrote:
> >
> >>> You'll note we referred to that bevhavior on the page. We don't think
> >>> what Git does is the same as supporting renames. AIUI, some Git users
> >>> feel the same way.
> >>
> >> Oh, we start another flamewar again?
> >
> > I'd hope not. It sounds as though you feel that supporting renames in
> > the data representation is *wrong*, and therefore it should be an insult
> > to you if we said that Git fully supported renames.
>
> Not recording and not supporting are quite different things.
Yes. There's a risk of confusing a feature with an implementation
detail. From http://bazaar-vcs.org/RcsComparisons:
"If a user can rename a file in the RCS without loosing the RCS
history for a file, then renames are considered supported. If
the operation resultes in a delete/add (aka "DA pair"), then
renames are not considered supported. If the operation results
in a copy/delete pair, renames are considered "somewhat"
supported. The problem with copy support is that it is hard to
define sane merge semantics for copies."
The first sentence sounds like a description of a user-visible feature.
The rest of it sounds like implementation.
And git probably has some deficiencies here, but it'd be more useful to
identify them in terms of things a user can't do.
--b.
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-10-17 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64eikdp2.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> Eh, stupid-and-obvious like this perhaps.
I'm not convinced that is enough. You need to make the individual
xdiff/*.c files depend on the xdiff/*.h files, because otherwise it will
think that the *.o files are up-to-date and just re-link the archive.
The kernel does automatic dependency generation for all the *.c files, and
it's _really_ nice. Having to do dependencies by hand is just always going
to suck. But the kernel can depend on more things (in particular, the
kernel can depend on gcc, and use things like "-MD,$(depfile)" to generate
lists of dependencies while building, so that any object file _always_ has
the things it depended upn explicitly listed).
But in the absense of those kinds of really clever and powerful tricks, it
might be worthwhile to even just have a "mkdepend" scrupt thing and
include the end result into the Makefile (we do already depend on GNU
make).
That would allow us to get the real dependencies (and minimal! right now
we sometimes compile too _much_ just because some of our dependencies are
so screwed up and lazy).
Linus
^ 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