* Re: [PATCH] Don't segfault if the given SHA1 name is longer than 40 characters
From: Nguyen Thai Ngoc Duy @ 2006-10-19 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt6xvt7q.fsf@assigned-by-dhcp.cox.net>
On 10/19/06, Junio C Hamano <junkio@cox.net> wrote:
> The patch is correct, but it needs a better explanation in the
> proposed commit log message than just "Don't segfault".
Well, maybe because I got a segfault when I accidentally pasted an
sha1 twice (blame my mouse). I hadn't looked closely enough to the
bug. Anyway, you got the bug and obviously have a better explanation
than mine. Please fix it with a better explanation. I'll be more
explanatory next time. Thank you :-)
> get_describe_name() can be fed a string foo-gXXX...XXX with a
> very looooooooong hexstring. It calls get_short_sha1() without
> checking if XXX...XXX part is longer than 40-bytes (in which
> case it cannot be a valid object name).
>
> get_sha1_1() has the same problem. Given a hexstring longer
> than 40-bytes, it calls the function with it because earlier
> ones such as get_sha1_hex() would reject the input.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add revspec documentation for ':path', ':[0-3]:path' and git-describe
From: Nguyen Thai Ngoc Duy @ 2006-10-19 4:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkncx6d2.fsf@assigned-by-dhcp.cox.net>
On 10/19/06, Junio C Hamano <junkio@cox.net> wrote:
> > As I'm not very good at English, please correct any mistake I made
>
> Thanks. I do not know about English, but I'd move things around
> to group them better. Most talk about committish but the
> colon-path are about trees and blobs.
It's ok to me.
--
Duy
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-19 5:21 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4536EC93.9050305@utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
On Wed, 18 Oct 2006 23:10:11 -0400, Aaron Bentley wrote:
> It is fine to say all branches are equal from a technical perspective.
> - From a social perspective, it's just not true.
That's actually a very important insight, but supporting the wrong
conclusion.
In a healthy situation, the only thing that makes a branch special are
social issues, such as you describe. That's how it should be.
But think about your favorite example of an unhealthy social situation
around a software project and a big, nasty fork. Every example I can
think of involves some technical distinction that makes one branch
more special than another.
Now, those situations also involve social problems, and those are even
more significant. But the technical blessing of one branch does not
help. And I think it contributes to the social problems in many cases.
So, I think the technical thing that is distributed version control is
an extremely important thing for us to use to help maintain healthy
social software projects. Reducing the technical hurdle of a fork, (to
where continual forking is actually a totally expected part of the
process), is a very healthy thing.
Now, both bzr and git are distributed systems, and either one will
help a great deal in the respects I'm talking about compared to
something like cvs.
As far as the revision numbers, my impression is that the numbers
would be confusing or worthless if I were to use bzr the way I'm
currently using git, as they certainly could not remain stable.
> In bzr development, it's very rare for anyone's revision numbers to change.
Which just says to me that the bzr developers really are sticking to a
centralized model. That's fine, but it does have impacts, and the tool
really does seem to have some bias toward this.
> I think you're implying that on a technical level, bzr doesn't support
> this. But it does. Every published repository has unique identifiers
> for every revision on its mainline, and it's exceedingly uncommon for
> these to change.
Every argument you make for the number change being uncommon just
strengthens the argument that it will be all that more
confusing/frustrating when the numbers do change.
In cairo, for example, we've made a habit of including a revision
identifier in our bug tracking system for every commit that resolves a
bug. I like having the assurance that those numbers will survive
forever. And it doesn't matter if the repository moves, or the project
is forked, or anything else. Those numbers cannot change.
I understand that bzr also has unique identifiers, but it sounds like
the tools try to hide them, and people aren't in the habit of using
them for things like this. Do bzr developers put revision numbers in
their bug trackers? Is there a guarantee they will always be valid?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-19 5:33 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4536EC93.9050305@utoronto.ca>
On Wed, Oct 18, 2006 at 11:10:11PM -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Linus Torvalds wrote:
>
> > 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's not true of bzr development. The "main maintainer" that runs the
> bzr.dev is an email bot. It's not an integrator-- its work is purely
> mechanical. It can't resolve merge conflicts.
The point here is, that because of using the bot, the revnos on bzr.dev
are indeed stable (and many of the merges are in fact pointless merges
(ie. merges of revision and it's ancestor)). But if you don't use the
bot, than doing:
bzr merge mainline
bzr push mainline
makes your revision the leftmost parent is your revison, not the one
from "mainline". The fact that bzr treats leftmost parent somewhat
specially makes people to replace the above with
bzr branch mainline
cd mainline
bzr merge feature-branch
bzr push
which is, well, more complicated (but you see it's not about main
maintainer -- anybody with write access can push).
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Jan Hudec @ 2006-10-19 5:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <eh68va$7er$1@sea.gmane.org>
On Thu, Oct 19, 2006 at 12:14:02AM +0200, Jakub Narebski wrote:
> Jan Hudec wrote:
> > Comments?
>
> What about fetching from repository? For revnos you have to assign revno for
> all commit you have downloaded; now you need only to unpack received pack
> (or not, if you used --keep option). More work.
I don't know git internals, so I can't tell for git. For bzr:
1) You have to add the data to the knits, since the knits are one for
each versioned file plus one for inventory and one for revision
metadata, so this is just a small addition to that work. In fact the
revnos in repository-wide case would be just the indices into the
revisions knit (while in the branch-wide there would have to be a
special list).
2) Bzr already generates a special list, revision-history, where it
stores a list of mainline branches (in fact it used to store a list
of local commits, but now lists the path over leftmost parents).
So it already does the work.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Martin Pool @ 2006-10-19 5:56 UTC (permalink / raw)
To: Carl Worth
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <87lkncev90.wl%cworth@cworth.org>
On 18 Oct 2006, Carl Worth <cworth@cworth.org> wrote:
> I understand that bzr also has unique identifiers, but it sounds like
> the tools try to hide them, and people aren't in the habit of using
> them for things like this. Do bzr developers put revision numbers in
> their bug trackers? Is there a guarantee they will always be valid?
There is a mix of
- Just giving the overall tarball version number, which is most
meaningful to users (and not related to bzr versions)
- Giving a mainline revision number, which will never revert because we
never pull (fast-forward) that branch. That has the substantial
(imo) benefit that you can immediately compare these numbers by eye,
and they are easy to quote.
- Giving a unique id, which is obviously most definitive and
appropriate if you're talking about something which is not
on the mainline or a well known branch. The launchpad.net
bug tracker links branches to bugs and does this through
revision ids.
--
Martin
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-10-19 5:58 UTC (permalink / raw)
To: git
* The 'maint' branch is now for post 1.4.3 fixes. It currently
contains these:
Nguyễn Thái Ngọc Duy (2):
Reject hexstring longer than 40-bytes in get_short_sha1()
Add revspec documentation for ':path', ':[0-3]:path' and git-describe
Nicolas Pitre (1):
reduce delta head inflated size
* The 'master' branch has produced 1.4.3 release today. I've
merged the 'maint' fixes and the first wave of what have been
cooking in "next".
Andy Whitcroft (1):
add proper dependancies on the xdiff source
Johannes Schindelin (1):
Turn on recursive with --summary
Junio C Hamano (7):
grep --all-match
teach revision walker about --all-match.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
git-send-email: do not drop custom headers the user prepared
git-send-email: real name with period need to be dq-quoted on From: line
Make git-send-email detect mbox-style patches more readily
diff --numstat
Markus Amsler (1):
git-imap-send: Strip smtp From_ header from imap message.
Martin Waitz (2):
gitweb: start to generate PATH_INFO URLs.
gitweb: warn if feature cannot be overridden.
Matthew Wilcox (1):
Add --dry-run option to git-send-email
Nguyễn Thái Ngọc Duy (2):
Reject hexstring longer than 40-bytes in get_short_sha1()
Add revspec documentation for ':path', ':[0-3]:path' and git-describe
Nicolas Pitre (1):
reduce delta head inflated size
Petr Baudis (3):
gitweb: Document features better
gitweb: Fix search form when PATH_INFO is enabled
bisect reset: Leave the tree in usable state if git-checkout failed
Rene Scharfe (2):
git-archive --format=zip: use default version ID
git-archive --format=zip: add symlink support
Robert Shearman (2):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
Santi Béjar (2):
merge and resolve: Output short hashes and .. in "Updating ..."
fetch: Misc output cleanup
Sasha Khapyorsky (1):
git-svnimport.perl: copying directory from original SVN place
* The 'next' branch, in addition, has these. Roughly speaking,
there are two and half big topics:
(1) Nico's delta-base-offset encoding;
(2) Linus's packed-refs and related changes;
(3) my blame --porcelain and its use in gitweb;
When the dust settles after the first wave I pushed out
tonight, I'd merge delta-base-offset stuff as the second wave,
and then hopefully packed-refs stuff after that. I suspect
there still remains breakage around ref-log I need to fix in
the latter topic.
Alan Chandler (1):
Gitweb - provide site headers and footers
Andy Whitcroft (2):
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Christian Couder (12):
Add [-s|--hash] option to Linus' show-ref.
Use Linus' show ref in "git-branch.sh".
Document git-show-ref [-s|--hash] option.
Fix show-ref usage for --dereference.
Add pack-refs and show-ref test cases.
When creating branch c/d check that branch c does not already exists.
Uncomment test case: git branch c/d should barf if branch c exists.
Fix a remove_empty_dir_recursive problem.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Check that a tag exists using show-ref instead of looking for the ref file.
Do not create tag leading directories since git update-ref does it.
Dennis Stosberg (2):
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Jeff King (3):
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
Johannes Schindelin (2):
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Jonas Fonseca (1):
Add man page for git-show-ref
Junio C Hamano (48):
upload-pack: stop the other side when they have more roots than we do.
Add git-for-each-ref: helper for language bindings
Fix t1400-update-ref test minimally
fsck-objects: adjust to resolve_ref() clean-up.
symbolit-ref: fix resolve_ref conversion.
Add callback data to for_each_ref() family.
Tell between packed, unpacked and symbolic refs.
pack-refs: do not pack symbolic refs.
git-pack-refs --prune
pack-refs: fix git_path() usage.
lock_ref_sha1_basic: remove unused parameter "plen".
Clean-up lock-ref implementation
update-ref: -d flag and ref creation safety.
update a few Porcelain-ish for ref lock safety.
Teach receive-pack about ref-log
receive-pack: call setup_ident before git_config
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
refs: minor restructuring of cached refs data.
lock_ref_sha1(): do not sometimes error() and sometimes die().
lock_ref_sha1(): check D/F conflict with packed ref when creating.
delete_ref(): delete packed ref
git-branch: remove D/F check done by hand.
show-ref --hash=len, --abbrev=len, and --abbrev
git-fetch: adjust to packed-refs.
Fix refs.c;:repack_without_ref() clean-up path
gitweb: make leftmost column of blame less cluttered.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
pack-refs: use lockfile as everybody else does.
gitweb: prepare for repositories with packed refs.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
pack-refs: call fflush before fsync.
blame.c: whitespace and formatting clean-up.
git-blame: --show-number (and -n)
git-blame: --show-name (and -f)
blame.c: move code to output metainfo into a separate function.
ref-log: allow ref@{count} syntax.
git-blame --porcelain
gitweb: use blame --porcelain
core.logallrefupdates create new log file only for branch heads.
git-pack-refs --all
core.logallrefupdates thinko-fix
pack-objects: document --delta-base-offset option
blame: Document and add help text for -f, -n, and -p
gitweb: spell "blame --porcelain" with -p
git-repack: repo.usedeltabaseoffset
pack-objects: use of version 3 delta is now optional.
gitweb: use for-each-ref to show the latest activity across branches
Revert "pack-objects: use of version 3 delta is now optional."
Linus Torvalds (6):
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
Luben Tuikov (4):
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
git-revert with conflicts to behave as git-merge with conflicts
Nicolas Pitre (9):
introduce delta objects with offset to base
teach git-unpack-objects about deltas with offset to base
teach git-index-pack about deltas with offset to base
make git-pack-objects able to create deltas with offset to base
make pack data reuse compatible with both delta types
let the GIT native protocol use offsets to delta base when possible
zap a debug remnant
allow delta data reuse even if base object is a preferred base
index-pack: compare only the first 20-bytes of the key.
Petr Baudis (2):
Fix broken sha1 locking
Fix buggy ref recording
Ryan Anderson (1):
Remove git-annotate.perl and create a builtin-alias for git-blame
* The 'pu' branch, in addition, has these.
Junio C Hamano (18):
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
para-walk: walk n trees, index and working tree in parallel
para walk wip
merge: loosen overcautious "working file will be lost" check.
git-pickaxe: blame rewritten.
git-pickaxe: minimally use revision machinery.
git-pickaxe: fix output for more than one paths from the same commit.
git-pickaxe: fix "bottom" commit handling.
git-pickaxe: allow using non -u0 diff internally.
git-pickaxe: use linked list of blame entries.
git-pickaxe: collapse trivial blame entry.
git-pickaxe: blame line movements within a file.
git-pickaxe: blame cut-and-pasted lines.
git-pickaxe: -M, -C, and -C -C
git-pickaxe: optimize nth_line()
git-pickaxe: make -C (copy from other file) take immediate blame.
git-pickaxe: document -M, -C, and -C -C
git-pickaxe: "--not A B -- path" is the same as "HEAD --not A B -- path"
Petr Baudis (1):
gitweb: Show project README if available
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Daniel Barkalow @ 2006-10-19 6:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0610180835000.3962@g5.osdl.org>
On Wed, 18 Oct 2006, Linus Torvalds wrote:
> 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..
AFAICT, "merge" actually execs "diff3", so if a system has only one,
either it's diff3, it's a "merge" from somewhere other than current rcs,
or it doesn't actually work.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Alexander Belchenko @ 2006-10-19 6:46 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <20061018185225.GU20017@pasky.or.cz>
Petr Baudis пишет:
...
> An example bundle is available at
>
> http://pasky.or.cz/~pasky/cp/example-bundle.txt
You probably miss main idea of bzr bundles. It's not just the way to
send via e-mail or other appropriate transport the part of repository.
It primarily was designed to be human readable as usual diff (i.e.
patch). It was designed to solve 2 thing simultaneously:
- be informative for human as usual patch
- be consistent for machine.
--
Alexander
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-19 7:02 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4536EC93.9050305@utoronto.ca>
> > 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.
>
> That sounds to me like a baton was passed. You asked Greg to behave
> like you, and told everyone else to expect that, too. Passing the baton
> was a social, not technical event, but it did happen. And there would
> certainly be no difficulty doing exactly that (right down to running
> "pull") in Bazaar land.
I'd like to point out that the same thing has happened in bzr-land.
Back in the "pre-bot" days, only Martin did put things in "his branch"
where most people got bzr from (same as Linus' git branch), but he was
away for a few weeks and during this time, there was 3 (or 4 perhaps)
other branches, called integration branches, that was being used.
They were all maintained by different people.
Everyone learned really quickly to use them instead of Martin's
branch. When Martin came back, he just pulled/merged these branches
and everything was back to normal.
I'd say in this case, bzr was even more "without a trunk" then in the
example Linus gives above.
What seams to be one interesting thing in this discussion is that,
because people use bzr and git in slightly different ways, they think
that one or the other cannot be used in another way.
bzr's use of revision numbers, doesn't mean it hasn't got unique
revision identifiers, and I can't see any reason why it couldn't be
used in the same way as git. Both are excellent tools, and since git
is more specialized (built to support the exact workflow used in
kernel development), it's more suited for that exact use.
bzr tries to take a broader view, for example, it does support a
centralized workflow if you want one. Most people don't, but a few
might. Because of this, it probably fits the kernel development less
good than git. That's fine I think! I happens to fit my workflow
better than git does :)
Regards,
Erik
^ permalink raw reply
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Alexander Belchenko @ 2006-10-19 8:19 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061018214623.GA32725@artax.karlin.mff.cuni.cz>
Jan Hudec пишет:
...
>
> Reading this thread I came to think, that the revnos should be assigned
> to _all_ revisions _available_, in order of when they entered the
> repository (there are some possible variations I will mention below)
>
...
> - They would be the same as subversion and svk, and IIRC mercurial as
> well, use, so:
> - They would already be familiar to users comming from those systems.
> - They are known to be useful that way. In fact for svk it's the only
> way to refer to revisions and seem to work satisfactorily (though
> note that svk is not really suitable to ad-hoc topologies).
I think that SVN model of revision numbers is wrong. And apply it to bzr
break many UI habits. Per example, when ones use svn and their repo has
many branches you never could say what revisions belongs to mainline. So
things like
bzr diff -rM..N
(where M and N absolute revisions numbers, and N = M+1(+2) etc.)
will more complicated, because in this case you first need to run log
command, remember actual numbers of those revisions.
And I each time frustrating to see that after mainline svn revision 1000
might be mainline revision 1020. It's very-very-very confusing. May be
only for me.
There is 2 things why I don't want to switch to svn (if I can do my own
choice): their strange tags implementation (their tags is the same as
branches, so what difference?) and their revisions numbers.
I also think that dotted revisions is not answer in this case, but it
looks very logical and nice.
I think bzr need to have a switch, a flag, probably in .bazaar.conf to
show revno to user or revid. And user can easily select what model is
more appropriate for him:
* decentralized (with revno)
* or distrubuted (with revid i.e. UUID)
> Comments?
-1 to make revno as in svn.
--
Alexander
^ permalink raw reply
* [PATCH] Don't use $author_name undefined when $from contains no /\s</.
From: Jim Meyering @ 2006-10-19 8:33 UTC (permalink / raw)
To: git
I noticed a case not handled in a recent patch.
Demonstrate it like this:
$ touch new-file
$ git-send-email --dry-run --from j --to k new-file 2>err
new-file
OK. Log says:
Date: Thu, 19 Oct 2006 10:26:24 +0200
Sendmail: /usr/sbin/sendmail
From: j
Subject:
Cc:
To: k
Result: OK
$ cat err
Use of uninitialized value in pattern match (m//) at /p/bin/git-send-email line 416.
Use of uninitialized value in concatenation (.) or string at /p/bin/git-send-email line 420.
Use of uninitialized value in concatenation (.) or string at /p/bin/git-send-email line 468.
There's a patch for the $author_name part below.
The example above shows that $subject may also be used uninitialized.
That should be easy to fix, too.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index b17d261..1c6d2cc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -412,7 +412,7 @@ sub send_message
}
my ($author_name) = ($from =~ /^(.*?)\s+</);
- if ($author_name =~ /\./ && $author_name !~ /^".*"$/) {
+ if ($author_name && $author_name =~ /\./ && $author_name !~ /^".*"$/) {
my ($name, $addr) = ($from =~ /^(.*?)(\s+<.*)/);
$from = "\"$name\"$addr";
}
--
1.4.3.g72bb
^ permalink raw reply related
* Re: VCS comparison table
From: Christian MICHON @ 2006-10-19 8:49 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <845b6e870610190002u420118b8ud634bb9594572c48@mail.gmail.com>
close to 200 post on bzr-git war!
is this the right place (git mailing list) to discuss about future
features of bzr ?
--
Christian
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-19 8:58 UTC (permalink / raw)
To: Christian MICHON; +Cc: bazaar-ng, git
In-Reply-To: <46d6db660610190149x32442596we4112cdd044185a@mail.gmail.com>
Christian MICHON wrote:
> close to 200 post on bzr-git war!
> is this the right place (git mailing list) to discuss about future
> features of bzr ?
>
Perhaps not, but the tone is friendly (mostly), the patience of the
bazaar people seems infinite and lots of people seem to be having fun
while at the same time learning a thing or two about a different SCM.
Best case scenario, both git and bazaar come out of the discussion as
better tools. If there would never be any cross-pollination, git
wouldn't have half the features it has today.
--
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: Matthew D. Fuller @ 2006-10-19 9:10 UTC (permalink / raw)
To: Carl Worth
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <87y7rdd47j.wl%cworth@cworth.org>
On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of
Carl Worth, and lo! it spake thus:
>
> But as you already said, it's often avoided specifically because it
> destroys locally-created revision numbers.
I think this has the causality backward. It's avoided because it
changes the ancestry of the branch in question, by rearranging the
left parents; this ties into Linus' assertion that all parents ought
to be treated equally, which I'm beginning to think is the base
lynchpin of this whole dissension.
Without a differentiation of the parents, there's no such creature as
a "mainline" on a branch, so it's hard to find anything to base revnos
on from the get-go; the whole discussion becomes meaningless and
incomprehensible then.
With the differentiation, numbering along the leftmost 'mainline'
makes sense, and fits the way people tend to work. "I did this, then
I did this, then I merged in Joe's stuff, then I did this", and the
numbering follows along that. And as long as it's the same branch,
those revnos will always be the same; I can't go back and add
something in between my first and second commits. THAT'S where revnos
are useful; referring to a point on given branch.
Certainly, they're of no (or extremely limited) use when referring to
_different_ branches. And when you change the arrangement of parents
on a branch, you create a different branch. That's why bzr (the
project, not the program) tends toward trunks that are merged into,
rather than ephemeral trunks that are merged from and then replaced
with the new trunk, and has its UI optimized by default for that case;
because the ordering of the parents IS considered important and to be
preserved. Ancestry changes aren't avoided because it would screw up
the revnos; the revnos don't get screwed up because the ancestry
changes are avoided for their OWN sake, and it's BECAUSE of that
pre-existing tendancy that the revnos could come into being in the
first place.
If you need to refer to a specific revision in a vacuum, a revno is
the *WRONG* tool for the job. Revnos exist to refer to points along a
branch. And in cases where there's a meaningful persistent branch, as
happens in most projects which have a trunk in some sense or another,
they can be the right tool for referring to points along that.
> 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).
That depends on what you mean by 'bias' (and for that matter, what you
mean by 'centralization'; I think that's being used in very different
ways here). If you don't care about the ancestry changes, you can go
ahead and change it around by merging and pushing like there's no
tomorrow, and it'll keep up just fine. Some attributes of it like the
revnos which assume you do care about the ancestry simply cease to be
of any applicability. That doesn't make it a useless feature, any
more than diff being inapplicable in a branch I'm using to store
binary files makes diff useless; it's just not one that's meaningful
in a given case.
bzr (the project) does care about the ordering of the parents, so it
doesn't do that. bzr (the tool) assumes that the majority of its
users will care, which is why it has revnos; because in the case where
you don't disturb the ancestry of given branches, revnos are very
useful in reference to that branch.
> 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.
I agree wholeheartedly. That's one of the reasons I'm using bzr, even
though 95% or better of what I do is very oriented around single,
central trees, after all 8-}
--
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: Matthieu Moy @ 2006-10-19 9:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian MICHON, bazaar-ng, git
In-Reply-To: <45373E27.3050209@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Perhaps not, but the tone is friendly (mostly), the patience of the
> bazaar people seems infinite and lots of people seem to be having fun
> while at the same time learning a thing or two about a different SCM.
> Best case scenario, both git and bazaar come out of the discussion as
> better tools. If there would never be any cross-pollination, git
> wouldn't have half the features it has today.
I second this.
I'm bzr user and occasionnal developper, and I learnt a lot about git
in the discussion. I hope I also could explain well some of the
features of bzr to some git guys, it's always interesting to
understand why other people do things on a different way, or why they
do it in the same way.
--
Matthieu
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Sean @ 2006-10-19 10:40 UTC (permalink / raw)
To: Alexander Belchenko; +Cc: git, bazaar-ng
In-Reply-To: <eh76np$trg$1@sea.gmane.org>
On Thu, 19 Oct 2006 09:46:32 +0300
Alexander Belchenko <bialix@ukr.net> wrote:
> You probably miss main idea of bzr bundles. It's not just the way to
> send via e-mail or other appropriate transport the part of repository.
> It primarily was designed to be human readable as usual diff (i.e.
> patch). It was designed to solve 2 thing simultaneously:
>
> - be informative for human as usual patch
> - be consistent for machine.
Petr already mentioned that the data currently shown in the email
text isn't really useful. But it's simple to make it an attachment
and show a combined diff instead.
Although that might just make the email bigger for not a lot of
gain. It's easy to use the git command line and gui tools to inspect
the bundle after importing it into your repository. And just as
easy to expunge the bundle afterward if it isn't up to grade.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-19 11:01 UTC (permalink / raw)
To: Charles Duffy; +Cc: git
In-Reply-To: <4536DBB1.6050701@spamcop.net>
Hi,
On Wed, 18 Oct 2006, Charles Duffy wrote:
> Johannes Schindelin wrote:
you neatly clipped the most important part of my email: I quoted you
saying that plugins can even change core behaviour!
> > So, the wonderful upside of plugins you described here are actually the
> > reason I will never, _never_ use bzr with plugins.
> >
>
> I presume that for this reason you will also never, _never_ use a
> non-mainline branch of git -- even if its actual code only touches UI
> enhancements or something similarly non-core
NO! The point was that I will not gladly run anything which could change
the core. If I know it touches only the UI, there is no problem.
If I get a shell script using git-core programs to do its job, I
_know_ that my repository will not be fscked afterwards.
And _that_ was the whole point of my email.
> And that you will never, _never_ use third-party wrappers because they
> might play LD_PRELOAD tricks. Or run any software with root privileges
> you haven't personally written. Or...
Most of it comes down to trust. And yes, you are correct, I will not run
git with some obscure module LD_PRELOADed that some guy from some planet
sent me.
You might have missed my argument being about the SCM, and not the
universe and all the rest.
> The claim that an extensibility mechanism should be rejected wholesale
> on account of being excessively powerful, on the other hand, is just
> silly.
Oh, but NO! An extensibility mechanism which allows for a fragile system
_is_ silly. Not my rejection of it.
Just take an example (illustrating that once again, one should not
attribute everything to malevolence...): I write a plugin for bzr. It does
really wonderful things, it even cooks you dinner.
Only that I happened to make a small mistake (if you followed some threads
on the git list, you'd know that small mistakes are a hobby of mine), and
by this mistake, your repository is ... gone. Small mistake, big
consequence. That is wrong with such a powerful system which caters for
developers, which are human after all.
Note that such a small mistake would be much more likely caught in git: if
it touches the core, plenty of eyes look at it.
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Charles Duffy @ 2006-10-19 11:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610191250400.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> I presume that for this reason you will also never, _never_ use a
>> non-mainline branch of git -- even if its actual code only touches UI
>> enhancements or something similarly non-core
>>
>
> NO! The point was that I will not gladly run anything which could change
> the core. If I know it touches only the UI, there is no problem.
>
If you're willing to look at the source of a branch to know that it
touches only the UI, why would you not be willing to look at the source
of a plugin to do the same thing?
> If I get a shell script using git-core programs to do its job, I
> _know_ that my repository will not be fscked afterwards.
>
> And _that_ was the whole point of my email.
>
It's a silly point. If you're willing to look at what your shell script
does and validate that it doesn't do LD_PRELOAD tricks or swap out git
core pieces, why wouldn't you be willing to accept a plugin after a
similar level of review, rather than stating outright that you would
*never* use them?
>> The claim that an extensibility mechanism should be rejected wholesale
>> on account of being excessively powerful, on the other hand, is just
>> silly.
>>
>
> Oh, but NO! An extensibility mechanism which allows for a fragile system
> _is_ silly. Not my rejection of it.
>
Shell scripts allow for a fragile system because they could include C
code snippets which they then compile and LD_PRELOAD. Sure, they "allow
for" a fragile system -- but the author has to go out of their way to
make it so. Similarly, folks writing bzr plugins need to take explicit
actions to monkeypatch existing code (as opposed to adding a new
transport/storage format/command/etc but leaving the old ones alone).
If you trust the author of your shell script not to build their own
LD_PRELOAD at runtime, why don't you trust the author of your bzr plugin
not to monkeypatch in replacements to core code if they say they aren't?
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-19 11:15 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <20061019091045.GV75501@over-yonder.net>
Matthew D. Fuller wrote:
> On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>> But as you already said, it's often avoided specifically because it
>> destroys locally-created revision numbers.
>
> I think this has the causality backward. It's avoided because it
> changes the ancestry of the branch in question, by rearranging the
> left parents; this ties into Linus' assertion that all parents ought
> to be treated equally, which I'm beginning to think is the base
> lynchpin of this whole dissension.
>
>
> Without a differentiation of the parents, there's no such creature as
> a "mainline" on a branch, so it's hard to find anything to base revnos
> on from the get-go; the whole discussion becomes meaningless and
> incomprehensible then.
>
> With the differentiation, numbering along the leftmost 'mainline'
You, and others, keep saying "leftmost". What on earth does left or
right have to do with anything? Or rather, how do you determine which
side anything at all is on?
> makes sense, and fits the way people tend to work. "I did this, then
> I did this, then I merged in Joe's stuff, then I did this", and the
> numbering follows along that. And as long as it's the same branch,
> those revnos will always be the same; I can't go back and add
> something in between my first and second commits. THAT'S where revnos
> are useful; referring to a point on given branch.
>
So long as the given branch is, in git-speak, "master"? I think I'm
starting to see how this would work, but I still fail to see how you can
then come up with revnos such as 2343.1.14.7.19, since the only ones
that seem to actually make any sense are the ones that track the
strictly linear development.
In git, this can be accomplished by auto-tagging each update of any
branch with a tag named numerically and incrementally, although no-one
really bothers with it.
Let's say you have the following graph, where A is the root commit, B
introduces the base for a couple of new features that three separate
coders start to work on in their own repositories. The feature started
on in D is logically coded as a two-stage change. F fixes a bug
introduced in D. I is the result of an octopus merge of all three
branches, where the three features are implemented and all bugs are
fixed (this is btw by far the most common pattern we have in our repos
here at work).
A
|
B
/|\
C | D
| | |\
| | E F
| | |/
| | G
| H /
\|/
I
Now a couple of questions arise.
- How do I do to get to C, D, E, F, G and H?
- When these get merged, which one will be considered the "left" parent,
and why?
>
>> 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).
>
> That depends on what you mean by 'bias' (and for that matter, what you
> mean by 'centralization'; I think that's being used in very different
> ways here). If you don't care about the ancestry changes, you can go
> ahead and change it around by merging and pushing like there's no
> tomorrow, and it'll keep up just fine. Some attributes of it like the
> revnos which assume you do care about the ancestry simply cease to be
> of any applicability.
How deep will I have to dig to get the immutable revids instead?
> That doesn't make it a useless feature, any
> more than diff being inapplicable in a branch I'm using to store
> binary files makes diff useless; it's just not one that's meaningful
> in a given case.
>
Binary diffs work just fine, thank you very much ;-)
> bzr (the project) does care about the ordering of the parents, so it
> doesn't do that. bzr (the tool) assumes that the majority of its
> users will care, which is why it has revnos; because in the case where
> you don't disturb the ancestry of given branches, revnos are very
> useful in reference to that branch.
>
>
>> 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.
>
> I agree wholeheartedly. That's one of the reasons I'm using bzr, even
> though 95% or better of what I do is very oriented around single,
> central trees, after all 8-}
>
I'm sure it's supported. The question is whether or not bazaar makes it
easy for those developers to exchange valuable information (revids,
since their revnos will be mixed up) so they can communicate detailed
info about "commit X introduced a bug in foo_diddle(). I fixed it in
commit Y, so if you merge it we can release". If revids are always
printed anyways, I see even less need for revnos. If it's hard to get
the revids I wouldn't consider the truly distributed workflow supported
any more than I consider CVS file rename support á la "just hand-edit
the ,v-files" to actually work.
--
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: Johannes Schindelin @ 2006-10-19 11:24 UTC (permalink / raw)
To: Charles Duffy; +Cc: git
In-Reply-To: <45375D16.90204@spamcop.net>
Hi,
On Thu, 19 Oct 2006, Charles Duffy wrote:
> Johannes Schindelin wrote:
> > > I presume that for this reason you will also never, _never_ use a
> > > non-mainline branch of git -- even if its actual code only touches UI
> > > enhancements or something similarly non-core
> > >
> >
> > NO! The point was that I will not gladly run anything which could change the
> > core. If I know it touches only the UI, there is no problem.
> >
>
> If you're willing to look at the source of a branch to know that it
> touches only the UI, why would you not be willing to look at the source
> of a plugin to do the same thing?
That is why I said I'd be gladly using a shell-script using git-core
programs. It is typically no more than 20 lines, and I can review that
quite easily.
> Shell scripts allow for a fragile system because they could include C code
> snippets which they then compile and LD_PRELOAD.
Well, I do not expect people to misbehave. You do not compile a nasty
C-program from a shell script _by mistake_.
I also expect people not to constantly miss my point. It could be that I
am not as proficient in the English language as I thought. In that case,
I'll better shut up.
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Karl Hasselström @ 2006-10-19 11:27 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061019091045.GV75501@over-yonder.net>
On 2006-10-19 04:10:45 -0500, Matthew D. Fuller wrote:
> I think this has the causality backward. It's avoided because it
> changes the ancestry of the branch in question, by rearranging the
> left parents; this ties into Linus' assertion that all parents ought
> to be treated equally, which I'm beginning to think is the base
> lynchpin of this whole dissension.
Yes, it seems you have found the needle. :-) In git, history is a DAG;
a commit has a _set_ of parents, so by definition they are not
ordered. This has a number of consequences. For example, you can't
really answer the question "Which branch was this commit on?". All you
can say is that "This commit is reachable from (and therefore part of)
branches X, Y, and Z."
In all other SCMs I have seen, a "branch" is conceptually an ordered
series of commits (some of which may be merges). In git, a "branch" is
a pointer to a commit, period. The commit knows its set of parents, so
all its history is there, but there is fundamentally no way to tell
which branch a commit was "on" when it was created.
This is an important point; it means there is no concept of "my" or
"your" branch. Every participant is adding commits to the same DAG,
and may at any point decide to share her additions with someone else,
or keep them private forever. And because "branches" don't really
exist, every commit really is created equal.
Really, every commit. Not even the initial commit of a project is
special -- it's just a commit with an empty parent set. And, it's
perfectly possible to make a (merge) commit whose parents belong to
previously disconnected parts of the DAG. This of course means that
it's not even possible to differentiate commits based on which project
they're part of, since one can create a commit whose parents belong to
different projects. All commits are _really_ born equal! There's just
one great DAG of all git commits that could possibly exist. (This has
been done in git's own history; the graphical viewer gitk was
originally a separate project, with its own initial commit, but that
initial commit is now reachable from all commits currently being made
to git -- that is, it has been merged.)
This structure of things may seem complex, since it's different, but
mathematically it's quite simple, and that's what counts in the end if
you want to do nontrivial things.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: VCS comparison table
From: Charles Duffy @ 2006-10-19 11:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610191321090.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> Shell scripts allow for a fragile system because they could include C code
>> snippets which they then compile and LD_PRELOAD.
>>
>
> Well, I do not expect people to misbehave. You do not compile a nasty
> C-program from a shell script _by mistake_.
>
You also don't replace bzrlib functionality (in your terms, plumbing) in
a plugin by mistake.
> I also expect people not to constantly miss my point.
I think your point is predicated on a misunderstanding of how plugins work.
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-19 11:37 UTC (permalink / raw)
To: Erik B?gfors
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <845b6e870610190002u420118b8ud634bb9594572c48@mail.gmail.com>
Dear diary, on Thu, Oct 19, 2006 at 09:02:16AM CEST, I got a letter
where Erik B?gfors <zindar@gmail.com> said that...
> bzr's use of revision numbers, doesn't mean it hasn't got unique
> revision identifiers, and I can't see any reason why it couldn't be
> used in the same way as git.
There is perhaps no "technical" reason, but it's also what the user
interface is designed around - most probably, using UUIDs instead of
revnos would be a lot less convenient for bzr people because you
probably primarily show revnos everywhere and UUIDs only in few special
places and/or when asked specifically through a command (correct me if
I'm wrong). Also, do you support "UUID autocompletion" so that you can
type just the unique UUID prefix instead of the whole thing?
> Both are excellent tools, and since git
> is more specialized (built to support the exact workflow used in
> kernel development), it's more suited for that exact use.
>
> bzr tries to take a broader view, for example, it does support a
> centralized workflow if you want one. Most people don't, but a few
> might. Because of this, it probably fits the kernel development less
> good than git. That's fine I think! I happens to fit my workflow
> better than git does :)
I think they are in fact just as flexible (+-epsilon). Git can support
centralized workflow as well - you have some central repository
somewhere and all the developers clone it, then pull from it and push to
it in basically the same way they would use CVS. And it is perhaps
currently even more used in practice than the "single-man" workflow
nowadays, as more project are using Git.
--
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: VCS comparison table
From: Petr Baudis @ 2006-10-19 11:46 UTC (permalink / raw)
To: Karl Hasselström
Cc: Matthew D. Fuller, Carl Worth, Aaron Bentley, Linus Torvalds,
Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061019112759.GA31066@diana.vm.bytemark.co.uk>
Dear diary, on Thu, Oct 19, 2006 at 01:27:59PM CEST, I got a letter
where Karl Hasselström <kha@treskal.com> said that...
> Really, every commit. Not even the initial commit of a project is
> special -- it's just a commit with an empty parent set. And, it's
> perfectly possible to make a (merge) commit whose parents belong to
> previously disconnected parts of the DAG. This of course means that
> it's not even possible to differentiate commits based on which project
> they're part of, since one can create a commit whose parents belong to
> different projects.
FWIW, IIRC the Git project has about 6 initial commits. :-)
BTW, a popular source of horrification in other VCSes are Git's octopus
merges. (A popular source of horrification in Git are kernel developers
doing octopus merges of 40 branches at once.) Does Bazaar support those?
(I can't really say it's a defect if it doesn't...)
(An octopus merge is a merge of more than two branches at once, in a
single commit.)
--
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