* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Junio C Hamano @ 2005-11-19 1:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511181705390.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I'm not convinced we ever really _need_ a pure "tree-to-tree" thing,
> although you can always do that by creating an extra commit with no parent
> and thus no history ;)
Nah, it is more like a commit object that records its tree and
another tree as its parent ;-).
I do not think tree-to-tree thing is very useful and that is
what I meant to say by "tree-to-tree is still stronger than
necessary".
What is recorded as a "change" by darcs feels more like "This
makes it to do Y instead of doing X", and it is not about
tree-to-tree. I know David Roundy is lurking on this list;
David, do you have any comment on this?
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-19 1:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437E697C.7090307@op5.se>
Andreas Ericsson wrote:
>>
>> You're assuming there *IS* an original (and initially main) project.
>>
>> There is another usage mode: "we're dumping CVS and switching to this
>> new-fangled git thing." I have myself done this with several projects
>> by now.
>
> I'm guessing Linus' scenario is more common. I do it myself and I'd like
> it to keep working.
>
I'm not arguing that. I'm arguing that the *option* might be useful.
-hpa
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Linus Torvalds @ 2005-11-19 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr79dcu0j.fsf@assigned-by-dhcp.cox.net>
On Fri, 18 Nov 2005, Junio C Hamano wrote:
>
> Nah, it is more like a commit object that records its tree and
> another tree as its parent ;-).
I don't think fsck would allow that. At least it wasn't _meant_ to allow
it, and it should complain about an object having the wrong type.
And I'd hope that "git-commit-tree" would refuse to write such a thing.
Linus
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 1:38 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <437DDDB1.60103@b-i-t.de>
On Fri, Nov 18, 2005 at 02:57:05PM +0100, sf wrote:
> >Indeed that emphasizes that the history lines are on living on a
> >higher level of abstraction that commits. Now what if we used
> >trees->tree commits, instead of the current commits->tree ones ? The
> >main problem would be to be able to reconstruct those history lines,
> >so that we can still extract the log - what's a better model if we
> >loose functionnality ? ;)
>
> You can traverse tree -> commit -> tree -> commit -> tree ... to get the
> history. No functionality lost.
No, that would require that a tree knows about the commits leading to
it, which would mix levels of abstraction as well.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-19 3:28 UTC (permalink / raw)
To: git
In-Reply-To: <20051118200217.GA2831@vrfy.org>
I just looked at the diff this commit introduces:
e6bd23911efd0a2bd756c77d9e7ba6576eb739a1
Documentation: asciidoc sources are utf-8
with gitk (BTW, I pulled from paulus today, so "master" branch
has the latest gitk) while my locale set to LC_CTYPE=en_US.utf8.
Surprisingly, the diff to Documentation/git-pack-redundant.txt,
which changes Lukas' name originally incorrectly encoded in
iso-8859-1 to utf-8, was shown and both pre-image and post-image
lines are readable.
I do not know how tcl/tk does it, but it is doing the right
thing.
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: H. Peter Anvin @ 2005-11-19 4:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64qpco40.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I just looked at the diff this commit introduces:
>
> e6bd23911efd0a2bd756c77d9e7ba6576eb739a1
> Documentation: asciidoc sources are utf-8
>
> with gitk (BTW, I pulled from paulus today, so "master" branch
> has the latest gitk) while my locale set to LC_CTYPE=en_US.utf8.
>
> Surprisingly, the diff to Documentation/git-pack-redundant.txt,
> which changes Lukas' name originally incorrectly encoded in
> iso-8859-1 to utf-8, was shown and both pre-image and post-image
> lines are readable.
>
> I do not know how tcl/tk does it, but it is doing the right
> thing.
>
Tcl/Tk assumes that anything that isn't valid UTF-8 is Latin-1.
-hpa
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Marco Costalba @ 2005-11-19 6:31 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git@vger.kernel.org
H. Peter Anvin wrote:
> Junio C Hamano wrote:
>
>> I just looked at the diff this commit introduces:
>>
>> e6bd23911efd0a2bd756c77d9e7ba6576eb739a1
>> Documentation: asciidoc sources are utf-8
>>
>> with gitk (BTW, I pulled from paulus today, so "master" branch
>> has the latest gitk) while my locale set to LC_CTYPE=en_US.utf8.
>>
>> Surprisingly, the diff to Documentation/git-pack-redundant.txt,
>> which changes Lukas' name originally incorrectly encoded in
>> iso-8859-1 to utf-8, was shown and both pre-image and post-image
>> lines are readable.
>>
>> I do not know how tcl/tk does it, but it is doing the right
>> thing.
>>
>
> Tcl/Tk assumes that anything that isn't valid UTF-8 is Latin-1.
>
> -hpa
> -
My locale is set to LC_CTYPE=it_IT (local codec is ISO 8859-15).
Gitk shows correctly pre-image lines, but not post-image. BTW it's
the same output I have with
git-diff-tree -p e6bd23911efd0a2bd756c77d9e7ba6576eb739a1
run from KDE Konsole.
So I think the local encoding (LC_CTYPE) has a role in the story.
Marco
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] gitk: moving all three panes if clicking on an arrow.
From: Junio C Hamano @ 2005-11-19 8:31 UTC (permalink / raw)
To: paulus; +Cc: Stefan-W. Hahn, git
In-Reply-To: <20051105195529.GB6081@scotty.home>
"Stefan-W. Hahn" <stefan.hahn@s-hahn.de> writes:
> [PATCH] gitk: moving all three panes if clicking on an arrow.
>
> Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Obviously correct and much more pleasant to use.
Acked-by: Junio C Hamano <junkio@cox.net>
Paul, I earlier sent a pull request; I included this patch there
as well. So you will find the following four.
commit e3fe532ddce7311cfbbdc98d2e157d33f6275231
Author: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Date: Sat Nov 5 20:55:29 2005 +0100
gitk: moving all three panes if clicking on an arrow.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit fd913b39101c6ff185e76e459479621c9b475fa1
Author: Pavel Roskin <proski@gnu.org>
Date: Fri Nov 11 10:09:12 2005 -0500
gitk: use git-diff-tree --no-commit-id
gitk switched to use git-diff-tree with one argument in gettreediffs and
getblobdiffs. git-diff-tree with one argument outputs commit ID in from
of the patch. This causes an empty line after "Comments" in the lower
right pane. Also, the diff in the lower left pane has the commit ID,
which is useless there.
This patch makes git use the newly added -no-commit-id option for
git-diff-tree to suppress commit ID. It also removes the p variable in
both functions, since it has become useless after switching to the
one-argument invocation for git-diff-tree.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit e246483dc5b56d7deb04a93b0aa08aba4cde0625
Author: Frank Sorenson <frank@tuxrocks.com>
Date: Sun Oct 30 02:06:46 2005 -0700
gitk: Specify line hover font
Hovering over a line in gitk displays the commit one-liner in a
box, but the text usually overflows the box. The box size is
computed with a specified font, so this patch sets the text font
as well.
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit 36a7cad6e4ae8a331731666d985a7619a76bb4fb
Author: Junio C Hamano <junkio@cox.net>
Date: Fri Nov 18 23:54:17 2005 -0800
readrefs: grab all refs with one call to ls-remote.
Instead of reading refs/heads/* and refs/tags/* files ourselves
and missing files in subdirectories of heads/ and tags/, use
ls-remote on local repository and grab all of them. This lets us
also remove the procedure readotherrefs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-19 8:48 UTC (permalink / raw)
To: Ismail Donmez; +Cc: git
In-Reply-To: <200511182329.52368.ismail@uludag.org.tr>
Ismail Donmez <ismail@uludag.org.tr> writes:
> Your produced XML is NOT valid then. You put encoding=utf-8 and then put
> latin-1 encoded data in it. You SHOULD NOT do that. Either put latin-1 as
> encoding in the RSS because you say its the way data should be else encode
> non-utf stuff to be utf-8.
Maybe, but that is not me ;-).
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Andreas Ericsson @ 2005-11-19 8:49 UTC (permalink / raw)
To: git
In-Reply-To: <437E7E3E.4040303@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>>
>>> You're assuming there *IS* an original (and initially main) project.
>>>
>>> There is another usage mode: "we're dumping CVS and switching to this
>>> new-fangled git thing." I have myself done this with several
>>> projects by now.
>>
>>
>> I'm guessing Linus' scenario is more common. I do it myself and I'd
>> like it to keep working.
>>
>
> I'm not arguing that. I'm arguing that the *option* might be useful.
>
Isn't it already? You can install and use any hooks you like after all.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Junio C Hamano @ 2005-11-19 10:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511181653191.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Although right now "-u" doesn't actually _force_ a conversion: if you have
> an email with 8-bit characters and no character set mentioned, it will
> silently just do nothing, and the end result won't be valid UTF-8 after
> all.
... unless it was already utf8, that is. I have received a
couple of patches with charset=utf-8; I think cte of them were
qp, which was a bit unpleasant.
> If we want utf-8, we should probably force it, and default to the latin1
> translation (with some way to specify alternatives).
Well, some people on the list seem to think UTF-8 is the one and
only right encoding, so for them if the message does not
identify what it is in, assuming UTF-8 and not doing any
conversion is probably the right thing ;-).
This suggests a few flags (config items) to mailinfo:
(1) if we pass thru the input intact or not (1 bit);
(2) what charset to assume if the mail does not identify
itself (default to latin1; specify "barf" to mean abort
processing if a message with 8-bit character does not
identify itself);
(3) what we do when the mail does not transliterate
correctly (1 bit -- fail, or remove offending bytes and
pretend things are peachy -- defaulting on the stricter
side);
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-19 10:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437EE72A.3050704@op5.se>
Hi,
On Sat, 19 Nov 2005, Andreas Ericsson wrote:
> Isn't it already? You can install and use any hooks you like after all.
Exactly. All you have to do is provide a recipe for Documentation/howto/.
Anybody wanting to enforce policy just takes that recipe, adjusts it for
her needs, and installs the hook.
Hth,
Dscho
^ permalink raw reply
* git --exec-path conversion
From: Marco Costalba @ 2005-11-19 11:14 UTC (permalink / raw)
To: junkio; +Cc: git
Hi,
if I understood correctly, git programs will be installed somewhere in $PATH for at least next
two months.
But I would like to update to what will be the future, i.e. prepending what 'git --exec-path' says
to any git command.
I don't call git programs directly but I use a function QGit::run(cmd) that does this plus other
things.
The problem is that I call QGit::run() also for other commands not related to git (ls, cat,
etc..).
How can I make the transition?
Now I have two ways, the brute force way and the easy (peraphs tricky) way.
The brute force is to create a new function QGit::runGitCmd() that deals only with git commands
_and_ replace all the occurences of run() with the latter.
The easy way is to prepend the exec-path *inside* run(), and to use to disambiguate bewteen git
and shell commands the testing of first three chars of the command to launch, something like:
if (cmd.left(3) == "git")
cmd = cmd.prepend(exec-path);
I would like to go with the second one, I'm a bit lazy ;-) , but I would like to ask if this is a
good policy, i.e. if also inside git programs/scripts (like in git.c I guess) is used or is
foreseen to keep using something like this.
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git --exec-path conversion
From: Johannes Schindelin @ 2005-11-19 11:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: junkio, git
In-Reply-To: <20051119111444.82122.qmail@web26309.mail.ukl.yahoo.com>
Hi,
On Sat, 19 Nov 2005, Marco Costalba wrote:
> if (cmd.left(3) == "git")
> cmd = cmd.prepend(exec-path);
Little nit: Test for "git-", because "git" and "gitk" will stay in the
PATH.
Ciao,
Dscho
^ permalink raw reply
* Re: git --exec-path conversion
From: Marco Costalba @ 2005-11-19 11:32 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: junkio, git@vger.kernel.org
Johannes Schindelin wrote:
>Hi,
>
>On Sat, 19 Nov 2005, Marco Costalba wrote:
>
>> if (cmd.left(3) == "git")
>> cmd = cmd.prepend(exec-path);
>
>
>Little nit: Test for "git-", because "git" and "gitk" will stay in the
>PATH.
>
You are rights. Thanks.
Also 'exec-path' is not a valid C++ identifier, it should be
if (cmd.left(4) == "git-")
cmd = cmd.prepend(exec_path);
Incredible how many errors in only two lines of code :-)
Marco
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
^ permalink raw reply
* Re: git --exec-path conversion
From: Junio C Hamano @ 2005-11-19 12:04 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20051119111444.82122.qmail@web26309.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> if I understood correctly, git programs will be installed
> somewhere in $PATH for at least next two months.
I suspect things will stay in /usr/bin longer than that, but
futureproofing is good in any case.
Assuming you are writing things in C or C++:
- run "git --exec-path" at the very beginning of main(),
- read the output, prepend it to $PATH using setenv(3).
and I think you are done. After this, your QGit::run("ls") and
QGit::run("git frotz") would not be affected (you still have
/usr/bin in your $PATH), and QGIT::run("git-frotz") would find
git-frotz installed somewhere outside /usr/bin.
^ permalink raw reply
* Re: git --exec-path conversion
From: Junio C Hamano @ 2005-11-19 12:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, junkio, git
In-Reply-To: <Pine.LNX.4.63.0511191218370.27986@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Little nit: Test for "git-", because "git" and "gitk" will stay in the
> PATH.
Heh, he is writing QGit; why should he run gitk ;-)?
^ permalink raw reply
* [PATCH] git-proxy updates.
From: Junio C Hamano @ 2005-11-19 12:13 UTC (permalink / raw)
To: Paul Collins; +Cc: git
In-Reply-To: <871x1wbgvn.fsf_-_@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> Here is an updated patch that first looks for GIT_PROXY_COMMAND in the
> environment and then git.proxycommand in the repository's
> configuration file.
Sorry for holding onto your patch without any action (other than
looking at it, which from your end you cannot tell I was doing
;-). I think we will benefit from your patch in some form, and
here is what I tried on top to update it to the multivalue
configuration syntax Linus suggested during the list discussion.
Requesting for comments the original author and from the general
public.
I suspect this touches the same area as the user-path series
Andreas Ericsson has been working on, so it might need some
adjusting after that patch series goes in. I'll see that soon
enough when I make the proposed updates branch tomorrow.
-- >8 --
This builds on top of the git-proxy mechanism Paul Collins did,
and updates its configuration mechanism.
* GIT_PROXY_COMMAND environment variable is used as the
catch-all fallback, as in the original. This has not
changed.
* Renames proxy configuration variables to core.gitproxy; this
has become a multi-value variable per list discussion, most
notably from suggestion by Linus.
[core]
;# matches www.kernel.org as well
gitproxy = netcatter for kernel.org
gitproxy = netscatter for sample.xz
gitproxy = none for mydomain.xz
gitproxy = netcatter-default
The values are command names, followed by an optional " for "
and domainname; the first tail-match of the domainname
determines which proxy command is used. An entry without "
for " matches any domain and can be used as the default.
The command name "none" is special -- it tells the mechanism
not to use any proxy command and use the native git://
connection.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
connect.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 45 insertions(+), 7 deletions(-)
applies-to: d4a5ace05fd892cb455f330d379cdaa69dc6005c
c1d7ac7b4680202d3549a72188f372367ac8837c
diff --git a/connect.c b/connect.c
index 43eec67..11a804f 100644
--- a/connect.c
+++ b/connect.c
@@ -449,25 +449,63 @@ static int git_tcp_connect(int fd[2], co
#endif /* NO_IPV6 */
static char *git_proxy_command = NULL;
+static const char *rhost_name = NULL;
+static int rhost_len;
static int git_proxy_command_options(const char *var, const char *value)
{
- if (git_proxy_command == NULL) {
- if (!strcmp(var, "git.proxycommand")) {
- git_proxy_command = xmalloc(strlen(value) + 1);
- strcpy(git_proxy_command, value);
+ if (!strcmp(var, "core.gitproxy")) {
+ if (git_proxy_command)
return 0;
+ /* [core]
+ * ;# matches www.kernel.org as well
+ * gitproxy = netcatter-1 for kernel.org
+ * gitproxy = netcatter-2 for sample.xz
+ * gitproxy = netcatter-default
+ */
+ const char *for_pos = strstr(value, " for ");
+ int matchlen = -1;
+ int hostlen;
+
+ if (!for_pos)
+ /* matches everybody */
+ matchlen = strlen(value);
+ else {
+ hostlen = strlen(for_pos + 5);
+ if (rhost_len < hostlen)
+ matchlen = -1;
+ else if (!strncmp(for_pos + 5,
+ rhost_name + rhost_len - hostlen,
+ hostlen) &&
+ ((rhost_len == hostlen) ||
+ rhost_name[rhost_len - hostlen -1] == '.'))
+ matchlen = for_pos - value;
+ else
+ matchlen = -1;
+ }
+ if (0 <= matchlen) {
+ /* core.gitproxy = none for kernel.org */
+ if (matchlen == 4 &&
+ !memcmp(value, "none", 4))
+ matchlen = 0;
+ git_proxy_command = xmalloc(matchlen + 1);
+ memcpy(git_proxy_command, value, matchlen);
+ git_proxy_command[matchlen] = 0;
}
+ return 0;
}
return git_default_config(var, value);
}
-static int git_use_proxy(void)
+static int git_use_proxy(const char *host)
{
+ rhost_name = host;
+ rhost_len = strlen(host);
git_proxy_command = getenv("GIT_PROXY_COMMAND");
git_config(git_proxy_command_options);
- return git_proxy_command != NULL;
+ rhost_name = NULL;
+ return (git_proxy_command && *git_proxy_command);
}
static int git_proxy_connect(int fd[2], const char *prog, char *host, char *path)
@@ -550,7 +588,7 @@ int git_connect(int fd[2], char *url, co
}
if (protocol == PROTO_GIT) {
- if (git_use_proxy())
+ if (git_use_proxy(host))
return git_proxy_connect(fd, prog, host, path);
return git_tcp_connect(fd, prog, host, path);
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-19 12:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511171443000.13959@g5.osdl.org>
2005/11/17, Linus Torvalds <torvalds@osdl.org>:
>
> > On Thu, 17 Nov 2005, Franck wrote:
> >
> > ok that's what I was trying to do by killing the parent object. Now
> > when looking a the graph using gitk all old objects have been removed.
> > But I'm suprised because the git repository is the same size as it was
> > before pruning all old objects. Can you explain why ?
>
> make sure you re-pack if it was packed. "git prune" will not remove packs
> at all, so..
>
I just looked at git-prune script and it seems to remove unreachable
objects only in .git/objects/[0-9a-f][0-9a-f] directories, not in pack
files.
Then by running git-repack -a -d, I build a new small pack that
contains only latest objects, but then the script runs
git-redundant-pack script which erases the new small one since all its
objects are included in the old big one. Is that correct ? If so
git-redundant-pack script could return the oldest redundant ?
Thanks
--
Franck
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Lukas Sandström @ 2005-11-19 12:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Franck
In-Reply-To: <cda58cb80511190423w1e46bf5bu@mail.gmail.com>
Franck wrote:
> 2005/11/17, Linus Torvalds <torvalds@osdl.org>:
>
>>>On Thu, 17 Nov 2005, Franck wrote:
>>>
>>>ok that's what I was trying to do by killing the parent object. Now
>>>when looking a the graph using gitk all old objects have been removed.
>>>But I'm suprised because the git repository is the same size as it was
>>>before pruning all old objects. Can you explain why ?
>>
>>make sure you re-pack if it was packed. "git prune" will not remove packs
>>at all, so..
>>
>
>
> I just looked at git-prune script and it seems to remove unreachable
> objects only in .git/objects/[0-9a-f][0-9a-f] directories, not in pack
> files.
>
> Then by running git-repack -a -d, I build a new small pack that
> contains only latest objects, but then the script runs
> git-redundant-pack script which erases the new small one since all its
> objects are included in the old big one. Is that correct ? If so
> git-redundant-pack script could return the oldest redundant ?
>
> Thanks
> --
> Franck
The reason the old pack is kept instead of the new one is that it
is a proper superset of the new one.
The "git-repack -a -d" case is fixed in Junios master, and I have sent out
a patch which lets you pipe git-fsck-objects --full --unreachable to
git-pack-redundant in the other cases, so the problem should hopefully
be resolved shortly.
/Lukas
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 13:16 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511181654.21052.Josef.Weidendorfer@gmx.de>
On Fri, Nov 18, 2005 at 04:54:20PM +0100, Josef Weidendorfer wrote:
> On Friday 18 November 2005 00:07, Yann Dirson wrote:
> > Current commit objects refer to a child tree, but to parent _commits_.
> > Whereas it seems necessary to walk through the history line, and
> > easily get a changelog, it is semantically quite not right: the
> > changes we record with a commit indeed come from modification of
> > trees, not of commits.
>
> Yes. The change to a tree (which is equalent to 2 trees - new old and
> the new one; or for merges multiple old ones and the new one) does not
> depend on any history. Unfortunately, we have no separate object to
> specify the "the change to a tree". We include this information into
> the commit object, and thus, bind it to the history.
>
> This could be changed in git, i.e. put the tree relationship into a
> separate object; even comments could be split up in change related and
> history related. The question is: is this useful, is there any
> important usage scenario that rectifies such a change?
The scenario I have it mind is "archeological work" - see my post
under "info/grafts file" for details. With luck for future work
vendors will switch to git and give access to their git history (or
use quilt or stgit and provide detailed patch stacks), so the need
could well disappear, but I would not could on it, as there are still
many firms working on a 2.4 base and only exporting monolithic
patches.
> > That is, the resulting tree does not depend on
> > the history of the parent trees, but on the parent trees themselves.
>
> No, the resulting tree is an independent object, it is the tree ;-)
> Do not confuse this with the commit pointing to the tree.
Right, that was a wrong wording. I meant the resulting tree results
from the change and and the parent trees themselves, not from the
change and the previous history.
> But tags for commit objects are equally useful, especially signed ones:
> they include a fixed history which can not be changed. Eg. they include
> all the people which attributed code to the project, and this is important
> for license questions. This is the reason that "grafting" should stay
> a local workaround.
This, and chaining commits is also useful to prevent loops, as said in
another part of this thread. But I wouldn't let such considerations
stop exploration first. If we cannot find a reasonable and useful way
of applying those ideas without taking these 2 points into account as
a first approximation, there would be no point in adding these 2
constraints right away :). It can be sufficient for now to be aware
of those and add them later.
> > Indeed that emphasizes that the history lines are on living on a
> > higher level of abstraction that commits.
>
> Hmm.. If you only have tree changes, there is no history. The history
> specifies an order of the changes. The changes themselve do not include
> any such order.
Right, but that does not mean we cannot reconstruct history from those
changes. It came to my mind during the last day, that if we had
commits only reference trees, we could construct from them the
equivalent of today's commit objects (which I'll call "history
objects" for clarity), but we could look at those generated "history
objects" as "cached" objects. Together with a cache of tree->commit
reverse-mapping objects as Stephan mentionned, we could generate them
on-the-fly at commit time.
Remember that in a first approach, I'll only consider those history
objects as a means to get a history log or similar.
That would give us low-intrusion grafts: we can regenerate the
relevant part of the "history object" cache when a commit gets added
or replaced, similarly to what would be done at commit-creation time.
But we would not need to regenerate all subsequent commit objects, so
that all refs/tags pointing to those subsequent commits would not need
to be messed with.
Since we would then have history objects looking like current commits,
we could even get a similar safeguard against history loops.
And if we want to get the "signed tag certifies history" stuff, we
could envision making some of these history objects permanent. But if
we allow history object to refer to tree parents as well, we do not
_need_to_ certify on every such tag the entire history plus changes
since the previous tag: a chain of "history objects" could stop on a
tree, thus making the tag a certificate of an incremental patch (ie,
what we get from signed patches in pub/linux/kernel, with the added
bonus of signing the invididual bits making up this patch).
> > However, I must admit that at this point, I have not found a
> > reasonable solution to this problem.
> >
> > Any genius with a solution out there ? :)
>
> What is the difficult problem here?
Getting a pure superset of the functionnality we currently have (while
not impairing git use in term of computing time). But finally that
may not be as hard as I expected :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vr79dcu0j.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 18, 2005 at 05:21:16PM -0800, Junio C Hamano wrote:
> I do not think tree-to-tree thing is very useful and that is
> what I meant to say by "tree-to-tree is still stronger than
> necessary".
>
> What is recorded as a "change" by darcs feels more like "This
> makes it to do Y instead of doing X", and it is not about
> tree-to-tree.
I'm not sure we could go that path. I see git and darcs as quite
opposed in approach, since darcs works by explicitely describing the
structure of changes, whereas git allows to use arbitrary ways to
derive this structure from the trees.
But then if we could reconcile those 2 approaches...
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: git --exec-path conversion
From: Marco Costalba @ 2005-11-19 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>Marco Costalba <mcostalba@yahoo.it> writes:
>
>>if I understood correctly, git programs will be installed
>>somewhere in $PATH for at least next two months.
>
>
>I suspect things will stay in /usr/bin longer than that, but
>futureproofing is good in any case.
>
>Assuming you are writing things in C or C++:
>
> - run "git --exec-path" at the very beginning of main(),
> - read the output, prepend it to $PATH using setenv(3).
>
>and I think you are done.
Yes. Thanks.
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
^ permalink raw reply
* Re: git --exec-path conversion
From: Johannes Schindelin @ 2005-11-19 13:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: junkio, git@vger.kernel.org
In-Reply-To: <20051119113247.91022.qmail@web26311.mail.ukl.yahoo.com>
Hi,
On Sat, 19 Nov 2005, Marco Costalba wrote:
> Incredible how many errors in only two lines of code :-)
If you want to know how to introduce 3 bugs in just 512 bytes of
production code (i.e. not a development version), see
http://www.xbox-linux.org/wiki/The_Hidden_Boot_Code_of_the_Xbox
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 14:04 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.63.0511180026080.18775@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, Nov 18, 2005 at 12:28:56AM +0100, Johannes Schindelin wrote:
> On Fri, 18 Nov 2005, Yann Dirson wrote:
>
> > Current commit objects refer to a child tree, but to parent _commits_.
> > Whereas it seems necessary to walk through the history line, and
> > easily get a changelog, it is semantically quite not right:
>
> Yes, it is. You base *your* work on *some* work. So, even if the trees may
> be equal, the base isn't.
Hm, I'm not sure I get your point here.
> > Indeed that emphasizes that the history lines are on living on a
> > higher level of abstraction that commits. Now what if we used
> > trees->tree commits, instead of the current commits->tree ones ?
>
> Now, how exactly would that be more abstract? Trees are just that:
> collections of files. Noone tells you what the idea was, which led from
> the last tree(s) to this one. That is not abstract.
Trees have an existence outside any consideration of what changes led
to them, as shown by the fact that git trees do not reference anything
outside them. And it is right that, at that level, noone tells you
how you got there - not less nor more than when you fetch a
linux-x.y.z.tar.gz2 from kernel.org.
Then at a bit higher level, you can consider changes from a tree to a
tree. What you usually do when you commit a change is explaining what
you change to the tree. Then changes themselves are just derived from
the trees (iow, "abstracted from" the trees), and you augment this
information with a message explaining what you did.
Then at a still higher level, you can derive history lines from the
individual trees and changes, and augment this information, eg. by
signing them.
The fact is, currently git does not distinguish much between those 2nd
and 3rd levels. It is my understanding that one of the most basic
design decisions of git was precisely to make the tool "aware" of the
1st level, and that it played an important part of why git works so
well: it maps to the reality closer than any other tool.
I was not convinced at all by the ideas when git appeared, but that
was probably because I was too much influenced by previous tools, all
focussing either on the history line (most of them), or on the changes
(darcs).
I think that if we can formalize into git the disctinction between
those two higher levels (and possibly other levels in the future), we
could get to an even more powerful and usable tool, even if, like git,
the basic ideas may look weird and possibly even counter-productive at
first sight.
As an example, here is an idea I had while formalizing the above 3rd
level: we also work at this level when rolling back a previous change,
since we take the history line into account. We could add, at that
History level, the possiblity to record this information, by linking
to that previous commit.
Now maybe I was mistaken in thinking the objects at the History level
should be only "cached" and temporary objects - that, and loop
prevention, and signed history lines, make too many reasons for them
to be permanent already :).
But their existence as such should not prevent to work at a lower
level. I'll have to reconsider the way I intended to design my
ArcheoloGIT toolkit, but I'm afraid it would need a new generation of
GIT ;)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ 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