* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-23 22:45 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061023222131.GB17019@over-yonder.net>
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
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-23 22:44 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: bazaar-ng, git
In-Reply-To: <20061023222131.GB17019@over-yonder.net>
On Mon, 23 Oct 2006, 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 (and all other logging functions) can take as its argument a set of
arbitrary revision expressions.
That means, for example, that you can give it a list of branches and tags,
and it will generate the combined log for all of them. "--all" is just
shorthand for that, but it's really just a special case of the generic
facility.
This is _invaluable_ when you want to actually look at how the branches
are related. The whole _point_ of having branches is that they tend to
have common state.
For example, let's say that you have a branch called "development", and a
branch called "experimental", and a branch called "mainline". Now,
_obviously_ all of these are related, but if you want to see how, what
would you do?
In git, one natural thing would be, for example, to do
gitk development experimental ^mainline
(where instead of "gitk" you can use any of the history listing
things - gitk is just the visually more clear one) which will show you
what exists in the branches "development" and "experimental", but it will
_subtract_ out anything in "mainline" (which is sensible - you may want to
see _just_ the stuff that is getting worked on - and the stuff in mainline
is thus uninteresting).
See? When you visualize multiple branches together, HAVING PER-BRANCH
REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid and interesting
operation to do.
An equally interesting thing to ask is: I've got two branches, show me the
differences between them, but not the stuff in common. Again, very simple.
In git, you'd literally just write
gitk a...b
(where "..." is "symmetric difference"). Or, if you want to see what is in
"a" but _not_ in "b", you'd do
gitk b..a
(now ".." is regular set difference, and the above is really identical to
the "a ^b" syntax).
And trust me, these are all very valid things to do, even though you're
talking about different branches.
Try it out.
> > 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.
No. If you "undo", you'd undo the whole history too. And if you undo to a
point that was on a branch, you'd have to re-write _all_ the revision
ID's.
> I consider it a _technical_ sign of a way of thinking about branches I
> prefer 8-}
Quite frankly, I just don't think you understand what it means.
Linus
^ permalink raw reply
* [RFC/PATCH] gitweb: Add "all parents" (-m) view to commitdiff
From: Jakub Narebski @ 2006-10-23 22:35 UTC (permalink / raw)
To: git
Add "all parents" view/link to commitdiff, which uses '-m' to show
diff to all parents of a merge commit.
This is instead of having link "combined" to combined (-c) or compact
combined (--cc) diff for a merge commit, till we have syntax
highlighting for combined diff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 255487d..84b4abb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3289,7 +3289,7 @@ sub git_commitdiff {
hash=>$hash, hash_parent=>$hash_parent)},
"raw");
- if (defined $hash_parent) {
+ if (defined $hash_parent && substr($hash_parent, 0, 1) ne '-') {
# commitdiff with two commits given
$formats_nav .=
' (' .
@@ -3310,6 +3310,15 @@ sub git_commitdiff {
')';
} else {
# merge commit
+ $formats_nav .= ' | ';
+ if (defined $hash_parent && $hash_parent eq '-m') {
+ $formats_nav .= 'all parents';
+ } else {
+ $formats_nav .=
+ $cgi->a({-href => href(action=>"commitdiff",
+ hash=>$hash, hash_parent=>'-m')},
+ 'all parents');
+ }
$formats_nav .=
' (' .
join(' ', map {
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] Make git-branch a builtin
From: Junio C Hamano @ 2006-10-23 22:34 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, krh
In-Reply-To: <11616396262982-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This replaces git-branch.sh with builtin-branch.c
> +static const char builtin_branch_usage[] =
> +"git-branch [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r";
Probably needs a matching change to your recent clean-up here.
> +static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> + void *cb_data)
> +{
> + if (ref_index >= ref_alloc) {
> + ref_alloc = ref_alloc > 0 ? ref_alloc * 2 : 16;
> + ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
> + }
It would be more consistent to use alloc_nr() from cache.h here
unless you have a specific need for allocation growing pattern,
which you don't. Other parts of the system even just grows by
one and let xrealloc() (and in turn underlying realloc()) take
care of the optimization of repeated reallocations, which may
also be fine.
> +static void create_branch(const char *name, const char *start,
> + int force, int reflog)
> +{
> + struct ref_lock *lock;
> + unsigned char sha1[20];
> + char ref[PATH_MAX], msg[PATH_MAX + 20];
> +
> + snprintf(ref, sizeof ref, "refs/heads/%s", name);
> + if (check_ref_format(ref))
> + die("'%s' is not a valid branch name.", name);
> +
> + if (resolve_ref(ref, sha1, 1, NULL)) {
> + if (!force)
> + die("A branch named '%s' already exists.", name);
> + else if (!strcmp(head, name))
> + die("Cannot force update the current branch.");
> + }
> +
> + if (get_sha1(start, sha1))
> + die("Not a valid branch point: '%s'.", start);
> +
> + lock = lock_any_ref_for_update(ref, NULL);
> + if (!lock)
> + die("Failed to lock ref for update: %s.", strerror(errno));
This is not enough. "$2^0" in git-branch.sh makes sure the
"start" specified dereferences to a commit object, and object
name we use to initialize the new branch is of the commit object
(IOW, test your code with "git branch new v1.0.0" and make sure
"git rev-parse new" returns the commit object not the tag that
points at it).
> +
> + if (reflog){
Style; (1) remove trailing TAB on the empty line; (2) one SP
between ')' and '{' please.
> diff --git a/builtin.h b/builtin.h
> index 9683a7c..144d299 100644
> --- a/builtin.h
> +++ b/builtin.h
> @@ -15,6 +15,7 @@ extern int write_tree(unsigned char *sha
> extern int cmd_add(int argc, const char **argv, const char *prefix);
> extern int cmd_annotate(int argc, const char **argv, const char *prefix);
> extern int cmd_apply(int argc, const char **argv, const char *prefix);
> +extern int cmd_branch(int argc, const char **argv, const char *prefix);
> extern int cmd_archive(int argc, const char **argv, const char *prefix);
> extern int cmd_cat_file(int argc, const char **argv, const char *prefix);
> extern int cmd_checkout_index(int argc, const char **argv, const char *prefix);
Style; order them alphabetically please...
> diff --git a/git.c b/git.c
> index 308252a..671b212 100644
> --- a/git.c
> +++ b/git.c
> @@ -222,6 +222,7 @@ static void handle_internal_command(int
> { "annotate", cmd_annotate, },
> { "apply", cmd_apply },
> { "archive", cmd_archive },
> + { "branch", cmd_branch },
> { "cat-file", cmd_cat_file, RUN_SETUP },
> { "checkout-index", cmd_checkout_index, RUN_SETUP },
> { "check-ref-format", cmd_check_ref_format },
In other words, match this.
We may someday want to do binary search into the command list,
and before that happens we should make sure this list is really
ordered.
^ permalink raw reply
* Re: VCS comparison table
From: David Lang @ 2006-10-23 22:28 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <20061023222131.GB17019@over-yonder.net>
On Mon, 23 Oct 2006, Matthew D. Fuller wrote:
>
> 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.
on many modern VCS systems it's O(n) on the number of changes (start from where
you are and apply the patch to change it to rev -1, then apply the patch to
change it to rev -2, etc)
on git it's O(1) (write the new files into place)
David Lang
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-23 22:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610231018410.3962@g5.osdl.org>
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.
> 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.
> 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.
> 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-}
--
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
* [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Jakub Narebski @ 2006-10-23 22:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd58k0wmx.fsf@assigned-by-dhcp.cox.net>
Use fixed string instead of shortened SHA1 identifier of commit
as a name for "mext" link in commitdiff view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Add a kind of "next" link in the bottom part of navigation bar for
>> "commitdiff" view.
>>
>> For commitdiff between two commits:
>> (from: _commit_)
>> For commitdiff for one single parent commit:
>> (parent: _commit_)
>> For commitdiff for one merge commit
>> (merge: _commit_ _commit_ ...)
>> For commitdiff for root (parentless) commit
>> (initial)
>> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
>> display, everything is perhaps unnecessary esc_html on display.
>
> Would it even be necessary to use any SHA-1 name in these cases,
> I wonder. Would it make the page less useful if we replace all
> of the above _commit_ with a fixed string, say, "parent"?
>
> I always hated gitweb diffs that prefix each filepair with their
> full 40-byte SHA-1 blob object names. It just adds noise to the
> output without adding any meaningful information.
Here you have. I used patch on top of previous one instead of amending
previous patch because I think it is interesting to have this history
of this feature.
This patch doesn't add any functionality.
gitweb/gitweb.perl | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4241d5c..255487d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3291,15 +3291,11 @@ sub git_commitdiff {
if (defined $hash_parent) {
# commitdiff with two commits given
- my $hash_parent_short = $hash_parent;
- if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) {
- $hash_parent_short = substr($hash_parent, 0, 7);
- }
$formats_nav .=
- ' (from: ' .
+ ' (' .
$cgi->a({-href => href(action=>"commitdiff",
hash=>$hash_parent)},
- esc_html($hash_parent_short)) .
+ 'from') .
')';
} elsif (!$co{'parent'}) {
# --root commitdiff
@@ -3307,19 +3303,19 @@ sub git_commitdiff {
} elsif (scalar @{$co{'parents'}} == 1) {
# single parent commit
$formats_nav .=
- ' (parent: ' .
+ ' (' .
$cgi->a({-href => href(action=>"commitdiff",
hash=>$co{'parent'})},
- esc_html(substr($co{'parent'}, 0, 7))) .
+ 'parent') .
')';
} else {
# merge commit
$formats_nav .=
- ' (merge: ' .
+ ' (' .
join(' ', map {
$cgi->a({-href => href(action=>"commitdiff",
hash=>$_)},
- esc_html(substr($_, 0, 7)));
+ 'parent');
} @{$co{'parents'}} ) .
')';
}
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] Checking for "diff.color." should come before "diff.color"
From: Jeff King @ 2006-10-23 21:57 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610232152.48543.andyparkins@gmail.com>
On Mon, Oct 23, 2006 at 09:52:48PM +0100, Andy Parkins wrote:
> Oops. Yep. So far I'm zero for five on my git patches - not doing too well
> am I? :-)
Keep trying. Many eyes on the code is never a bad thing, and
fortunately there are many eyes on your patches, too. :)
-Peff
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Shawn Pearce @ 2006-10-23 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <11616396262982-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
[snip]
> ---
> Makefile | 3 +-
> builtin-branch.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> builtin.h | 1 +
> git-branch.sh | 131 --------------------------------
> git.c | 1 +
> 5 files changed, 221 insertions(+), 132 deletions(-)
[snip]
> diff --git a/git-branch.sh b/git-branch.sh
> deleted file mode 100755
> index 4379a07..0000000
> --- a/git-branch.sh
> +++ /dev/null
> @@ -1,131 +0,0 @@
[snip 131 lines]
Aside from compatability with non-Git tools...
Wouldn't it make more sense to just include the full SHA1 of the
file we are deleting rather than the entire 131 line negative diff?
--
Shawn.
^ permalink raw reply
* [PATCH] Make git-branch a builtin
From: Lars Hjemli @ 2006-10-23 21:40 UTC (permalink / raw)
To: git; +Cc: junkio, krh
This replaces git-branch.sh with builtin-branch.c
The changes is basically a patch from Kristian Høgsberg, updated
to apply onto current 'next'
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Makefile | 3 +-
builtin-branch.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git-branch.sh | 131 --------------------------------
git.c | 1 +
5 files changed, 221 insertions(+), 132 deletions(-)
diff --git a/Makefile b/Makefile
index 36b9e06..e249d34 100644
--- a/Makefile
+++ b/Makefile
@@ -158,7 +158,7 @@ BASIC_CFLAGS =
BASIC_LDFLAGS =
SCRIPT_SH = \
- git-bisect.sh git-branch.sh git-checkout.sh \
+ git-bisect.sh git-checkout.sh \
git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-fetch.sh \
git-ls-remote.sh \
@@ -270,6 +270,7 @@ BUILTIN_OBJS = \
builtin-annotate.o \
builtin-apply.o \
builtin-archive.o \
+ builtin-branch.o \
builtin-cat-file.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
diff --git a/builtin-branch.c b/builtin-branch.c
new file mode 100755
index 0000000..3105efd
--- /dev/null
+++ b/builtin-branch.c
@@ -0,0 +1,217 @@
+/*
+ * Builtin "git branch"
+ *
+ * Copyright (c) 2006 Kristian Høgsberg <krh@redhat.com>
+ * Based on git-branch.sh by Junio C Hamano.
+ */
+
+#include "cache.h"
+#include "refs.h"
+#include "commit.h"
+#include "builtin.h"
+
+static const char builtin_branch_usage[] =
+"git-branch [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r";
+
+
+static const char *head;
+static unsigned char head_sha1[20];
+
+static int in_merge_bases(const unsigned char *sha1,
+ struct commit *rev1,
+ struct commit *rev2)
+{
+ struct commit_list *bases, *b;
+ int ret = 0;
+
+ bases = get_merge_bases(rev1, rev2, 1);
+ for (b = bases; b; b = b->next) {
+ if (!hashcmp(sha1, b->item->object.sha1)) {
+ ret = 1;
+ break;
+ }
+ }
+
+ free_commit_list(bases);
+ return ret;
+}
+
+static void delete_branches(int argc, const char **argv, int force)
+{
+ struct commit *rev, *head_rev;
+ unsigned char sha1[20];
+ const char *name;
+ int i;
+
+ head_rev = lookup_commit_reference(head_sha1);
+ for (i = 0; i < argc; i++) {
+ if (!strcmp(head, argv[i]))
+ die("Cannot delete the branch you are currently on.");
+
+ name = xstrdup(mkpath("refs/heads/%s", argv[i]));
+ if (!resolve_ref(name, sha1, 1, NULL))
+ die("Branch '%s' not found.", argv[i]);
+
+ rev = lookup_commit_reference(sha1);
+ if (!rev || !head_rev)
+ die("Couldn't look up commit objects.");
+
+ /* This checks whether the merge bases of branch and
+ * HEAD contains branch -- which means that the HEAD
+ * contains everything in both.
+ */
+
+ if (!force &&
+ !in_merge_bases(sha1, rev, head_rev)) {
+ fprintf(stderr,
+ "The branch '%s' is not a strict subset of your current HEAD.\n"
+ "If you are sure you want to delete it, run 'git branch -D %s'.\n",
+ argv[i], argv[i]);
+ exit(1);
+ }
+
+ if (delete_ref(name, sha1))
+ printf("Error deleting branch '%s'\n", argv[i]);
+ else
+ printf("Deleted branch %s.\n", argv[i]);
+
+ free(name);
+ }
+}
+
+static int ref_index, ref_alloc;
+static char **ref_list;
+
+static int append_ref(const char *refname, const unsigned char *sha1, int flags,
+ void *cb_data)
+{
+ if (ref_index >= ref_alloc) {
+ ref_alloc = ref_alloc > 0 ? ref_alloc * 2 : 16;
+ ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
+ }
+
+ ref_list[ref_index++] = xstrdup(refname);
+
+ return 0;
+}
+
+static int ref_cmp(const void *r1, const void *r2)
+{
+ return strcmp(*(char **)r1, *(char **)r2);
+}
+
+static void print_ref_list(int remote_only)
+{
+ int i;
+
+ if (remote_only)
+ for_each_remote_ref(append_ref, NULL);
+ else
+ for_each_branch_ref(append_ref, NULL);
+
+ qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
+
+ for (i = 0; i < ref_index; i++) {
+ if (!strcmp(ref_list[i], head))
+ printf("* %s\n", ref_list[i]);
+ else
+ printf(" %s\n", ref_list[i]);
+ }
+}
+
+static void create_branch(const char *name, const char *start,
+ int force, int reflog)
+{
+ struct ref_lock *lock;
+ unsigned char sha1[20];
+ char ref[PATH_MAX], msg[PATH_MAX + 20];
+
+ snprintf(ref, sizeof ref, "refs/heads/%s", name);
+ if (check_ref_format(ref))
+ die("'%s' is not a valid branch name.", name);
+
+ if (resolve_ref(ref, sha1, 1, NULL)) {
+ if (!force)
+ die("A branch named '%s' already exists.", name);
+ else if (!strcmp(head, name))
+ die("Cannot force update the current branch.");
+ }
+
+ if (get_sha1(start, sha1))
+ die("Not a valid branch point: '%s'.", start);
+
+ lock = lock_any_ref_for_update(ref, NULL);
+ if (!lock)
+ die("Failed to lock ref for update: %s.", strerror(errno));
+
+ if (reflog){
+ log_all_ref_updates = 1;
+ snprintf(msg, sizeof msg, "branch: Created from %s", start);
+ }
+
+ if (write_ref_sha1(lock, sha1, msg) < 0)
+ die("Failed to write ref: %s.", strerror(errno));
+}
+
+int cmd_branch(int argc, const char **argv, const char *prefix)
+{
+ int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int reflog = 0;
+ int i, prefix_length;
+
+ git_config(git_default_config);
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-d")) {
+ delete = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-D")) {
+ delete = 1;
+ force_delete = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-f")) {
+ force_create = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-r")) {
+ remote_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-l")) {
+ reflog = 1;
+ continue;
+ }
+ usage(builtin_branch_usage);
+ }
+
+ head = xstrdup(resolve_ref("HEAD", head_sha1, 0, NULL));
+ if (!head)
+ die("Failed to resolve HEAD as a valid ref.");
+ if (strncmp(head, "refs/heads/", 11))
+ die("HEAD not found below refs/heads!");
+
+ head += 11;
+
+ if (delete)
+ delete_branches(argc - i, argv + i, force_delete);
+ else if (i == argc)
+ print_ref_list(remote_only);
+ else if (i == argc - 1)
+ create_branch(argv[i], head, force_create, reflog);
+ else if (i == argc - 2)
+ create_branch(argv[i], argv[i + 1], force_create, reflog);
+ else
+ usage(builtin_branch_usage);
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 9683a7c..144d299 100644
--- a/builtin.h
+++ b/builtin.h
@@ -15,6 +15,7 @@ extern int write_tree(unsigned char *sha
extern int cmd_add(int argc, const char **argv, const char *prefix);
extern int cmd_annotate(int argc, const char **argv, const char *prefix);
extern int cmd_apply(int argc, const char **argv, const char *prefix);
+extern int cmd_branch(int argc, const char **argv, const char *prefix);
extern int cmd_archive(int argc, const char **argv, const char *prefix);
extern int cmd_cat_file(int argc, const char **argv, const char *prefix);
extern int cmd_checkout_index(int argc, const char **argv, const char *prefix);
diff --git a/git-branch.sh b/git-branch.sh
deleted file mode 100755
index 4379a07..0000000
--- a/git-branch.sh
+++ /dev/null
@@ -1,131 +0,0 @@
-#!/bin/sh
-
-USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
-LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
-If one argument, create a new branch <branchname> based off of current HEAD.
-If two arguments, create a new branch <branchname> based off of <start-point>.'
-
-SUBDIRECTORY_OK='Yes'
-. git-sh-setup
-
-headref=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
-
-delete_branch () {
- option="$1"
- shift
- for branch_name
- do
- case ",$headref," in
- ",$branch_name,")
- die "Cannot delete the branch you are on." ;;
- ,,)
- die "What branch are you on anyway?" ;;
- esac
- branch=$(git-show-ref --verify --hash -- "refs/heads/$branch_name") &&
- branch=$(git-rev-parse --verify "$branch^0") ||
- die "Seriously, what branch are you talking about?"
- case "$option" in
- -D)
- ;;
- *)
- mbs=$(git-merge-base -a "$branch" HEAD | tr '\012' ' ')
- case " $mbs " in
- *' '$branch' '*)
- # the merge base of branch and HEAD contains branch --
- # which means that the HEAD contains everything in both.
- ;;
- *)
- echo >&2 "The branch '$branch_name' is not a strict subset of your current HEAD.
-If you are sure you want to delete it, run 'git branch -D $branch_name'."
- exit 1
- ;;
- esac
- ;;
- esac
- git update-ref -d "refs/heads/$branch_name" "$branch"
- echo "Deleted branch $branch_name."
- done
- exit 0
-}
-
-ls_remote_branches () {
- git-rev-parse --symbolic --all |
- sed -ne 's|^refs/\(remotes/\)|\1|p' |
- sort
-}
-
-force=
-create_log=
-while case "$#,$1" in 0,*) break ;; *,-*) ;; *) break ;; esac
-do
- case "$1" in
- -d | -D)
- delete_branch "$@"
- exit
- ;;
- -r)
- ls_remote_branches
- exit
- ;;
- -f)
- force="$1"
- ;;
- -l)
- create_log="yes"
- ;;
- --)
- shift
- break
- ;;
- -*)
- usage
- ;;
- esac
- shift
-done
-
-case "$#" in
-0)
- git-rev-parse --symbolic --branches |
- sort |
- while read ref
- do
- if test "$headref" = "$ref"
- then
- pfx='*'
- else
- pfx=' '
- fi
- echo "$pfx $ref"
- done
- exit 0 ;;
-1)
- head=HEAD ;;
-2)
- head="$2^0" ;;
-esac
-branchname="$1"
-
-rev=$(git-rev-parse --verify "$head") || exit
-
-git-check-ref-format "heads/$branchname" ||
- die "we do not like '$branchname' as a branch name."
-
-prev=''
-if git-show-ref --verify --quiet -- "refs/heads/$branchname"
-then
- if test '' = "$force"
- then
- die "$branchname already exists."
- elif test "$branchname" = "$headref"
- then
- die "cannot force-update the current branch."
- fi
- prev=`git rev-parse --verify "refs/heads/$branchname"`
-fi
-if test "$create_log" = 'yes'
-then
- mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
- touch "$GIT_DIR/logs/refs/heads/$branchname"
-fi
-git update-ref -m "branch: Created from $head" "refs/heads/$branchname" "$rev" "$prev"
diff --git a/git.c b/git.c
index 308252a..671b212 100644
--- a/git.c
+++ b/git.c
@@ -222,6 +222,7 @@ static void handle_internal_command(int
{ "annotate", cmd_annotate, },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
+ { "branch", cmd_branch },
{ "cat-file", cmd_cat_file, RUN_SETUP },
{ "checkout-index", cmd_checkout_index, RUN_SETUP },
{ "check-ref-format", cmd_check_ref_format },
--
1.4.3.1.g9164-dirty
^ permalink raw reply related
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Linus Torvalds @ 2006-10-23 21:19 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610231402560.3962@g5.osdl.org>
On Mon, 23 Oct 2006, Linus Torvalds wrote:
>
> Try it. The default "extreme" simplification is a _hell_ of a lot faster
> than doing the full history.
[ timings removed ]
Btw, the reason it is so much faster is that it can be done early, and
allows us to prune out parts of the history that we don't care about.
For example, when we hit a merge, and the result of that merge is
identical to one of the parents (in the set of filenames that we are
interested in), we can simply choose to totally ignore the other parent,
and we don't need to traverse that history at _all_. Because clearly, all
the actual _data_ came from just the other one.
So the "extreme" simplification is way way faster, because in the presense
of a lot of merges, it can select to go down just one of the paths, and
totally ignore the other ones. In practice, for a fairly "bushy" history
tree like the kernel, that can cut down the number of commits you need to
compare by a factor of two or more.
In many ways, it is also actually a _better_ result, in that it's a
"closer to minimal" way of reaching a particular state. So if you're just
interested in how something came to be, and want to just cut through the
crap, the result extreme simplification really _is_ better.
So the branches that were dismissed really _aren't_ important - they might
contain real work, but from the point of the end result, that real work
might as well not have happened, since the simpler history we chose _also_
explain the end result sufficiently.
So I think the default simplification is really a good default: not only
because it's fundamentally cheaper, but because it is actually more likely
to be distill what you actually care about if you wonder what happened to
a file or a set of files.
But if you care about all the "side efforts" that didn't actually matter
for the end result too, then you'd want the more expensive, and more
complete graph. But it _will_ be a lot more expensive to compute.
Linus
^ permalink raw reply
* Re: [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Jakub Narebski @ 2006-10-23 21:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610231409430.3962@g5.osdl.org>
Linus Torvalds wrote:
> On Mon, 23 Oct 2006, Petr Baudis wrote:
>>
>> Not really - mind you, this is only about the diff headers. Actually, it
>> is only about the hunk headers, specifically when we append the function
>> name to the hunk header.
>
> Ahh. I totally misunderstood, looking at just the diff, and not the bigger
> context of it.
>
> Removing whitespace from the "comment" in the hunk header is obviously
> fine.
>
> Sorry for the noise.
Well, this points out that commit message was not clear enough.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Linus Torvalds @ 2006-10-23 21:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jim Meyering, git
In-Reply-To: <20061023210327.GT20017@pasky.or.cz>
On Mon, 23 Oct 2006, Petr Baudis wrote:
>
> Not really - mind you, this is only about the diff headers. Actually, it
> is only about the hunk headers, specifically when we append the function
> name to the hunk header.
Ahh. I totally misunderstood, looking at just the diff, and not the bigger
context of it.
Removing whitespace from the "comment" in the hunk header is obviously
fine.
Sorry for the noise.
Linus
^ permalink raw reply
* Re: [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Jakub Narebski @ 2006-10-23 21:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610231347490.3962@g5.osdl.org>
Linus Torvalds wrote:
> On Mon, 23 Oct 2006, Jim Meyering wrote:
>>
>> This removes trailing blanks from git-generated diff headers
>> the same way a similar patch did that for GNU diff:
>
> NO!
>
> This is _wrong_
>
> You should only remove the space IF IT IS THE ONLY THING ON THE WHOLE
> LINE!
If I understand the description of this patch given by the mentioned article
and example therein (Jim, you should include appropriate parts of mentioned
email in commit message, not just provide link to it), trailing spaces are
removed from extended diff header, i.e. the "which function are we in",
diff -p header. Not from diff body.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Linus Torvalds @ 2006-10-23 21:06 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, git
In-Reply-To: <453D2B98.8010903@freedesktop.org>
On Mon, 23 Oct 2006, Josh Triplett wrote:
>
> Or have I misunderstood the case you have concerns about? Why would the
> "nice" format incur additional cost?
Try it. The default "extreme" simplification is a _hell_ of a lot faster
than doing the full history.
[torvalds@g5 linux]$ time git-rev-list --full-history --parents HEAD -- kernel/sched.c >/dev/null
real 0m4.660s
user 0m4.612s
sys 0m0.044s
[torvalds@g5 linux]$ time git-rev-list --parents HEAD -- kernel/sched.c >/dev/null
real 0m1.684s
user 0m1.680s
sys 0m0.004s
and the "nice" thing will be much slower still: just trying to figure out
whether a commit is a parent of another commit is expensive. Doing so for
_each_ merge is more expensive still. I think it's O(n^3), but what do I
know..
Linus
^ permalink raw reply
* Re: [PATCH] Checking for "diff.color." should come before "diff.color"
From: Andy Parkins @ 2006-10-23 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vk62qydvu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
On Monday 2006, October 23 21:29, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > In git_diff_ui_config() the strncmp() for "diff.color" would have matched
> > for "diff.color.", so "diff.color." configs would never be processed.
>
> A test case that demonstrates the breakage without the patch
> would be nice. Could you come up with a two-patch series that
> is:
No need. Jeff King already caught the fact that my patch is unnecessary. I
withdraw it.
Sorry to keep bothering you all with these non-entity patches. I really am
only trying to help :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Petr Baudis @ 2006-10-23 21:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git
In-Reply-To: <Pine.LNX.4.64.0610231347490.3962@g5.osdl.org>
Dear diary, on Mon, Oct 23, 2006 at 10:49:37PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
>
>
> On Mon, 23 Oct 2006, Jim Meyering wrote:
> >
> > This removes trailing blanks from git-generated diff headers
> > the same way a similar patch did that for GNU diff:
>
> NO!
>
> This is _wrong_
>
> You should only remove the space IF IT IS THE ONLY THING ON THE WHOLE
> LINE!
>
> You must not remove white-space in general.
>
> So the patch should check something like
>
> if (len == 1 && rec[0] == ' ')
> len = 0;
>
> and not like you did it.
>
> Otherwise the patch will simply not even _apply_.
Not really - mind you, this is only about the diff headers. Actually, it
is only about the hunk headers, specifically when we append the function
name to the hunk header. A trailing whitespace can come out of that even
if the source does not have any trailing whitespaces since we trim the
line at 40 bytes.
--
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: [PATCH] Checking for "diff.color." should come before "diff.color"
From: Andy Parkins @ 2006-10-23 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <20061023202952.GC31068@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Monday 2006, October 23 21:29, Jeff King wrote:
> No, it's a strcmp for "diff.color", so it must match exactly. The code
> is fine.
Oops. Yep. So far I'm zero for five on my git patches - not doing too well
am I? :-)
> Are you experiencing some bug, or was this just from poking through the
> code?
Nah; poking around only. I'm playing with git using the git repository. I
have a feeling it's making me noisy and annoying.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Josh Triplett @ 2006-10-23 20:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610231237080.3962@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
Linus Torvalds wrote:
> On Mon, 23 Oct 2006, Josh Triplett wrote:
> - The nice one that doesn't throw away potentially interesting
> duplicate paths to reach the same end result. We don't have this one,
> so no git commands do this yet.
>
> The way to do this one would be "--full-history", but then removing all
> parents that are "redundant". In other words, for any merge that
> remains (because of the --full-history), check if one parent is a full
> superset of another one, and if so, remove the "dominated" parent,
> which simplifies the merge. Continue until nothing can be simplified
> any more.
>
> This would _usually_ end up giving the same graph as the "extreme"
> simplification, but if there were two branches that really _did_
> generate the same end result using different commits, they'd remain in
> the end result.
>
> The problem with the "nice one" is that it's expensive as hell. There may
> be clever tricks to make it less so, though. But I think it's the
> RightThing(tm) to do, at least as an option for when you really want to
> see a reasonable history that still contains everything that is relevant.
So, if a commit has more than one parent (a merge), you want to
eliminate any parents that end up as ancestors to other parents in the
merge (including if their head has the same commit ID), but not
eliminate multiple parents with different head commits but the same tree
object? That seems simple enough; I *think* git-split actually already
does that, though I haven't actually tested that particular case. If
git log eliminates all but one of the parents with different commits but
the same tree, I believe the commit sequence generated by git-split will
differ from that of git log in that case, by including all such parents.
I do agree that the behavior you describe seems like the best
simplification, and I don't think the alternative you describe as
"extreme simplification" makes any sense at all (picking a parent
arbitrarily), nor does it seem any simpler to generate; either way, you
still have to figure out if one parent has another as an ancestor, while
the additional "extreme simplification" just *adds* a comparison of tree
hashes.
Or have I misunderstood the case you have concerns about? Why would the
"nice" format incur additional cost?
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Linus Torvalds @ 2006-10-23 20:49 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87y7r63hq6.fsf@rho.meyering.net>
On Mon, 23 Oct 2006, Jim Meyering wrote:
>
> This removes trailing blanks from git-generated diff headers
> the same way a similar patch did that for GNU diff:
NO!
This is _wrong_
You should only remove the space IF IT IS THE ONLY THING ON THE WHOLE
LINE!
You must not remove white-space in general.
So the patch should check something like
if (len == 1 && rec[0] == ' ')
len = 0;
and not like you did it.
Otherwise the patch will simply not even _apply_.
Linus
^ permalink raw reply
* Re: [PATCH] Checking for "diff.color." should come before "diff.color"
From: Jeff King @ 2006-10-23 20:29 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610232051.17396.andyparkins@gmail.com>
On Mon, Oct 23, 2006 at 08:51:17PM +0100, Andy Parkins wrote:
> In git_diff_ui_config() the strncmp() for "diff.color" would have
> matched for "diff.color.", so "diff.color." configs would never be
> processed.
No, it's a strcmp for "diff.color", so it must match exactly. The code
is fine.
Are you experiencing some bug, or was this just from poking through the
code?
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-23 20:29 UTC (permalink / raw)
To: Jeff King
Cc: Aaron Bentley, James Henstridge, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, Andreas Ericsson, Carl Worth, git
In-Reply-To: <20061023200648.GB31068@coredump.intra.peff.net>
On Mon, 23 Oct 2006, Jeff King wrote:
> On Mon, Oct 23, 2006 at 01:18:30PM -0400, Aaron Bentley wrote:
>
>> And, unlike git, Bazaar branches are all independent entities[1], and
> [...]
>> [1] The fact that they may share storage is not important to the model.
By the way, git repositories (remember that working area in bzr is
associated with branch, and in git with repository) can share storage,
either sharing only immutable "old history" (part of DAG) via
$GIT_DIR/objects/info/alternates file or GIT_ALTERNATE_OBJECT_DIRECTORIES
environment variable, or via having shared commit object database
via symlinking $GIT_DIR/objects directory or via setting
GIT_OBJECT_DIRECTORY variable.
Git doesn't support latter fully out of the box (you must be careful
with prune) but on the other side bzr doesn't support cloning whole
repository.
> It all Just Works because there _isn't_ any branch information. It's
> simply a pointer into the DAG, so if I have the right parts of the DAG
> (which git is careful to make sure of), I can just make a pointer, and I
> have absolutely zero connection to wherever the DAG came from.
Well, with exception of reflog, which is local to repository
(and doesn't get propagated).
>> they each have a URL.
>
> In cogito, branches can each have a URL, but git-clone doesn't have a
> way (that I know of) to clone only a subset of branches. It would be
> fairly trivial to implement, I think.
On the other side Cogito doesn't have way to clone all the branches.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-cherry should show "+" instead of "-" and vice versa
From: Andy Parkins @ 2006-10-23 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <20061023193326.GS20017@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
On Monday 2006, October 23 20:33, Petr Baudis wrote:
> Did the documentation ever get fixed or noone cared enough? ;-)
My patch makes git-cherry match the documentation.
Personally I think that the documentation is correct. git-cherry is, to me,
terribly useful. I've got a few patches in my own branch and it's very
useful to be able to check to see if those emailed patches have been accepted
upstream with a simple
git-cherry -v upstream
Which makes it natural to see
"-" = patch not in upstream
"+" = patch in upstream
I read the thread you pointed at, and didn't really understand what the downer
on git-cherry was, or why the patch wasn't accepted. Have I misunderstood
something?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
From: Jim Meyering @ 2006-10-23 20:22 UTC (permalink / raw)
To: git
This removes trailing blanks from git-generated diff headers
the same way a similar patch did that for GNU diff:
http://article.gmane.org/gmane.comp.gnu.utils.bugs/13839
Signed-off-by: Jim Meyering <jim@meyering.net>
---
xdiff/xemit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 714c563..1bca639 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -92,6 +92,8 @@ static void xdl_find_func(xdfile_t *xf,
len = sz;
if (len && rec[len - 1] == '\n')
len--;
+ while (0 < len && isspace ((unsigned char) rec[len - 1]))
+ len--;
memcpy(buf, rec, len);
*ll = len;
return;
--
1.4.3.1.g178e-dirty
^ permalink raw reply related
* Re: VCS comparison table
From: Jeff King @ 2006-10-23 20:06 UTC (permalink / raw)
To: Aaron Bentley
Cc: James Henstridge, Jakub Narebski, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, Andreas Ericsson, Carl Worth, git
In-Reply-To: <453CF966.7000308@utoronto.ca>
On Mon, Oct 23, 2006 at 01:18:30PM -0400, Aaron Bentley wrote:
> And, unlike git, Bazaar branches are all independent entities[1], and
[...]
> [1] The fact that they may share storage is not important to the model.
Sorry, I don't understand this statement. How are git branches not
independent? Sure, they tend to exist in repositories with other
branches, but there's no need to (it simply allows the sharing of object
storage). There's no reason I can't move any branch from any repo into
its own repo, or vice versa move any unrelated branch into a repo with
other branches.
It all Just Works because there _isn't_ any branch information. It's
simply a pointer into the DAG, so if I have the right parts of the DAG
(which git is careful to make sure of), I can just make a pointer, and I
have absolutely zero connection to wherever the DAG came from.
> they each have a URL.
In cogito, branches can each have a URL, but git-clone doesn't have a
way (that I know of) to clone only a subset of branches. It would be
fairly trivial to implement, I think.
> So:
>
> http://code.aaronbentley.com/bzrrepo/bzr.ab 1695
>
> is a name for
>
> abentley@panoramicfeedback.com-20060927202832-9795d0528e311e31
The git analog is of course:
http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v2.6.18
as a name for
e478bec0ba0a83a48a0f6982934b6de079e7e6b3
The difference being that Linus assigned the "local" name of v2.6.18
rather than having git auto-assign it.
> And it does not depend on any other branch, especially not bzr.dev
Of course. For me, the above commit is actually
ssh://peff.net/home/peff/git/linux-2.6 v2.6.18
but once it is in my local repository, it's indistinguishable from one I
pulled directly from kernel.org.
And I wonder if THAT is at the root of this discussion. bzr isn't
"centralized" in the sense that you have to talk to a central server, or
rely on it for doing any operations. But you actually CARE about where
your commits come from, and git fundamentally doesn't.
-Peff
^ 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