* 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
* Re: Git Notes idea.
From: Jeff King @ 2008-12-17 10:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812170420560.14632@racer>
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.
> 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.
> > 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.
> Has the tree changed? Sure it has. Because Junio committed and pushed
> some changes.
I think it is safe to say the tree generally changes for rebase, but not
necessarily for something like an amended commit, or a pull of a patch
sent by mail. So there are times when it changes, and times when it
doesn't.
And if there were some simple way of handling the times when it didn't
change at no general cost, I think going that way would be fine. But:
> And the worst part about your idea to attach notes to trees rather than
> commits: For things like Acked-by:... you very much want to annotate the
> commit, _not_ the tree. The tree is useless here. It says nothing about
> the patch, nothing about the explanation, and nothing about the history.
This is a huge cost, IMHO. I think you generally want to annotate
commits, not trees, and the semantic difference is important (but again,
I think all of the proposals are capable of doing either -- but if you
want a "show me the notes on this commit" feature to interoperate, it
needs to pick one).
> > root/
> > 12/
> > 34567890123456789012345678901234567890/
> > <type>
>
> Funny. That is Peff's proposal.
Clearly we have independent verification that it's a good idea. ;)
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox