* Re: git-clone --how-much-disk-space-will-this-cost-me? [--depth n]
From: Shawn O. Pearce @ 2008-12-17 15:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jean-Luc Herren, jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812160039180.30035@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 16 Dec 2008, Jean-Luc Herren wrote:
> > jidanni@jidanni.org wrote:
> > > JH> So maybe what you really want is an ETA display during the cloning
> > > JH> process? Sounds like a good idea to me.
>
> And then you'll end up being the unlucky bastard to be the first to
> clones the new latest revision of a repository, and ETA won't be
> available, and you'll complain about the fact that sometimes it is there
> and sometimes it is not.
>
> The fact is, fundamentally, we don't know how many bytes to push when
> generating a pack to answer the clone request. Sometimes we _could_ but
> not always. It is therefore better to be consistent and let people know
> that there is simply no ETA.
Hmm.
What if on an initial clone (no "have" lines received) we sum up
the sizes of the *.pack and all of the loose objects and sent
that as an initial size estimate. Its going to be the upper bound
of the final pack that we send. At worst it over-estimates on the
size and download finishes faster.
I'm willing to bet that most of the "big" repositories out there
don't have a lot of garbage in them. Linus' kernel repository
doesn't rewind, so he has 0 garbage. Anyone cloning from him would
get a reasonable estimate. Likewise with a Gentoo/KDE/WebKit/gcc
sort of giant tree most of that is in a huge historical pack.
That one pack file alone is completely reachable and dominates the
transfer size.
On smaller trees where people may have a lot of rebase garbage or
everything is loose the estimate will be quite a bit above what we
transfer, but how much so that it matters?
Yea, a single stray binary of some *.mpg or *.iso accidentally
added and then removed (and now unreachable) will vastly inflate
the numbers. In which case the repository owner will be encouraged
to prune when people won't clone his estimated 8 GiB download,
which is actually only 1 MiB.
--
Shawn.
^ permalink raw reply
* Re: Strange untracked file behaviour
From: Miklos Vajna @ 2008-12-17 14:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812170605300.14632@racer>
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
On Wed, Dec 17, 2008 at 06:09:16AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I just spent three hours narrowing it down to this test case (but now I
> have to catch 3 hours of sleep):
Thank you very much! :-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: fix description for enabling hooks
From: Miklos Vajna @ 2008-12-17 14:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <4948ADE8.2050804@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Wed, Dec 17, 2008 at 08:44:40AM +0100, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > This is true, but having the executable bit is necessary as well. I
> > think it would be better to just append this requirement instead of
> > replacing the old one with this.
>
> Markus's proposed new wording is correct because the .sample hooks *are*
> already executable.
I thought about the following situation: The user reads the
documentation while working in an older repo (initialized a few versions
ago). S/he sees that the .sample suffix is already missing, so s/he
assumes that the hook is already active. Which is not true, because the
+x bit is missing.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] doc/git-reset: add reference to git-stash
From: Miklos Vajna @ 2008-12-17 14:33 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200812170949.42753.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Wed, Dec 17, 2008 at 09:49:42AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> Miklos Vajna, 17.12.2008:
> > On Wed, Dec 17, 2008 at 03:59:36AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> > > ++
> > > +See also linkgit:git-stash[1].
> >
> > Manpages have a dedicated "SEE-ALSO" section. What about this?
>
> That's only appropriate if the commands are generally related to each
> other, which isn't true for git-reset and git-stash.
Ah, OK.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: Pete Wyckoff @ 2008-12-17 14:04 UTC (permalink / raw)
To: John Chapman; +Cc: Git Mailing List
In-Reply-To: <1229377952.18839.11.camel@therock.nsw.bigpond.net.au>
thestar@fussycoder.id.au wrote on Tue, 16 Dec 2008 08:52 +1100:
> On Mon, 2008-12-15 at 14:30 -0500, Pete Wyckoff wrote:
> Modifying the on_branch code is the right place to do what you want,
> however I was hoping that specifying your 'interesting' branches by
> regexp would be sufficient? All those places that do not get matched
> are effectively ignored and do not become part of the git repo.
[..]
> Do you need to use a client spec here, or is it possible to just use
> regexps? I'd like to try and avoid the need to parse the clientspec,
> that's all.
There is code to parse the client spec in git-p4, and I did hack it
to put the various depot contents in the git tree according to where
the spec says they go. Not a big hassle, and will do the same for
git-p4c if needed. (Not clean enough or tested with non-client-spec
configs to submit upstream for git-p4 though.)
> The script does try to import the full history, however it starts that
> history only at the most recent change, which is defined as a tag.
>
> Thus, if your main branch is 'trunk', then you should be able to
> manually import your changes, tag it as 'trunk/102388', to indicate
> that's p4's revision 102388 of trunk, and the script should then begin
> checking out changeset 102389. I haven't had a chance to test that
> theory yet, but it should work.
Okay, this is interesting. Would like to pursue that approach.
Except for the "manually import" part. Maybe bits of git-p4's
full-checkout model could be borrowed here? Anyway, will take a
look when you're ready.
-- Pete
^ permalink raw reply
* git clone rsync:// broken
From: demerphq @ 2008-12-17 13:45 UTC (permalink / raw)
To: git
Hi,
Summary:
There seems to be a problem with cloning via rsync in that a corrupted
packed-refs file is/maybe transmitted, and the HEAD file is not
correctly transfered.
Detail:
I've been encountering some problems getting things set up so people
can clone using rsync.
The object repository seems to transfer fine, in that the resulting
directory is the right size approximately, but the cloning fails with
the error message
warning: remote HEAD refers to nonexistent ref, unable to checkout
Inspecting the .git/HEAD file it points at refs/heads/master, which
doesn't exist as for historical reasons our master is called 'blead'.
Looking at the packed-refs file there was a duplicate incorrect entry
in the file. Which was remedied by executing
git pack-refs --all
on the source repository which improves the situation somewhat, as
after a clone fails we were able do a
git checkout -b blead origin/blead
and things seem ok. But the clone still fails as the HEAD is not correct.
If we use git://, http://, or ssh:// protocols to clone everything
transfers fine.
I checked in the #git channel and there were a number of comments by
people that helped me investigate:
because git transport via rsync seems to assume packed-refs is sorted
- which it maybe wasnt (cant check now anymore).
That caused the failure like "fatal: Duplicated ref, and SHA1s don't
match: refs/remotes/origin/p4/maint-5.10/perl"
The remaining problem is, that HEAD seems not get fetched at all
And I dont see how HEAD should get fetched in the transport.c code
The other dumb protocol aka http explicitly gets it
So i would bugreport this
For anyone wanting to try the repo is public at:
perl5.git.perl.org/perl, which works fine with http://, and git://,
but currently rsync:// is broken.
This isnt the official perl repository yet. We were planning to go
live with it tomorrow. Meaning if you do clone it please be aware that
we might replace the repository with a complete new version before it
goes live.
cheers,
Yves
ps: Im not on list, so please cc me in any replies.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Emily Ren @ 2008-12-17 13:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0812170447h7546cbf0v3151166668ad1248@mail.gmail.com>
Sverre, Johannes,
Thank you very much for sharing your good idea ! Yes, maintaining two
separate rep maybe best.
Johannes,
Does your second suggestion mean that I need to write a script and use
git hook to enable it ?
Thanks,
Emily
On Wed, Dec 17, 2008 at 8:47 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> [It is common not to top-post on this list :)]
>
> On Wed, Dec 17, 2008 at 13:35, Emily Ren <lingyan.ren@gmail.com> wrote:
>> As far as I know, gitosis can control someone readonly/writable to
>> some repo, it has no access control on branch/tag level. Am I right ?
>
> Ah, sorry, I meant to control access to different repo's for different groups.
>
>> I'll look at github and gitorious, are they free software ?
>
> IIRC gitorious is open source, but I just checked and I don't see any
> access control there; which leaves github, which is not free software
> I'm afraid.
>
> I think, as Johannes said, keeping two seperate repo's and using some
> form of access control on those would be best.
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Sverre Rabbelier @ 2008-12-17 12:47 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0812170435t32fce496q41f825c01ee7045c@mail.gmail.com>
[It is common not to top-post on this list :)]
On Wed, Dec 17, 2008 at 13:35, Emily Ren <lingyan.ren@gmail.com> wrote:
> As far as I know, gitosis can control someone readonly/writable to
> some repo, it has no access control on branch/tag level. Am I right ?
Ah, sorry, I meant to control access to different repo's for different groups.
> I'll look at github and gitorious, are they free software ?
IIRC gitorious is open source, but I just checked and I don't see any
access control there; which leaves github, which is not free software
I'm afraid.
I think, as Johannes said, keeping two seperate repo's and using some
form of access control on those would be best.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Emily Ren @ 2008-12-17 12:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0812170353y5d78f03ao1c0619c9bd68f309@mail.gmail.com>
Sverre,
Thank you for your information !
As far as I know, gitosis can control someone readonly/writable to
some repo, it has no access control on branch/tag level. Am I right ?
I'll look at github and gitorious, are they free software ?
Thanks,
Emily
On Wed, Dec 17, 2008 at 7:53 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 10:15, Emily Ren <lingyan.ren@gmail.com> wrote:
>> I want some group can pull these branches or tags from my repo, while
>> other's can't, Need I maintain two repositories ?
>
> I think gitosis should be able to do that? Otherwise you could look
> into hosting sites like github or gitorious, I think they have at
> least some form of access control, yes?
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <200812171316.21531.thomas.jarosch@intra2net.com>
Thnks!
In fact, the first line was enough!
git config --global color.diff auto
Mark
On Wed, Dec 17, 2008 at 2:15 PM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Wednesday, 17. December 2008 13:13:34 Mark Ryden wrote:
> [colors in diff]
>> What do you mean ?
>> where ? how ?
>
> This should do the trick:
>
> git config --global color.diff auto
> git config --global color.status auto
> git config --global color.branch auto
>
> Thomas
>
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Johannes Schindelin @ 2008-12-17 12:25 UTC (permalink / raw)
To: Emily Ren; +Cc: Junio C Hamano, git
In-Reply-To: <856bfe0e0812170115p73d72495ve81046127e68c281@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Emily Ren wrote:
> I want some group can pull these branches or tags from my repo, while
> other's can't, Need I maintain two repositories ?
Either that (that would be the easy method, and also the proper one, since
people would not even know what you hide), but you could patch
upload-pack so that it runs a hook with the rev-list arguments in
do_rev_list() in upload-pack.c, and die() if the hook returns non-zero.
Ciao,
Dscho
^ permalink raw reply
* Re: white spaces in a patch
From: Jeff King @ 2008-12-17 12:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Mark Ryden, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <200812171316.21531.thomas.jarosch@intra2net.com>
On Wed, Dec 17, 2008 at 01:15:56PM +0100, Thomas Jarosch wrote:
> This should do the trick:
>
> git config --global color.diff auto
> git config --global color.status auto
> git config --global color.branch auto
These days we have
git config --global color.ui auto
-Peff
^ permalink raw reply
* Re: Git Notes idea.
From: Petr Baudis @ 2008-12-17 12:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Govind Salinas, Jeff King, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812170003540.14632@racer>
On Wed, Dec 17, 2008 at 12:48:02AM +0100, Johannes Schindelin wrote:
> Again, do not limit your design by your expectations. People already talk
> about having cover letters for their patch series as notes, and Pasky
> seems to discuss tracking explicit renames with notes when he does not
> play Go, instead of maintaining repo.or.cz and git.or.cz.
I don't really play Go that much anymore! ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: white spaces in a patch
From: Sverre Rabbelier @ 2008-12-17 12:13 UTC (permalink / raw)
To: Mark Ryden; +Cc: Junio C Hamano, git
In-Reply-To: <dac45060812170344u368ffd7fx4e86253b4a13ffc7@mail.gmail.com>
On Wed, Dec 17, 2008 at 12:44, Mark Ryden <markryde@gmail.com> wrote:
> Any ideas ? does "git diff" does highlight for anyone ?
Do you have color on?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: white spaces in a patch
From: Sverre Rabbelier @ 2008-12-17 12:16 UTC (permalink / raw)
To: Mark Ryden; +Cc: Junio C Hamano, git
In-Reply-To: <dac45060812170413w7c8cffaifa1a0f3b649474e4@mail.gmail.com>
On Wed, Dec 17, 2008 at 13:13, Mark Ryden <markryde@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 2:13 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Do you have color on?
$ git config color.diff true
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: white spaces in a patch
From: Thomas Jarosch @ 2008-12-17 12:15 UTC (permalink / raw)
To: Mark Ryden; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <dac45060812170413w7c8cffaifa1a0f3b649474e4@mail.gmail.com>
On Wednesday, 17. December 2008 13:13:34 Mark Ryden wrote:
[colors in diff]
> What do you mean ?
> where ? how ?
This should do the trick:
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
Thomas
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0812170413j5ed2d9eak89df8517bc91c5fd@mail.gmail.com>
What do you mean ?
where ? how ?
Mark
On Wed, Dec 17, 2008 at 2:13 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 12:44, Mark Ryden <markryde@gmail.com> wrote:
>> Any ideas ? does "git diff" does highlight for anyone ?
>
> Do you have color on?
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Johannes Schindelin @ 2008-12-17 12:12 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812170103w1007cf4fs1e83e506c6dd909@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Emily Ren wrote:
> I created a repository, and I don't want somebody to pull some branch or
> tag from my repository with git protocol. How can I do ?
Yes, it is easy: do not push it into that repository.
If you already did, delete it in that repository.
Ciao,
Dscho
^ permalink raw reply
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 12:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0812171307460.28560@intel-tinevez-2-302>
Hello,
Thanks!
"git diff --check" indeed tells about trailing whitespace
Mark
On Wed, Dec 17, 2008 at 2:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 16 Dec 2008, Junio C Hamano wrote:
>
>> "Mark Ryden" <markryde@gmail.com> writes:
>>
>> > 2) Is there a way to get some messages about that there are white
>> > spaces when creating a git patch?
>>
>> Doesn't "git diff" highlight whitespace errors? That way, you can catch
>> errors before you make a commit that has them.
>
> Not to mention "git diff --check", which should catch them, too.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: white spaces in a patch
From: Johannes Schindelin @ 2008-12-17 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Ryden, git
In-Reply-To: <7vej07p84i.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 16 Dec 2008, Junio C Hamano wrote:
> "Mark Ryden" <markryde@gmail.com> writes:
>
> > 2) Is there a way to get some messages about that there are white
> > spaces when creating a git patch?
>
> Doesn't "git diff" highlight whitespace errors? That way, you can catch
> errors before you make a commit that has them.
Not to mention "git diff --check", which should catch them, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Sverre Rabbelier @ 2008-12-17 11:53 UTC (permalink / raw)
To: Emily Ren; +Cc: Git Mailinglist
In-Reply-To: <856bfe0e0812170115p73d72495ve81046127e68c281@mail.gmail.com>
On Wed, Dec 17, 2008 at 10:15, Emily Ren <lingyan.ren@gmail.com> wrote:
> I want some group can pull these branches or tags from my repo, while
> other's can't, Need I maintain two repositories ?
I think gitosis should be able to do that? Otherwise you could look
into hosting sites like github or gitorious, I think they have at
least some form of access control, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] gitk: force focus to main window
From: Johannes Sixt @ 2008-12-17 11:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Johannes Schindelin
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On msysGit, the focus is first on the (Tk) console. This console is then
hidden, but keeps the focus. Work around that by forcing the focus onto
the gitk window.
This fixes issue 14.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
gitk-git/gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 1c8d98e..b3d8219 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10898,4 +10898,5 @@ if {[info exists permviews]} {
addviewmenu $n
}
}
+focus -force .
getcommits {}
--
1.6.1.rc3.980.ga0bb
^ permalink raw reply related
* [PATCH] gitk: Swap positions of 'next' and 'prev' buttons in the 'Find' section.
From: Johannes Sixt @ 2008-12-17 11:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
The button order 'prev' left of 'next' feels more natural than the other
way round, in particular, compared to the order of the forward and backward
arrows that are in the line above.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
gitk-git/gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b63109b..1c8d98e 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2052,7 +2052,7 @@ proc makewindow {} {
button .tf.lbar.fnext -text [mc "next"] -command {dofind 1 1}
button .tf.lbar.fprev -text [mc "prev"] -command {dofind -1 1}
label .tf.lbar.flab2 -text " [mc "commit"] "
- pack .tf.lbar.flabel .tf.lbar.fnext .tf.lbar.fprev .tf.lbar.flab2 \
+ pack .tf.lbar.flabel .tf.lbar.fprev .tf.lbar.fnext .tf.lbar.flab2 \
-side left -fill y
set gdttype [mc "containing:"]
set gm [tk_optionMenu .tf.lbar.gdttype gdttype \
--
1.6.1.rc3.980.ga0bb
^ permalink raw reply related
* Re: white spaces in a patch
From: Mark Ryden @ 2008-12-17 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej07p84i.fsf@gitster.siamese.dyndns.org>
Hello,
I tried:
git apply patch1.txt
patch1.txt:34: trailing whitespace.
patch1.txt:53: trailing whitespace.
And
"git diff" show differences but **does not**
highlight anything.
I tried in tchs and in Bash.
Any ideas ? does "git diff" does highlight for anyone ?
Rgs,
Mark
On Wed, Dec 17, 2008 at 9:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Mark Ryden" <markryde@gmail.com> writes:
>
>> 1) Is there a way to check whether there are white spaces in this
>> file without running git-apply?
>
> "sed -n -e '/^+.*[ ]$/p' patch.txt" perhaps?
>
>> 2) Is there a way to get some messages about that there are white spaces
>> when creating a git patch?
>
> Doesn't "git diff" highlight whitespace errors? That way, you can catch
> errors before you make a commit that has them.
>
^ permalink raw reply
* Re: Git Notes idea.
From: Johannes Schindelin @ 2008-12-17 11:38 UTC (permalink / raw)
To: Jeff King; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <20081217101110.GC18265@coredump.intra.peff.net>
Hi,
On Wed, 17 Dec 2008, Jeff King wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
> > > I agree, I haven't thought of any fix along these lines other than
> > > to make gc do the clean up.
> >
> > I have, and IIRC I briefly mentioned it back then. Basically, you
> > will have to add a "git notes gc" or some such, which basically reads
> > in the whole notes, traverses all reachable commits, marking the
> > corresponding notes, and then writes out all marked notes (leaving the
> > other notes behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
Right. So my original proposal to use separate refs for separate purposes
might make sense again, so you can have private as well as public notes.
> > I wonder why you speak as if none of that had been implemented yet.
> > From my work, it is obvious that hashtable is better than sorted list
> > (except for the fan-out, which obviously wants to be an array), and
> > from Peff's it is obvious that we want to keep the hashtables in
> > memory.
>
> If he is planning on doing a separate pyrite implementation, then it
> _hasn't_ been implemented yet. And I don't care there if he uses hash
> tables or sorted lists or whatever. I think the most important thing is
> getting down the design of the _data structure_, so that we can have a
> compatible implementation inside git itself.
Well, I don't care about pyrite. As far as I am concerned, it might as
well use an incompatible version. I really don't care.
> > > IMO notes are just a generallized tag.
> >
> > IMO notes have nothing to do with a tag. Tags point to commits (or
> > other objects, but that's beside the point here). Notes are pointed
> > _to_ by commits.
>
> I think maybe we are just talking about semantics, but I think notes are
> not pointed to by commits. There is an external mapping of commits to
> notes, which is very different. I can give you the commit without you
> knowing the notes, or that the notes even exist.
>
> But in practice, I don't know if this distinction is going to influence
> any of the design or use.
You are correct, of course, that the commit does not point to the notes
explicitely, by having a SHA-1 _in_ the commit object. But the main point
still stands: you go from commit to note, not from note to commit. And
this is in stark contrast to tags, where you go from tag to commit, _not_
from commit to tag.
That is a fundamental _difference_ between tags and notes, so that I
refuse to accept the notion of notes being a generalized form of tags.
Ciao,
Dscho
^ 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