* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 23:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807290153300.2725@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
On Tue, Jul 29, 2008 at 01:54:17AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Actually, this _is_ the opposite of -s ours, no? -s ours just takes our
> tree, your -s theirs just takes their tree.
>
> Sorry for the confusion I caused,
Aah. :-)
I did not read the source of git-merge-ours and based on your
description I thought my knowledge / the doc about -s ours was not
correct.
So I guess my original patch was right, then.
Note to self: "take 2" gets messy, time to send a "take 3" soon. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Hackontest ideas?
From: Petr Baudis @ 2008-07-29 0:01 UTC (permalink / raw)
To: git
Hi,
participating in this might be fun, even if there is not much time
left to sign up:
http://www.hackontest.org/index.php?action=Root-projectDetail(120)
(What feature in Git or a Git-related tool would you implement, given 24
hours staight and unlimited pizza supply?)
P.S.: Disclaimer - yes, if someone suggests something cool enough to
do with Git, I might apply. ;-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-29 0:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20080728235847.GR32057@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
On Tue, Jul 29, 2008 at 01:58:47AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> So I guess my original patch was right, then.
s/patch/description/. The check for the same trees are still valid.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-29 0:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807290123300.2725@eeepc-johanness>
On Tue, Jul 29, 2008 at 01:27, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> To me, this suggests that they were too married to 'production' being the
> "dominant" branch.
<snip>
> If the result should become the state of 'x', too, I would then just
> 'git push origin y:x'.
But this means that everybody doing a 'git pull' on that repo will get
complaints when pulling, right? Should they just send out a message to
all their users that they'll need to rebase all their changes now?
(Not being sarcastic, am trying to work out what the recommended
workflow is here.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Hackontest ideas?
From: Miklos Vajna @ 2008-07-29 0:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080729000103.GH32184@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:
> participating in this might be fun, even if there is not much time
> left to sign up:
>
> http://www.hackontest.org/index.php?action=Root-projectDetail(120)
>
> (What feature in Git or a Git-related tool would you implement, given 24
> hours staight and unlimited pizza supply?)
>
> P.S.: Disclaimer - yes, if someone suggests something cool enough to
> do with Git, I might apply. ;-)
Restartable git-clone? :-)
It was a GSoC idea this year, but in the end nobody started working on
it.
(I was about to work on it, but finally my 'builtin-merge' application
was accepted.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Petr Baudis @ 2008-07-29 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <7vwsj5rf48.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 12:19:19PM -0700, Junio C Hamano wrote:
> We need to refresh the entry to pick up potential ctime changes.
>
> read-cache.c | 7 ++++++-
> builtin-ls-files.c | 21 +++++++++++++++------
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 1cae361..834096f 100644
Oops, silly me. Sorry for being slower than you at fixing this. ;-)
> diff --git a/builtin-ls-files.c b/builtin-ls-files.c
> index e8d568e..a6b30c8 100644
If you are going to apply this, you might be interested in squashing
this:
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index f43af41..2ead7af 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -53,7 +53,14 @@ OPTIONS
-s::
--stage::
- Show stage files in the output
+ Show cached files in an extended format also listing the entry
+ mode, sha1 and stage number; see below for details.
+
+-S::
+--stat::
+ Show cached files in a special format listing stat information
+ stored in the index; this is useful probably only for Git
+ debugging purposes.
--directory::
If a whole directory is classified as "other", show just its
(and even if you aren't, maybe the first part is useful, though it's
minor.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply related
* Re: Showing changes about to be commited via git svn dcommit
From: Lee Marlow @ 2008-07-29 0:32 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080728235326.GQ32057@genesis.frugalware.org>
Works perfectly and makes sense to boot! Thanks, Miklos
-Lee
On Mon, Jul 28, 2008 at 5:53 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Mon, Jul 28, 2008 at 04:54:19PM -0600, Lee Marlow <lee.marlow@gmail.com> wrote:
>> $> git svn dcommit --dry-run | grep -E '^diff-tree ' | cut -b 11- |
>> git diff-tree --stdin -p -v
>>
>> Is this the real way to do it? Do others do something similar?
>
> Depends on how did you created your git-svn repo. If you have only one
> branch with no prefix, then I would try:
>
> git log git-svn..master
>
^ permalink raw reply
* Re: Hackontest ideas?
From: Tarmigan @ 2008-07-29 0:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080729000103.GH32184@machine.or.cz>
On Mon, Jul 28, 2008 at 5:01 PM, Petr Baudis <pasky@ucw.cz> wrote:
> participating in this might be fun, even if there is not much time
> left to sign up:
>
> http://www.hackontest.org/index.php?action=Root-projectDetail(120)
>
> (What feature in Git or a Git-related tool would you implement, given 24
> hours staight and unlimited pizza supply?)
>
> P.S.: Disclaimer - yes, if someone suggests something cool enough to
> do with Git, I might apply. ;-)
It might be cool if git-daemon supported
avahi/zeroconf/bonjour/rendezvous as a server and maybe git-status(?
or maybe a new command) had a flag that could make it an avahi client
and list repositories on the local network being advertised over
avahi.
It looks like bzr has an avahi plugin. Not sure whether it would be a
useful feature for people. What do other folks think?
As a project, it seems fairly self-contained and well defined, and
might be doable for a small team in 24 hours.
-Tarmigan
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-29 0:37 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728192651.GA26677@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> My situation was two long-running branches, "stable" and "devel",
> both of which were worked on by many developers. One person was in
> charge of integration and branch management. They wanted "stable" to
> get the contents of "devel" (which were now ready for release), ignoring
> any small fixes that had been done on "stable" (since they had all been
> moved over to "devel" previously, but in subtly different ways that
> would create conflicts). And "git reset" was not an option, because they
> wanted to keep the history of "stable" in case those fixes needed to be
> looked at later.
I sense a slightly broken workflow here, whether the "-s theirs" strategy
is used or the merge is done in the other direction using "-s ours"
strategy.
Remember, when you create a merge commit between one history and another,
you are making this statement:
I have looked at the tree state and the development history behind
both of these commits, and came up with this tree, which I believe
suits the purpose of _my_ history better than either of them.
That is why, after making such a merge with "git merge other", you won't
see any output from "git log ..other", which asks "what do I have yet to
merge?" Everything that was included in other is now in your history and
there is nothing you have to worry about having left out anymore.
So if you suspect that the sutuation "in case those fixes needed to be
looked at later" ever arises, such a merge should *not* be recorded as a
proper merge on the 'stable' branch, because at that point when you are
doing that "-s theirs" merge (and this applies equally to the case where
you make "-s ours" merge as well), you actually have not looked at "those
fixes" closely enough to make the above statement with confidence.
Having said that, that "looking back in history" can easily be done if you
mark such a "Use '-s theirs' for expediency" merge as potentially an iffy
one in its commit log message somewhere. Later if you actually hit
issues, you can locate such a merge commit, and inspect the output from
"git log $commit^2..$commit^1". You would see those fixes the "devel"
history did not have in the "stable" branch when such a merge was made.
So the above is not a fundamental objection to the approach, and that is
why I said "slightly broken". With a proper explanation between the right
use case (I think what you outlined is an example of good practice) and
the wrong use case (for example, the one described in $gmane/89024, the
whole thing after 'I think "-s theirs" is even worse.', not just the part
that was quoted in $gmane/89178), I think it is Ok to have "-s theirs"
strategy in our toolset.
Even though having said all of the above, I would actually prefer such a
"pull all of the devel down to stable" be done with this workflow instead:
(1) go to 'devel';
(2) merge all of 'stable';
(3) look at the result and prove it is perfect;
(4) go to 'stable';
(5) merge 'devel'.
The last step would be a fast-forward, and you do not need "-s theirs"
anywhere in this procedure. Step (2) can be helped with "-s ours" (which
have the same issue I discussed above), but the result is checked before
it hits the 'stable' (presumably more precious branch), which is
conceptually a big difference. This is where the existing asymmetry
between theirs and ours comes from.
Incidentally, this is how 'maint' skips to tip of 'master' after a new
major version is released, but 'maint' is merged up into 'master' often
enough that we rarely need to even use "ours" strategy.
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-29 0:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <20080729001751.GH10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Mon, Jul 28, 2008 at 12:19:19PM -0700, Junio C Hamano wrote:
>> We need to refresh the entry to pick up potential ctime changes.
>>
>> read-cache.c | 7 ++++++-
>> builtin-ls-files.c | 21 +++++++++++++++------
>> 2 files changed, 21 insertions(+), 7 deletions(-)
>>
>> diff --git a/read-cache.c b/read-cache.c
>> index 1cae361..834096f 100644
>
> Oops, silly me. Sorry for being slower than you at fixing this. ;-)
I did think about ctime issues when I applied the patch.
rename(2) is hardlink to new name followed by unlink of old name, so
internally link count changes twice (and the first "link to new" can
exceed max links and is even allowed to make the whole thing fail); but I
do not think of any other reason for this change in ctime.
^ permalink raw reply
* Re: Hackontest ideas?
From: Junio C Hamano @ 2008-07-29 0:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080729000103.GH32184@machine.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> (What feature in Git or a Git-related tool would you implement, given 24
> hours staight and unlimited pizza supply?)
"Use 'assume unchanged' bit to implement narrow checkout".
^ permalink raw reply
* Re: Hackontest ideas?
From: Junio C Hamano @ 2008-07-29 1:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080729000103.GH32184@machine.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> (What feature in Git or a Git-related tool would you implement, given 24
> hours staight and unlimited pizza supply?)
"git-merge-blame"
(http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3).
^ permalink raw reply
* Re: Hackontest ideas?
From: Petr Baudis @ 2008-07-29 1:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5f5o6em.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@ucw.cz> writes:
>
> > (What feature in Git or a Git-related tool would you implement, given 24
> > hours staight and unlimited pizza supply?)
>
> "Use 'assume unchanged' bit to implement narrow checkout".
I think Nguyen Thai Ngoc Duy is already working on this? (Though I think
he does not use the assume unchanged bit; but this will be likely done
before the end of September.)
(This is a bit annoying, by the way - the deadline is way too early...)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-29 1:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Brown, Alex Riesen, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 28 Jul 2008, David Brown wrote:
>
>> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>>
>> > because there are situations where it produces too much false
>> > positives. Like when file system crawlers keep changing it when
>> > scanning and using the ctime for marking scanned files.
>>
>> That's interesting, since most backup software uses the ctime to determine
>> file changes.
>
> It really is just Beagle that is (was? I can dream) a piece of
> unbelievable crap.
>
> Anybody who uses extended attributes as part of a indexing scheme is just
> insane. Modifying the file you are indexing is not just fundamentally
> wrong to begin with, but it will then also be incredibly inefficient to
> read those entries one at a time.
It's a typo and you are saying it _is_ fundamentally wrong, aren't you?
If you are prepared to pick up new files, you need to crawl everywhere
anyway, so if the xattr is used to leave a mark "The last time I looked at
this file was this" in the file itself, it does not sound too bad to me.
It would be irritating that it touches ctime, though, but I do not use it
so it is not my problem ;-)
http://beagle-project.org/FAQ "Do I really need extended attributes?"
talks about BEAGLE_DISABLE_XATTR environment variable and interestingly
it says disabling use of xattr would slow you down.
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Linus Torvalds @ 2008-07-29 1:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Brown, Alex Riesen, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vbq0ho5g7.fsf@gitster.siamese.dyndns.org>
On Mon, 28 Jul 2008, Junio C Hamano wrote:
> >
> > Anybody who uses extended attributes as part of a indexing scheme is just
> > insane. Modifying the file you are indexing is not just fundamentally
> > wrong to begin with, but it will then also be incredibly inefficient to
> > read those entries one at a time.
>
> It's a typo and you are saying it _is_ fundamentally wrong, aren't you?
Not a typo, and I'm sayin that "it's not _just_ fundamentally wrong"
So yes, it's fundamentally wrong, but it's worse than that. It's
fundamentally wrong _and_ it's inefficient as hell.
> If you are prepared to pick up new files, you need to crawl everywhere
> anyway, so if the xattr is used to leave a mark "The last time I looked at
> this file was this" in the file itself, it does not sound too bad to me.
It's absolutely horrible.
It means that you have another extra indirection and accompanying disk
seek to check the thing. It's a total performance nightmare. Trust me,
anybody who uses extended attributes like this simply does not know what
he is doing.
> It would be irritating that it touches ctime, though, but I do not use it
> http://beagle-project.org/FAQ "Do I really need extended attributes?"
> talks about BEAGLE_DISABLE_XATTR environment variable and interestingly
> it says disabling use of xattr would slow you down.
They don't have a clue. They say that, but it's simply not true.
Of course, the fact that they think it is probably implies that they did
something EVEN MORE STUPID for the non-xattr case. That wouldn't surprise
me at all. If I had to guess, I'd guess that they used an SQL database and
query language, and did all their tests with hot caches too.
The kernel does caching really well, and the kernel is fast as hell, so
_of_course_ when you benchmark, using kernel data structures looks good,
especially if you benchmark against code that isn't well written for the
particular usage case.
Linus
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-29 1:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Brown, Alex Riesen, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <alpine.LFD.1.10.0807281817230.3486@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The kernel does caching really well, and the kernel is fast as hell, so
> _of_course_ when you benchmark, using kernel data structures looks good,
> especially if you benchmark against code that isn't well written for the
> particular usage case.
Ok. While I have your attention on st_ctime, let me ask you a stupid
question. Why does "rename(old, new)" change st_ctime when you move a
regular file?
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: David Brown @ 2008-07-29 1:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Alex Riesen, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <7v3alto4r7.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:
>Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> The kernel does caching really well, and the kernel is fast as hell, so
>> _of_course_ when you benchmark, using kernel data structures looks good,
>> especially if you benchmark against code that isn't well written for the
>> particular usage case.
>
>Ok. While I have your attention on st_ctime, let me ask you a stupid
>question. Why does "rename(old, new)" change st_ctime when you move a
>regular file?
A simple answer might be that posix requires it. But, from the point of
view of backup software, not updating the ctime on rename would be
horrible, because you'd never know when files got renamed.
David
^ permalink raw reply
* Re: Hackontest ideas?
From: Nguyen Thai Ngoc Duy @ 2008-07-29 1:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080729011404.GI32184@machine.or.cz>
On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> > Petr Baudis <pasky@ucw.cz> writes:
> >
> > > (What feature in Git or a Git-related tool would you implement, given 24
> > > hours staight and unlimited pizza supply?)
> >
> > "Use 'assume unchanged' bit to implement narrow checkout".
>
>
> I think Nguyen Thai Ngoc Duy is already working on this? (Though I think
> he does not use the assume unchanged bit; but this will be likely done
> before the end of September.)
You are welcome to do ;) I got to narrow checkout from subtree
checkout where 'assume unchanged' bit was unapplicable so my approach
is a bit different, but probably 'assume unchanged' bit is the right
way to go.
--
Duy
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Linus Torvalds @ 2008-07-29 1:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Brown, Alex Riesen, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7v3alto4r7.fsf@gitster.siamese.dyndns.org>
On Mon, 28 Jul 2008, Junio C Hamano wrote:
>
> Ok. While I have your attention on st_ctime, let me ask you a stupid
> question. Why does "rename(old, new)" change st_ctime when you move a
> regular file?
Hmm. I think that's just a plain POSIX oddity. There's no real "reason"
for it, except the historical one: in really old UNIX terms, rename used
to be a "link+unlink".
And that "link+unlink" updated ctime because the 'nlink' part of the inode
changed. Never mind that it got changed right back ;)
Linus
^ permalink raw reply
* Re: Hackontest ideas?
From: Petr Baudis @ 2008-07-29 2:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0807281855w3b06f624q18f5ac76a3bb405c@mail.gmail.com>
On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:
> On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> > > Petr Baudis <pasky@ucw.cz> writes:
> > >
> > > > (What feature in Git or a Git-related tool would you implement, given 24
> > > > hours staight and unlimited pizza supply?)
> > >
> > > "Use 'assume unchanged' bit to implement narrow checkout".
> >
> >
> > I think Nguyen Thai Ngoc Duy is already working on this? (Though I think
> > he does not use the assume unchanged bit; but this will be likely done
> > before the end of September.)
>
> You are welcome to do ;) I got to narrow checkout from subtree
> checkout where 'assume unchanged' bit was unapplicable so my approach
> is a bit different, but probably 'assume unchanged' bit is the right
> way to go.
But I rather liked the elegancy of just narrowing this down to a
particular subtree. Is there really a good reason to generalize this
further?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Linus Torvalds @ 2008-07-29 2:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Brown, Alex Riesen, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <alpine.LFD.1.10.0807281853520.3486@nehalem.linux-foundation.org>
On Mon, 28 Jul 2008, Linus Torvalds wrote:
>
> Hmm. I think that's just a plain POSIX oddity. There's no real "reason"
> for it, except the historical one: in really old UNIX terms, rename used
> to be a "link+unlink".
Side note: a lot of the mtime/ctime/atime rules are really pretty
arbitrary. They've grown over time, and have various historic reasons.
'ctime' in particular is more arbitrary than most, and I don't at all
guarantee that all Unixes will work exactly the same wrt ctime and rename.
In fact, I -can- guarantee that some older versions of Linux haven't
always updated ctime on renames, for example, and it's probably still
per-filesystem.
Linus
^ permalink raw reply
* Re: Hackontest ideas?
From: Nguyen Thai Ngoc Duy @ 2008-07-29 2:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080729020212.GI10151@machine.or.cz>
On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:
> > On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> > > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> > > > Petr Baudis <pasky@ucw.cz> writes:
> > > >
> > > > > (What feature in Git or a Git-related tool would you implement, given 24
> > > > > hours staight and unlimited pizza supply?)
> > > >
> > > > "Use 'assume unchanged' bit to implement narrow checkout".
> > >
> > >
> > > I think Nguyen Thai Ngoc Duy is already working on this? (Though I think
> > > he does not use the assume unchanged bit; but this will be likely done
> > > before the end of September.)
> >
> > You are welcome to do ;) I got to narrow checkout from subtree
> > checkout where 'assume unchanged' bit was unapplicable so my approach
> > is a bit different, but probably 'assume unchanged' bit is the right
> > way to go.
>
>
> But I rather liked the elegancy of just narrowing this down to a
> particular subtree. Is there really a good reason to generalize this
> further?
I think because it's doable and people do need to narrow to more than
one subtree sometimes. Also it would solve ".git* in parent
directories" problem that is really hard if you strictly do "narrow
down to a particular subtree".
--
Duy
^ permalink raw reply
* [PATCH 0/2] gitweb use sections
From: Gustavo Sverzut Barbieri @ 2008-07-29 2:34 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
The following two patches will add sections to gitweb so usability is
improved for large project listing. It looks like:
http://staff.get-e.org/
but it's a new code that also supports owner sort.
Patches orverview:
* [PATCH 1/2] gitweb: sort projects by path.
This one is required to fix project sort. Since we use paths, we
should compare individual components to make it look like a
tree. Since we now can enable sections this error will be more
evident, so there is the fix.
* [PATCH 2/2] gitweb: add section support to gitweb project listing.
The real section work. This will add use_sections variable and if
it evaluates to true sections will be enabled. Just project and
owner sections are implemented.
I hope it looks good for inclusion. Last time I did perl was about 8
years ago, please point any problems and I'll fix them.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
^ permalink raw reply
* [PATCH 1/2] gitweb: sort projects by path.
From: Gustavo Sverzut Barbieri @ 2008-07-29 2:34 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
In-Reply-To: <1217298868-16513-1-git-send-email-barbieri@profusion.mobi>
Projects are paths, so they should be sorted in pieces, not as a
whole, so a/x will be come before a-b/x.
Signed-off-by: Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
---
gitweb/gitweb.perl | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..c5675cf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3574,17 +3574,40 @@ sub fill_project_list_info {
return @projects;
}
+sub cmp_paths {
+ my ($a, $b) = @_;
+ my @la = split('/', $a);
+ my @lb = split('/', $b);
+ my $last;
+
+ if ($#la < $#lb) {
+ $last = $#la;
+ } else {
+ $last = $#lb;
+ }
+
+ for (my $i = 0; $i < $last; $i++) {
+ if ($la[$i] gt $lb[$i]) {
+ return 1;
+ }
+ }
+
+ return $#la <=> $#lb;
+}
+
# print 'sort by' <th> element, either sorting by $key if $name eq $order
# (changing $list), or generating 'sort by $name' replay link otherwise
sub print_sort_th {
- my ($str_sort, $name, $order, $key, $header, $list) = @_;
+ my ($sort_mode, $name, $order, $key, $header, $list) = @_;
$key ||= $name;
$header ||= ucfirst($name);
if ($order eq $name) {
- if ($str_sort) {
+ if ($sort_mode == 2) {
+ @$list = sort {cmp_paths($a->{$key}, $b->{$key})} @$list;
+ } elsif ($sort_mode == 1) {
@$list = sort {$a->{$key} cmp $b->{$key}} @$list;
- } else {
+ } elsif ($sort_mode == 0) {
@$list = sort {$a->{$key} <=> $b->{$key}} @$list;
}
print "<th>$header</th>\n";
@@ -3596,6 +3619,10 @@ sub print_sort_th {
}
}
+sub print_sort_th_path {
+ print_sort_th(2, @_);
+}
+
sub print_sort_th_str {
print_sort_th(1, @_);
}
@@ -3620,8 +3647,8 @@ sub git_project_list_body {
if ($check_forks) {
print "<th></th>\n";
}
- print_sort_th_str('project', $order, 'path',
- 'Project', \@projects);
+ print_sort_th_path('project', $order, 'path',
+ 'Project', \@projects);
print_sort_th_str('descr', $order, 'descr_long',
'Description', \@projects);
print_sort_th_str('owner', $order, 'owner',
--
1.5.5.2
^ permalink raw reply related
* [PATCH 2/2] gitweb: add section support to gitweb project listing.
From: Gustavo Sverzut Barbieri @ 2008-07-29 2:34 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
In-Reply-To: <1217298868-16513-2-git-send-email-barbieri@profusion.mobi>
Section headers will be optionally displayed when projects dirnames or
owner names changes (depending on sort order), making it easier to
find projects in large setups.
Signed-off-by: Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
---
gitweb/gitweb.css | 7 +++++
gitweb/gitweb.perl | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 79 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index aa0eeca..44abc4c 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -235,6 +235,13 @@ tr.dark:hover {
background-color: #edece6;
}
+tr.section td {
+ background-color: #d9d8d1;
+ border-top: 1px solid #000000;
+ border-left: 1px solid #000000;
+ font-weight: bold;
+}
+
td {
padding: 2px 5px;
font-size: 100%;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5675cf..c99cea3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -15,7 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
-use File::Basename qw(basename);
+use File::Basename qw(basename dirname);
binmode STDOUT, ':utf8';
BEGIN {
@@ -82,6 +82,9 @@ our $projects_list_description_width = 25;
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
+# use sections to separate projects by dirname, helps usability
+our $use_sections = 1;
+
# show repository only if this file exists
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
@@ -3631,6 +3634,66 @@ sub print_sort_th_num {
print_sort_th(0, @_);
}
+sub print_section_tr {
+ my ($n_cols, $section) = @_;
+ print "<tr class=\"section\"><td colspan=\"$n_cols\">$section</td></tr>\n";
+}
+
+sub print_section_internal {
+ my ($order, $n_cols, $current, $getter) = @_;
+ my $current_value = $getter->($current);
+
+ if (!$current_value) {
+ return 0;
+ }
+
+ my $last_value = '';
+ if ($current > 0) {
+ $last_value = $getter->($current - 1);
+ }
+
+ if ($current_value ne $last_value) {
+ print_section_tr($n_cols, $current_value);
+ return 1;
+ }
+
+ return 0;
+}
+
+sub print_section_project {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ sub get_section_project {
+ my ($index) = @_;
+ return dirname(@$projects[$index]->{'path'});
+ }
+
+ return print_section_internal($order, $n_cols, $current, \&get_section_project);
+}
+
+sub print_section_owner {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ sub get_section_owner {
+ my ($index) = @_;
+ return @$projects[$index]->{'owner'};
+ }
+
+ return print_section_internal($order, $n_cols, $current, \&get_section_owner);
+}
+
+sub print_section {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ if ($order eq 'project') {
+ return print_section_project($order, $n_cols, $current, $projects);
+ } elsif ($order eq 'owner') {
+ return print_section_owner($order, $n_cols, $current, $projects);
+ }
+
+ return 0;
+}
+
sub git_project_list_body {
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
@@ -3658,9 +3721,17 @@ sub git_project_list_body {
print "<th></th>\n" . # for links
"</tr>\n";
}
+ my $n_cols = $check_forks ? 6 : 5;
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
+
+ if ($use_sections) {
+ if (print_section($order, $n_cols, $i, \@projects)) {
+ $alternate = 1;
+ }
+ }
+
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
--
1.5.5.2
^ 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