Matthew D. Fuller wrote:
> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of
> Linus Torvalds, and lo! it spake thus:
>>
>> I already briought this up once, and I suspect that the bzr people
>> simply DID NOT UNDERSTAND the question:
>>
>> - how do you do the git equivalent of "gitk --all"
>
> I for one simply DO NOT UNDERSTAND the question, because I don't know
> what that is or what I'd be trying to accomplish by doing it. The
> documentation helpfully tells me that it's something undocumented.
gitk(1)
=======
NAME
----
gitk - git repository browser
DESCRIPTION
-----------
Displays changes in a repository or a selected set of commits. This includes
visualizing the commit graph, showing information related to each commit, and
the files in the trees of each revision.
Historically, gitk was the first repository browser. It's written in tcl/tk
and started off in a separate repository but was later merged into the main
git repository.
OPTIONS
-------
To control which revisions to shown, the command takes options applicable to
the git-rev-list(1) command. This manual page describes only the most
frequently used options.
[...]
--all::
Show all branches.
Which means that "gitk --all" means show whole DAG in graphical history viewer.
As in bzr there is no command (nor plugin) to clone whole repository,
I guess that the answer is that you can't do this. But perhaps
I'm mistaken, and you can do this in bzr-gtk/bzrk...
>> For example, how long does it take to do an arbitrary "undo" (ie
>> forcing a branch to an earlier state) [...]
>
> I don't understand the thrust of this, either. As I understand the
> operation you're talking about, it doesn't have anything to do with a
> branch; you'd just be whipping the working tree around to different
> versions. That should be O(diff) on any modern VCS.
For example if you decide to discard some changes completely, reverting
(this action in git is called 'rewind') branch to some previous revision.
And in git this operation is O(1), not O(diff).
BTW. The following question IIRC remained unanswered: can you easily
in bzr create branch off arbitrary revision (for example deciding that
stable branch should start two revisions back in history from development
branch)?
>> and yes, performance does matter.
>
> I agree, and I currently find a number of places bzr doesn't hit the
> level of performance I think it should. I'm not convinced, however,
> that any notable proportion of that has to do with the abstract model
> behind it. And insofar as it has to do with the physical storage
> model, that can easily be (and I'm confident will be, considering it's
> a focus) ameliorated with later repository formats.
Some of physical storage models needs specific abstract model. I think
that git storage model is in this class.
>> The whole confusing between "bzr pull" and "bzr merge" is another
>> _technical_ sign of why branch-local revision numbers are a mistake.
>
> I consider it a _technical_ sign of a way of thinking about branches I
> prefer 8-}
Or _perhaps_ just the way of thinking about branches in the way you are
used to.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html