* paginate git-diff by default?
From: Martin Waitz @ 2006-10-10 18:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
hoi :)
I always find myself typing "git -p diff".
Should we paginate git-diff output by default?
I was sure this was discussed before but I could not immediately
find it, so I'm simply asking again ;-).
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: paginate git-diff by default?
From: Shawn Pearce @ 2006-10-10 18:15 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061010181337.GE8612@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
>
> I always find myself typing "git -p diff".
> Should we paginate git-diff output by default?
>
> I was sure this was discussed before but I could not immediately
> find it, so I'm simply asking again ;-).
I agree. I'm very used to git log automatically running my $PAGER;
I'm always surprised that git diff doesn't do the same when attached
to my tty.
--
Shawn.
^ permalink raw reply
* Re: Approxidate licensing
From: Linus Torvalds @ 2006-10-10 18:17 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, dwmw2, git
In-Reply-To: <Pine.LNX.4.64.0610101246241.9789@iabervon.org>
On Tue, 10 Oct 2006, Daniel Barkalow wrote:
>
> Would the three of you agree to license date.c under the LGPL or BSD? It
> looks like you're the only authors of non-trivial changes [1]. And it seems
> reasonable to want the date parsing thing under non-GPL terms outside of
> git.
I'm not a huge fan of the LGPL, especially with the recent issues of
GPLv3. The reason? The LGPL is expressly designed to be compatible with
the GPL, but it's designed to be compatible with any version (and you
can't limit it, the way you can the real GPL).
So you can take LGPL 2.1 code, and relicense it under GPLv3, and make
changes to it, and those changes won't be available to a GPLv2 project.
That said, I don't think the date.c code is all that important, and I
don't see why anybody would do something nasty like that anyway, so I
guess I don't actually care. A lot of the approxidate code was actually
written as a joke, and it will parse just about anything without any
error, and without telling you that it returned a date that may not make
any sense at all.
For example, currently
./test-date "$(cat date.c)"
returns
Tue Nov 30 11:58:59 1937
for me, but don't ask me why. It's just put together the random numbers
and month-names embedded in the source and made some insane decision that
it must be a date (since you told it so). And it never returned an error.
Some other things are just silly and not even correct
./test-date "One year ago yesterday at tea-time"
which doesn't even give the right answer (because it will go _backwards_
to tea-time on Oct 8th, even though it obviously _should_ return "Oct 9,
17:00". I don't have the energy to try to fix it.
It also needs this important patch to be complete. I don't know how this
could ever have fallen through the cracks!
Linus
---
diff --git a/date.c b/date.c
index 1825922..0b06994 100644
--- a/date.c
+++ b/date.c
@@ -657,6 +657,7 @@ static const struct typelen {
{ "hours", 60*60 },
{ "days", 24*60*60 },
{ "weeks", 7*24*60*60 },
+ { "fortnights", 2*7*24*60*60 },
{ NULL }
};
^ permalink raw reply related
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 18:23 UTC (permalink / raw)
To: Josef Weidendorfer, Andreas Ericsson
Cc: Jeff King, Petr Baudis, Jakub Narebski, git, Junio C Hamano
In-Reply-To: <200610101514.20705.Josef.Weidendorfer@gmx.de>
--- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> One thing I found confusing in this regard the first time:
> Why do list rows show a recoloring with mouse over?
It's a highlight and it's a good highlight. It suggests that the
row is "alive", i.e. that the title is clickable. It "shows" you
your current "selection" by having the mouse pointer over the row.
I like it.
Luben
^ permalink raw reply
* Re: Approxidate licensing
From: Edesio Costa e Silva @ 2006-10-10 18:33 UTC (permalink / raw)
To: barkalow; +Cc: Edesio Costa e Silva, git
In-Reply-To: <1073a5540610101128q3fb9f68fsf3a28fbda20927d1@mail.gmail.com>
Try the TCL modules that parse date and time (tclGetDate.y and
tclClock.c). They are licensed BSD style.
Edésio
> From: Daniel Barkalow <barkalow@iabervon.org>
> Date: Oct 10, 2006 2:39 PM
> Subject: Approxidate licensing
> To: Linus Torvalds <torvalds@osdl.org>, Junio C Hamano
> <junkio@cox.net>, dwmw2@infradead.org
> Cc: git@vger.kernel.org
>
>
> I'm working on an LGPL project (for my company; it's obscure enough and
> we're lazy enough that we're not really distributing it in general in
> either source or binary form), and I'm running into the usual date parsing
> issue (i.e., all the standard functions are broken in various ways). My
> plan has been to write my own, but it's hard to get the motivation when
> approxidate exists, works well, and is open source.
>
> Would the three of you agree to license date.c under the LGPL or BSD? It
> looks like you're the only authors of non-trivial changes [1]. And it seems
> reasonable to want the date parsing thing under non-GPL terms outside of
> git.
>
> -Daniel
> *This .sig left intentionally blank*
>
> [1] git log and git blame are pretty impressive, but they don't quite
> catch that most of date.c was written by David as part of commit-tree.c,
> then Tony replaced it with a version that uses curl, then Edgar separated
> it out into a date.c and simultaneously reverted Tony's changes. On the
> other hand, the commit messages do say this, and you can use git log and
> git blame to verify that they're true. The only thing they don't let
> you verify is what the differences are between the date.c added in
> ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone
> wants to make git blame *really* magic, date.c would be a good test case.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 18:50 UTC (permalink / raw)
To: Josef Weidendorfer, Andreas Ericsson
Cc: Jeff King, Petr Baudis, Jakub Narebski, git, Junio C Hamano
In-Reply-To: <200610101514.20705.Josef.Weidendorfer@gmx.de>
--- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:
> > I like my links blue and underlined. Can't be arsed to mouse over things
> > to figure out if they're clickable. If they're not blue and underlined,
> > they're not, insofar as I'm concerned.
>
> Same opinion here.
>
> Better be functional than beautiful but confusing.
Indeed.
The larger the group of people deciding on an issue, the less
forward ideas and thinking is introduced. They are inversely
proportional.
Note that almost all forward ideas and ground breaking thoughts have
always been introduced by one, at most two people, not in a forum
or committee. For example (relavant to the audience of this list):
Linux, git, sparse.
Imagine if the design of git has been initiated in a committee or
a mailing list or a forum...
Can someone please submit those two patches
a) one which underlines ALL clickable links in ALL of gitweb, and
b) second which puts redundant links of everything to everything,
just because we can,
and then we can move on?
Thanks,
Luben
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Josef Weidendorfer @ 2006-10-10 18:52 UTC (permalink / raw)
To: ltuikov
Cc: Andreas Ericsson, Jeff King, Petr Baudis, Jakub Narebski, git,
Junio C Hamano
In-Reply-To: <20061010182343.18986.qmail@web31808.mail.mud.yahoo.com>
On Tuesday 10 October 2006 20:23, Luben Tuikov wrote:
> --- Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > One thing I found confusing in this regard the first time:
> > Why do list rows show a recoloring with mouse over?
>
> It's a highlight and it's a good highlight. It suggests that the
> row is "alive", i.e. that the title is clickable.
If you look e.g. at a gitweb shortlog, neither the first nor the
second column is clickable. Still, there is this highlighting.
I remember I clicked and wondered that nothing is happening.
> It "shows" you
> your current "selection" by having the mouse pointer over the row.
As you can do nothing with this "selection", it really makes no
sense to show it. If you could make this selection permanent by
clicking on the row, and do some actions on your selection,
it would be different.
IMHO, a valid argument would be that this highlighting makes it
easier to quickly see which information in different columns belong
together, especially when much whitespace is used.
But for this, alternative coloring of rows is enough.
Josef
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Johannes Schindelin @ 2006-10-10 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dongsheng Song, git
In-Reply-To: <7viris2hkh.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 10 Oct 2006, Junio C Hamano wrote:
> If it was /tmp/gitweb permission problem then the newer gitweb
> shouldn't have that issue so it would be a moot point, but if
> the pitfall still applies to the current software we might want
> to add a "common pitfals" section to gitweb/README.
Make that "common pitfalse".
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: paginate git-diff by default?
From: Johannes Schindelin @ 2006-10-10 19:06 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061010181337.GE8612@admingilde.org>
Hi,
On Tue, 10 Oct 2006, Martin Waitz wrote:
> I always find myself typing "git -p diff".
I don't. Because I have an alias "pd" for that on all of my machines. ;')
Ciao,
Dscho
^ permalink raw reply
* [PATCH] paginate git-diff by default
From: Martin Waitz @ 2006-10-10 19:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061010181558.GB16972@spearce.org>
On Tue, Oct 10, 2006 at 02:15:58PM -0400, Shawn Pearce wrote:
> Martin Waitz <tali@admingilde.org> wrote:
> > I always find myself typing "git -p diff".
> > Should we paginate git-diff output by default?
>
> I agree. I'm very used to git log automatically running my $PAGER;
> I'm always surprised that git diff doesn't do the same when attached
> to my tty.
so here is the overly complex implementation:
---
diff --git a/git.c b/git.c
index 03acb25..3408e81 100644
--- a/git.c
+++ b/git.c
@@ -226,7 +226,7 @@ static void handle_internal_command(int
{ "check-ref-format", cmd_check_ref_format },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "count-objects", cmd_count_objects, RUN_SETUP },
- { "diff", cmd_diff, RUN_SETUP },
+ { "diff", cmd_diff, RUN_SETUP | USE_PAGER },
{ "diff-files", cmd_diff_files, RUN_SETUP },
{ "diff-index", cmd_diff_index, RUN_SETUP },
{ "diff-stages", cmd_diff_stages, RUN_SETUP },
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 19:19 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <egfo99$lg6$2@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Luben Tuikov wrote:
>
> >> It probably is wise to resurrect those "redundant" links.
> >
> > If someone does this, can they also remove the now "other"
> > redundant link? (the link at the pathname itself) A simple
> > code analyzer would show the duplicate code in gitweb.
>
> Easy, easy now.
Can you please CC me when replying to a post of mine? Else
I have to go chase in the git folder as opposed it coming to
my inbox. Thanks!
> I'd rather add some more "hidden" links, but for each hidden
> link (which are convenience only, to have larger are to click,
> or to have closer area to click) I'd like to have clearly marked
> link (marked as a link, i.e. using default link style; and with link text
> denoting _kind_ of link) which leads to the same contents.
Why would you like all this? If users start using those other links
all the time, what is the purpose of the "hidden" links as you call them?
Consider the "tree" link between "commitdiff" and "snapshot" (if enabled)
in shortlog view.
Consider the "hidden" link of each entry (file/directory).
Can you see how they are different?
Introducing this to an engineer who has little knowlege about git:
"Click on the file or directory name, to get the file or go into
the directory"
Simple and intuitive, no need to mention "blob" or "tree" or "object".
Or,
"Click on the 'blob' link to get the ... Click on the 'tree' link to
get the ... Oh you didn't know what a 'tree' or 'blob' object is?
A 'blob' is ... A 'tree' is ..."
At which point the engineer has lost 90% of his interest.
It even gets even worse for the obnoxious "tree" link next to each commit
in shortlog view:
"The tree link is the the tree object which is part of a commit object.
Oh you don't know the internals of a commit object? A commit object
binds a tree object and a (parent) commit object, but blah, blah, blah..."
Can you see how all this apparent "simplicity" you're trying to introduce
contradics the mere links you're introducing it with?
Surely "we can", but should we? The "tree" link in shortlog next to each commit
is one such example of "we can", but we shouldn't.
The question is: Given the average engineer, what is the gitweb interface
such that they can start using it fastest with the minimum amount of
questions?
> But we agreed (I guess) to disagree on the whole redundancy in user
> interface issue (although I agree on the issue of reducing clutter).
> BTW. we can reduce redundancy in the code without need for removing
> "alternate entry points" in interface, I think.
Clutter and redundancy is just a part of it. A larger part is
how much git or non-git oriented we want to make the interface, which
seems related to the overall simplicity and intuitiveness.
The golden question:
What is the interface such that both git-experts and never-seen-git-
but-know-about-SCMs engineers can find it intuitive to use with minimal
amount of questions?
Luben
^ permalink raw reply
* Re: Approxidate licensing
From: Junio C Hamano @ 2006-10-10 19:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610101246241.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Would the three of you agree to license date.c under the LGPL or BSD? It
> looks like you're the only authors of non-trivial changes [1]. And it seems
> reasonable to want the date parsing thing under non-GPL terms outside of
> git.
I do not think I have enough code in there to influence the
license of that file, so what I say below does not matter on
this particular issue.
The project as a whole is GPLv2 and GPLv2 only, but date.c is
isolated enough that I think there are valid form of using it in
your program without making your program a derived work. In
other words, I do not think I have (even if I had written
significant part of it, which I didn't) right to demand to see
the rest of your program if you used date.c. I do not think I
even have rights to ask about what kind of program it is.
My wishes about the code I write for this project is very
simple:
If you improve my code that had helped you to make it help
you even better, I would like to have that change back, so
that your change would help me the same way as it helped
you.
The readers may have noticed that I have slight problem with
GPLv2; in my wish it does not matter if you distribute the
result or not. And I am selfish. It is not about helping my
users, but about helping me ;-).
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Eran Tromer @ 2006-10-10 19:46 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0610100800490.3952@g5.osdl.org>
On 2006-10-10 17:03, Linus Torvalds wrote:
> On Tue, 10 Oct 2006, Sam Vilain wrote:
>> If using git-repack -a, unreferenced objects are kept behind in the
>> pack. This might be the best default, but there are no good ways
>> to clean up the packfiles if a lot of rebasing is happening, or
>> branches have been deleted.
>
> Don't do this.
Too late: "git repack -a -d" already does it, in contradiction to its
manpage. It creates a new pack by following .git/refs, and then deletes
all old pack files.
> I understand why you want to do it, but the fact is, it's dangerous.
>
> Right now, "git repack" is actually safe to run even on a repository which
> is being modified! And that's actually important, if you have something
> like a shared repo that gets re-packed every once in a while from a
> cron-job!
Don't run it on a shared repo, then. And grab a coffee while it runs.
But why force leaf repositories to accumulate garbage?
This functionality is just as racy, and just as necessary, as
"git-prune". It merely garbage-collects the packs as well. Git seems to
collect unreferenced objects faster than the space between the cushions
in my sofa, and there ought to be a way to tidy up things.
Linus, I see why you neither need nor want this functionality in your
typical workflow, but things look different for a downstream developer
who engages in a variety of garbage-generating activities like tracking
wild trees, rebasing patches and using stgit. I really don't need that
unreferenced copy of 2.6.15-rc2-mm1 in my packs anymore.
Eran
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-10 19:57 UTC (permalink / raw)
To: ltuikov; +Cc: Jakub Narebski, git
In-Reply-To: <20061010191904.99261.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Or,
> "Click on the 'blob' link to get the ... Click on the 'tree' link to
> get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> A 'blob' is ... A 'tree' is ..."
>
> At which point the engineer has lost 90% of his interest.
>
> It even gets even worse for the obnoxious "tree" link next to each commit
> in shortlog view:
> "The tree link is the the tree object which is part of a commit object.
> Oh you don't know the internals of a commit object? A commit object
> binds a tree object and a (parent) commit object, but blah, blah, blah..."
Isn't that a simple "labelling" question? I do not think
anybody minds to show clickable string "contents" (instead of
"blob" or "tree") at the places you mention above and if we did
so everybody would be happy, right?
^ permalink raw reply
* Release 1.4.2 build failure
From: Phillip Susi @ 2006-10-10 20:22 UTC (permalink / raw)
To: git
I tried to build git release 1.4.2 and it failed with the following tests:
*** t3403-rebase-skip.sh ***
* ok 1: setup
* ok 2: rebase with git am -3 (default)
* FAIL 3: rebase --skip with am -3
git reset --hard HEAD &&
git rebase --skip
* ok 4: checkout skip-merge
* ok 5: rebase with --merge
* ok 6: rebase --skip with --merge
* FAIL 7: merge and reference trees equal
test -z "`git-diff-tree skip-merge skip-reference`"
* failed 2 among 7 test(s)
I enabled the --verbose and --debug test options in the test script
makefile and then got this:
* ok 2: rebase with git am -3 (default)
* expecting success:
git reset --hard HEAD &&
git rebase --skip
previous dotest directory .dotest still exists but mbox given.
* FAIL 3: rebase --skip with am -3
git reset --hard HEAD &&
git rebase --skip
* expecting success: git checkout -f skip-merge
* ok 4: checkout skip-merge
* expecting failure: git rebase --merge master
Merging HEAD with aa79649ca1fa23815a1ad3e336d9f860599556a3
Merging:
7cb7464379042fecc2968751bd55656a97d28c77 goodbye
aa79649ca1fa23815a1ad3e336d9f860599556a3 we should skip this
found 1 common ancestor(s):
b0ab61719ccd2e08f34e326172362a485540934e hello
Auto-merging hello
CONFLICT (content): Merge conflict in hello
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase
--abort".
* ok 5: rebase with --merge
* expecting success:
git reset --hard HEAD &&
git rebase --skip
Merging HEAD with 46a6fc9814012b86849bc8fc8ae2d5cc1958c3cb
Merging:
7cb7464379042fecc2968751bd55656a97d28c77 goodbye
46a6fc9814012b86849bc8fc8ae2d5cc1958c3cb this should not be skipped
found 1 common ancestor(s):
aa79649ca1fa23815a1ad3e336d9f860599556a3 we should skip this
Committed: 0002 this should not be skipped
All done.
* ok 6: rebase --skip with --merge
* expecting success: test -z "`git-diff-tree skip-merge skip-reference`"
* FAIL 7: merge and reference trees equal
test -z "`git-diff-tree skip-merge skip-reference`"
/tmp/buildd/git-core-1.4.2/t/../gitk: line 3: exec: wish: not found
* failed 2 among 7 test(s)
Does anyone know what this means? I am building on Ubuntu Dapper Drake.
Please CC replies.
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Junio C Hamano @ 2006-10-10 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sam Vilain, git
In-Reply-To: <Pine.LNX.4.64.0610100800490.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 10 Oct 2006, Sam Vilain wrote:
>>
>> If using git-repack -a, unreferenced objects are kept behind in the
>> pack. This might be the best default, but there are no good ways
>> to clean up the packfiles if a lot of rebasing is happening, or
>> branches have been deleted.
>
> Don't do this.
>
> I understand why you want to do it, but the fact is, it's dangerous.
Sorry, I understand "it's dangerous" part, but I do not
understand "why you want to do it" part.
@@ -32,6 +33,11 @@ case ",$all_into_one," in
,,)
rev_list='--unpacked'
pack_objects='--incremental'
+ if [ -n "$prune" ]
+ then
+ # prune junk first
+ git-prune
+ fi
;;
,t,)
rev_list=
This shouldn't make any difference if the repository is
quiescent (and is dangerous if it isn't). pack-objects will
not get fed things that are not reachable.
@@ -40,8 +46,14 @@ case ",$all_into_one," in
# Redundancy check in all-into-one case is trivial.
existing=`cd "$PACKDIR" && \
find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
+
+ if [ -n "$prune" ]
+ then
+ rev_list=`cd "$GIT_DIR" && find refs -type f -print`
+ fi
;;
esac
+
We give --all to rev-list so this should not have any effect
either; other than that the code introduced by this hunk is
broken with packed-refs.
Isn't "repack -a -d" what Sam wants?
^ permalink raw reply
* git benchmark
From: Paolo Ciarrocchi @ 2006-10-10 20:32 UTC (permalink / raw)
To: Git Mailing List
hi all,
I installed both git and mercurial, I would like to repeat test as per
http://git.or.cz/gitwiki/GitBenchmarks but I need help on how to run
them... hints?
I'm really not a git/mercurial expert so step by step instruction
would be more then appreciated, then I'll run test and report
results...
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* rpmbuild fails
From: Anders Larsen @ 2006-10-10 20:31 UTC (permalink / raw)
To: git
The current git fails when building rpms:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/perl5/vendor_perl/5.8.6/Git.pm
Indeed git.spec.in does not specify any files for perl-Git, only
%files -n perl-Git -f perl-files
%defattr(-,root,root)
nothing more.
How is this supposed to be handled correctly?
Cheers
Anders
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vvemsymdx.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Or,
> > "Click on the 'blob' link to get the ... Click on the 'tree' link to
> > get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> > A 'blob' is ... A 'tree' is ..."
> >
> > At which point the engineer has lost 90% of his interest.
> >
> > It even gets even worse for the obnoxious "tree" link next to each commit
> > in shortlog view:
> > "The tree link is the the tree object which is part of a commit object.
> > Oh you don't know the internals of a commit object? A commit object
> > binds a tree object and a (parent) commit object, but blah, blah, blah..."
>
> Isn't that a simple "labelling" question? I do not think
Not quite. You have to explain to the engineer that the "tree" link
next to each "comit title" "shows" the project _at the state of that
commit_. Which is the WORST PR for git and gitweb. Why?
Because now you have to explain internals of git and gitweb.
Instead of letting the engineer click on the commit to see the commit
and then the commit provides a _context_ where "tree" makes much more
intuitive sense.
OTOH, if one is an expert in git, then they have no problem
getting to the information: commit->tree.
> anybody minds to show clickable string "contents" (instead of
> "blob" or "tree") at the places you mention above and if we did
Well, "contents" of a commit is a tricky thing. This is why I don't
like the "tree" link next to each commit in shortlog, but didn't mention
anything when the patch was posted a couple of days ago.
It is just an unnecessary "fast forward interpretation" of commit.
> so everybody would be happy, right?
I don't know anymore.
Luben
P.S. Notice how there is a "snapshot" link on each line of
shortlog, but there is no "snapshot" link in the nav bar
of a=commit. The "snapshot" link is next to "tree" down
in the commit data. There is also a "tree" link which is also
in the navbar, but "shortlog" is missing.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 20:29 UTC (permalink / raw)
To: Luben Tuikov, Junio Hamano; +Cc: git
In-Reply-To: <20061010191904.99261.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Luben Tuikov wrote:
>>
>>>> It probably is wise to resurrect those "redundant" links.
>>>
>>> If someone does this, can they also remove the now "other"
>>> redundant link? (the link at the pathname itself) A simple
>>> code analyzer would show the duplicate code in gitweb.
>>
>> I'd rather add some more "hidden" links, but for each hidden
>> link (which are convenience only, to have larger are to click,
>> or to have closer area to click) I'd like to have clearly marked
>> link (marked as a link, i.e. using default link style; and with
>> link text denoting _kind_ of link) which leads to the same contents.
>
> Why would you like all this? If users start using those other links
> all the time, what is the purpose of the "hidden" links as you call
> them?
It was answered in the part you haven't quoted. Sometimes "hidden link"
purpose it is to have larger area where we can click, for example in
"tree" view the name of file (the name of directory is not hidden, as
it uses default link style), in "shortlog"/"heads"/"tags" view the title
(subject) of a commit/ref. Sometimes it is to have link closer, for
example name of files in diff header being "hidden link" to file
contents before and after the change.
"Hidden links" are in fact half hidden, as I think all of them are
underlined on mouseover.
But, as I have said, we cannot use default link style for those "hidden
links", either because as in "shortlog" view this would negatively
affect readibility, or it would clash with syntax highlighting as in
the case of "commitdiff" and "blobdiff" views, or because we have two
types of object we want to be visually distinct, but there is only one
default style of links like in the case of directory (tree) and file
(blob) entries in the "tree" view.
> Consider the "tree" link between "commitdiff" and "snapshot"
> (if enabled) in shortlog view.
>
> Consider the "hidden" link of each entry (file/directory).
>
> Can you see how they are different?
Yes, "tree" link is small, blue (if not visited), and underlined.
But I guess that wasn't what you had in mind.
IMPORTANT: By the way, by removing 'redundant' "blob"/"tree" link we
remove the possibility of denoting which links (which directories and
files) we have visited (sic!).
> Introducing this to an engineer who has little knowlege about git:
> "Click on the file or directory name, to get the file or go into
> the directory"
> Simple and intuitive, no need to mention "blob" or "tree" or "object".
> Or,
> "Click on the 'blob' link to get the ... Click on the 'tree' link
> to get the ... Oh you didn't know what a 'tree' or 'blob' object
> is? A 'blob' is ... A 'tree' is ..."
>
> At which point the engineer has lost 90% of his interest.
The links are for git and gitweb users. They tell (we assume that git
user knows what blob, tree, etc. means; we assume that gitweb user
knows what blob views or tree view means)
"Click on the 'blob' link to get 'blob' view for current line file"
like the "history" link tells
"Click on the 'history' link to get history of a current line file"
For example "hidden link" of title/subject of a commit in "shortlog" or
"history" view doesn't tell us what kind of view it leads too: commit,
commitdiff? Well, it doesn't tell us that it is link, either... ;-)
> It even gets even worse for the obnoxious "tree" link next to each
> commit in shortlog view:
> "The tree link is the the tree object which is part of a commit
> object. Oh you don't know the internals of a commit object?
> A commit object binds a tree object and a (parent) commit object,
> but blah, blah, blah..."
>
> Can you see how all this apparent "simplicity" you're trying to
> introduce contradics the mere links you're introducing it with?
I don't understand you. The "tree" link in shortlog is a _shortcut_ to
the "tree" view (and I think that one can guess that tree view means
directory listing in the state as saved by given commit), without it
you would have to do it in two steps, first going to commit view, then
clicking on tree in the main navbar. So it is IMHO usefull.
Perhaps you meant "tree" header in "commit" view? There surely we could
use ordinary link style for sha1 which is tree identifier. Cause surely
we don't need for the sha1 to be readable, as in the case of commit
title in the shortlog view. Additionally it would serve as a way to
distinguish on first glance which headers are clickable, and which are
not. And there we could I guess loose redundant headers.
[...]
> The question is: Given the average engineer, what is the gitweb
> interface such that they can start using it fastest with the minimum
> amount of questions?
Given average user/programmer...
>> But we agreed (I guess) to disagree on the whole redundancy in user
>> interface issue (although I agree on the issue of reducing clutter).
>> BTW. we can reduce redundancy in the code without need for removing
>> "alternate entry points" in interface, I think.
>
> Clutter and redundancy is just a part of it. A larger part is
> how much git or non-git oriented we want to make the interface, which
> seems related to the overall simplicity and intuitiveness.
One must pay atention to not to make interface _too simple_, and less
usable because of it. And definition of intuitiveness depends on the
person...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7vvemsymdx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Or,
> > "Click on the 'blob' link to get the ... Click on the 'tree' link to
> > get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> > A 'blob' is ... A 'tree' is ..."
> >
> > At which point the engineer has lost 90% of his interest.
> >
> > It even gets even worse for the obnoxious "tree" link next to each commit
> > in shortlog view:
> > "The tree link is the the tree object which is part of a commit object.
> > Oh you don't know the internals of a commit object? A commit object
> > binds a tree object and a (parent) commit object, but blah, blah, blah..."
>
> Isn't that a simple "labelling" question? I do not think
> anybody minds to show clickable string "contents" (instead of
> "blob" or "tree") at the places you mention above and if we did
> so everybody would be happy, right?
Not, IMHO it is not a good idea. Clicking on file name leads to it
contents, but it is not obvoius what kind of view is it. "blob" link
leads to blob view, "tree" link leads to tree view, which are known
what they mean to any git user.
--
Jakub Narebski
Poland
^ permalink raw reply
* Junio's wishes [Was: Re: Approxidate licensing]
From: Horst H. von Brand @ 2006-10-10 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7v64es0ycq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> My wishes about the code I write for this project is very
> simple:
>
> If you improve my code that had helped you to make it help
> you even better, I would like to have that change back, so
> that your change would help me the same way as it helped
> you.
>
> The readers may have noticed that I have slight problem with
> GPLv2; in my wish it does not matter if you distribute the
> result or not. And I am selfish. It is not about helping my
> users, but about helping me ;-).
There is a small practical problem with that: How would you find out I'm
using a modified version of your code internally? Also, the "distribution"
part of GPLv2 is a useful filter: Only such modifications that are
worthwhile to distribute get back, not each and every corner I paint myself
into while playing around.
All in all, a nice balance, IMVHO.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-10 21:00 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <20061010205238.33892.qmail@web31803.mail.mud.yahoo.com>
Luben Tuikov wrote:
> P.S. Notice how there is a "snapshot" link on each line of
> shortlog, but there is no "snapshot" link in the nav bar
> of a=commit. The "snapshot" link is next to "tree" down
> in the commit data. There is also a "tree" link which is also
> in the navbar, but "shortlog" is missing.
The problem with snapshot is that we can have snapshot of a commit
(and all links in the top part of navigation bar till now deals with
current commit), and snapshot of a tree, which can be subdirectory
(and all links in the bottom part of navigation bar deals with
the views/presentations of a current object).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-10 21:02 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <200610102231.37136.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> > > Or,
> > > "Click on the 'blob' link to get the ... Click on the 'tree' link to
> > > get the ... Oh you didn't know what a 'tree' or 'blob' object is?
> > > A 'blob' is ... A 'tree' is ..."
> > >
> > > At which point the engineer has lost 90% of his interest.
> > >
> > > It even gets even worse for the obnoxious "tree" link next to each commit
> > > in shortlog view:
> > > "The tree link is the the tree object which is part of a commit object.
> > > Oh you don't know the internals of a commit object? A commit object
> > > binds a tree object and a (parent) commit object, but blah, blah, blah..."
> >
> > Isn't that a simple "labelling" question? I do not think
> > anybody minds to show clickable string "contents" (instead of
> > "blob" or "tree") at the places you mention above and if we did
> > so everybody would be happy, right?
>
> Not, IMHO it is not a good idea. Clicking on file name leads to it
> contents, but it is not obvoius what kind of view is it. "blob" link
It is pretty obvious to me: the contents of the object, whether it be
"blob" or "tree". The contents of "blob" and the contents of "tree"
as shown by gitweb.
Luben
> leads to blob view, "tree" link leads to tree view, which are known
> what they mean to any git user.
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: [PATCH] Add --dry-run option to git-send-email
From: Jakub Narebski @ 2006-10-10 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20061010145823.GB8993@parisc-linux.org>
Matthew Wilcox wrote:
> Add a --dry-run option to git-send-email due to having made too many
> mistakes with it in the past week. I like having a safety catch on my
> machine gun.
+1
I'd like also for git-send-email to check if there are any patches to send,
as I oftend did forgot to provide patches.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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