* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:40 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <45373E27.3050209@op5.se>
Andreas Ericsson wrote:
> 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.
And it certainly helps to explain user-visible differences between
Bazaar-NG and GIT; I'd like to put ComparisonWithBazaarNG page on
GitWiki (http://git.or.cz/gitwiki/) some time soon, in addition
to ComparisonWithMercurial I meant to add from some time (stemming
from discussion on #revctrl list on FreeNode), and in addition
to existing GitSvnComparison page on GitWiki).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-20 10:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <200610201151.13199.jnareb@gmail.com>
On 20/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> James Henstridge wrote:
> > On 20/10/06, Carl Worth <cworth@cworth.org> wrote:
> >> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:
>
> >>> Additionally, the new mainline can keep a mirror of the
> >>> abandoned mainline in its repository, because there are virtually no
> >>> additional storage requirements to doing so.
> >>
> >> And this part I don't understand. I can understand the mainline
> >> storing the revisions, but I don't understand how it could make them
> >> accessible by the published revision numbers of the "abandoned"
> >> line. And that's the problem.
> >
> > With this sort of setup, I would publish my branches in a directory
> > tree like this:
> >
> > /repo
> > /branch1
> > /branch2
> >
> > I make "/repo" a Bazaar repository so that it stores the revision data
> > for all branches contained in the directory (the tree contents,
> > revision meta data, etc).
>
> And here we have a feature which is as far as I see unique to git,
> namely to have persistent branches with _separate namespace_. It means
> that we can have hierarchical branch names (including names like
> "remotes/<remotename>/<branch of remote>", or "jc/diff"), and we don't
> have to guess where repository name ends and branch name begins.
With the above layout, I would just type:
bzr branch http://server/repo/branch1
This command behaves identically whether the repository data is in
/repo or in /repo/branch1. Someone pulling from the branch doesn't
have to care what the repository structure is. Having a separate
namespace for branch names only really makes sense if the user needs
to care about it.
As for heirarchical names, there is nothing stopping you from using
deaper directory structures with Bazaar too. Bazaar just checks each
successive parent directory til it finds a repository for the branch.
> The idea of "branches (and tags) as directories" was if I understand
> it correctly introduced by Subversion, and from what can be seen from
> troubles with git-svn (stemming from the fact that division between
> project name and branch name is the matter of _convention_) at least
> slightly brain-damaged.
I think you are a bit confused about how Bazaar works here. A Bazaar
repository is a store of trees and revision metadata. A Bazaar branch
is just a pointer to a head revision in the repository. As you can
probably guess, the data for the branch is a lot smaller than the data
for the repository.
You can store the repository and branch in the same directory to get a
standalone branch. The layout I described above has a repository in a
parent directory, shared by multiple branches.
If you are comparing Subversion and Bazaar, a Bazaar branch shares
more properties with a full Subversion repository rather than a
Subversion branch.
> > The "/repo/branch1" essentially just contains a list of mainline
> > revision IDs that identify the branch. This could probably be just
> > store the head revision ID, but there are some optimisations that make
> > use of the linear history here.
> >
> > If the ancestry of "/repo/branch2" is a subset of branch1 (as it might
> > be if the in the case of forked then merged projects), then all its
> > revision data will already be in the repository when branch1 was
> > imported. The only cost of keeping the branch around (and publishing
> > it) is the list of revision IDs in its mainline history.
> >
> > For similar reasons, the cost of publishing 20 related Bazaar branches
> > on my web server is generally not 20 times the cost of publishing a
> > single branch.
> >
> > I understand that you get similar benefits by a GIT repository with
> > multiple head revisions.
>
> You can get similar benefits by a GIT repository with shared object
> database using alternates mechanism. And that is usually preferred
> over storing unrelated branches, i.e. branches pointing to disconnected
> DAG (separate trees in BK terminology) of revision, if that you mean by
> multiple head revisions (because in GIT there is no notion of "mainline"
> branch, only of current (HEAD) branch).
I may have got the git terminology wrong. I was trying to draw
parallels between the .git/refs/... files in a git repository and the
way multiple branches can be stored in a Bazaar repository.
I am not claiming that you'll get bandwidth or disk space benefits for
storing unrelated branches in a single Bazaar repository. But if the
branches are related, then there will be space savings (which is what
the great-grandparent post was asking about).
> >>>> But for these communications, revision numbers will not provide
> >>>> historically stable values that can be used.
> >>>
> >>> They certainly can.
> >>>
> >>> The coder says "I've put up a branch at http://example.com/bzr/feature.
> >>> In revision 5, I started work on feature A. I finished work in
> >>> revision 6. But then I had to fix a related bug in revision 7."
> >>
> >> "I've put this branch up" isn't historically stable...
> >
> > With the repository structure mentioned above, the cost of publishing
> > multiple branches is quite low. If I continue to work on the project,
> > then there is no particular bandwidth or disk space reasons for me to
> > cut off access to my old branches.
> >
> > For similar reasons, it doesn't cost me much to mirror other people's
> > related branches if I really care about them.
>
> But the revision number in this case _changes_. It is from 7 to
> branch:7 but still it changes somewhat.
A revision number is only has meaning in the context of a branch. If
I mirror a branch, the revision numbers in the context of each will
refer to the same revision IDs.
I am not sure what sort of distinction you are trying to draw.
> >> The naming in git really is beautiful and beautifully simple.
> >
> > I don't think anyone is saying that universally unique names are bad.
> > But I also don't see a problem with using shorter names that only have
> > meaning in a local scope.
> >
> > I've noticed some people using abbreviated SHA1 sums with GIT. Isn't
> > that also a case of trading potential global uniqueness for
> > convenience when working in a local scope?
>
> Emphasisis on _potential_. SHA1 id abbreviated to 6 characters might
> be not unique in larger project, but for example the chance that
> SHA1 id abbreviated to 7 or 8 characters is not unique is really low.
My point was that by shortening the IDs with GIT, you are trading
global uniqueness (i.e. the identifier may clash with one found in a
different context) for the convenience of shorter identifiers.
Provided you know that the tradeoff is being made, it isn't generally
much of a problem. I agree that the ability to pick how much of a
tradeoff is made by altering the length of the identifier is a nice
property of GIT.
> Yet another analogy:
>
> SHA1 identifiers of commits (and not only commits) can be compared
> to Message-Ids of Usenet messages, while revision numbers can be compared
> to Xref number of Usenet message which if I understand correctly is unique
> only for given news server. But Message-Ids cannot be shortened
> meaningfully like SHA1 ids can; newertheless they are used in communication
> without any problems. Even if namespace is not simple ;-)
I can't say I ever used usenet much, so can't comment too much. But
from your description, a (server, xref) tuple could be used to look up
the unique identifier in a similar way to how you can do so in Bazaar
with a (branch_url, revno) tuple.
James.
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-20 10:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Aaron Bentley, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <200610201157.22348.jnareb@gmail.com>
On 20/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > What's nice is being able see the revno 753 and knowing that "diff -r
> > 752..753" will show the changes it introduced. Checking the revo on a
> > branch mirror and knowing how out-of-date it is.
>
> Huh? If you want what changes have been introduced by commit
> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do
>
> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143
>
> (or better "git show" instead of "git diff" or "git diff-tree").
> If you give only one commit (only one revision) git automatically
> gives diff to its parent(s).
If a revision has multiple parents, what does it diff against in this
case? Do you get one diff against each parent revision?
James.
^ permalink raw reply
* Re: VCS comparison table
From: Andy Whitcroft @ 2006-10-20 10:45 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jakub Narebski, Aaron Bentley, Andreas Ericsson, Linus Torvalds,
Carl Worth, bazaar-ng, git
In-Reply-To: <vpqwt6v1f11.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Huh? If you want what changes have been introduced by commit
>> c3424aebbf722c1f204931bf1c843e8a103ee143, you just do
>>
>> # git diff c3424aebbf722c1f204931bf1c843e8a103ee143
>
> How does git chose which ancestor to use if this revision has more
> than one in this case?
Well if there is more than one parent, then there are more than one
diff. For instance this is a merge commit which I asked to 'see'.
This gets shown in the combined diff format, showing the results of the
conflict resolution.
diff --cc this
index fbbafbf,10c8337..43b7af0
--- a/this
+++ b/this
@@@ -1,3 -1,3 +1,4 @@@
1
+ 2a
+2b
3
If you want to know each individual diff in a more 'standard' form you
can ask about the parents specifically.
apw@pinky$ git diff HEAD^1..
diff --git a/this b/this
index fbbafbf..43b7af0 100644
--- a/this
+++ b/this
@@ -1,3 +1,4 @@
1
+2a
2b
3
apw@pinky$ git diff HEAD^2..
diff --git a/bar b/bar
new file mode 100644
index 0000000..8dc5f23
--- /dev/null
+++ b/bar
@@ -0,0 +1 @@
+this that other
diff --git a/this b/this
index 10c8337..43b7af0 100644
--- a/this
+++ b/this
@@ -1,3 +1,4 @@
1
2a
+2b
3
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:44 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <45379A02.1010105@utoronto.ca>
Aaron Bentley wrote:
>> It would be nice if the SCM tools included rss feeds for communicating zip
>> patch bundles.
>
> The bzr "webserve" plugin provides rss feeds.
Git "gitweb" (in git.git repo from some time) web interface provides OPML
and RSS feeds.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vac3sru9a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> The other big difference is being able to do merges in seconds. The
>> biggest cost of doing a big merge these days seems to literally be
>> generating the diffstat of the changes at the end (which is purely a UI
>> issue, but one that I find so important that I'll happily take the extra
>> few seconds for that, even if it sometimes effectively doubles the
>> overhead).
>
> An interesting effect on this is when people have a column for
> merge performance in a SCM comparison table, they would include
> time to run the diffstat as part of the time spent for merging
> when they fill in the number for git, but not for any other SCM.
So if you want to compare merge performance with other SCM, you should
either add time to run diffstat for other SCM, or substract time to
run "git diff-tree --stat".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 11:00 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Linus Torvalds, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45382120.9060702@utoronto.ca>
Aaron Bentley wrote:
> Bazaar encourages you to stick lots and lots of branches in your
> repository. They don't even have to be related. For example, my repo
> contains branches of bzr, bzrtools, Meld, and BazaarInspect.
GIT encourages you to use separate repositories for unrelated projects.
And alternates mechanism for related projects (like different Linux
kernel repositories: Linus, stable, etc.).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 10:53 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <453803E6.2060309@utoronto.ca>
Aaron Bentley wrote:
>>> And I personally have been developing a bugtracker that is
>>> distributed in the same way bzr is; it stores bug data in the source
>>> tree of a project, so that bug activities follow branches around.
>>
>> That kind of thing sounds very useful. As I've been talking about
>> "numbers" here in bug trackers and mailing lists, it should be obvious
>> that I consider the information stored in such systems an important
>> part of the history of a code project. So it would be nice if all of
>> that history were stored in an equally reliable system in some way.
>
> If you're interested, it's called "Bugs Everywhere" and it's available here:
> http://panoramicfeedback.com/opensource/
>
> New VCS backends are welcome :-D
While SCM can (and should be usually) distributed, I think that bugtracker
has to be centralized.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 11:09 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610201034170.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 20 Oct 2006, Lachlan Patrick wrote:
>
>> How does git disambiguate SHA1 hash collisions?
>
> It does not. You can fully expect the universe to go down before that
> happens.
Or you can compile git with COLLISION_CHECK
>From Makefile:
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 11:24 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <vpq1wp42rd4.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Then, one other difference is in the UI. bzr shows you commits in a
> kind of hierarchical maner, like (fictive example, that's not the real
> exact format).
>
> $ bzr log
> commiter: upstream@maintainer.com
> message:
> merged the work on a feature
> ------
> commiter: contributor@site.com
> message:
> prepared for feature X
> ------
> commiter: contributor@site.com
> message:
> implemented feature X
> ------
> commiter: contributor@site.com
> message:
> added testcase for feature X
> ------
> commiter: upstream@maintainer.com
> message:
> something else
>
> No big difference in the model either, but it probably reveals a
> different vision of what "history" means.
We have in GIT git-show-branch command for that (although it
has quite strange UI, and shows only title of commit), we
can do "git log | git name-rev --stdin", or better use graphical
history viewers like gitk (Tcl/Tk) or qgit (Qt). Graphical history
viewers are a must with more complicated history.
Bazaar-NG has bzr-gtk.
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-20 11:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ehaapb$5t7$3@sea.gmane.org>
Hi,
On Fri, 20 Oct 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Fri, 20 Oct 2006, Lachlan Patrick wrote:
> >
> >> How does git disambiguate SHA1 hash collisions?
> >
> > It does not. You can fully expect the universe to go down before that
> > happens.
>
> Or you can compile git with COLLISION_CHECK
>
> >From Makefile:
> # Define COLLISION_CHECK below if you believe that SHA1's
> # 1461501637330902918203684832716283019655932542976 hashes do not give you
> # sufficient guarantee that no collisions between objects will ever happen.
You can document your disbelief.
But it does not change a thing. Since v0.99~653, we do not have any
collision check, even if compiled with COLLISION_CHECK.
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 11:38 UTC (permalink / raw)
To: git
In-Reply-To: <453761D5.80306@spamcop.net>
Charles Duffy wrote:
> 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.
Perhaps the cause for not having plugins in GIT (besides the fact that
it follows OSS + Unix guidelines) is that git is not libified, yet. It
is "scriptified", i.e. it has many helper programs, and has options for
pipelining that it is really easy to use in scripts (Cogito, pg, StGit),
but the libification effort is [only] ongoing.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] Remove dead code after direct graph drawing
From: Marco Costalba @ 2006-10-20 11:49 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200610200111.26259.Josef.Weidendorfer@gmx.de>
On 10/20/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Thursday 19 October 2006 16:13, Josef Weidendorfer wrote:
> > Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> Hmmm...
>
> Is the git mailing list the right place for qgit patches?
Yes, I don't see other competitors ;-)
> Probably, I should have prefixed them with "qgit:" ...
>
No problem, I should found them anyway and I don't need to manually
remove "qgit" prefix before to apply to repository.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 11:50 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Andreas Ericsson, Matthew D. Fuller, bazaar-ng,
Linus Torvalds, Carl Worth, git
In-Reply-To: <20061019123349.GE20017@pasky.or.cz>
I have lost somewhere among many emails in this thread the email I
wanted to reply to, the one mentioning for the first time the lack of
parents ordering in GIT, but this one should do.
Petr Baudis wrote:
> The lack of parents ordering in Git is directly connected with
> fast-forwarding.
There are exactly _two_ places where Git treats first parent specially
(correct me if I'm wrong).
First, <commit-ish>^ is shortcut for <commit-ish>^1, i.e. for first
parent of commit. <commit-ish>~<n> is shortcut for <commit-ish>^^...^
(n-times '^'), which means that <commit-ish>~<n> is n-th parent in
1st-parent lineage of <commit-ish>. But you can always use names
like for example next~12^2^^2~2.
Second, git-diff with only one <commit-ish> generates diff to first
parent. But you can always use '-c' or '-cc' combined diff format
or '-m' with default diff format to compare to _all_ parents.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 12:01 UTC (permalink / raw)
To: James Henstridge
Cc: Aaron Bentley, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <a7e835d40610200345o2ad83bb7k6dfc29867498971c@mail.gmail.com>
James Henstridge wrote:
> On 20/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > > What's nice is being able see the revno 753 and knowing that "diff -r
> > > 752..753" will show the changes it introduced. Checking the revo on a
> > > branch mirror and knowing how out-of-date it is.
> >
> > Huh? If you want what changes have been introduced by commit
> > c3424aebbf722c1f204931bf1c843e8a103ee143, you just do
> >
> > # git diff c3424aebbf722c1f204931bf1c843e8a103ee143
> >
> > (or better "git show" instead of "git diff" or "git diff-tree").
> > If you give only one commit (only one revision) git automatically
> > gives diff to its parent(s).
>
> If a revision has multiple parents, what does it diff against in this
> case? Do you get one diff against each parent revision?
If revision has multiple parents (is merge commit), git-diff
(which is used by git-show) does not show differences (unless you
give two revisions in git-diff case).
You can either use '-m' option to show differences from all its
parents, or '-c'/'--cc' to show combined diff ('--cc' shows more
compact diff).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 12:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610201335420.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 20 Oct 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Fri, 20 Oct 2006, Lachlan Patrick wrote:
>>>
>>>> How does git disambiguate SHA1 hash collisions?
>>>
>>> It does not. You can fully expect the universe to go down before that
>>> happens.
>>
>> Or you can compile git with COLLISION_CHECK
>>
>> From Makefile:
>> # Define COLLISION_CHECK below if you believe that SHA1's
>> # 1461501637330902918203684832716283019655932542976 hashes do not give you
>> # sufficient guarantee that no collisions between objects will ever happen.
>
> You can document your disbelief.
>
> But it does not change a thing. Since v0.99~653, we do not have any
> collision check, even if compiled with COLLISION_CHECK.
So why it is left in Makefile? Does defining this change a thing
or not (in which case this section should be removed)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] Simpler way to draw commit graph
From: Marco Costalba @ 2006-10-20 11:46 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200610191613.31119.Josef.Weidendorfer@gmx.de>
On 10/19/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> For drawing the commit graph, previously every item got a
> pixmap created and set with item->setPixmap(), which is
> drawn by the standard implementation of QListView::paintCell().
>
> Instead, this commit implements drawing of the graph
> directly in our own ListView::paintCell(). This gets rid of
> a lot of complex code to reset the pixmap of invisible items
> which was needed in large repositories before to not allocate
> huge amounts of memory.
>
> As we directly draw only the visible cells, it has no
> influence on performance (especially, as we got rid of
> pixmaps of invisible items before, and most often had
> to draw the graph anyway).
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
> ---
>
It looks sane. Thanks, I will apply this week-end.
>
> In order to solve this, I looked at the code, and do not understand
> one thing: Why are you creating pixmaps for the graph, and do
> draw directly in paintCell() ?
>
The code to create pixmaps is older then the one to remove not visible pixmaps.
When I added the latter I missed the opportunity to reformat exsisting code.
> This patch does exactly this, and the next one does cleanup
> of code which is not used afterwards.
>
> If you like, I can comeup with a patch to directly draw the lines
> which would get rid of the original problem.
>
Yes, please.
Thanks
Marco
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Horst H. von Brand @ 2006-10-20 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vejt5xjt9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> The latest feature release GIT 1.4.3 is available at the usual
> places:
[...]
> rename builtin-cat-file.c => builtin-cat-file.c (0%)
Huh?!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-20 12:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <eha9rq$5t7$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> If you're interested, it's called "Bugs Everywhere" and it's available here:
>> http://panoramicfeedback.com/opensource/
>>
>> New VCS backends are welcome :-D
>
> While SCM can (and should be usually) distributed, I think that bugtracker
> has to be centralized.
Well, indeed, I think bug _reporting_ should be somehow centralized,
while bug _fixing_ can be decentralized: You fix a bug, you mark it as
fixed, and then the main branch gets the information that the bug is
fixed when the bugfix is merged.
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-20 12:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610201403.53664.jnareb@gmail.com>
Hi,
On Fri, 20 Oct 2006, Jakub Narebski wrote:
> > But it does not change a thing. Since v0.99~653, we do not have any
> > collision check, even if compiled with COLLISION_CHECK.
>
> So why it is left in Makefile? Does defining this change a thing
> or not (in which case this section should be removed)?
It does not. The relevant parts in the code read like this:
sha1_filc.c:1442
/* FIXME!!! Collision check here ? */
sha1_file.c:1541
/*
* FIXME!!! We might do collision checking here, but we'd
* need to uncompress the old file and check it. Later.
*/
It was hoped that the people who actually care would implement that
functionality. (Note that in an earlier version, the check was
implemented, but would have to be different these days: pack files did not
exist then).
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 13:17 UTC (permalink / raw)
To: James Henstridge
Cc: bazaar-ng, Linus Torvalds, Carl Worth, Andreas Ericsson, git
In-Reply-To: <a7e835d40610200342ibc56fd9t542a60230ebe0020@mail.gmail.com>
James Henstridge wrote:
> On 20/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> James Henstridge wrote:
>>> On 20/10/06, Carl Worth <cworth@cworth.org> wrote:
>>>> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:
>>> With this sort of setup, I would publish my branches in a directory
>>> tree like this:
>>>
>>> /repo
>>> /branch1
>>> /branch2
>>>
>>> I make "/repo" a Bazaar repository so that it stores the revision data
>>> for all branches contained in the directory (the tree contents,
>>> revision meta data, etc).
>>
>> And here we have a feature which is as far as I see unique to git,
>> namely to have persistent branches with _separate namespace_. It means
>> that we can have hierarchical branch names (including names like
>> "remotes/<remotename>/<branch of remote>", or "jc/diff"), and we don't
>> have to guess where repository name ends and branch name begins.
>
> With the above layout, I would just type:
> bzr branch http://server/repo/branch1
With Cogito (you can think of it either as alternate Git UI, or as SCM
built on top of Git) you would use
$ cg clone http://server/repo#branch
for example
$ cg clone git://git.kernel.org/pub/scm/git/git.git#next
to clone _single_ branch (in bzr terminology, "heavy checkout" of branch).
But you can also clone _whole_ repository, _all_ published branches with
$ cg clone git://git.kernel.org/pub/scm/git/git.git
With core Git it is the same, but we don't have the above shortcut
for checking only one branch; branches to checkout are in separate
arguments to git-clone.
In bzr it seems that you cannot distinguish (at least not only
from URL) where repository ends and branch begins.
*Sidenote:* In current version of gitweb you can get file
in given repository in given branch using the following
notation:
http://path/to/gitweb.cgi/repo/sitory/branch/name:file/name
gitweb can detect where branch name ends and repository name
begins; usually (by convention) "bare" git repositories uses
<project>.git name, "clothed" git repositories uses
<project>/.git
See also below.
> This command behaves identically whether the repository data is in
> /repo or in /repo/branch1. Someone pulling from the branch doesn't
> have to care what the repository structure is. Having a separate
> namespace for branch names only really makes sense if the user needs
> to care about it.
>
> As for hierarchical names, there is nothing stopping you from using
> deaper directory structures with Bazaar too. Bazaar just checks each
> successive parent directory til it finds a repository for the branch.
>
>> The idea of "branches (and tags) as directories" was if I understand
>> it correctly introduced by Subversion, and from what can be seen from
>> troubles with git-svn (stemming from the fact that division between
>> project name and branch name is the matter of _convention_) at least
>> slightly brain-damaged.
>
> I think you are a bit confused about how Bazaar works here. A Bazaar
> repository is a store of trees and revision metadata. A Bazaar branch
> is just a pointer to a head revision in the repository. As you can
> probably guess, the data for the branch is a lot smaller than the data
> for the repository.
>
> You can store the repository and branch in the same directory to get a
> standalone branch. The layout I described above has a repository in a
> parent directory, shared by multiple branches.
>
> If you are comparing Subversion and Bazaar, a Bazaar branch shares
> more properties with a full Subversion repository rather than a
> Subversion branch.
Oh, that explained yet another difference between Bazaar-NG (and other
SCM which uses similar model) and Git.
In Git branch is just a pointer to head (top) commit (hence they are stored
under .git/refs/heads/) in given line of development. Git also stores
information (in .git/HEAD) about which branch we are currently on, which
means on which branch git puts new commits. Nothing more (well, there
can be log of changes to head in .git/logs/refs/heads/ but that is optional
and purely local information). In Bazaar-NG you have to store (if I
understand it correctly) mapping from revnos to revisions.
By default (it means for example default behavior of git-clone, if we don't
use --bare option) git repository is _embedded_ in working area. We have
.git/
.git/HEAD
...
.git/refs/heads/
...
<working area files, e.g.>
So repo/branch wouldn't work, because 'branch' would conflict with working
area files. GIT doesn't follow the CVS model of separate storage area
(CVSROOT) and having only pointer to said area (files in CVS/
subdirectories) in working directory.
In GIT to work on some repository you don't (like from what I understand
in Bazaar-NG) "checkout" some branch (which would automatically copy some
data in case of "heavy checkout" or just save some pointer to repository
in "lightweight checkout" case). You clone whole repository; well you can
select which branches to clone. "Checkout" in GIT terminology means to
populate working area with given version (and change in repository which
branch is current, usually).
How checked out working area looks like in Bazaar-NG?
[...]
>>> For similar reasons, the cost of publishing 20 related Bazaar branches
>>> on my web server is generally not 20 times the cost of publishing a
>>> single branch.
>>>
>>> I understand that you get similar benefits by a GIT repository with
>>> multiple head revisions.
>>
>> You can get similar benefits by a GIT repository with shared object
>> database using alternates mechanism. And that is usually preferred
>> over storing unrelated branches, i.e. branches pointing to disconnected
>> DAG (separate trees in BK terminology) of revision, if that you mean by
>> multiple head revisions (because in GIT there is no notion of "mainline"
>> branch, only of current (HEAD) branch).
>
> I may have got the git terminology wrong. I was trying to draw
> parallels between the .git/refs/... files in a git repository and the
> way multiple branches can be stored in a Bazaar repository.
Yes, but using Git that way has serious disadvantages. For example
there is only one current branch pointer and only one index (dircache)
per git repository.
> I am not claiming that you'll get bandwidth or disk space benefits for
> storing unrelated branches in a single Bazaar repository. But if the
> branches are related, then there will be space savings (which is what
> the great-grandparent post was asking about).
So it is way better to use one repository per project, and use alternates
mechanism to save space.
But I agree that saving "old fork" info as separate branch doesn't lead
to that much inefficiency as might be thought.
But after saving "old fork" as a branch revno based revision identifiers
change from http://old.host/old/repo:127 to http://host/repo/old.fork:127
That is maybe minimal change, but this is change!
P.S. In two separate git repositories, even if they exchange information
with each other, the branch names can be different.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 13:20 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpqslhjyxlz.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> >> If you're interested, it's called "Bugs Everywhere" and it's available here:
> >> http://panoramicfeedback.com/opensource/
> >>
> >> New VCS backends are welcome :-D
> >
> > While SCM can (and should be usually) distributed, I think that bugtracker
> > has to be centralized.
>
> Well, indeed, I think bug _reporting_ should be somehow centralized,
> while bug _fixing_ can be decentralized: You fix a bug, you mark it as
> fixed, and then the main branch gets the information that the bug is
> fixed when the bugfix is merged.
But you don't need much infrastructure for branch fixing. Fix it in
repository, and write bug number (you have to have centralized bugtracker
for numbers) or bug identifier in commit message. You write (or post-commit
hook writes) in bugtracker that bug was fixed in commit <commit-id>.
You tell mainline to pull from you. That's all.
^ permalink raw reply
* Re: VCS comparison table
From: Horst H. von Brand @ 2006-10-20 13:22 UTC (permalink / raw)
To: Aaron Bentley
Cc: Linus Torvalds, Andreas Ericsson, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4536EC93.9050305@utoronto.ca>
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Linus Torvalds wrote:
[...]
> > The "main trunk matters" mentality (which has deep roots in CVS - don't
> > get me wrong, I don't think you're the first one to do this) is
> > fundamentally antithetical to truly distributed system, because it
> > basically assumes that some maintainer is "more important" than others.
> Linus, if you got hit by a bus, it would still be a shock, and it would
> still take time for the Linux world to recover. Your insights and
> talent, both technical and social, make you the most important kernel
> developer. And it stays that way because you deserve it. Projects with
> good leadership don't fork, or if they do, the fork withers and dies
> pretty quickly.
So? It makes no sense to me to cater only to "successful projects"... most
projects /aren't/ successful ;-)
> It is fine to say all branches are equal from a technical perspective.
> From a social perspective, it's just not true.
Yes, but what matters here is the principle... if branches aren't equal, it
makes some things unnecessarily hard (i.e., forking, passing maintainership
over, ...). Sure, they aren't activities that should be actively
encouraged, but they shouldn't be made harder than necessary either.
> The scale of Bazaar development is much smaller than the scale of kernel
> development, so it doesn't make sense to maintain long-term divergent
> branches like the mm tree. We do occasionally have long-lived feature
> branches, though.
Are you saying Bazaar is aimed at small(ish) projects (only)?
> > That special maintainer is the maintainer whose merge-trunk is followed,
> > and whose revision numbers don't change when they are merged back.
> In bzr development, it's very rare for anyone's revision numbers to
> change.
"Very rare" != "never". The "very rare" cases /will/ come back to bite you,
once you grow accustomed to "hasn't ever happened"
[...]
> > I'll just point out that one of my design goals for git was to make every
> > single repository 100% equal. That means that there MUST NOT be a "trunk",
> > or a special line of development. There is no "vendor branch".
> I think you're implying that on a technical level, bzr doesn't support
> this. But it does. Every published repository
What makes a "published repository" special, as oposed to my local
playground?
> has unique identifiers
> for every revision on its mainline,
Are they different among repositories, even though they came from another
of the set?
> and it's exceedingly uncommon for
> these to change.
See above.
> There are special procedures to maintain bzr.dev, but
> there's nothing technically unique about it. People develop against
> bzr.dev rather than my integration branch, because they have
> non-technical reasons for wanting their changes to be merged into
> bzr.dev, not my integration branch.
OK.
^ permalink raw reply
* (unknown)
From: andyparkins @ 2006-10-20 13:25 UTC (permalink / raw)
>From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 14:25:48 +0100
Subject: [PATCH] Remove git-send-email references from documentation
To: git@vger.kernel.org
MIME-Version: 1.0
X-TUID: 17b00343571b31b8
X-UID: 99
X-Length: 1933
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_c5MOFrK5Yix34S1"
Message-Id: <200610201425.48598.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_c5MOFrK5Yix34S1
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
git-send-email doesn't exist; so don't refer to it in the documentation.
Perhaps git-send-email.perl is meant to do this job? It runs with an error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-format-patch.txt | 2 +-
Documentation/git.txt | 3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
--Boundary-00=_c5MOFrK5Yix34S1
Content-Type: text/x-patch;
name="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 67425dc..9257030 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -112,7 +112,7 @@ git-format-patch -M -B origin::
See Also
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
+gitlink:git-am[1]
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..1f60d3f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,9 +478,6 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
-gitlink:git-send-email[1]::
- Send patch e-mails out of "format-patch --mbox" output.
-
gitlink:git-symbolic-ref[1]::
Read and modify symbolic refs.
--Boundary-00=_c5MOFrK5Yix34S1--
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-20 13:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthieu Moy, Andreas Ericsson, Matthew D. Fuller, bazaar-ng,
Linus Torvalds, Carl Worth, git
In-Reply-To: <200610201350.12273.jnareb@gmail.com>
Jakub Narebski wrote:
> Second, git-diff with only one <commit-ish> generates diff to first
> parent. But you can always use '-c' or '-cc' combined diff format
> or '-m' with default diff format to compare to _all_ parents.
I stand corrected: git-diff refuses to show anything if provided
with only one commit, and commit has more than one parent. So it
does not reat first parent specially.
--
Jakub Narebski
Poland
^ 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