* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Johannes Schindelin @ 2005-11-20 1:24 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.19.17.23.17.920228@smurf.noris.de>
Hi,
On Sat, 19 Nov 2005, Matthias Urlichs wrote:
> [...] What can you do with such a thing that you cannot do now, just as
> easily, besides slow down your programs with an unnecessary level of
> indirection?
I tend to agree. In fact, if I would like to introduce earlier history
(for the sake of archeology or whatever), I would import the earlier
history into git, possibly finding the best match in the current
development branch (for example, when the original project continued for a
while to be tracked in CVS), and then make a merge between these two.
Then, I'd merge the new development's HEAD, and it would be fine:
ORIG1 .. ORIG2 .. .. ORIG_HEAD
|
| GIT1 .. GIT2 .. .. GIT_HEAD
| / /
| / /
UNIFYING_MERGE /
\ /
\ /
NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
Where ORIG_HEAD's tree is identical with GIT1's tree. The resulting branch
would serve every research purpose I can think of (just be sure not to
use "-m" with git-whatchanged).
Ciao,
Dscho
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Johannes Schindelin @ 2005-11-20 1:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511190950161.13959@g5.osdl.org>
Hi,
On Sat, 19 Nov 2005, Linus Torvalds wrote:
> And text with 8-bit latin1 is almost never valid utf-8.
I had the impression utf-8 was designed in a way so you could strike
"almost". But I don't have my docs handy...
Ciao,
Dscho
^ permalink raw reply
* Re: what is "rebase"?
From: Johannes Schindelin @ 2005-11-20 1:15 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fyps8bl1.fsf@blue.stonehenge.com>
Hi,
On Sun, 19 Nov 2005, Randal L. Schwartz wrote:
> Can someone point me to a simple explanation of what "rebase" is?
How about the definition in Documentation/glossary.txt?
> rebase::
> To clean a branch by starting from the head of the main line of
> development ("master"), and reapply the (possibly cherry-picked)
> changes from that branch.
Hth,
Dscho
^ permalink raw reply
* Re: still unclear on setting up a repository
From: Randal L. Schwartz @ 2005-11-20 1:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437FCC60.3090100@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> Randal L. Schwartz wrote:
>> And then, another "go-boom" problem:
>> % cg-fetch
>> Hard links don't work - using copy
>> Fetching head...
>> cp: illegal option -- d
Andreas> I think this was resolved some weeks ago. Perhaps you could try the
Andreas> latest cogito from git://git.kernel.org/pub/scm/cogito/cogito.git ?
I'm grabbing nearly hourly.
localhost:~/MIRROR/cogito-GIT % cg-status
Heads:
>master 22ff47e9b3c5fc8aa2efbc5ac8690b06b868ef6f
R origin 22ff47e9b3c5fc8aa2efbc5ac8690b06b868ef6f
Error with this version.
Andreas> As for rsync; From the output you posted above, you were setting up
Andreas> both the repositories on your local machine. Using rsync for those
Andreas> cases would be pretty stupid.
rsync instead of cp if you really need "-d".
Andreas> On a side-note, could you please turn off your spamvertising
Andreas> auto-reply? It sends me some info about your perl-expertise and
Andreas> contact-numbers every now and then. It's getting a bit annoying.
If you email me directly, you'll get that note no more than once per
month. Some day, I'll create a system to whitelist people that never
want to see it again. Damn TUIT shortage. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: still unclear on setting up a repository
From: Andreas Ericsson @ 2005-11-20 1:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86br0g883v.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
> And then, another "go-boom" problem:
>
> % cg-fetch
> Hard links don't work - using copy
> Fetching head...
> cp: illegal option -- d
I think this was resolved some weeks ago. Perhaps you could try the
latest cogito from git://git.kernel.org/pub/scm/cogito/cogito.git ?
>
> Any chance you could make this more POSIX-like? I know you have a big
> warning in README.osx, but are you *really* needing all those weird
> GNU-isms? Maybe you could fall back to using rsync to copy exactly
> what you need?
>
There aren't that many. This particular one was a typo, iirc.
As for rsync; From the output you posted above, you were setting up both
the repositories on your local machine. Using rsync for those cases
would be pretty stupid.
On a side-note, could you please turn off your spamvertising auto-reply?
It sends me some info about your perl-expertise and contact-numbers
every now and then. It's getting a bit annoying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* still unclear on setting up a repository
From: Randal L. Schwartz @ 2005-11-20 0:40 UTC (permalink / raw)
To: git
I'm really unclear here if it's me, the code, or the docs...
first, create the "remote"
% cg-admin-setuprepo remote.git
that works fine, now set up the "local"
% mkdir local.git
% cd local-git
% cg-init -m "junk message why should I have to do this one, it's dumb"
Now here's where I'm unclear. I need to "push" this into the remote,
so I try this:
% cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
% cg-branch-ls
This seems to report the right thing. I have a branch "origin"
that points at the remote repository. So far, I think I'm understanding
what's happening. But now, go boom:
% cg-push
cg-push: where to push to?
Huh? How do I do the initial push? Not this way? Is it me, docs, or
code that is broken here?
UPDATE...
aha... "cg-push origin" works. But "cg-push" is documented to
default to "origin". Why doesn't it?
And then, another "go-boom" problem:
% cg-fetch
Hard links don't work - using copy
Fetching head...
cp: illegal option -- d
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
cg-fetch: unable to get the head pointer of branch master
Any chance you could make this more POSIX-like? I know you have a big
warning in README.osx, but are you *really* needing all those weird
GNU-isms? Maybe you could fall back to using rsync to copy exactly
what you need?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* what is "rebase"?
From: Randal L. Schwartz @ 2005-11-19 23:25 UTC (permalink / raw)
To: git
Can someone point me to a simple explanation of what "rebase" is?
The git-rebase manpage doesn't define the word, or provide an example
of its use.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH, take 2] Re: Make "gitk" work better with dense revlists
From: Yann Dirson @ 2005-11-19 22:48 UTC (permalink / raw)
To: git
In-Reply-To: <20051115225740.GB28173@nowhere.earth>
On Tue, Nov 15, 2005 at 11:57:40PM +0100, Yann Dirson wrote:
> Linus wrote:
> >To generate the diff for a commit, gitk used to do
> >
> > git-diff-tree -p -C $p $id
>
> Although the "$p" reference is harmful to --dense mode, and redundant
> when we just want to look at a single commit, removing it breaks the
> "Diff this -> selected" and "Diff selected -> this" features.
As noted by Junio off-list, this original fix was not good. Here is
another try, which should be more robust, and, unlike the 1st try,
handle all cases. Also pullable from
http://ydirson.free.fr/soft/git/git.git/
commit 6483475ddd1af24fc138d36cfec986335685663e
tree 421f408703235272f7b4d86f77a451f4e6606ec3
parent 6ed64058e1241f9939c4abf5d6a9eaed6a2cc795
author Yann Dirson <ydirson@altern.org> Sat, 19 Nov 2005 23:36:16 +0100
committer Yann Dirson <dwitch@gandelf.nowhere.earth> Sat, 19 Nov 2005 23:36:16 +0100
Fix gitk this->selected diffs
The change made to accomodate dense revlists in single-commit diffs
had broken computing of diffs between arbitrary trees, which does need
to pass two commit ids, whether sparse or dense.
This patch changes the two git-diff-tree calls to get the necessary
two ids in this case. It does so by propagating a "singlecommit" flag
through all functions involved via an additionnal argument.
Signed-off-by: Yann Dirson <ydirson@altern.org>
6483475ddd1af24fc138d36cfec986335685663e
diff --git a/gitk b/gitk
index 95b05c0..e3389e2 100755
--- a/gitk
+++ b/gitk
@@ -2197,9 +2197,9 @@ proc selectline {l isnew} {
$cflist delete 0 end
$cflist insert end "Comments"
if {$nparents($id) == 1} {
- startdiff [concat $id $parents($id)]
+ startdiff [concat $id $parents($id)] 1
} elseif {$nparents($id) > 1} {
- mergediff $id
+ mergediff $id 1
}
}
@@ -2268,7 +2268,7 @@ proc goforw {} {
}
}
-proc mergediff {id} {
+proc mergediff {id singlecommit} {
global parents diffmergeid diffmergegca mergefilelist diffpindex
set diffmergeid $id
@@ -2279,7 +2279,7 @@ proc mergediff {id} {
showmergediff
}
} else {
- contmergediff {}
+ contmergediff {} $singlecommit
}
}
@@ -2299,7 +2299,7 @@ proc findgca {ids} {
return $gca
}
-proc contmergediff {ids} {
+proc contmergediff {ids singlecommit} {
global diffmergeid diffpindex parents nparents diffmergegca
global treediffs mergefilelist diffids treepending
@@ -2316,7 +2316,7 @@ proc contmergediff {ids} {
if {![info exists treediffs($ids)]} {
set diffids $ids
if {![info exists treepending]} {
- gettreediffs $ids
+ gettreediffs $ids $singlecommit
}
return
}
@@ -2794,40 +2794,45 @@ proc similarity {pnum l nlc f events} {
return [expr {200 * $same / (2 * $same + $diff)}]
}
-proc startdiff {ids} {
+proc startdiff {ids singlecommit} {
global treediffs diffids treepending diffmergeid
set diffids $ids
catch {unset diffmergeid}
if {![info exists treediffs($ids)]} {
if {![info exists treepending]} {
- gettreediffs $ids
+ gettreediffs $ids $singlecommit
}
} else {
- addtocflist $ids
+ addtocflist $ids $singlecommit
}
}
-proc addtocflist {ids} {
+proc addtocflist {ids singlecommit} {
global treediffs cflist
foreach f $treediffs($ids) {
$cflist insert end $f
}
- getblobdiffs $ids
+ getblobdiffs $ids $singlecommit
}
-proc gettreediffs {ids} {
+proc gettreediffs {ids singlecommit} {
global treediff parents treepending
set treepending $ids
set treediff {}
set id [lindex $ids 0]
set p [lindex $ids 1]
- if [catch {set gdtf [open "|git-diff-tree -r $id" r]}] return
+ if {$singlecommit == 1} {
+ set range "$id"
+ } else {
+ set range "$p $id"
+ }
+ if [catch {set gdtf [open "|git-diff-tree -r $range" r]}] return
fconfigure $gdtf -blocking 0
- fileevent $gdtf readable [list gettreediffline $gdtf $ids]
+ fileevent $gdtf readable [list gettreediffline $gdtf $ids $singlecommit]
}
-proc gettreediffline {gdtf ids} {
+proc gettreediffline {gdtf ids singlecommit} {
global treediff treediffs treepending diffids diffmergeid
set n [gets $gdtf line]
@@ -2837,12 +2842,12 @@ proc gettreediffline {gdtf ids} {
set treediffs($ids) $treediff
unset treepending
if {$ids != $diffids} {
- gettreediffs $diffids
+ gettreediffs $diffids $singlecommit
} else {
if {[info exists diffmergeid]} {
- contmergediff $ids
+ contmergediff $ids $singlecommit
} else {
- addtocflist $ids
+ addtocflist $ids $singlecommit
}
}
return
@@ -2851,14 +2856,18 @@ proc gettreediffline {gdtf ids} {
lappend treediff $file
}
-proc getblobdiffs {ids} {
+proc getblobdiffs {ids singlecommit} {
global diffopts blobdifffd diffids env curdifftag curtagstart
global difffilestart nextupdate diffinhdr treediffs
set id [lindex $ids 0]
set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [list | git-diff-tree -r -p -C $id]
+ if {$singlecommit == 1} {
+ set cmd [list | git-diff-tree -r -p -C $id]
+ } else {
+ set cmd [list | git-diff-tree -r -p -C $p $id]
+ }
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
@@ -3373,7 +3382,7 @@ proc doseldiff {oldid newid} {
$ctext conf -state disabled
$ctext tag delete Comments
$ctext tag remove found 1.0 end
- startdiff [list $newid $oldid]
+ startdiff [list $newid $oldid] 0
}
proc mkpatch {} {
--
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 related
* cg-commit doesn't like new repository
From: Alan Chandler @ 2005-11-19 22:43 UTC (permalink / raw)
To: git
I just decided to make a repository of /etc, but because I didn't want to load
in all the files, I used git-init-db to create the repository rather than
cg-init-db
I then did cg-add for fstab
followed up by cg-commit which then failed as shown below
As soon as I have done a git-commit, all is OK, and cg-commit works again.
I presume there is something that cg-init-db does which makes it suitable for
cogito - but what, and shouldn't cg-commit notice and either do it
automatically or give a different error message?
cg-commit
usage: git-diff-index [-m] [--cached] [<common diff options>] <tree-ish>
[<path>...]
common diff options:
-z output diff-raw with lines terminated with NUL.
-p output patch format.
-u synonym for -p.
--name-only show only names of changed files.
--name-status show names and status of changed files.
-R swap input file pairs.
-B detect complete rewrites.
-M detect renames.
-C detect copies.
--find-copies-harder
try unchanged files as candidate for copy detection.
-l<n> limit rename attempts up to <n> paths.
-O<file> reorder diffs according to the <file>.
-S<string> find filepair whose only one side contains the string.
--pickaxe-all
show all files diff when -S is used and hit is found.
cg-commit: Nothing to commit
root@kanger etc[master]#
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [RFC] git email submissions
From: Junio C Hamano @ 2005-11-19 21:08 UTC (permalink / raw)
To: git
In-Reply-To: <437B73E2.3080903@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> I would presume an email body would look like
>
> overall description of changes
> git log master..HEAD | git shortlog
> git diff master..HEAD | diffstat -p1
> git diff master..HEAD
> <pack file MIME attachment>
As Smurf commented, the delta data is sent twice if you sent a
pack of "^his mine" -- once as a textual diff and then the delta
data in the pack. You can slightly do better than that.
Because you are sending the diff, the pack you send does not
have to include the post-image of patch application, and I
suspect your pack would not have to contain anything other than
commit objects.
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-19 20:42 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <437F1E67.8020302@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> 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.
After thinking a bit about it, I tend to agree with what Linus
said, and would vote for the simplicity of the older way. From
usage point of view, git-repack is primarily about repacking,
and the -d option is a funny exception applicable to -a case,
only because it is so obvious (i.e. after repacking everything
into one, it is obvious any other packs are unneeded). We might
even want to make the "-a" flag to imply "-a -d" there.
^ permalink raw reply
* Re: Change encoding of RSS feed to latin-1
From: Ismail Donmez @ 2005-11-19 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <20051119201406.GA8985@puritan.petwork>
Saturday 19 November 2005 22:14 tarihinde, Nikolai Weibull şunları yazmıştı:
> Ismail Donmez wrote:
> > As the other thread grew into merits of using UTF-8 I think best fix
> > for now is putting encoding=latin-1 into RSS feed so everyone is
> > happy. After all its latin-1 encoded data not utf-8. Anyone disagrees?
> > Can we now please fix/change gitweb so xml parsers can parse it
> > without workarounding?
>
> If you know that your log-messages will be in latin-1 or UTF-8 or
> whatever encoding you like, then modify your gitweb.cgi to match. Just
> search for 'utf-8' and change it to what you prefer.
>
> What perhaps is of general interest is modifying the distributed
> gitweb.cgi to allow for easily changing the encoding on a
> per-installation basis, just like $projectroot is configurable on a
> per-installation basis.
>
> UTF-8 is still a sane default for gitweb.cgi.
I am just interested in parsing linus's tree's rss feed. And no UTF-8 is not a
sane default when the encoding used is not UTF-8. And Linus puts it it will
be latin-1 for long I guess.
Regards,
ismail
^ permalink raw reply
* Re: Change encoding of RSS feed to latin-1
From: Nikolai Weibull @ 2005-11-19 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <200511192156.23259.ismail@uludag.org.tr>
Ismail Donmez wrote:
> As the other thread grew into merits of using UTF-8 I think best fix
> for now is putting encoding=latin-1 into RSS feed so everyone is
> happy. After all its latin-1 encoded data not utf-8. Anyone disagrees?
> Can we now please fix/change gitweb so xml parsers can parse it
> without workarounding?
If you know that your log-messages will be in latin-1 or UTF-8 or
whatever encoding you like, then modify your gitweb.cgi to match. Just
search for 'utf-8' and change it to what you prefer.
What perhaps is of general interest is modifying the distributed
gitweb.cgi to allow for easily changing the encoding on a
per-installation basis, just like $projectroot is configurable on a
per-installation basis.
UTF-8 is still a sane default for gitweb.cgi.
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
^ permalink raw reply
* Change encoding of RSS feed to latin-1
From: Ismail Donmez @ 2005-11-19 19:56 UTC (permalink / raw)
To: git
Ok,
As the other thread grew into merits of using UTF-8 I think best fix for now
is putting encoding=latin-1 into RSS feed so everyone is happy. After all its
latin-1 encoded data not utf-8. Anyone disagrees? Can we now please
fix/change gitweb so xml parsers can parse it without workarounding?
Regards,
ismail
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-19 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Franck, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511190953520.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So "git repack" should _never_ call git-redundant-pack. It's always either
> wrong or pointless.
Right-o.
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Linus Torvalds @ 2005-11-19 18:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Paul Mackerras, linuxppc64-dev, Git Mailing List, Junio C Hamano,
Fredrik Kuivinen
In-Reply-To: <20051119140736.GA24901@lst.de>
[ Junio, Fredrik, you're cc'd because the "merge-one-file" logic doesn't
clean up empty directories after removing a file in merge ]
On Sat, 19 Nov 2005, Christoph Hellwig wrote:
>
> Btw, in current Linus' tree arch/ppc64/ contains various empty
> directories, anyone care to git rm -r arch/ppc64 (and include/asm-ppc64
> now) ?
Actually, a git tree can never contain an empty subdirectory (well, it
technically _can_, but it really shouldn't - the index only tracks
_files_, and directories in git are created only as needed to contain
those files. An empty directory tree - while technically possible in a
data structure sense - would be a bug in git if git ever created one).
So when you say "in current Linus' tree", I suspect that in my tree it
very much does not, but in _your_ tree the stale directories still exist
because "git pull" just hasn't removed them.
It's a git bug/misfeature: git does not remove directories when the last
file in it has been removed, simply because git doesn't actually really
even _track_ directories at all. It only tracks files that just happen to
be in directories.
[ Side note: this is not strictly true: git _will_ actually remove
directories that become empty when you switch between different branches
with "git checkout". However, even then it will not actually ever remove
a directory that contains any non-tracked files, so if you have old
object files etc, git will never remove that directory even if all the
tracked files got removed. ]
The reason I say "bug/misfeature" and not outright "bug" is the fact that
removing directories is not something that git can really always do.
Exactly because directories are often used for things that aren't tracked.
Should it just remove old object files? Hell no. Stuff git doesn't know
about (even if they have been marked in ".gitignore") it definitely
shouldn't touch.
So in general, after you've merged somebody elses tree, the final pruning
of your own old checked-out directories is really up to you.
But I agree that git should maybe at least _tell_ people about "there's a
directory there that I'm not tracking". And it could perhaps remove the
empty ones outright a bit more aggressively (ie now it effectively does it
only for "git checkout" and for the _trivial_ cases of merges that happen
with "git pull", but it doesn't do it if the merge ended up being of the
more involved case that needed higher-level - but still automatic - help).
Frederik - I don't do perl, but I think for the recursive merge strategy,
it's the "removeFile()" thing. And for the old git-merge-one-file.sh, it's
that "deleted in both or deleted in one and unchanged in the other" case.
In both cases, I think it should do something like
.. remove the file itself ..
#
# remove all directories leading up the path if they
# have become non-empty
#
path=$(dirname $path)
while [ "$path" ] && rmdir "$path"; do
path=$(dirname $path)
done
or similar.
But as mentioned, quite often, this still won't remove the directories,
since it will have various old stale build-files in them.
Linus
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Linus Torvalds @ 2005-11-19 17:56 UTC (permalink / raw)
To: Franck, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <cda58cb80511190423w1e46bf5bu@mail.gmail.com>
On Sat, 19 Nov 2005, Franck wrote:
>
> 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 ?
Gaah.
The git-redundant-pack logic has totally broken "git repack -a -d"
Junio, can we undo that, please? With "-a", redundant pack removal is
trivial (and we used to do it right, exactly because it is trivial), and
without "-a", redundant pack removal is pointless (since it will never
pack objects that are already packed).
So "git repack" should _never_ call git-redundant-pack. It's always either
wrong or pointless.
git-redundant-pack is great for "git prune", not for repack.
Linus
^ permalink raw reply
* Re: Rss produced by git is not valid xml?
From: Linus Torvalds @ 2005-11-19 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jb57wud.fsf@assigned-by-dhcp.cox.net>
On Sat, 19 Nov 2005, Junio C Hamano wrote:
>
> 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 ;-).
If you replace "assume" with "verify", then I agree.
It's pretty easy to verify whether something is valid utf-8 or not (not
trivial - you have to also check the sequences for minimality, which adds
a few extra tests, but it's certainly not complicated).
And text with 8-bit latin1 is almost never valid utf-8.
Linus
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Matthias Urlichs @ 2005-11-19 17:23 UTC (permalink / raw)
To: git
In-Reply-To: <20051119170929.GF3393@nowhere.earth>
Hi, Yann Dirson wrote:
> But the 2nd and 3rd levels are not currently distinct in git.
I don't think you *can* make them distinct. Sure, you could introduce
"change" object which refers to a couple of source trees and a destination
tree, and then create a "history" object which links previous history and
a change, but what's the point? What can you do with such a thing
that you cannot do now, just as easily, besides slow down your programs
with an unnecessary level of indirection?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"To those who wish to punish others--or at least to see them punished, if
the avengers are too cowardly to take matters in to their own hands-- the
belief in a fiery, hideous hell appears to be a great source of comfort."
[Steve Allen, "Steve Allen, on
the Bible Religion & Morality"]
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 17:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Ryan Anderson
In-Reply-To: <Pine.LNX.4.63.0511191612350.4895@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Sat, Nov 19, 2005 at 04:27:12PM +0100, Johannes Schindelin wrote:
> On Sat, 19 Nov 2005, Yann Dirson wrote:
> > - 1st level describes states that existed
> > - 2nd level describes events that occured, causing the state to change
> > - 3rd level describes the succession of events
>
> But using git's approach you have these levels. Only that you do not
> strictly record them as such:
>
> - 1st level is trees, agreed.
>
> - 2nd level is inside the commits, i.e. if you look at the tree(s)
> of the parent commit(s), you can extract that tree->tree change.
>
> - 3rd level is not just the succession of events: commit->commit
> is much stronger.
I think we do agree on this too - it's just the usual problem with
written discussions.
> By the last, I mean that in the commit, by referencing the parent(s)
> (which itself references its parent(s)) you have the whole history. And by
> validating the commit object by its SHA1, you have the history immutable,
> too.
Right. But the 2nd and 3rd levels are not currently distinct in git.
See below.
> Now, the original purpose of this thread was to discuss a way to un-graft
> some commit objects, i.e. to re-record a history which was not recorded as
> such.
>
> This may be nice for completeness purposes, but it contradicts the main
> idea behind git: You want to be certain about things. By signing off on
> some commit (together with the meta information about its parent(s) and
> the tree), you state that you actually placed your work on *that*
> particular history. And if you based your work on a commit I have, I can
> be certain that we agree.
My proposal only introduces an additional level. You will still be
able to sign history lines, and they will still be immutable.
This proposal is only meant to add some flexibility. With the current
model, if I take Linus' 2.6 tree, I only have the 2.6 history back to
2.6.12rc2. I would first like to note that any signed commit in this
tree can assert nothing prior to that version: we are only able to
check part of the history.
Now let's suppose that I am interested in adding some prior history,
say 2.6.11->2.6.12rc2. I can add the tree and commit objects for that
range, and I now want to graft to current tree. That is, I will add a
new history line, which will have to duplicate all subsequent commits
from the current tree. That includes for example duplicating
comments, whereas in my model they would belong to the level below,
and would not need duplicating: the new history line will just
reference the lower-level commits, which do contain
comment/date/author information. The history-level objects will
probably just need to contain the following information:
- commit to describe
- previous history
- history commiter, which may be distinct from the commiter of the
change
- date of the record of the history object, which will be distinct
from the commit date, except usually for the history line on which
the change author works
We can then note that:
- to provide the same level of information with current objects, the
commits on the new history line would have to also point to their
counterpart in the original history line, adding information that
belongs to the 4th level (how our view of history evolves with time)
- the number of history objects could be made much less than the
number of commits, by using a single one to describe the full path
between two branchpoints of that history line:
parent: xxxxxx
parent: yyyyyy
commit: zzzzzz
commit: aaaaaa
commit: bbbbbb
committer: ...
date: ...
> The proposed rewriting of the history is very lax about that:
>
> Say, you introduce a history line, where you start with -- say -- some
> obsolete proprietary code from some telephone company, and then change --
> say, by a primitive algorithm -- the code to match git-0.99.8, all the
> time committing with some random commit message.
>
> Then you make a graft which says git-0.99.8 was derived from that history
> , too. Now, you ungraft the tree. It looks like other developers and I
> signed off on working on a "derivative" of some obscure, copyrighted code.
No, the grafted commits should not be accessible from a
previously-signed history line. The operation you describe will
produce a different history line, and I can already do the same with
git now :)
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: Johannes Schindelin @ 2005-11-19 15:27 UTC (permalink / raw)
To: Yann Dirson; +Cc: git, Ryan Anderson
In-Reply-To: <20051119141341.GE3393@nowhere.earth>
Hi,
On Sat, 19 Nov 2005, Yann Dirson wrote:
> - 1st level describes states that existed
> - 2nd level describes events that occured, causing the state to change
> - 3rd level describes the succession of events
But using git's approach you have these levels. Only that you do not
strictly record them as such:
- 1st level is trees, agreed.
- 2nd level is inside the commits, i.e. if you look at the tree(s)
of the parent commit(s), you can extract that tree->tree change.
- 3rd level is not just the succession of events: commit->commit
is much stronger.
By the last, I mean that in the commit, by referencing the parent(s)
(which itself references its parent(s)) you have the whole history. And by
validating the commit object by its SHA1, you have the history immutable,
too.
Now, the original purpose of this thread was to discuss a way to un-graft
some commit objects, i.e. to re-record a history which was not recorded as
such.
This may be nice for completeness purposes, but it contradicts the main
idea behind git: You want to be certain about things. By signing off on
some commit (together with the meta information about its parent(s) and
the tree), you state that you actually placed your work on *that*
particular history. And if you based your work on a commit I have, I can
be certain that we agree.
The proposed rewriting of the history is very lax about that:
Say, you introduce a history line, where you start with -- say -- some
obsolete proprietary code from some telephone company, and then change --
say, by a primitive algorithm -- the code to match git-0.99.8, all the
time committing with some random commit message.
Then you make a graft which says git-0.99.8 was derived from that history
, too. Now, you ungraft the tree. It looks like other developers and I
signed off on working on a "derivative" of some obscure, copyrighted code.
Nice?
Hth,
Dscho
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-19 14:13 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson, Johannes Schindelin
In-Reply-To: <20051119140404.GD3393@nowhere.earth>
On Sat, Nov 19, 2005 at 03:04:05PM +0100, Yann Dirson wrote:
> 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.
IOW,
- 1st level describes states that existed
- 2nd level describes events that occured, causing the state to change
- 3rd level describes the succession of events
and for the record, I am likely to introduce with ArcheoloGIT a 4th
level, which will describe how our idea of history evolves over time.
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 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
* 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: 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
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