* bug#1571: only one word about git in (info "(emacs)Version Control")
From: jidanni @ 2008-12-15 16:15 UTC (permalink / raw)
To: bug-gnu-emacs
In (info "(emacs)Version Control") there is literally only one word
about git, on (info "(emacs)Customizing VC"). Somebody who has used
git for more than a few minutes should add something.
emacs-version "22.2.1"
(I added X-Debbugs-CC: git@vger.kernel.org (lest I use a real CC
causing bug number escalation), but it seems the git list filters
things coming in from the side.)
^ permalink raw reply
* Re: [PATCH] Documentation: fix description for enabling hooks
From: Johannes Sixt @ 2008-12-17 7:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <20081217041312.GZ5691@genesis.frugalware.org>
Miklos Vajna schrieb:
> On Wed, Dec 17, 2008 at 03:59:23AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> Since f98f8cb (Ship sample hooks with .sample suffix, 2008-06-24) hooks
>> are not enabled by making them executable anymore, but by removing the
>> '.sample' suffix from the filename.
>
> 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.
-- Hannes
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Petr Baudis @ 2008-12-17 8:10 UTC (permalink / raw)
To: Matt Kraai; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20081216142357.GF4529@ftbfs.org>
Hi,
On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:
> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
> > But a change to the function signature of feature subroutines is not
> > something I'd like to apply while other series that want to add new
> > features are still cooking. How about doing these two patches as the
> > first thing that goes to 'next' after 1.6.1, and then force other series
> > rebase on top of your change? Alternatively, we could make you wait until
> > other series do settle in 'next' and then apply your change rebased on
> > them, but I think that is probably less optimal.
>
> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
> released. Thanks for your help,
is it worth keeping them separate? Just a single patch makes more sense
to me, the interface is much nicer in the latter than in the former. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Move 'lineno' id from link to row element in git_blame
From: Petr Baudis @ 2008-12-17 8:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Luben Tuikov
In-Reply-To: <20081209224330.28106.18301.stgit@localhost.localdomain>
On Tue, Dec 09, 2008 at 11:46:16PM +0100, Jakub Narebski wrote:
> Move l<line number> ID from <a> link element inside table row (inside
> cell element for column with line numbers), to encompassing <tr> table
> row element. It was done to make it easier to manipulate result HTML
> with DOM, and to be able write 'blame_incremental' view with the same,
> or nearly the same result.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
^ permalink raw reply
* Re: [PATCH 2/3 (edit v2)] gitweb: Cache $parent_commit info in git_blame()
From: Petr Baudis @ 2008-12-17 8:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Nanako Shiraishi, git, Luben Tuikov
In-Reply-To: <200812110133.33124.jnareb@gmail.com>
On Thu, Dec 11, 2008 at 01:33:29AM +0100, Jakub Narebski wrote:
> Luben Tuikov changed 'lineno' link from leading to commit which gave
> current version of given block of lines, to leading to parent of this
> commit in 244a70e (Blame "linenr" link jumps to previous state at
> "orig_lineno"). This made possible data mining using 'blame' view.
>
> The current implementation calls rev-parse once per each blamed line
> to find parent revision of blamed commit, even when the same commit
> appears more than once, which is inefficient.
>
> This patch attempts to mitigate this issue by storing (caching)
> $parent_commit info in %metainfo, which makes gitweb call
> git-rev-parse only once per each unique commit in blame output.
>
>
> In the tables below you can see simple benchmark comparing gitweb
> performance before and after this patch
>
> File | L[1] | C[2] || Time0[3] | Before[4] | After[4]
> ====================================================================
> blob.h | 18 | 4 || 0m1.727s | 0m2.545s | 0m2.474s
> GIT-VERSION-GEN | 42 | 13 || 0m2.165s | 0m2.448s | 0m2.071s
> README | 46 | 6 || 0m1.593s | 0m2.727s | 0m2.242s
> revision.c | 1923 | 121 || 0m2.357s | 0m30.365s | 0m7.028s
> gitweb/gitweb.perl | 6291 | 428 || 0m8.080s | 1m37.244s | 0m20.627s
>
> File | L/C | Before/After
> =========================================
> blob.h | 4.5 | 1.03
> GIT-VERSION-GEN | 3.2 | 1.18
> README | 7.7 | 1.22
> revision.c | 15.9 | 4.32
> gitweb/gitweb.perl | 14.7 | 4.71
>
> As you can see the greater ratio of lines in file to unique commits
> in blame output, the greater gain from the new implementation.
>
> Footnotes:
> ~~~~~~~~~~
> [1] Lines:
> $ wc -l <file>
> [2] Individual commits in blame output:
> $ git blame -p <file> | grep author-time | wc -l
> [3] Time for running "git blame -p" (user time, single run):
> $ time git blame -p <file> >/dev/null
> [4] Time to run gitweb as Perl script from command line:
> $ gitweb-run.sh "p=.git;a=blame;f=<file>" > /dev/null 2>&1
>
> The gitweb-run.sh script includes slightly modified (with adjusted
> pathnames) code from gitweb_run() function from the test script
> t/t9500-gitweb-standalone-no-errors.sh; gitweb config file
> gitweb_config.perl contents (again up to adjusting pathnames; in
> particular $projectroot variable should point to top directory of git
> repository) can be found in the same place.
>
>
> Alternate solutions:
> ~~~~~~~~~~~~~~~~~~~~
> Alternate solution would be to open bidi pipe to "git cat-file
> --batch-check", (like in Git::Repo in gitweb caching by Lea Wiemann),
> feed $long_rev^ to it, and parse its output which has the following
> form:
>
> 926b07e694599d86cec668475071b32147c95034 commit 637
>
> This would mean one call to git-cat-file for the whole 'blame' view,
> instead of one call to git-rev-parse per each unique commit in blame
> output.
>
>
> Yet another solution would be to change use of validate_refname() to
> validate_revision() when checking script parameters (CGI query or
> path_info), with validate_revision being something like the following:
>
> sub validate_revision {
> my $rev = shift;
> return validate_refname(strip_rev_suffixes($rev));
> }
>
> so we don't need to calculate $long_rev^, but can pass "$long_rev^" as
> 'hb' parameter.
>
> This solution has the advantage that it can be easily adapted to
> future incremental blame output.
>
> Acked-by: Luben Tuikov <ltuikov@yahoo.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
(though I think the commit message is total overkill for such an obvious
change ;-)
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-17 8:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Matt Kraai, git, Jakub Narebski
In-Reply-To: <20081217081028.GA3640@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hi,
>
> On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:
>> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
>> > But a change to the function signature of feature subroutines is not
>> > something I'd like to apply while other series that want to add new
>> > features are still cooking. How about doing these two patches as the
>> > first thing that goes to 'next' after 1.6.1, and then force other series
>> > rebase on top of your change? Alternatively, we could make you wait until
>> > other series do settle in 'next' and then apply your change rebased on
>> > them, but I think that is probably less optimal.
>>
>> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
>> released. Thanks for your help,
>
> is it worth keeping them separate? Just a single patch makes more sense
> to me, the interface is much nicer in the latter than in the former. :-)
I agree.
It should come *first* before other topics that are not in 'master/next'
and change the function signature of feature subs of only existing (read:
in 'master') ones. This will force gb/gitweb-patch (and anybody else's
patch that haven't been submitted, waiting during the -rc period) to be
rebased on top of the updated interface, but that's life.
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-17 8:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4948AB14.8030004@viscovery.net>
----- Original Message ----
> From: Johannes Sixt <j.sixt@viscovery.net>
>
> Gili Pearl schrieb:
> > Here is one problem I saw when trying to work in the three-level model.
> > At some point, I had the following setup:
> >
> > top-level : A----B----C----D
> > \
> > \
> > mid-level1: K----L----M
> > \
> > \
> > low-level1: X----Y
> >
> > The maintainer of mid-level1 has decided that commits K L M are ready to be
> > merged into the top-level repo. So he rebased on top-level before asking 'please
> > pull', but after that the low-level was not able to rebase on the mid-level
> > any more.
>
> In this model, the mid-level1 maintainer should *not* rebase against
> top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.
>
But what if K-L-M conflict with C-D? The one who should take care about it is
the mid-level1 maintainer (or possibly one of the low-level1 maintainers).
> > So what is the right working flow for us?
>
> The only ones who should be allowed to rebase are developers at the lowest
> level. Everyone else should only pull or merge.
>
I still don't see clearly what happens next in the example above when the low
level developr wants to push X-Y upstream? On which branch should he rebase?
Need he rebase on mid-level (where K-L-M were already merged upstream), or
maybe direclty on the top-level??
Thanks
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johan Herland @ 2008-12-17 8:33 UTC (permalink / raw)
To: git; +Cc: Gili Pearl, Johannes Sixt
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
On Wednesday 17 December 2008, Gili Pearl wrote:
> ----- Original Message ----
>
> > From: Johannes Sixt <j.sixt@viscovery.net>
> > Gili Pearl schrieb:
> > > Here is one problem I saw when trying to work in the three-level
> > > model. At some point, I had the following setup:
> > >
> > > top-level : A----B----C----D
> > > \
> > > \
> > > mid-level1: K----L----M
> > > \
> > > \
> > > low-level1: X----Y
> > >
> > > The maintainer of mid-level1 has decided that commits K L M are ready
> > > to be merged into the top-level repo. So he rebased on top-level
> > > before asking 'please pull', but after that the low-level was not
> > > able to rebase on the mid-level any more.
> >
> > In this model, the mid-level1 maintainer should *not* rebase against
> > top-level. Rather, he should ask the top-level maintainer to *merge*
> > K-L-M.
>
> But what if K-L-M conflict with C-D? The one who should take care about
> it is the mid-level1 maintainer (or possibly one of the low-level1
> maintainers).
If there is a merge conflict, mid-level1 maintainer will typically merge D
and M into a new merge commit N:
top-level : A----B----C----D
\ \
\ \
mid-level1: K----L----M----N
...and then ask top-level maintainer to merge N (which should have no
conflicts by now). The merge can also be done by low-level1 developer.
> > > So what is the right working flow for us?
> >
> > The only ones who should be allowed to rebase are developers at the
> > lowest level. Everyone else should only pull or merge.
>
> I still don't see clearly what happens next in the example above when the
> low level developr wants to push X-Y upstream? On which branch should he
> rebase? Need he rebase on mid-level (where K-L-M were already
> merged upstream), or maybe direclty on the top-level??
If you're a leaf developer (i.e. allowed to rebase), you should rebase
against your immediate upstream's branch. In this example, that is
mid-level1's branch.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] Enable threaded delta search on Mac OS X/Darwin
From: Arjen Laarhoven @ 2008-12-17 8:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
This was tested on branch 'next' on an Intel dual-core Mac running OS X
10.5 and a single-CPU PowerPC G4 running OS X 10.4.
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 5158197..aabf013 100644
--- a/Makefile
+++ b/Makefile
@@ -645,6 +645,7 @@ ifeq ($(uname_S),Darwin)
endif
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
--
1.6.1.rc3.294.g91f21
^ permalink raw reply related
* Re: [PATCH 2/3 (edit v2)] gitweb: Cache $parent_commit info in git_blame()
From: Junio C Hamano @ 2008-12-17 8:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Nanako Shiraishi, git, Luben Tuikov
In-Reply-To: <20081217081935.GC3640@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (though I think the commit message is total overkill for such an obvious
> change ;-)
I think so too; the performance figures are nice but there is no need to
talk about what is not implemented.
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-17 8:44 UTC (permalink / raw)
To: Johan Herland, git; +Cc: Johannes Sixt
In-Reply-To: <200812170933.04080.johan@herland.net>
Johan, Johanes, Thanks! You made yourself prefectly clear.
git is wonderfult :)
----- Original Message ----
> From: Johan Herland <johan@herland.net>
>
> On Wednesday 17 December 2008, Gili Pearl wrote:
> > ----- Original Message ----
> >
> > > From: Johannes Sixt
> > > Gili Pearl schrieb:
> > > > Here is one problem I saw when trying to work in the three-level
> > > > model. At some point, I had the following setup:
> > > >
> > > > top-level : A----B----C----D
> > > > \
> > > > \
> > > > mid-level1: K----L----M
> > > > \
> > > > \
> > > > low-level1: X----Y
> > > >
> > > > The maintainer of mid-level1 has decided that commits K L M are ready
> > > > to be merged into the top-level repo. So he rebased on top-level
> > > > before asking 'please pull', but after that the low-level was not
> > > > able to rebase on the mid-level any more.
> > >
> > > In this model, the mid-level1 maintainer should *not* rebase against
> > > top-level. Rather, he should ask the top-level maintainer to *merge*
> > > K-L-M.
> >
> > But what if K-L-M conflict with C-D? The one who should take care about
> > it is the mid-level1 maintainer (or possibly one of the low-level1
> > maintainers).
>
> If there is a merge conflict, mid-level1 maintainer will typically merge D
> and M into a new merge commit N:
>
> top-level : A----B----C----D
> \ \
> \ \
> mid-level1: K----L----M----N
>
> ...and then ask top-level maintainer to merge N (which should have no
> conflicts by now). The merge can also be done by low-level1 developer.
>
> > > > So what is the right working flow for us?
> > >
> > > The only ones who should be allowed to rebase are developers at the
> > > lowest level. Everyone else should only pull or merge.
> >
> > I still don't see clearly what happens next in the example above when the
> > low level developr wants to push X-Y upstream? On which branch should he
> > rebase? Need he rebase on mid-level (where K-L-M were already
> > merged upstream), or maybe direclty on the top-level??
>
> If you're a leaf developer (i.e. allowed to rebase), you should rebase
> against your immediate upstream's branch. In this example, that is
> mid-level1's branch.
>
>
> Have fun!
>
> ...Johan
>
> --
> Johan Herland,
> www.herland.net
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johannes Sixt @ 2008-12-17 8:48 UTC (permalink / raw)
To: Gili Pearl; +Cc: git
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
Gili Pearl schrieb:
> ----- Original Message ----
>> From: Johannes Sixt <j.sixt@viscovery.net>
>>
>> Gili Pearl schrieb:
>>> Here is one problem I saw when trying to work in the three-level model.
>>> At some point, I had the following setup:
>>>
>>> top-level : A----B----C----D
>>> \
>>> \
>>> mid-level1: K----L----M
>>> \
>>> \
>>> low-level1: X----Y
>>>
>>> The maintainer of mid-level1 has decided that commits K L M are ready to be
>>> merged into the top-level repo. So he rebased on top-level before asking 'please
>>> pull', but after that the low-level was not able to rebase on the mid-level
>>> any more.
>> In this model, the mid-level1 maintainer should *not* rebase against
>> top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.
>>
>
>
> But what if K-L-M conflict with C-D? The one who should take care about it is
> the mid-level1 maintainer (or possibly one of the low-level1 maintainers).
Ideally, mid-level1 maintainer will have done the merge in a throw-away
branch and will know about the difficulties of the merge and has to tell
top-level maintainer about it. Then top-level maintainer decides whether
he can redo the merge himself (because it's trivial enough), or whether he
prefers to pull the throw-away merge, which then obviously is
not-so-throw-away anymore.
> I still don't see clearly what happens next in the example above when the low
> level developr wants to push X-Y upstream? On which branch should he rebase?
> Need he rebase on mid-level (where K-L-M were already merged upstream), or
> maybe direclty on the top-level??
The question is perhaps: How do the mid-level and low-level developers get
the changes made by the other teams?
The answer is: When mid-level has completed a feature (i.e. the branch was
integrated into top-level), then he is allowed to pull from top-level.
This must result in a fast-forward merge. Low-level developers always
rebase against mid-level.
-- Hannes
^ permalink raw reply
* Re: [PATCH] doc/git-reset: add reference to git-stash
From: Markus Heidelberg @ 2008-12-17 8:49 UTC (permalink / raw)
To: Miklos Vajna; +Cc: gitster, git
In-Reply-To: <20081217041159.GY5691@genesis.frugalware.org>
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.
> (See Documentation/git-commit.txt for an example.)
man git-commit
/See
-> I get 4 search matches outside of the "SEE ALSO" section and it makes
sense in these cases.
Markus
^ permalink raw reply
* Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Emily Ren @ 2008-12-17 9:03 UTC (permalink / raw)
To: git
Hi,
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 ?
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Michael J Gruber @ 2008-12-17 9:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <vpqbpvcro5z.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 16.12.2008 19:05:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Miklos Vajna venit, vidit, dixit 16.12.2008 16:48:
>>> Use '{tilde}' instead of '~', becase the later does not appear in the
>>> manpage version, just in the HTML one.
>> Curiously, "git help daemon" (which execs "man git-daemon") displays the
>> tilde but "man git-daemon" does not (nor does "konqueror
>> man:git-daemon"). Humh?
>
> You probably have two manpages because of two git installations. "man"
> will take the one in your manpath, and git will try to find the one
> corresponding to the version of git you actually launched.
You're right! I have current pages in ~/share/man/man? and older ones in
~/man/man?. I guess the latter is in the standard search path (I don't
have MANPATH set) but the former is not. I probably dumped a man-tarball
in the standard place back when I didn't know about quick-install-doc.
Now I'm just wondering why ~/share/man is the standard target for git
and ~/man in the standard man path, at least on (K)Ubuntu 7.10 at my
workplace.
Michael
^ permalink raw reply
* Re: Can I forbid somebody to pull some branch or tag from my repo with git protocol?
From: Junio C Hamano @ 2008-12-17 9:09 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812170103w1007cf4fs1e83e506c6dd909@mail.gmail.com>
"Emily Ren" <lingyan.ren@gmail.com> writes:
> 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 ?
By not putting that tag or branch in that repository (note that you can
have a repository only to publish which is different from your main
working repository).
.
^ 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 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vw7p3r8.fsf@gitster.siamese.dyndns.org>
I want some group can pull these branches or tags from my repo, while
other's can't, Need I maintain two repositories ?
On Wed, Dec 17, 2008 at 5:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Emily Ren" <lingyan.ren@gmail.com> writes:
>
>> 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 ?
>
> By not putting that tag or branch in that repository (note that you can
> have a repository only to publish which is different from your main
> working repository).
> .
>
^ permalink raw reply
* Re: rebasing commits that have notes, was Re: Git Notes idea.
From: Johan Herland @ 2008-12-17 9:15 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jeff King, Govind Salinas
In-Reply-To: <alpine.DEB.1.00.0812170110160.14632@racer>
On Wednesday 17 December 2008, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Dec 2008, Jeff King wrote:
> > Some discussion of the interaction of notes and rebase:
> > http://thread.gmane.org/gmane.comp.version-control.git/100533
>
> Oh, I misinterpreted that label... of course you can track rebases in
> notes, but some issue that we did not look into yet (I think) is the
> issue that you can cherry-pick and rebase commits and lose notes in the
> process.
>
> It seems that the notes idea is not that unintrusive as I thought...
So we have two issues here:
1. Using notes to annotate the rebase/cherry-pick action itself.
2. Preserving (or at least giving the user the option of preserving) notes
across a rebase/cherry-pick.
I think issue #1 has already been discussed, and is largely resolved: People
can do this if they want to; it probably only makes sense when
rebasing/cherry-picking public branches; etc... AFAICS there are no
remaining problems here that needs an intrusive solution (see below for one
such unintrusive alternative).
Issue #2, however, is a little more involved. We can discuss the merits of
wanting to preserve notes across a rebase/cherry-pick itself; e.g. when it
makes sense to preserve notes, and when it doesn't make sense, but I think
this is orthogonal to the issue of HOW to preserve them, so instead of
focusing on WHY, I'll focus on HOW:
If notes are named according to the "refs/notes:<first byte in hex>/<rest of
bytes>/<referenced object SHA-1>" scheme (and AFAICS this is still being
discussed, so it's indeed a big IF), then rebase/cherry-pick of the
referenced object simply translates to a rename/copy of the corresponding
note (this is of course assuming that the note itself does not contain the
SHA-1 of the referenced object). This could probably be solved fairly
unintrusively in the current code, but there are (as always) complications:
- The user may want to amend the note after the rebase/cherry-pick (just as
(s)he may want to amend the commit message).
- In some cases it may even make sense to fold (parts of) the note _into_
the commit message.
- probably more reasons...
So what about the following proposal: Add hooks that are invoked by
rebase/cherry-pick with the <from-SHA1> and <to-SHA1> as arguments. A
typical hook script can then use this information to look up notes
referencing <from-SHA1> and update these to reference <to-SHA1> instead,
and in the process, prompt the user to do whatever changes (s)he wants to.
The hook scripts can do other things as well, e.g. implementing issue #1
above (adding notes for annotating the rebase/cherry-pick itself.)
Have fun! :)
...Johan
PS: What's the current status on git-sequencer? It's probably the best place
to invoke these hooks.
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-17 9:38 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <5d46db230812161043m4a5873a8w4c323d634b639ba0@mail.gmail.com>
On Tue, Dec 16, 2008 at 12:43:55PM -0600, Govind Salinas wrote:
> I was thinking I would do my first implementation in pyrite and if I find
> that it works well I will port it.
OK, though your performance will probably suck unless you dump the notes
tree into a local hash at the beginning of your program. And looking up
every commit's note during revision traversal is one of the intended
uses (e.g., decorating git-log output, or filtering commits based on a
particular note).
And as Dscho mentioned, most of what you need is already there in C.
You are welcome to implement whatever you want in pyrite, of course, but
there is a desire to have this accessible to the revision traversal
machinery. And that means if you want your version in pyrite to be
compatible with what ends up in git, the data structure design needs to
be suitable for both.
> I just read the proposal from Johannes, he seems to want to use a
> similar layout. However, I would like to modify my proposal slightly
> to make it work better when a gc is run. I would modify the tree to
> look like this...
>
> let 1234567890123456789012345678901234567890 be the
> id of the item that is annotated.
>
> let abcdef7890123456789012345678901234567890 be the
> id of the note to be attached
>
> root/
> 12/
> 34567890123456789012345678901234567890/
> abcdef7890123456789012345678901234567890
>
> This way all the notes are attached to a tree, so that gc won't
> think they are unreferenced objects.
But you have lost the ordering in your list, then, since they will not
be ordered by sha1 of the note contents. I don't know if you care. The
second sha1 is pointless, anyway, since nobody will know that number as
a reference; why not just name them monotonically starting at 1?
One of the things I don't like about having several notes is that it
introduces an extra level of indirection that every user has to pay for,
whether they want it or not. If a note can be a blob _or_ a tree, then
those who want to use blobs can reap the performance benefit. Those who
want multiple named notes in a hierarchy can pay the extra indirection
cost.
I haven't measured how big a cost that is (but bearing in mind that we
might want to do this lookup once per revision in a traversal, even one
extra object lookup can have an impact).
I'm also still not convinced the fan-out is worthwhile, but I can see
how it might be. It would be nice to see numbers for both.
> Perhaps I am missing something, how is it a linear search?. Since we
I think Johannes explained in detail in another message, but it is a
linear search to look up directly in a tree object. Of course you can
build a hash or a sorted fixed-size list as an index.
> Also, how large do you expect the list to be under reasonable
> circumstances.
As many notes as there are commits is my goal (e.g., it is not hard to
imagine an automated process to add notes on build status). Ideally, we
could handle as many notes as there are objects; I see no reason not to
allow annotating arbitrary sha1's (I don't know if there is a use for
that, but the more scalable the implementation, the better).
> > Some thoughts from me on naming issues:
> > http://article.gmane.org/gmane.comp.version-control.git/100402
>
> On naming. I strongly support a ref/notes/sha1/sha1 approach. If
> having a type to the note is important, then perhaps the first line of
> a note could be considered a type or a set of "tags". This way you
I don't think we are talking about the same thing. What I mean by naming
is "here is a shorthand for referring to notes" that is not necessarily
coupled with the implementation. That is, I would like to do something
like:
git log --notes-filter="foo:bar == 1"
and have that "foo:bar" as a shorthand on each commit for:
refs/notes/foo:$COMMIT/bar
Without a left-hand side (e.g., "bar"), we get:
refs/notes/default:$COMMIT/bar
Or without a right-hand side (e.g., "foo:"), we get:
refs/notes/foo:$COMMIT
So you can group related notes in the same tree (which gives you fast
lookup if you are looking at multiple ones, since you only have to do
the tree lookup once), or you can keep notes in separate trees (which
means you can distribute some but not others).
I think your "list of notes" proposal on top of that would be for any
note resolution to provide a tree instead of a blob, with sequenced
elements. I.e., foo:bar might have multiple notes, like:
refs/notes/foo:$COMMIT/bar/1
refs/notes/foo:$COMMIT/bar/2
refs/notes/foo:$COMMIT/bar/3
> drawback is that you have to open the blob to see the type. A hybrid
> approach that uses refs/notes/acked/sha/sha which is one lookup if
Right, that is possible, but implementing only half of what I suggested
above. I think you should be flexible enough to have grouped notes for
fast lookup, or ungrouped notes for more flexibility.
-Peff
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-17 9:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Govind Salinas, 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:
> > Perhaps I am missing something, how is it a linear search?
>
> Yes, you are missing what I wrote in the original thread: tree objects
> must be read in a forward direction, one by one.
Thanks, that was a nice writeup of what was discussed at the
GitTogether.
> Peff's very cute idea was to decouple that process from the per-commit
> procedure, and basically make it a one-time cost (per Git call, and only
> when notes were asked for).
To be fair, it was not my cute idea, but somebody else's (I think David
Reiss). I just coded it quickly because somebody was talking about
iPhones or something. :)
> To the contrary. When I rebase, the tree _does_ change, otherwise I
> would have rebased onto something that had the same original tree as
> my rebase-base to begin with, which would make the rebase rather
> pointless.
Another fun option would be to put notes on patch-ids. That would of
course be horrifically slow to look up, but would survive many
cherry-picks and rebases (but not all, of course).
I don't know if that is useful or not, but I don't see any reason why
the discussed implementation would forbid it (somebody would just have
to implement the lookups at a useful spot).
> > On naming. I strongly support a ref/notes/sha1/sha1 approach.
> I think you meant refs/notes:<first byte in hex>/<rest of bytes>/<some
> arbitrary SHA-1>?
You seem to be in favor of the fan-out. Out of curiosity, did you ever
do numbers on whether the fan-out is actually helpful?
> I am rather supporting refs/nots:<first byte in hex>/<rest of bytes>
> being either a blob, or a tree containing human readable tags, such as
> "bugfix" or "review" or some such.
Yes, I am in favor of the "tree or blob" idea, too. I want this to not
just be about "I am a person writing a note" but "arbitrary data
attached to an object after it has been created". And that means
thinking up front about managing the namespace.
-Peff
^ 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
* 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: 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
* [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
* [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
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