* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-26 16:21 UTC (permalink / raw)
To: Vincent Ladeuil; +Cc: bazaar-ng, git
In-Reply-To: <87k62n5ahp.fsf@alplog.fr>
On Thu, 26 Oct 2006, Vincent Ladeuil wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>
> Linus> Commits are defined by a _combination_ of:
>
> Linus> - the tree they commit (which is recursive, so the
> Linus> commit name indirectly includes information EVERY
> Linus> SINGLE BIT in the whole tree, in every single file)
>
> And here you keep that separate from any SCM related info,
> right ?
I don't understand that question.
The commits contain the tree information. A raw commit in git (this is the
true contents of the current top commit in my kernel tree, just added
indentation and an empty line between the command I used to generate it
and the output, to make it stand out better in the email) looks something
like this:
[torvalds@g5 linux]$ git-cat-file commit HEAD
tree ba1ed8c744654ca91ee2b71b7cdee149c8edbef1
parent 2a4f739dfc59edd52eaa37d63af1bd830ea42318
parent 012d64ff68f304df1c35ce5902f5023dc14b643f
author Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
committer Linus Torvalds <torvalds@g5.osdl.org> 1161873881 -0700
Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Fix memory corruption in pci_4u_free_consistent().
[SPARC64]: Fix central/FHC bus handling on Ex000 systems.
where the _name_ of the commit is
[torvalds@g5 linux]$ git-rev-parse HEAD
e80391500078b524083ba51c3df01bbaaecc94bb
ie the commit itself contains the exact tree name (and the name of the
parents), and the name of the commit is literally the SHA1 of the contents
of the commit (plus a git-specific header).
> >> Trees are defined by their content only ?
>
> Linus> Where "contents" does include names and
> Linus> permissions/types (eg execute bit and symlink etc).
>
> Which can also be expressed as: "Everything the user can
> manipulate outside the SCM context", right ?
Again, I'm not sure what you mean by that. The SCM does not track
_everything_. It does not track user names and inode numbers, so in a
sense a developer can change things that the SCM simply doesn't _care_
about and never tracks. But yes, the tree contents uniquely identify the
exact contents that the user cares about.
> Linus> If you compare the commit name, and they are equal,
> Linus> you automatically know
>
> Linus> - the trees are 100% identical
> Linus> - the histories are 100% identical
>
> And that's the only info you can get, no ordering here.
No, there is ordering there too. But yes, the ordering is not in the name
itself, you have to go look at the actual commit history to see it.
The name is just an identifier.
> Linus> If you only care about the actual tree, you compare
> Linus> the tree name for equality, ie you can do
>
> Linus> git-rev-parse commit1^{tree} commit2^{tree}
>
> Linus> and compare the two: if and only if they are equal are
> Linus> the actual contents 100% equal.
>
> Actually, that's backwards:
>
> "their actual contents are equal" implies "their signatures are
> equal".
No.
If the signatures are equal, the contents are equal, and vice versa. It
really is a two-way thing.
> But, two totally different trees can have the same signature.
No. Don't even think that way. That just confuses you. The hash is
cryptographic, and large enough, that you really can equate the contents
with the hash. Anything else is just not even interesting.
^ permalink raw reply
* [PATCH] gitweb: Slight visual improvements to commitdiff view
From: Jakub Narebski @ 2006-10-26 16:13 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 14 +++++++++++++-
gitweb/gitweb.perl | 15 +++++++++------
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 0eda982..cb2c627 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -114,7 +114,7 @@ div.log_link {
width: 136px;
}
-div.list_head {
+div.diff_tree_head {
padding: 6px 8px 4px;
border: solid #d9d8d1;
border-width: 1px 0px 0px;
@@ -128,6 +128,18 @@ div.author_date {
font-style: italic;
}
+div.commitdiff_log {
+ padding: 8px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px 0px;
+}
+
+div.patchset {
+ padding-top: 8px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 0px 0px;
+}
+
a.list {
text-decoration: none;
color: #000000;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0d2ea72..a33cae1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1844,11 +1844,11 @@ sub git_print_tree_entry {
sub git_difftree_body {
my ($difftree, $hash, $parent) = @_;
- print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
+ print "<div class=\"list_head\">\n";
print(($#{$difftree} + 1) . " files changed:\n");
+ print "</div>\n";
}
- print "</div>\n";
print "<table class=\"diff_tree\">\n";
my $alternate = 1;
@@ -2055,7 +2055,8 @@ sub git_patchset_body {
# for now, no extended header, hence we skip empty patches
# companion to next LINE if $in_header;
- if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) { # no change
+ if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) {
+ # no change, empty patch
$in_header = 1;
next LINE;
}
@@ -3486,13 +3487,15 @@ sub git_commitdiff {
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash,
$formats_nav);
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
git_print_authorship(\%co);
- print "<div class=\"page_body\">\n";
+
if (@{$co{'comment'}} > 1) {
- print "<div class=\"log\">\n";
+ print "<div class=\"commitdiff_log\">\n";
git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title
=> 1);
- print "</div>\n"; # class="log"
+ print "</div>\n"; # class="commitdiff_log"
}
+ print "<div class=\"page_body\">\n";
+
} elsif ($format eq 'plain') {
my $refs = git_get_references("tags");
my $tagname = git_get_rev_name_tags($hash);
--
1.4.3.3
^ permalink raw reply related
* Re: VCS comparison table
From: Vincent Ladeuil @ 2006-10-26 16:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610260753090.3962@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> On Thu, 26 Oct 2006, Vincent Ladeuil wrote:
>>
>> Ok, so git make a distinction between the commit (code created by
>> someone) and the tree (code only).
>>
>> Commits are defined by their parents.
Linus> Commits are defined by a _combination_ of:
Linus> - the tree they commit (which is recursive, so the
Linus> commit name indirectly includes information EVERY
Linus> SINGLE BIT in the whole tree, in every single file)
And here you keep that separate from any SCM related info,
right ?
Linus> - the parent(s) if any (which is also recursive, so
Linus> the commit name indirectly includes information about
Linus> EVERY SINGLE BIT in not just the current tree, but
Linus> every tree in the history, and every commit that is
Linus> reachable from it)
Linus> - the author, committer, and dates of each (and
Linus> committer is actually very often different from
Linus> author)
Linus> - the actual commit message
Linus> So a commit really names - uniquely and authoratively
Linus> - not just the commit itself, but everything ever
Linus> associated with it.
Thanks for the clarification. But no need to shout about EVERY
SINGLE BIT, the pointer to BDDs was already talking a bit about
bits :)
But I agree, this is the important point that may be missed.
>> Trees are defined by their content only ?
Linus> Where "contents" does include names and
Linus> permissions/types (eg execute bit and symlink etc).
Which can also be expressed as: "Everything the user can
manipulate outside the SCM context", right ?
>> If that's the case, how do you proceed ?
Linus> If you compare the commit name, and they are equal,
Linus> you automatically know
Linus> - the trees are 100% identical
Linus> - the histories are 100% identical
And that's the only info you can get, no ordering here. (Just
pointing the obvious, as soon as you try to put more info into
the signature, the equality will vanish).
But for various optimizations this equality property is the only
needed one.
Do we agree ?
Linus> If you only care about the actual tree, you compare
Linus> the tree name for equality, ie you can do
Linus> git-rev-parse commit1^{tree} commit2^{tree}
Linus> and compare the two: if and only if they are equal are
Linus> the actual contents 100% equal.
Actually, that's backwards:
"their actual contents are equal" implies "their signatures are
equal".
But, two totally different trees can have the same signature.
My god ! What an horror ! Not. I even wonder if I will live so
long as to see it occurs... So we *can* pretend that:
"theirs signatures are equal" is equivalent to "their contents
are equal"
And that's all we care :)
But I digressed, the question was about a detail on your tree
definition, once the signature is defined to be unique (as in
canonical), the property of comparing the signatures as if they
were the objects themselves follows. Thanks for the confirmation.
>> Calculate a sha1 representing the content (or the content
>> of the diff from parent) of all the files and dirs in the
>> tree ? Or from the sha1s of the files and dirs themselves
>> recursively based on sha1s of the files and dirs they
>> contain ?
Linus> The latter.
Thanks for providing the clarification. So of course, finding the
differences between the trees is quick, you can prune anywhere
the signatures equality is verified.
>> I ask because the later seems to provide some nice effects
>> similar to what makes BDD
>> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so
>> efficient: you can compare graphs of any complexity or size in
>> O(1) by just comparing their signatures.
Linus> This is exactly what git does. You can compare entire
Linus> trees (and subdirectories are just other trees) by
Linus> just comparing 20 bytes of information.
I understand that, years ago even. I have a bit of practice with
BDDs and I am accustomed to that so lovely property. But without
that practice, I think most people will just wonder...
<snip/>
Linus> And the reason it's fast is that we can compare 20,000
Linus> files (names, contents, permissions) by just comparing
Linus> a _single_ 20-byte SHA1.
Yeah, let's go further ! We can compare gazillions of files and
their history since epoch by comparing _two_ signatures ! :-)
Linus> In git, revision names (and _everything_ has a
Linus> revision name: commits, trees, blobs, tags) really
Linus> have meaning. They're not just random noise.
I know that effect, but I understand people complaining that they
*look* like noise.
I'm still searching a parallel in nature, but the best I could
find is DNA, ever look at a DNA ?
Looks like noise no ? No ordering either between parents and
children... But there is a way to identify a parent from the DNA
of a children...
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Alex Riesen @ 2006-10-26 15:42 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610261641.11239.andyparkins@gmail.com>
^ permalink raw reply
* Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-10-26 15:41 UTC (permalink / raw)
To: git
Hello,
I have something like this:
# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#
# modified: oops/file1
# modified: good/file2
# modified: good/file3
# modified: good/file4
i.e. the index has been updated to hold oops/file1
If I then didn't want to commit oops/file1, how do I restore the HEAD
oops/file1 back to the index without doing a full reset?
What I'm wishing for is a per file reset...
git-reset --mixed HEAD oops/file1
(I realise that the above is crazy, but I hope it's explaining what I want).
When I do a git checkout -f oops/file1; I get
"git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'oops/file1' which can not be resolved as commit?"
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: (unknown)
From: Linus Torvalds @ 2006-10-26 15:35 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <200610261522.44433.Josef.Weidendorfer@gmx.de>
On Thu, 26 Oct 2006, Josef Weidendorfer wrote:
> On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
> > Heh, I spoke too fast.
> >
> > "git log origin..master"
> >
> > If you do not have none of .git/origin
>
> Really? I thought refs are always looked up in ".git/refs" only?
Yes and no.
The "iterate over all refs" code only ever looks in the "refs"
subdirectory, so when you _list_ refs, they won't ever be shown unless
they are there. That affects a lot of programs (like "git ls-remote").
Also, a symlink-ref has to point into "refs/" or it is considered invalid.
But, there are two extra rules:
- ".git/HEAD" is obviously special, and will show up separately even for
things like "git ls-remote", so even processes that _list_ things will
show it.
- when you do a named lookup, stuff directly in ".git" will take
precedence over EVERYTHING, even if it is never listed. So for example,
if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't
matter. Your ".git/HEAD" will still be looked up first.
Similarly, other "special heads", like ORIG_HEAD or MERGE_HEAD will be
looked up in .git, even though they will never be listed by anything.
So the "refs/" requirement is a real requirement for a "true ref", but it
is still overruled by the rule that we have special refs in $GIT_DIR that
always take precedence.
This also means, for example, that you can always give the "full" refname
for lookup, ie
git-rev-parse refs/heads/master
works, because that's the "full path" from the ".git" subdirectory. If we
only ever looked things up inside "refs", you'd have to use
"heads/master".
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-26 15:22 UTC (permalink / raw)
To: Jelmer Vernooij
Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git, Erik B?gfors
In-Reply-To: <20061024093033.GA23906@rhonwyn.vernstok.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jelmer Vernooij wrote:
> The graphical frontends to bzr, for example, don't know about revno's but
> only about revids.
Gannotate shows revnos where appropriate. Not sure about others.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFQNK60F+nu1YWqI0RAiGiAJ45IG/nHsl3/5rP23nxYLduopVj/QCfUX+9
E01mr0edaZld9aKMASRbo+o=
=YavT
^ permalink raw reply
* Re: an option to make "git-diff Z A" prints Z's diff before A's
From: Linus Torvalds @ 2006-10-26 15:16 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Jim Meyering, git
In-Reply-To: <20061026084221.GB13780@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 947 bytes --]
On Thu, 26 Oct 2006, Karl Hasselström wrote:
>
> A related question: is there a way to limit the path to Z, but
> excluding Z/B? That is, I'm interested in the changes in Z, but not
> the changes in its subdirectory B.
We never did that, no. It's certainly a relevant thing to do, and it would
be sensible to have a kind of common logic with revision parsing (where a
caret (^) at the beginning would mean "not"), but at the same time, it's
not been common enough (read: "I have personally never missed it") to
actually become an issue.
So I _think_ it would fit fairly well into the current code (just teach
the stuff that uses "char **pathspec" about that new rule), and it might
not be too bad. On the other hand, that particular code is pretty dense
and part of a very core and performance critical subsystem, so unless you
_really_ want this, you might be better off averting your eyes and just
ignoring this issue ;)
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-26 15:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehqeja$d5j$1@sea.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>>There is very little difference between this:
>>
>>http://example.com/mywebpage#5
>>
>>And this:
>>
>>http://example.com/mybranch 5
>>
>>In fact, we've been planning to unify them into one identifier.
>
>
> Well, then it is not much simpler than 8-chars sha1. And sha1 is more
> decentralized, because you can use it when you don't have access to net,
> and when the _central_ revno server is down.
What do you mean by _central_ revno server? example.com? Does that
also apply to google.com?
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFQNCc0F+nu1YWqI0RAlslAJ0XJ8Fezxyn5Ty1oAcgAo4LdQEAvQCfbWk+
vVTmHwIuhyd7lhAxMm2uMZ8=
=c4pE
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-26 15:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehq924$llq$1@sea.gmane.org>
On Thu, Oct 26, 2006 at 02:18:53PM +0200 I heard the voice of
Jakub Narebski, and lo! it spake thus:
>
> You can get similar workflow in git using 'origin'/'master' pair, I
> think.
Not the same, because as soon as your 'git pull' _can_ fast-foward, it
will. You can't merge a set of changes from another branch that's a
strict superset of yours in, without it fast-forwarding them.
I suppose you could take great care to ensure that the other branch is
never in a position to be fast-forwarded onto yours, most simply just
by making forced commits before you do a pull, but that's revolting.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-26 15:05 UTC (permalink / raw)
To: Vincent Ladeuil
Cc: Jeff King, James Henstridge, Junio C Hamano, bazaar-ng,
Matthew D. Fuller, Carl Worth, Andreas Ericsson, git,
Jakub Narebski
In-Reply-To: <877iyne4dm.fsf@alplog.fr>
On Thu, 26 Oct 2006, Vincent Ladeuil wrote:
>
> Ok, so git make a distinction between the commit (code created by
> someone) and the tree (code only).
>
> Commits are defined by their parents.
Commits are defined by a _combination_ of:
- the tree they commit (which is recursive, so the commit name indirectly
includes information EVERY SINGLE BIT in the whole tree, in every
single file)
- the parent(s) if any (which is also recursive, so the commit name
indirectly includes information about EVERY SINGLE BIT in not just the
current tree, but every tree in the history, and every commit that is
reachable from it)
- the author, committer, and dates of each (and committer is actually
very often different from author)
- the actual commit message
So a commit really names - uniquely and authoratively - not just the
commit itself, but everything ever associated with it.
> Trees are defined by their content only ?
Where "contents" does include names and permissions/types (eg execute bit
and symlink etc).
> If that's the case, how do you proceed ?
If you compare the commit name, and they are equal, you automatically know
- the trees are 100% identical
- the histories are 100% identical
If you only care about the actual tree, you compare the tree name for
equality, ie you can do
git-rev-parse commit1^{tree} commit2^{tree}
and compare the two: if and only if they are equal are the actual contents
100% equal.
> Calculate a sha1 representing the content (or the content of the
> diff from parent) of all the files and dirs in the tree ? Or
> from the sha1s of the files and dirs themselves recursively based
> on sha1s of the files and dirs they contain ?
The latter.
> I ask because the later seems to provide some nice effects
> similar to what makes BDD
> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so
> efficient: you can compare graphs of any complexity or size in
> O(1) by just comparing their signatures.
This is exactly what git does. You can compare entire trees (and
subdirectories are just other trees) by just comparing 20 bytes of
information.
How do you think we can do a diff between two arbitrary kernel revisions
so fast? Why do you think we can afford to do a
git log drivers/usb include/linux/usb*
that literally picks out the history (by comparing state) for every commit
in the tree?
I can do the above log-generation in less than ten _seconds_ for the last
year and a half of the kernel. That's 20k+ lines of logs of commits that
only touch those files and directories. And I _need_ it to be fast,
because that's literally one of the most common operations I do.
And the reason it's fast is that we can compare 20,000 files (names,
contents, permissions) by just comparing a _single_ 20-byte SHA1.
In git, revision names (and _everything_ has a revision name: commits,
trees, blobs, tags) really have meaning. They're not just random noise.
^ permalink raw reply
* [PATCH] Make filenames line up in git-status output
From: Andy Parkins @ 2006-10-26 14:17 UTC (permalink / raw)
To: git
When all the filenames line up it's much easier to copy and paste them
somewhere else, or to remove the "modified:", "copied:", etc prefix.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
wt-status.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 4b74e68..3952809 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -72,25 +72,25 @@ static void wt_status_print_filepair(int
color_printf(color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
case DIFF_STATUS_ADDED:
- color_printf(c, "new file: %s", p->one->path); break;
+ color_printf(c, "new file: %s", p->one->path); break;
case DIFF_STATUS_COPIED:
- color_printf(c, "copied: %s -> %s",
+ color_printf(c, "copied: %s -> %s",
p->one->path, p->two->path);
break;
case DIFF_STATUS_DELETED:
- color_printf(c, "deleted: %s", p->one->path); break;
+ color_printf(c, "deleted: %s", p->one->path); break;
case DIFF_STATUS_MODIFIED:
- color_printf(c, "modified: %s", p->one->path); break;
+ color_printf(c, "modified: %s", p->one->path); break;
case DIFF_STATUS_RENAMED:
- color_printf(c, "renamed: %s -> %s",
+ color_printf(c, "renamed: %s -> %s",
p->one->path, p->two->path);
break;
case DIFF_STATUS_TYPE_CHANGED:
color_printf(c, "typechange: %s", p->one->path); break;
case DIFF_STATUS_UNKNOWN:
- color_printf(c, "unknown: %s", p->one->path); break;
+ color_printf(c, "unknown: %s", p->one->path); break;
case DIFF_STATUS_UNMERGED:
- color_printf(c, "unmerged: %s", p->one->path); break;
+ color_printf(c, "unmerged: %s", p->one->path); break;
default:
die("bug: unhandled diff status %c", p->status);
}
--
1.4.3.3.g5bca6
^ permalink raw reply related
* stg mail
From: Karl Hasselström @ 2006-10-26 14:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jakub Narebski, git
In-Reply-To: <b0943d9e0610260457m780dd7d4t95fe36130cbdf551@mail.gmail.com>
On 2006-10-26 12:57:50 +0100, Catalin Marinas wrote:
> On 26/10/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Hmm. So now I know why you haven't taken my "stg email" patches. I
> > guess I'll have to fix 'stg import' then. :-)
>
> That's one of the reasons (and I didn't have time to document myself
> before giving a proper reply). The other is that Gnus (and gmail)
> doesn't display the messages properly - it shows a lot of "=20".
Hmm, this sounds like a mistake in my code, since one would expect
those two to be able to handle QP-encoded bodies properly. In fact, if
they didn't, all mails from me would look like that to you, since mutt
seems to QP-encode mails that I send.
I only viewed the mails in mutt, and they looked fine there.
> Is it possible not to affect the body (or make it optional)?
The vger mail server breaks 8bit encoded mails (which was what stg
mail generated previously), at least if they don't stick to ascii. So
if the body contains non-ascii stuff (such as my name in the sign-off
line), we do need the encoding. I could certainly do the QP-encoding
conditionally on there being non-ascii characters, though, and use
7bit or whatever it's called otherwise.
> People only using "patch" to apply the diffs would have problems
> with this encoding.
People feeding the raw email to patch would have this problem, yes.
But with the "8bit" encoding not working on all mail servers, there is
no way around this for non-ascii patches. But as I said, we certainly
could avoid QP-encoding pure ascii patches.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-26 13:53 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <4540BC6B.1050009@utoronto.ca>
Aaron Bentley wrote:
> Andreas Ericsson wrote:
>> The only issue I have with bzr's revno's and truly distributed setup is
>> that, by looking at the table, it seems to claim that you have found
>> some miraculous way to make revnos work without a central server. Since
>> everyone agrees that they don't, this should IMO be listed as mutually
>> exclusive features.
>
> The "simple namespace" is both a URL and a revno.
>
> And therefore, it's just as distributed and decentralized as the web.
>
> There is very little difference between this:
>
> http://example.com/mywebpage#5
>
> And this:
>
> http://example.com/mybranch 5
>
> In fact, we've been planning to unify them into one identifier.
Well, then it is not much simpler than 8-chars sha1. And sha1 is more
decentralized, because you can use it when you don't have access to net,
and when the _central_ revno server is down.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-26 13:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Matthew D. Fuller, bazaar-ng, David Lang, git
In-Reply-To: <45408A53.10400@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
> The only issue I have with bzr's revno's and truly distributed setup is
> that, by looking at the table, it seems to claim that you have found
> some miraculous way to make revnos work without a central server. Since
> everyone agrees that they don't, this should IMO be listed as mutually
> exclusive features.
The "simple namespace" is both a URL and a revno.
And therefore, it's just as distributed and decentralized as the web.
There is very little difference between this:
http://example.com/mywebpage#5
And this:
http://example.com/mybranch 5
In fact, we've been planning to unify them into one identifier.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFQLxr0F+nu1YWqI0RAiVrAJ9rb+uylIuxqMo2VMelI3Qm6oNQOwCfeTAb
kOkp9kOkRl1YEVEP+G3y2SU=
=Zgsg
^ permalink raw reply
* Re: [PATCH 3/3] mimic unpack-objects when --stdin is used with index-pack
From: Nicolas Pitre @ 2006-10-26 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz7jqzoo.fsf@assigned-by-dhcp.cox.net>
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > It appears that git-unpack-objects writes the last part of the input
> > buffer to stdout after the pack has been parsed. This looks a bit
> > suspicious since the last fill() might have filled the buffer up to
> > the 4096 byte limit and more data might still be pending on stdin,
> > but since this is about being a drop-in replacement for unpack-objects
> > let's simply duplicate the same behavior for now.
>
> This seems to break t5300 when applied on top of everything
> else. The other two numbered patches are Ok.
Yeah.... actually the problem appeared to me in my sleep! (Worrisome
isn't it?)
So you just need to amend this patch with:
diff --git a/index-pack.c b/index-pack.c
index 7f7dc5d..5c747a6 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -461,7 +461,7 @@ static void parse_pack_objects(unsigned
/* If input_fd is a file, we should have reached its end now. */
if (fstat(input_fd, &st))
die("cannot fstat packfile: %s", strerror(errno));
- if (S_ISREG(st.st_mode) && st.st_size != consumed_bytes + 20)
+ if (S_ISREG(st.st_mode) && st.st_size != consumed_bytes)
die("pack has junk at the end");
if (!nr_deltas)
^ permalink raw reply related
* Re: shortlog, was Re: merge-recursive, was Re: What's in git.git
From: Andreas Ericsson @ 2006-10-26 13:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610260937070.12418@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 26 Oct 2006, Andreas Ericsson wrote:
>
>> I keep writing
>> git log --short
>>
>> when I really want
>> git log --pretty=short | git shortlog
>>
>>
>> I'll have a look at making it work if I get a spare moment.
>
> Why don't you simply drop the --pretty=short altogether?
>
> git log | git shortlog
>
Dunno. Mainly because I saw the "git log --pretty=short | git shortlog"
construct somewhere, I guess. Either way, it would make more sense to
have it as --pretty=by-author or something like that instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: shortlog, was Re: merge-recursive, was Re: What's in git.git
From: Nicolas Pitre @ 2006-10-26 13:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <45409D79.8010909@op5.se>
On Thu, 26 Oct 2006, Andreas Ericsson wrote:
> I keep writing
> git log --short
>
> when I really want
> git log --pretty=short | git shortlog
>
>
> I'll have a look at making it work if I get a spare moment.
Why don't you simply drop the --pretty=short altogether?
git log | git shortlog
^ permalink raw reply
* Re: git-shortlog mailmap
From: Petr Baudis @ 2006-10-26 13:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehqaco$r4l$1@sea.gmane.org>
Dear diary, on Thu, Oct 26, 2006 at 02:41:38PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Because git-shortlog has to deal also with _historical_ data, which caused
> one way or the other to have only email and not realname recorded.
When does it in practice have to deal also with historical data, these
days?
--
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
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Nicolas Pitre @ 2006-10-26 13:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehq0md$i44$2@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 620 bytes --]
On Thu, 26 Oct 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > Karl Hasselström <kha@treskal.com> writes:
> >
> >> On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> >>
> >>> That said, git-am should understand QP with coding in mail headers.
> >>
> >> I really hope it does, since I just patched StGIT to generate such
> >> headers. (Out of pure vanity -- I don't want my name mangled!)
> >
> > Sorry for an earlier hiccup.
>
> That said, I don't think that Nicolas Pitre wanted to have "index-pâck"
> in subject instead of "index-pack".
Indeed. I don't know how that â ended up there.
Nicolas
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Nicolas Pitre @ 2006-10-26 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vlkn3o1w1.fsf@assigned-by-dhcp.cox.net>
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Johannes Schindelin wrote:
> >
> >> BTW what happened to the builtin shortlog? It is the last Perl script I
> >> use regularly... (should make people happy who are stuck with Activision
> >> Perl...)
> >
> > BTW. both Perl version and builtin shorlog have email->real name translation
> > table built in. In Perl script version it is in __DATA__ section, and we
> > could update it using Inline::Files module, in C version it was in table.
> > But in fact this list is project specific. Shouldn't we make it customizable
> > (::sigh::, yet another file in $GIT_DIR...).
>
> It already reads from .mailmap which could be tracked as part of
> the sources (if it is project specific it would be better if it
> can be shared among members).
The C version was missing that support if I remember right.
Actually I think that the email table should be removed out of the tool
entirely and always read from .mailmap instead.
^ permalink raw reply
* Re: (unknown)
From: Josef Weidendorfer @ 2006-10-26 13:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vwt6okpgr.fsf@assigned-by-dhcp.cox.net>
On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
> Heh, I spoke too fast.
>
> "git log origin..master"
>
> If you do not have none of .git/origin
Really? I thought refs are always looked up in ".git/refs" only?
> , .git/refs/origin,
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).
Yes.
However, IMHO it really should be a alias to "remotes/origin/<branch>",
depending on current "<branch>" you are on. AFAI can remember,
when implementing it, HEAD was choosen as sha1_name.c should not
cope with porcelain issues (e.g. getting current branch name).
It was the intention to change remotes/origin/HEAD in the porcelain
command before actual use.
Is this still sensible?
^ permalink raw reply
* Re: git-shortlog mailmap
From: Johannes Schindelin @ 2006-10-26 13:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehqc8r$2nc$1@sea.gmane.org>
Hi,
On Thu, 26 Oct 2006, Jakub Narebski wrote:
> Andreas Ericsson wrote:
>
> > Wouldn't this be better implemented in the rev-list code then, so all
> > log viewers can benefit from it?
>
> Because this belongs to porcelain. Plumbing shouldn't show something
> that isn't there.
Actually, I think it would make sense. Since log viewers are
porcelain-ish, they could transform the author/committer data according
to .mailmap. Of course, that means that if two people have different
mailmaps, they have to be aware of that fact when disagreeing over some
authorship.
Ciao,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: Rogan Dawes @ 2006-10-26 13:14 UTC (permalink / raw)
To: Vincent Ladeuil; +Cc: bazaar-ng, git
In-Reply-To: <87u01r9rz7.fsf@alplog.fr>
Vincent Ladeuil wrote:
>>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
>
> Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:
> >> Ok, so git make a distinction between the commit (code created by
> >> someone) and the tree (code only).
>
> Jeff> Yes (a commit is a tree, zero or more parents, commit message, and
> Jeff> author/committer info).
>
> The parents of a tree are also trees or can/must they be commits ?
This refers to the parents of a _commit_, not of a tree, and the parents
must be _commits_. The parents allow us to determine what changed
between the previous commit(s), and the current one. If there are more
than one parent, then we have a merge commit.
So, a commit refers to a tree representing the state of the code at the
time of the commit, as well as to any parent commit(s). If there are no
parent commits, then the commit is an "initial commit" (i.e. the first
checkin). A project can have multiple "initial commits", typically where
two previously independent projects are merged together, c.f. gitk and git.
>
> >> Commits are defined by their parents.
>
> Jeff> Partially, yes.
>
> I buy that this "partially" means "the other parts are irrelevant
> to this discussion".
Yes.
> >> Trees are defined by their content only ?
>
> Jeff> Yes.
>
> So it is possible that : starting from a tree T,
>
> - I make a patch A,
> - you make the patch B,
> - A and B are equal (stop watching above my shoulder please, or what is me ?),
> - we both commit,
> - we pull changes from each other repository.
>
> We will end up with a tree T2 with a hash corresponding to both
> T+A and T+B, but each of us will have a different commit id CA
> and CB both pointing to T2, did I get it ?
>
> Vincent
Yes. That is exactly right.
From there, we can either trivially merge CA and CB with a new merge
commit referring to T2, but citing both CA and CB as parents, or simply
discard one of the lines of development, depending on how much
subsequent development cited CA or CB as parents.
^ permalink raw reply
* Re: git-shortlog mailmap
From: Jakub Narebski @ 2006-10-26 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <4540AD6E.6070201@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> Petr Baudis wrote:
>>>
>>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
>>> where Jakub Narebski <jnareb@gmail.com> said that...
>>>>
>>>> BTW. both Perl version and builtin shorlog have email->real name translation
>>>> table built in. In Perl script version it is in __DATA__ section, and we
>>>> could update it using Inline::Files module, in C version it was in table.
>>>> But in fact this list is project specific. Shouldn't we make it customizable
>>>> (::sigh::, yet another file in $GIT_DIR...).
>>>>
>>> I really dislike the fact that we _do_ this mapping at all, this seems
>>> so much a totally wrong point at which to do it. The information tracked
>>> in Git is still wrong and all the tools except shortlog still display it
>>> wrong - why should shortlog in particular be special? Why don't we do
>>> this at the git-am time instead?
>>
>> Because git-shortlog has to deal also with _historical_ data, which caused
>> one way or the other to have only email and not realname recorded. So till
>> history gets rewritteen, and tags resigned, git-shortlog has to do the
>> mapping to have meaningfull output.
>
> Wouldn't this be better implemented in the rev-list code then, so all
> log viewers can benefit from it?
Because this belongs to porcelain. Plumbing shouldn't show something
that isn't there.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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