* [FOR DEBUGGING] Stop installing BUILT_INS
From: Steffen Prohaska @ 2008-07-29 5:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217308647-23673-1-git-send-email-prohaska@zib.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b2bc0ef..e416ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,7 +1366,7 @@ endif
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
- { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: git-scm.com
From: Shawn O. Pearce @ 2008-07-29 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Also note that one of the major gripe with you making money off of Git
> > could be the following: we have over 500 contributors, and most of them --
> > first and foremost of all, the two major contributors, Junio and Shawn --
> > cannot make money from Git. Envy is wrong, but it is real.
>
> I do not talk for Shawn, but I think that comment misses the mark by a
> large margin, at least for me.
I'm glad you guys think so highly of my contributions, but I am
only a small cog in the big machine known as "git". I just happen
to like very-fine grained commits for any changes, which skews my
commit count upwards a bit. There are _many_ contributors in that
"Primary Authors" list on git-scm.com who deserve attention too. :)
> I haven't been in this for money. The original motivation of my
> involvement was to help sending Linus back to the kernel as quickly as
> possible, but now I primarily do this for fun. Doing it for money would
> risk removing the fun factor.
>
> What I personally lack right now is time and mental bandwidth.
Well, here you could have spoken for me I think. I do git because
I find it fun, rewarding, and challenging. Though these days it
has been a little bit more work and a little bit less fun-challenge
as I am plowing through code for egit, but its a labor of love.
My contributions to Git are also about giving back, in return for
the benefit I have gained over the years from using Linux, and the
thousands of other open source packages that make it all work.
I'm not big on kernel hacking (though I did try it for about 6
months) so this is one way I can put a few pennys back in the open
source take-a-penny/leave-a-penny penny jar.
More recently I may be in a position where my new employer might
be able to make some contribution to the community through part of
my time. I shall see if it winds up detracting from the fun aspect
of it for me. Personally I tend to get so focused on something that
I have a very hard time moving away from it, and just want to focus
on that one thing and do it well. Doing it at day-job may make
that easier, and reduce stress on me, in turn making it more fun.
> [...] Corporate sponsors that can pay back in money but not in
> patches may be able to find other ways to help us, but I do not offhand
> know what's the most effective way for them to do so if they wanted to.
I don't know how much kernel.org needs support, but we rely heavily
on kernel.org for our main distribution site of git. Its a drop
in the bucket compared to the Linux kernel activity itself, but I
imagine that the right sort of Linux-friendly (and Git-friendly)
corporate sponsor could really help kernel.org out. Of course only
so much help is really useful, and I have no idea what kernel.org's
financial (and staff time) situtation is like, so I'll shut up now.
Pasky's repo.or.cz is another huge area that the community relies
upon. Fortunately Pasky has been able to offer its services freely,
but in the future it may reach a point where corporate support
for adminstration assitance, duct-tape development, bandwidth or
hardware, may be extremely beneficial.
--
Shawn.
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Steffen Prohaska @ 2008-07-29 5:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217277453.488e2e0db0f41@webmail.nextra.at>
On Jul 28, 2008, at 10:37 PM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>> This might solve a fundamental problem we have with the
>> computation of system directories based on relative paths
>> in combination with the new gitexecpath 'libexec/git-core'.
>> The problem is that the program 'git' is hardlinked to
>> directories with different depth. It is either used as
>> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
>> (2 directories). Thus, using the same relative path
>> in system_path() yields different results when starting from the
>> two locations. I recognized the problem because /etc/gitconfig
>> is no longer be read.
>>
>> The patch below might fix the problem by always calling 'bin/git'
>> for builtin commands. The computation in system_path() would
>> always start from 'bin' and thus yields predictable results. I
>> am not sure however if it fully solves the problem because other
>> code paths might run the dashed forms directly.
>
> This paragraph should go into the commit message.
I'll send an updated patch including a commit message defending
the change more offensively.
>> I think the only way to verify correctness would be to stop
>> installing the dashed forms for builtins. If they were not
>> installed they could not be called. The only entry point for all
>> builtins would be 'bin/git'. I don't think we want to stop
>> installing the dashed forms right away.
>>
>> So what shall we do?
>
> Your patches make a lot of sense.
Unfortunately, I am sure that they do not solve the problem fully, even
if we removed the dashed forms completely. I'll send a second patch
that
modifies the Makefile to stop installing the BUILT_INS. It might be
useful for debugging.
Steffen
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vvdyppv4c.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 02:16:35PM -0700, Junio C Hamano wrote:
> The quoted sentence by me in that message was after I explained why "per
> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
> say "by the way, '-s theirs' is even worse and here is why".
Your reason was "it keeps your crap in the history". And while I
generally am in favor of getting rid of crap and keeping a clean
history, I think it is very much dependent on the individual project's
preferences. IOW, that history might not contain "crap" but rather
now-obsolete changes that are of historical interest.
But I do agree that -Xtheirs is crap. ;)
-Peff
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vsktto78y.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote:
> 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.
Right, that is precisely what I wanted to say. These are the histories
of the devel and stable branches, and now they both are the contents of
stable. In this case, "I have looked at all of the commits in stable
that were _not_ in devel, and confirmed that they have moral equivalents
in devel".
> 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.
Right, that is just what I wanted.
> 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.
No, I had looked at them with confidence. I just didn't want history
thrown away for two reasons:
- historical interest; some of the commits had counterparts in devel
that were done differently (because the two branches had diverged),
but it might later be interesting to see how and why the stable
changes were done (e.g., if a similar situation arose)
- this project did not rebase, favoring the simplicity of "git pull"
over clean history.
Bear in mind that this project was not very big. I think devel had ~20
commits, and stable had about ~5. So it was easy to get such confidence.
> 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.
Of course you can do this (and that is, in fact, exactly what I did).
But there is no point discussing "what hits stable" since neither branch
is precious. All of this is happening in a private repo that nobody is
looking at. So it really is a case of thinking about it as "devel
subsumes stable, and then stable becomes devel" versus "stable is
discarded in favor of master".
I think both are equally valid ways of looking at what is happening. The
only differences will be:
- the commit message will be reversed ("Merge X into Y"). And this
really comes down to "how would I want to see this presented in 3
months when I look at it?". And either is valid, depending on how you
think of the problem (but I think in both cases, you owe it to
future readers to write a bit of text saying _why_ such a strategy
was OK to use).
- the parents will be swapped. Using "-s theirs" should let you ask
"what changes did I make on my stable branch" using
"--first-parent". I don't know how useful that is, as I don't
actively work on that project anymore.
-Peff
^ permalink raw reply
* [trivial fast-export PATCH] Fix typo in documentation
From: Nick Andrew @ 2008-07-29 4:50 UTC (permalink / raw)
To: git
Fix typo in documentation
"hg-fast-import" should be "hg-fast-export" everywhere it is used.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
---
hg-fast-export.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hg-fast-export.txt b/hg-fast-export.txt
index 1b8bb1c..ede56a9 100644
--- a/hg-fast-export.txt
+++ b/hg-fast-export.txt
@@ -1,4 +1,4 @@
-hg-fast-import.(sh|py) - mercurial to git converter using git-fast-import
+hg-fast-export.(sh|py) - mercurial to git converter using git-fast-import
Legal
=====
@@ -16,7 +16,7 @@ Using hg-fast-export is quite simple for a mercurial repository <repo>:
mkdir repo-git # or whatever
cd repo-git
git init
- hg-fast-import.sh -r <repo>
+ hg-fast-export.sh -r <repo>
Incremental imports to track hg repos is supported, too.
@@ -31,7 +31,7 @@ again.
Notes/Limitations
=================
-hg-fast-import supports multiple branches but only named branches with exaclty
+hg-fast-export supports multiple branches but only named branches with exactly
one head each. Otherwise commits to the tip of these heads within branch
will get flattened into merge commits.
@@ -42,11 +42,11 @@ when importing a small number of changesets per incremental import).
Design
======
-hg-fast-import.py was designed in a way that doesn't require a 2-pass mechanism
+hg-fast-export.py was designed in a way that doesn't require a 2-pass mechanism
or any prior repository analysis: if just feeds what it finds into
git-fast-import. This also implies that it heavily relies on strictly
linear ordering of changesets from hg, i.e. its append-only storage
-model so that changesets hg-fast-import already saw never get modified.
+model so that changesets hg-fast-export already saw never get modified.
Todo
====
^ permalink raw reply related
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-29 4:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217186640.488ccb50a934a@webmail.nextra.at>
On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>>
>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
>>
>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>> With MinGW's
>>>>
>>>> gcc.exe (GCC) 3.4.5 (mingw special)
>>>> GNU ld version 2.17.50 20060824
>>>>
>>>> the old define caused link errors:
>>>>
>>>> git.o: In function `main':
>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>>>> collect2: ld returned 1 exit status
>>>>
>>>> The modified define works.
>>>
>>> I have the same tools, but not this error. ???
>>
>> I cleaned my work tree and built several times but did not
>> find out what exactly is causing the error. So I came up
>> with the modified define, which declares the static
>> mingw_main in global scope. I have no clue why I see the
>> error that you don't have.
>
> Neither do I. But a strange line number you have there. In 01d9b2d
> (from
> mingw.git) I have 'exit(1)' in line 500 of git.c.
I have the same in line 500. I am still wondering what this could
mean. But I do not yet now :-(
Steffen
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 4:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807290123300.2725@eeepc-johanness>
On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:
> > So the logical sequence was:
> >
> > git checkout production
> > git merge -s theirs master
>
> To me, this suggests that they were too married to 'production' being the
> "dominant" branch.
Perhaps. But I see this as an operation on the production branch: "pull
in master's changes, forgetting ours". In your workflow (git checkout
master && git merge -s ours production && git push origin
master:production) we perform an operation on master, which doesn't seem
as intuitive to me.
Not to mention that we might not _control_ master. What about (and I
think Sverre mentioned something like this previously):
I forked the kernel and made some changes. Some of my changes got
applied upstream. The others are now obsolete. Now I want to bring
myself in sync with Linus, but I want to keep my history (either
because the history is interesting to me, or because others are basing
their work on it).
Then your workflow, while still possible within the local repository,
means you are munging the "linus" branch, which seems wrong. That branch
is probably even just a tracking branch, which you would not want to
build on, anyway.
-Peff
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 4:31 UTC (permalink / raw)
To: sverre; +Cc: Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <bd6139dc0807281709u43218e97p8ba239f3e520e10@mail.gmail.com>
On Tue, Jul 29, 2008 at 02:09:18AM +0200, Sverre Rabbelier wrote:
> > 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.)
I think you are missing the fact that he is doing this push _after_
having merged the history into master via "-s ours". So it is a
fast-forward to push at that point.
-Peff
^ permalink raw reply
* [PATCH 1/2 v2] gitweb: sort projects by path.
From: Gustavo Sverzut Barbieri @ 2008-07-29 3:59 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
In-Reply-To: <1217298868-16513-2-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>
---
New version that fix cmp_paths. Unlike I though initially, $#list
reports the last element index, not the list length. Nonetheless the
last component must be compared only if the list lengths are the same,
otherwise we'll get $root/a/a.git before $root/b.git and sections will
look ugly (group elements of the same level together).
gitweb/gitweb.perl | 42 +++++++++++++++++++++++++++++++++++++-----
1 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..06c9901 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3574,17 +3574,45 @@ 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++) {
+ my $r = $la[$i] cmp $lb[$i];
+ if ($r != 0) {
+ return $r;
+ }
+ }
+
+ if ($#la == $#lb) {
+ return $la[$last] cmp $lb[$last];
+ } else {
+ 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 +3624,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 +3652,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
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 3:33 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807282023290.3334@nehalem.linux-foundation.org>
On Mon, 28 Jul 2008, Linus Torvalds wrote:
>
> And quite frankly, I've seen that behaviour from you before, when it comes
> to other things. So go away. Write the code. Come back with patches. In
> the meantime, we've told you what to do: use --full-history if you really
> want it.
Btw, if you really do end up wanting to actually do something about it, I
can already tell you that trying to do so in "git log" isn't going to be
useful. Do it in "gitk" instead, and make gitk simplify the --full-history
output.
I tried to explain to you the why part earlier (go back and look for
"incremental" and "topo-sort"), but it all seemed to fly right by you, and
you started repeating your ranting instead.
IOW, put up or shut up.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 3:29 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, 29 Jul 2008, Roman Zippel wrote:
>
> Right now you're giving me the choice between a crappy incomplete history
> or a crappy history full of useless information. That's it? As long as
> your challenge involves being compared to crappy history, I'm not
> interested.
No, my challenges have not been about "crappy history" but about
performance and about getting it right. The reason I pointed you to
lib/vsprintf.c had nothing to do with crappiness, and had everythign to do
with just picking a random example of something where you absolutely
*HAVE* to simplify history.
The fact that it simplifies to a linear one is totally immaterial. You
continue to miss the point. Over and over AND OVER again!
> Can we please get past this and look at what is required to produce the
> correct history?
I'm not even going to bother with this argument.
You dismiss all my issues, and then you continue to talk about "correct",
even though it isn't a correctness thing - it's a difference of opinion.
Me, I *much* prefer the simplified history. That _is_ the correct one for
me.
And the sad part is, what you want is there. It's a command line switch
away. You were told in the very first message what the switch was. If you
don't want to use "--full-history", you can actually use "git whatchanged"
instead of "git log", and it implies the switch without you even having to
type it.
So it's all there. Use it. Just don't bother adding me to the cc to your
inane flames, because I'm fed up with the fact that you can't actually be
bothered to read my emails, and just want to flame.
And quite frankly, I've seen that behaviour from you before, when it comes
to other things. So go away. Write the code. Come back with patches. In
the meantime, we've told you what to do: use --full-history if you really
want it.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Martin Langhoff @ 2008-07-29 3:15 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 2:59 PM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Can we please get past this and look at what is required to produce the
> correct history?
Roman - correct is --full-history -- any simplification that makes it
easy on your eyes *is* a simplification. And consumers that want to do
nice user-friendly simplification like gitk does can hang off the data
stream.
> it's also possible to update it when merging/pulling new data.
If that's what you want to do, you can prototype it with a hook on
fetch and commit. That is definitely an area that hasn't been explored
- what nicer (but expensive) views on the history we have can be
afforded by pre-computing things on fetch and commit hooks.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807272148030.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> You don't actually understand how git works, do you?
Probably not and to be honest I don't care, all I want is my history - the
correct one. All I know it's in there somehow and all I care is how to get
it out of there.
Right now you're giving me the choice between a crappy incomplete history
or a crappy history full of useless information. That's it? As long as
your challenge involves being compared to crappy history, I'm not
interested. If the solution should involve a switch "--correct-history"
or I have to wait for the result, I don't care, because it's the correct
history I want. As long as you're trying to sell me crappy history I'm not
buying it.
Can we please get past this and look at what is required to produce the
correct history?
Fact is based on the current git-log output it's simply impossible to
produce the correct history without reading the whole history first, since
the very last commit can still be relevant for an earlier merge to connect
it properly into the graph. This means we need some extra information
before even starting to scan through the commits. Luckily this information
can be cached once it has been generated and it also can be updated
incrementally. E.g. this information could be generated while generating
the pack, so you only had to scan the commits which haven't been packed
yet, but it's also possible to update it when merging/pulling new data.
It's also not much information that is needed, all that is needed is list
of commits per file (which are are usually only a few, mostly even none),
which git-log can use, so it knows that these are important while scanning
the tree.
Technically I don't see a really hard problem to implement this, the
problem for me is only that I have no idea where to start this within git
and how to integrate it. The other problem (over which I have absolutely
no control) is whether anyone actually wants to produce a correct history.
I hope there is someone, otherwise there would be no need for "git-log
--full-history" (which is also used by git-web), this e.g. produces a nice
example in kernel/printk.c, where git-web produces two commits (search for
tty_write_message), for which none of the front ends can tell me usefully
how it fits into the history (they either don't show it at all or it's
lost in "gitk --full-history").
bye, Roman
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-29 2:49 UTC (permalink / raw)
To: David Brown
Cc: Linus Torvalds, Alex Riesen, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <20080729014120.GA26807@old.davidb.org>
David Brown <git@davidb.org> writes:
> 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.
I would understand that an obvious implementation would be to link to new
and then unlink the old, and the link count of the moved entity needs to
change (although in the end, the increment and decrement would cancel out)
in each step, so it would be convenient for the implementation to update
ctime in both steps; however my reading of POSIX does not seem to require
it.
The only mention of ctime I find is about updating the parent directories
of old and new, as contents of both change so do their mtime and ctime
obviously need to change. But it does not talk about ctime of the entity
being moved.
Additionally, the only way rename(2) is described to fail with EMLINK is
when renaming an directory and the parent of the new location cannot have
any more links; which implies that it does not have to fail if the first
step of link+unlink overflows the link count of old.
Ah, I found in the informative Application Usage section that this is
implementation dependent.
Sorry for the noise.
^ permalink raw reply
* [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
* [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 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
* 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
* 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: 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 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: 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: 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: [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
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