* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 19:27 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Carl Worth, bazaar-ng, git, Erik Bågfors
In-Reply-To: <20061022185350.GW75501@over-yonder.net>
On Son, Oct 22, 2006 Matthew D. Fuller wrote:
> On Sun, Oct 22, 2006 at 07:25:41AM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>>
>> git pull . mainline
>
> This throws me a little. I'd expect it to Just Do It when it's
> fast-forwarding, but if it's doing a merge, I'd prefer it to stop and
> wait before creating the commit, even if there are no textual
> conflicts. I realize you can just look at it afterward and back out
> the commit if necessary, but still...
Or you can use --no-commit option to git pull, and commit later.
But it is true that you can always amend the commit with
got commit --amend, even if the commit is merge.
>> Ah, I hadn't realized that bzr commits stored an "originating
>> branch" inside them.
>
> Every branch has a nickname, settable with 'bzr nick' (defaulting to
> whatever the directory it's in is), and that's stored as a text field
> in each commit. It's mostly cosmetic, but it's handy to see at a
> glance.
If I remember correctly Linus argued against it, because branch
name is something local to repository (most common example is
"mine 'master' is yours 'origin'").
There was proposal for "note" header for notes like merge algorithm
used, or branch name, visible only in 'raw' mode, but it wasn't
implemented.
>> The mainline..featureA syntax literally just means:
>>
>> the set of commits that are reachable by featureA
>> and excluding the set of commits reachable by mainline
>
> From what I can gather from this, though, that means that when I merge
> stuff from featureA into mainline (and keep on with other stuff in
> featureA), I'll no longer be able to see those older commits from this
> command. And I'll see merged revisions from branches other than
> mainline (until they themselves get merged into mainline), correct?
> It sounds more like a 'bzr missing --mine-only' than looking down a
> mainline in log...
That's true. That is what history viewers are for (gitk, qgit, tig,
gitview, git-show-branch, git-browser) are for.
And there is always reflog (if you enable it, of course).
^ permalink raw reply
* Re: [PATCH 3/3] Teach git-branch -v and -w options
From: Junio C Hamano @ 2006-10-22 19:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <11615166273819-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This makes git-branch display sha1 and first line of commit
> message for each branch.
>
> Additionaly, the -w option may be used to specify columnwidth
> for branchname (default is 20 characters)
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
If you are going in this direction, probably you would want to
refactor 2/3 a bit differently, so that you do not have to
duplicate the same printf for local and remote cases?
^ permalink raw reply
* Re: VCS comparison table
From: David Clymer @ 2006-10-22 19:36 UTC (permalink / raw)
To: Carl Worth
Cc: Matthew D. Fuller, bazaar-ng, Linus Torvalds, Andreas Ericsson,
git, Jakub Narebski
In-Reply-To: <87ac3p1jn7.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
On Sat, 2006-10-21 at 13:47 -0700, Carl Worth wrote:
> On Sat, 21 Oct 2006 08:01:11 -0500, "Matthew D. Fuller" wrote:
> > I think we're getting into scratched-record-mode on this.
>
> I apologize if I've come across as beating a dead horse on this. I've
> really tried to only respond where I still confused, or there are
> explicit indications that the reader hasn't understood what I was
> saying, ("I don't understand how you've come to that conclusion",
> etc.). I'll be even more careful about that below, labeling paragraphs
> as "I'm missing something" or "Maybe I wasn't clear".
>
> > G: So use revids everywhere.
> >
> > B: Revnos are handier tools for [situation] and [situation] for
> > [reason] and [reason].
>
> I'm missing something:
>
> I still haven't seen strong examples for this last claim. When are
> they handier? I asked a couple of messages back and two people replied
> that given one revno it's trivial to compute the revno of its
> parent. But that's no win over git's revision specifications,
> (particularly since they provide "parent of" operators).
I would say that: revnos are handier tools than revids...etc
I think that since G: was making a statement about revids, B: was making
an implicit comparison with them.
bzr log -r before:1
being handier than
bzr log -r before:revid:david@zettazebra.com-20061022175244-4b85cb5f0cbc79ad
-davidc
--
gpg-key: http://www.zettazebra.com/files/key.gpg
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Jeff King @ 2006-10-22 19:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610221548.42048.andyparkins@gmail.com>
On Sun, Oct 22, 2006 at 03:48:35PM +0100, Andy Parkins wrote:
> Git's commit-ish is very powerful. I was wondering however, if there was a
> shortcut for (for example)?
>
> git-diff 3435fdb4c^..3435fdb4c
>
> That is - the short range of a particular commit's parent to that commit; like
>
> git-diff 3435fdb4c!
>
> Or similar.
I think a more general (but possibly harder to implement and use!) form
would be a commit-ish token for "refer to previous commit-ish." This
would not increase expressiveness, but could save a lot of typing. So if
'!' meant "the last sha1/ref parsed", your example range would be:
3435fdb4c^..!
but you could also do more exotic things like:
3435fdb4c~25..!~20
Obviously you could think of more interesting ways to refer to previous
THINGS. But I think in most cases in which you have repeated refs, you
really are just repeating one ref twice as a basis for a range.
The '!' character is probably a bad choice, since it's generally an
interactive shell metacharacter. I'm not sure what would be a better
choice; we're running low on punctuation.
At any rate, I'm not convinced this is a worthwhile optimization. It's
annoying to have to re-specify a long sha1, but in 99% of cases, you
really are looking for sha1^..sha1. As others have pointed out, that's
already handled through git-show.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] Teach git-branch -v and -w options
From: Lars Hjemli @ 2006-10-22 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz7o5eki.fsf@assigned-by-dhcp.cox.net>
On 10/22/06, Junio C Hamano <junkio@cox.net> wrote:
> If you are going in this direction, probably you would want to
> refactor 2/3 a bit differently, so that you do not have to
> duplicate the same printf for local and remote cases?
>
I actually did, but then abandoned it since it would change the output
for remote branches (two spaces indent). I didn't want to cause any
regressions :-)
But if that's ok, my abandoned patch contained this:
@@ -48,14 +48,35 @@ If you are sure you want to delete it, r
exit 0
}
-ls_remote_branches () {
- git-rev-parse --symbolic --all |
- sed -ne 's|^refs/\(remotes/\)|\1|p' |
- sort
-}
-+width=20
+sedmatch="^refs/heads/"
+sedsubst=
+verbose=
force=
create_log=
+
+ls_refs () {
+ git-rev-parse --symbolic --all |
+ sed -ne "s|$sedmatch|$sedsubst|p" |
+ sort |
+ while read ref
+ do
+ if test "$headref" = "$ref"
+ then
+ pfx='*'
+ else
+ pfx=' '
+ fi
+ if test "$verbose" = "yes"
+ then
+ log=$(git-log --max-count=1 --pretty=oneline $ref)
+ printf "%s %-*s %s\n" "$pfx" "$width" "$ref" "$log"
+ else
+ echo "$pfx $ref"
+ fi
+ done
+}
+
while case "$#,$1" in 0,*) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -64,8 +85,8 @@ do
exit
;;
-r)
- ls_remote_branches
- exit
+ sedmatch="^refs/\(remotes/\)"
+ sedsubst="\1"
;;
-f)
force="$1"
@@ -73,6 +94,13 @@ do
-l)
create_log="yes"
;;
+ -v)
+ verbose="yes"
+ ;;
+ -w)
+ shift
+ width=$1
+ ;;
--)
shift
break
@@ -86,18 +114,7 @@ done
case "$#" in
0)
- git-rev-parse --symbolic --branches |
- sort |
- while read ref
- do
- if test "$headref" = "$ref"
- then
- pfx='*'
- else
- pfx=' '
- fi
- echo "$pfx $ref"
- done
+ ls_refs
exit 0 ;;
1)
head=HEAD ;;
And then I added -a and -t (for "all" and "tags", obviously), and felt
I went over the top :-)
Btw: in the meantime, Kristian Høgsberg pointed me to an earlier
thread regarding making git-branch a builtin, which I'm going to look
at tonight.
So many options, so little time :-)
I'm open for suggestions/preferences etc...
--
larsh
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 19:57 UTC (permalink / raw)
To: David Clymer
Cc: Matthew D. Fuller, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <1161544685.22276.127.camel@zepto.home.zettazebra.com>
David Clymer wrote:
> Bzr: Branches and all shared history may be stored locally in disparate
> locations, and all VCS functions are available locally.
Branches in bzr are both one-source (one head) DAG (of parents), and
the "mainline" i.e. track of commits commited in this branch-as-place.
Bazaar-NG tries to keep both information in DAG by using first parent
to mark commits on current branch-as-place.
Additionally bzr by default uses revnos, numbering commits on branch,
which needs maintaining mainline identity for revnos not to change
even for one branch-as-place.
This leads to the need to use "merge" if you want to maintain revnos
unchanged, and "pull" if you are not interested in that.
Git correctly realizes that mainline identity is local information,
and instead of trying to save local information in DAG which is shared,
it uses reflog.
[That's of course totally biased view.]
> Git: Same thing, except that all shared history must also be identically
> ordered.
That is the EFFECT of preferring fast-forward over preserving
"first parent is my branch" property. So the RESULT is that
shared history is identically ordered.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 20:06 UTC (permalink / raw)
To: David Clymer
Cc: Matthew D. Fuller, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <1161544685.22276.127.camel@zepto.home.zettazebra.com>
David Clymer wrote:
> 1. revnos don't work because they don't serve the same purpose as revids
> or git's SHA1 commit ids.
Revnos works only locally, or in star-topology configuration. They have
some consequences: treating first parent specially, need for merges
instead of fast-forward even if fast-forward would be applicable,
two different "fetch" operators: "pull" (which uses revids on the
pulled side) and "merge" (which preserves revids on pullee side).
> 2. bzr does not support fully distributed development because revnos
> "don't work" as stated in #1.
Bazaar is biased towards centralized/star-topology development if we
want to use revids. In fully distributed configuration there is no
"simple namespace".
> 3. Ok, bzr does support distributed development, I just say it doesn't
> because I think revids are ugly.
I think that bzr revids are uglier that git commit-ids.
If on the pros side of bzr is "simple namespace", you must remember that
it is simple namespace only for not fully distributed development. The
pros of "simple namespace" with cons of "merge" vs "pull" and centralization
required for uniqueness of revids.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Andy Parkins @ 2006-10-22 20:17 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0610221017180.3962@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On Sunday 2006, October 22 18:25, Linus Torvalds wrote:
> Umm. That's not actually a very sensible operation. It's only sensible in
> the special case of "diff", and for that special case, what we do is to
> actually just say that the _command_ is special, not the range.
>
> It's called "git show".
You're entirely correct, that that is what I was looking for in that
particular case. However, the reason I raised it as a question was that I
was poking around with git (which I'm enjoying immensely by the way - it
really is as perfect an SCM as I have ever used) and in short succession did
git-diff X^..X
git-log X^..X
git-format-patch X^..X
I imagined that I would eventually stumble on other git commands where I would
want to do this operation again. I'm sure I will have picked an incorrect
command in each case, however, they all did exactly what I wanted so I
stopped looking for the "right" command :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
From: Junio C Hamano @ 2006-10-22 20:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610211752.19891.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Code should be aligned the same way, regardless of tab size.
> Use tabs for indent, but spaces for align.
I do not necessarily agree with that policy; the result of
applying this patch is still inconsistent in some places, and I
think that is primarily because the policy itself is flawed.
For example, a part of sub format_paging_nav looks like this:
sub format_paging_nav {
>>>>>>>>my ($action, $hash, $head, $page, $nrevs) = @_;
...
>>>>>>>>if ($page > 0) {
>>>>>>>>>>>>>>>>$paging_nav .= " ⋅ " .
>>>>>>>>>>>>>>>>>>>>>>>>$cgi->a({-href => href(action=>$a
>>>>>>>>>>>>>>>>>>>>>>>> -accesskey => "p", -titl
>>>>>>>>} else {
...
If your policy is to indent continuation lines (which is why you
have a TAB before "$cgi->a"), not having a TAB before the
continued parameter list for the $cgi->a() call look inconsistent.
If on the other hand your policy is to align parameters to an
operator that are spread over multiple lines, " ⋅ " and
"$cgi-a(..." are left and right parameters to the string
concatenation operator "." in between them, so "$cgi->a" should
be pushed back with a run of SP starting at the column that
begins $paging_nav and aligned with the DQ at the beginning of
the " ⋅ " string.
By the way, is there a handy way to view something like the
above with "cat" (like "cat -e" is an easy way to find trailing
whitespace problems)? I usually end up running this but I feel
that there ought to be a canned command.
#!/usr/bin/perl
my $monochrome = 0;
my $tab = 8;
my $tab_color = "\033[44m";
my $reset_color = "\033[0m";
my $tab_padchar = ' ';
if ($monochrome) {
$tab_color = $reset_color = '';
$tab_padchar = '>';
}
while (<>) {
chomp;
my (@frag) = split(/\t/, $_);
my $pos = 0;
for (my $i = 0; $i < @frag; $i++) {
if ($i) {
my $len = 8 - $pos % 8;
print $tab_color;
print $tab_padchar x $len;
print $reset_color;
$pos += $len;
}
print $frag[$i];
$pos += length($frag[$i]);
}
print "\n";
}
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
From: Jakub Narebski @ 2006-10-22 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b9g5cde.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Code should be aligned the same way, regardless of tab size.
>> Use tabs for indent, but spaces for align.
>
> I do not necessarily agree with that policy; the result of
> applying this patch is still inconsistent in some places, and I
> think that is primarily because the policy itself is flawed.
To be true I do those "whitespace cleanup" patches when I notice
that something is mis-aligned for _my_ tab width (2 spaces).
I use Emacs with show-whitespace-mode to not introduce errors
which would be aligned for 2 columsn wide tabs but be misaligned
for more common 5 or 8 characters wide tabs.
> For example, a part of sub format_paging_nav looks like this:
>
> sub format_paging_nav {
> >>>>>>>>my ($action, $hash, $head, $page, $nrevs) = @_;
> ...
> >>>>>>>>if ($page > 0) {
> >>>>>>>>>>>>>>>>$paging_nav .= " ⋅ " .
> >>>>>>>>>>>>>>>>>>>>>>>>$cgi->a({-href => href(action=>$a
> >>>>>>>>>>>>>>>>>>>>>>>> -accesskey => "p", -titl
> >>>>>>>>} else {
> ...
>
> If your policy is to indent continuation lines (which is why you
> have a TAB before "$cgi->a"), not having a TAB before the
> continued parameter list for the $cgi->a() call look inconsistent.
>
> If on the other hand your policy is to align parameters to an
> operator that are spread over multiple lines, " ⋅ " and
> "$cgi-a(..." are left and right parameters to the string
> concatenation operator "." in between them, so "$cgi->a" should
> be pushed back with a run of SP starting at the column that
> begins $paging_nav and aligned with the DQ at the beginning of
> the " ⋅ " string.
That is preferred, and usually used policy, although I sometimes
use former to avoid too long lines.
I never claimed to be perfect...
Nevertheless this patch for example correct situation where the
line which should be aligned is aligned using mixture of tabs and
spaces differing from line to line in the "same alignment" block.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH qgit 1/2] Directly draw lanes in ListView::paintCell()
From: Josef Weidendorfer @ 2006-10-22 20:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
This gives much flexibility in contrast to previous fixed
pixmaps. E.g. lane symbols could overlap now, which was
not possible before.
However, this patch does not change any drawing aside
from fixing the ugly spaces in the lanes on commits with
tag/branch labels, and shows the selection even in the
graph background (not really sure if this is wanted;
however, easy to change).
This patch does not cleanup the old pixmap drawing; it even
uses the width of one pixmap as global lane width.
The new painting code regroups the drawing commands in
multiple switch-statements to prepare for far simpler code
with booleans for different elements, and not one type only.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
Hi Marco,
the change looks bigger than it really is because of the
pure rearrangement of the drawing code.
I hope I used your indentation style.
Josef
src/listview.cpp | 184 +++++++++++++++++++++++++++++++++++++++++++++++-------
src/listview.h | 5 +-
2 files changed, 166 insertions(+), 23 deletions(-)
diff --git a/src/listview.cpp b/src/listview.cpp
index db19267..a947564 100644
--- a/src/listview.cpp
+++ b/src/listview.cpp
@@ -405,24 +405,162 @@ void ListViewItem::setDiffTarget(bool b)
repaint();
}
-void ListViewItem::paintGraph(const Rev& c, QPainter* p, const QColorGroup& cg, int width) {
+/* Draw graph part for a lane
+ */
+void ListViewItem::paintGraphLane(QPainter* p, int type, int x1, int x2,
+ const QColor& col, const QBrush& back) {
+
+ int h = height();
+ int r = (x2-x1)/3;
+
+#define P_CENTER (x1+x2)/2, h/2
+#define P_0 x2, h/2
+#define P_90 (x1+x2)/2, 0
+#define P_180 x1, h/2
+#define P_270 (x1+x2)/2, h
+#define R_CENTER (x1+x2)/2-r, h/2-r, 2*r, 2*r
+
+ p->setPen(QPen(col, 2));
+
+ // vertical line
+ switch (type) {
+ case ACTIVE:
+ case NOT_ACTIVE:
+ case MERGE_FORK:
+ case MERGE_FORK_R:
+ case MERGE_FORK_L:
+ case JOIN:
+ case JOIN_R:
+ case JOIN_L:
+ p->drawLine(P_90, P_270);
+ break;
+ case HEAD:
+ case HEAD_R:
+ case HEAD_L:
+ case BRANCH:
+ p->drawLine(P_CENTER, P_270);
+ break;
+ case TAIL:
+ case TAIL_R:
+ case TAIL_L:
+ case INITIAL:
+ case BOUNDARY:
+ case BOUNDARY_C:
+ case BOUNDARY_R:
+ case BOUNDARY_L:
+ p->drawLine(P_90, P_CENTER);
+ break;
+ default:
+ break;
+ }
+
+ // horizontal line
+ switch (type) {
+ case MERGE_FORK:
+ case JOIN:
+ case HEAD:
+ case TAIL:
+ case CROSS:
+ case CROSS_EMPTY:
+ case BOUNDARY_C:
+ p->drawLine(P_180, P_0);
+ break;
+ case MERGE_FORK_R:
+ case JOIN_R:
+ case HEAD_R:
+ case TAIL_R:
+ case BOUNDARY_R:
+ p->drawLine(P_180, P_CENTER);
+ break;
+ case MERGE_FORK_L:
+ case JOIN_L:
+ case HEAD_L:
+ case TAIL_L:
+ case BOUNDARY_L:
+ p->drawLine(P_CENTER, P_0);
+ break;
+ default:
+ break;
+ }
+
+ // center symbol, e.g. rect or ellipse
+ switch (type) {
+ case ACTIVE:
+ case INITIAL:
+ case BRANCH:
+ p->setPen(Qt::NoPen);
+ p->setBrush(col);
+ p->drawEllipse(R_CENTER);
+ break;
+ case MERGE_FORK:
+ case MERGE_FORK_R:
+ case MERGE_FORK_L:
+ p->setPen(Qt::NoPen);
+ p->setBrush(col);
+ p->drawRect(R_CENTER);
+ break;
+
+ case UNAPPLIED:
+ // Red minus sign
+ p->setPen(Qt::NoPen);
+ p->setBrush(red);
+ p->drawRect( (x1+x2)/2-r, h/2 - 1, 2*r, 2);
+ break;
+
+ case APPLIED:
+ // Green plus sign
+ p->setPen(Qt::NoPen);
+ p->setBrush(DARK_GREEN);
+ p->drawRect( (x1+x2)/2-r, h/2 - 1, 2*r, 2);
+ p->drawRect( (x1+x2)/2-1, h/2-r, 2, 2*r);
+ break;
+
+ case BOUNDARY:
+ p->setBrush(back);
+ p->drawEllipse(R_CENTER);
+ break;
+
+ case BOUNDARY_C:
+ case BOUNDARY_R:
+ case BOUNDARY_L:
+ p->setBrush(back);
+ p->drawRect(R_CENTER);
+ break;
+
+ default:
+ break;
+ }
+
+#undef P_CENTER
+#undef P_0
+#undef P_90
+#undef P_180
+#undef P_270
+#undef R_CENTER
+
+}
+
+
+void ListViewItem::paintGraph(const Rev& c, QPainter* p,
+ const QColorGroup& cg, int width) {
+
+ static QColor colors[COLORS_NUM] = {Qt::black, Qt::red, DARK_GREEN,
+ Qt::blue, Qt::darkGray, BROWN,
+ Qt::magenta, ORANGE};
- // Copied from QListViewItem::paintCell
QListView* lv = listView();
if (!lv)
return;
- const BackgroundMode bgmode = lv->viewport()->backgroundMode();
- const QColorGroup::ColorRole crole = QPalette::backgroundRoleFromMode(bgmode);
+ QColorGroup::ColorRole crole = QColorGroup::Base;
+ if ( isSelected() && lv->allColumnsShowFocus() )
+ crole = QColorGroup::Highlight;
- if (isSelected() && lv->allColumnsShowFocus())
- p->fillRect(0, 0, width, height(), cg.brush(QColorGroup::Highlight));
- else
- p->fillRect(0, 0, width, height(), cg.brush(crole));
+ QBrush back = cg.brush( crole );
+ p->fillRect( 0, 0, width, height(), back );
const QValueVector<int>& lanes(c.lanes);
uint laneNum = lanes.count();
- int pw = pms[0]->width();
int mergeLane = -1;
for (uint i = 0; i < laneNum; i++)
if (isMerge(lanes[i])) {
@@ -430,26 +568,28 @@ void ListViewItem::paintGraph(const Rev&
break;
}
- for (uint i = 0; i < laneNum; i++) {
+ int laneWidth = pms[0]->width();
+ int x1 = 0, x2;
+ for (uint i = 0; i < laneNum && x1 < width; i++, x1 = x2) {
+ x2 = x1 + laneWidth;
- int ln = lanes[i], idx;
+ int ln = lanes[i];
if (ln == EMPTY)
- continue;
+ continue;
+ int type = ln;
if (ln == CROSS)
- idx = COLORS_NUM * (NOT_ACTIVE - 1);
- else
- idx = COLORS_NUM * (ln - 1);
+ type = NOT_ACTIVE;
int col = ( isHead(ln) || isTail(ln) || isJoin(ln)
- || ln == CROSS_EMPTY) ? mergeLane : i;
+ || ln == CROSS_EMPTY) ? mergeLane : i;
- idx += col % COLORS_NUM;
- p->drawPixmap(i * pw, 0, *pms[idx]);
- if (ln == CROSS) {
- idx = COLORS_NUM * (CROSS - 1) + mergeLane % COLORS_NUM;
- p->drawPixmap(i * pw, 0, *pms[idx]);
- }
+ paintGraphLane(p, type, x1, x2,
+ colors[col % COLORS_NUM], back);
+
+ if (ln == CROSS)
+ paintGraphLane(p, CROSS, x1, x2,
+ colors[mergeLane % COLORS_NUM], back);
}
}
diff --git a/src/listview.h b/src/listview.h
index 8e78d71..7e52e9a 100644
--- a/src/listview.h
+++ b/src/listview.h
@@ -33,7 +33,10 @@ public:
private:
void setupData(const Rev& c);
- void paintGraph(const Rev& c, QPainter* p, const QColorGroup& cg, int width);
+ void paintGraphLane(QPainter* p, int type, int x1, int x2,
+ const QColor& col, const QBrush& back);
+ void paintGraph(const Rev& c, QPainter *p,
+ const QColorGroup& cg, int width);
void addTextPixmap(SCRef text, const QColor& color, bool bold = false);
QPixmap* doAddTextPixmap(SCRef text, const QColor& color, int col, bool bold);
const QString timeDiff(unsigned long secs) const;
--
1.4.3.rc2.gf8ffb
^ permalink raw reply related
* [PATCH qgit 2/2] Remove old drawing code for graph part pixmaps
From: Josef Weidendorfer @ 2006-10-22 20:44 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
The laneWidth is now explicitly set in GraphMetrics, and
shared with the ListViewItem's via reference.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
src/listview.cpp | 187 ++----------------------------------------------------
src/listview.h | 4 +-
src/mainimpl.cpp | 3 +-
src/mainimpl.h | 6 +--
4 files changed, 10 insertions(+), 190 deletions(-)
diff --git a/src/listview.cpp b/src/listview.cpp
index a947564..7251b97 100644
--- a/src/listview.cpp
+++ b/src/listview.cpp
@@ -222,11 +222,10 @@ void ListView::on_newRevsAdded(const Fil
if (lv->childCount() == 0)
lastItem = NULL;
- const QPtrVector<QPixmap>& pm = d->m()->gm.pixmaps;
-
for (uint i = lv->childCount(); i < shaVec.count(); i++) {
- lastItem = new ListViewItem(lv, lastItem, git, shaVec[i], pm,
- evenLine, secs, fh);
+ lastItem = new ListViewItem(lv, lastItem, git, shaVec[i],
+ d->m()->gm.laneWidth,
+ evenLine, secs, fh);
evenLine = !evenLine;
}
}
@@ -344,7 +343,7 @@ bool ListView::filterRightButtonPressed(
bool ListView::getLaneParentsChilds(ListViewItem* item, int x, SList p, SList c) {
- uint lane = x / d->m()->gm.width();
+ uint lane = x / d->m()->gm.laneWidth;
int t = item->getLaneType(lane);
if (t == EMPTY || t == -1)
return false;
@@ -387,8 +386,8 @@ bool ListView::filterDropEvent(QDropEven
// ****************************** ListViewItem *****************************
ListViewItem::ListViewItem(QListView* p, ListViewItem* a, Git* g, SCRef s,
- const QPtrVector<QPixmap>& pm, bool e, unsigned long t, FileHistory* f) :
- QListViewItem(p, a), git(g), fh(f), sha_(s), pms(pm), secs(t), isEvenLine(e) {
+ const int& w, bool e, unsigned long t, FileHistory* f) :
+ QListViewItem(p, a), git(g), fh(f), sha_(s), laneWidth(w), secs(t), isEvenLine(e) {
populated = isDiffTarget = isHighlighted = false;
}
@@ -568,7 +567,6 @@ void ListViewItem::paintGraph(const Rev&
break;
}
- int laneWidth = pms[0]->width();
int x1 = 0, x2;
for (uint i = 0; i < laneNum && x1 < width; i++, x1 = x2) {
x2 = x1 + laneWidth;
@@ -743,176 +741,3 @@ const QString ListViewItem::timeDiff(uns
}
-// ***************** GraphMetrics related methods *********************
-
-#define P_OR pw/2, ph/2
-#define P_0 pw, ph/2
-#define P_90 pw/2, 0
-#define P_180 0, ph/2
-#define P_270 pw/2, ph
-
-void MainImpl::GraphMetrics::setupPixmaps(int ph) {
-
- // set dimensions
- int pw = 3 * ph / 4;
- int r = ph / 4; // radius of dots
-
- // create cross line mask
- QPixmap cm(pw, ph);
- cm.fill();
- QPainter p;
- p.begin(&cm);
- p.setPen(QPen(Qt::black, 2));
- p.drawLine(P_180, P_0);
- p.end();
- QBitmap crossMask = cm.createHeuristicMask();
-
- QBrush myWhiteBrush(ODD_LINE_COL, Qt::SolidPattern);
- QColor colors[COLORS_NUM] = {Qt::black, Qt::red, DARK_GREEN, Qt::blue,
- Qt::darkGray, BROWN, Qt::magenta, ORANGE};
- pixmaps.clear();
- pixmaps.resize(LANE_TYPES_NUM * COLORS_NUM);
-
- for (int i = 0; i < LANE_TYPES_NUM * COLORS_NUM; i++) {
-
- int type = (i / COLORS_NUM) + 1;
- QColor myColorNum(colors[i % COLORS_NUM]);
- QBrush myBrush(myColorNum, Qt::SolidPattern);
-
- QPixmap* pm = new QPixmap(pw, ph);
- pm->fill(ODD_LINE_COL);
- p.begin(pm);
- p.setPen(QPen(myColorNum, 2));
-
- switch (type) {
- case ACTIVE:
- p.drawLine(P_90, P_270);
- p.save();
- p.setPen(Qt::NoPen);
- p.setBrush(myBrush);
- p.drawEllipse(pw/2 - r, ph/2 - r, 2*r, 2*r);
- p.restore();
- break;
- case NOT_ACTIVE:
- p.drawLine(P_90, P_270);
- break;
- case MERGE_FORK:
- p.drawLine(P_90, P_270);
- p.drawLine(P_180, P_0);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myBrush);
- break;
- case MERGE_FORK_R:
- p.drawLine(P_90, P_270);
- p.drawLine(P_180, P_OR);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myBrush);
- break;
- case MERGE_FORK_L:
- p.drawLine(P_90, P_270);
- p.drawLine(P_OR, P_0);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myBrush);
- break;
- case JOIN:
- p.drawLine(P_90, P_270);
- p.drawLine(P_180, P_0);
- break;
- case JOIN_R:
- p.drawLine(P_90, P_270);
- p.drawLine(P_180, P_OR);
- break;
- case JOIN_L:
- p.drawLine(P_90, P_270);
- p.drawLine(P_OR, P_0);
- break;
- case HEAD:
- p.drawLine(P_OR, P_270);
- p.drawLine(P_180, P_0);
- break;
- case HEAD_R:
- p.drawLine(P_OR, P_270);
- p.drawLine(P_180, P_OR);
- break;
- case HEAD_L:
- p.drawLine(P_OR, P_270);
- p.drawLine(P_OR, P_0);
- break;
- case TAIL:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_180, P_0);
- break;
- case TAIL_R:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_180, P_OR);
- break;
- case TAIL_L:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_OR, P_0);
- break;
- case CROSS:
- pm->setMask(crossMask);
- pm->fill(p.pen().color());
- break;
- case CROSS_EMPTY:
- p.drawLine(P_180, P_0);
- break;
- case INITIAL:
- p.drawLine(P_90, P_OR);
- p.save();
- p.setPen(Qt::NoPen);
- p.setBrush(QBrush(myColorNum, Qt::SolidPattern));
- p.drawEllipse(pw/2 - r, ph/2 - r, 2*r, 2*r);
- p.restore();
- break;
- case BRANCH:
- p.drawLine(P_OR, P_270);
- p.save();
- p.setPen(Qt::NoPen);
- p.setBrush(QBrush(myColorNum, Qt::SolidPattern));
- p.drawEllipse(pw/2 - r, ph/2 - r, 2*r, 2*r);
- p.restore();
- break;
- case UNAPPLIED:
- p.save();
- p.setPen(Qt::NoPen);
- p.setBrush(QBrush(Qt::red, Qt::SolidPattern));
- p.drawRect(pw/2 - r, ph/2 - 1, 2*r, 2);
- p.restore();
- break;
- case APPLIED:
- p.save();
- p.setPen(Qt::NoPen);
- p.setBrush(QBrush(DARK_GREEN, Qt::SolidPattern));
- p.drawRect(pw/2 - r, ph/2 - 1, 2*r, 2);
- p.drawRect(pw/2 - 1, ph/2 - r, 2, 2*r);
- p.restore();
- break;
- case BOUNDARY:
- p.drawLine(P_90, P_OR);
- p.save();
- p.setBrush(myWhiteBrush);
- p.drawEllipse(pw/2 - r, ph/2 - r, 2*r, 2*r);
- p.restore();
- p.drawEllipse(pw/2 - r, ph/2 - r, 2*r, 2*r);
- break;
- case BOUNDARY_C:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_180, P_0);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myWhiteBrush);
- p.drawRect(pw/2 - r, ph/2 - r, 2*r, 2*r);
- break;
- case BOUNDARY_R:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_180, P_OR);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myWhiteBrush);
- p.drawRect(pw/2 - r, ph/2 - r, 2*r, 2*r);
- break;
- case BOUNDARY_L:
- p.drawLine(P_90, P_OR);
- p.drawLine(P_OR, P_0);
- p.fillRect(pw/2 - r, ph/2 - r, 2*r, 2*r, myWhiteBrush);
- p.drawRect(pw/2 - r, ph/2 - r, 2*r, 2*r);
- break;
- }
- p.end();
- pixmaps.insert(i, pm); // pixmaps has autoDelete set
- }
-}
diff --git a/src/listview.h b/src/listview.h
index 7e52e9a..eafb7c2 100644
--- a/src/listview.h
+++ b/src/listview.h
@@ -20,7 +20,7 @@ class FileHistory;
class ListViewItem: public QListViewItem {
public:
ListViewItem(QListView* p, ListViewItem* a, Git* g, SCRef sha,
- const QPtrVector<QPixmap>& pm, bool e, unsigned long t, FileHistory* f);
+ const int& w, bool e, unsigned long t, FileHistory* f);
SCRef sha() const { return sha_; }
int getLaneType(uint pos) const;
@@ -45,7 +45,7 @@ private:
Git* git;
FileHistory* fh;
const QString sha_;
- const QPtrVector<QPixmap>& pms;
+ const int& laneWidth;
unsigned long secs;
bool populated, isEvenLine, isHighlighted, isDiffTarget;
};
diff --git a/src/mainimpl.cpp b/src/mainimpl.cpp
index 0a1efb4..620b3e8 100644
--- a/src/mainimpl.cpp
+++ b/src/mainimpl.cpp
@@ -109,7 +109,6 @@ MainImpl::MainImpl(const QString& cd, QW
lineEditSHA->setMinimumWidth(wd);
// gm is now set to application's default font
- gm.pixmaps.setAutoDelete(true);
adjustFontSize(0); // create pixmaps
connect(git, SIGNAL(newRevsAdded(const FileHistory*, const QValueVector<QString>&)),
@@ -945,7 +944,7 @@ void MainImpl::adjustFontSize(int delta)
int h = item->height();
delete item;
- gm.setupPixmaps(h); // (re)create the pixmaps
+ gm.laneWidth = 3 * h / 4;
emit repaintListViews(gm.font);
}
diff --git a/src/mainimpl.h b/src/mainimpl.h
index 0dbc38a..3446806 100644
--- a/src/mainimpl.h
+++ b/src/mainimpl.h
@@ -155,11 +155,7 @@ private:
int recentRepoMenuPos;
struct GraphMetrics {
- void setupPixmaps(int height);
- int height() const { return pixmaps[0]->height(); }
- int width () const { return pixmaps[0]->width(); }
-
- QPtrVector<QPixmap> pixmaps;
+ int laneWidth;
QFont font;
};
GraphMetrics gm;
--
1.4.3.rc2.gf8ffb
^ permalink raw reply related
* Re: [PATCH 3/3] Teach git-branch -v and -w options
From: Lars Hjemli @ 2006-10-22 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7r83x9f.fsf@assigned-by-dhcp.cox.net>
[the gitlist fell off my first reply, so I've put it back...]
On 10/22/06, Junio C Hamano <junkio@cox.net> wrote:
> I was almost going to say that your patch saddened me because
> doing builtin-branch on top of Linus's packed-refs work (which
> means doing the series on top of "next") was part of my plan,
Heh, I don't want to compete with your c-skills :-)
> If you are aware of Kristian's patch that is a good news. I do
> not have much objection to add optional frills to git-branch
> listing output, but I'd rather not see it done in the shell
> implementation. Doing anything on the current git-branch.sh
> means that would need to be re-done later.
Agreed. I'll try and come up with a builtin instead, and let you worry
about more interesting stuff.
--
larsh
^ permalink raw reply
* Re: [PATCH] Build in shortlog
From: Johannes Schindelin @ 2006-10-22 20:50 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, junkio
In-Reply-To: <453BA8E9.8010703@gmail.com>
Hi,
On Sun, 22 Oct 2006, A Large Angry SCM wrote:
> Johannes Schindelin wrote:
> [...]
> > diff --git a/Makefile b/Makefile
> > index 018dad2..0beda57 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -106,7 +106,7 @@ uname_P := $(shell sh -c 'uname -p 2>/de
> > # CFLAGS and LDFLAGS are for the users to override from the command line.
> > -CFLAGS = -g -O2 -Wall
> > +CFLAGS = -g -O0 -Wall
> > LDFLAGS =
> > ALL_CFLAGS = $(CFLAGS)
> > ALL_LDFLAGS = $(LDFLAGS)
> > @@ -178,7 +178,7 @@ SCRIPT_SH = \
> [...]
>
> This part of your patch needs some explanation.
Easy. Too many Czech beer, and not enough sleep. Therefore not enough
removing debug remnants.
Junio, if you want to apply, could you please edit this part out?
Ciao,
Dscho
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Johannes Schindelin @ 2006-10-22 20:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0610221017180.3962@g5.osdl.org>
Hi,
On Sun, 22 Oct 2006, Linus Torvalds wrote:
> Anyway, there's two kinds of commands wrt revision ranges in git:
>
> - "git diff"
> - everything else
Well, there is also "git format-patch". If you provide it with only one
commit-ish "<rev>", it will believe you actually meant "<rev>..".
Ciao,
Dscho
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Linus Torvalds @ 2006-10-22 20:56 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610222117.45766.andyparkins@gmail.com>
On Sun, 22 Oct 2006, Andy Parkins wrote:
>
> You're entirely correct, that that is what I was looking for in that
> particular case. However, the reason I raised it as a question was that I
> was poking around with git (which I'm enjoying immensely by the way - it
> really is as perfect an SCM as I have ever used) and in short succession did
>
> git-diff X^..X
> git-log X^..X
> git-format-patch X^..X
Now, "git show" obviously does exactly what you probably wanted, but for
future reference, the "git log" family of commands also take a "number of
commits" limiter.
So you can also do things like
git log --cc -1 X
and it will actually do something very similar to "git show". It's not
_quite_ identical, but it's close - at least for the special case of a
single commit.
"git show" actually uses a magic "no_walk" internal flag which means that
you can give it _several_ revisions, and it will take them as a raw "list"
of revisions rather than take them as a command to "walk" the revision
space and then just show one of them (like the "git log --cc -1" example
would do).
So with "git show", you can do
git show X Y Z
and it will show those exact three commits. That's _different_ from
git log --cc -3 X Y Z
which will show the three "most recent" commits when you start walking the
revision DAG. (The above "git log" command really doesn't make much sense,
since the output will depend on commit date - it has well-specified
behaviour, but it's really a pretty random thing to do: it might, for
example, show the three commits X, X^ and Z, and not Y at all).
Anyway, "git show" is a very useful thing. It's actually one of the
commands I use most. If I ever want to see what happened in a single
commit (eg somebody sends me a bug-report and says "commit XYZ introduced
a regression"), that's what I would use.
Looking at my history, the commands I tend to use most are:
git log
git diff
git pull <some-remote-repo>
gitk ORIG_HEAD..
git log -p some/directory/or/file
git grep -w <some-identifier> [possibly-some-subdirectory]
git show <some-rev>
and while I think that "git pull" and "gitk ORIG_HEAD.." thing tends to be
something special to being a top-level maintainer (although maybe I'm
wrong - you'd probably do the same just because you're following a remote
tree under active development), all the rest are commands that everybody
should know so intimately that they don't even need to think about them.
"git grep" in particular seems to be something that a lot of people
haven't necessarily even realized is there. Yet it's actually extremely
powerful and efficient both for the "current tree" and for "old
revisions".
It's interesting: I used to do a lot of "plain grep" usage, but with git,
most of my greps by far are all of the form "git grep". I've gotten so
used to it that I find myself wanting to do "git grep" even on non-git
stuff, and if I look at somebody elses tar-ball I often end up doing
git init-db
git add .
just to be able to do "git grep" on it. I've totally stopped doing the
"find . -name '*.[ch]' | xargs grep -w" sequence that I _used_ to do a lot
of.
Linus
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
From: Linus Torvalds @ 2006-10-22 21:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610222236.45414.jnareb@gmail.com>
On Sun, 22 Oct 2006, Jakub Narebski wrote:
>
> To be true I do those "whitespace cleanup" patches when I notice
> that something is mis-aligned for _my_ tab width (2 spaces).
Oh, wow.
You have clearly been damaged by some nasty GNU coding style or similar.
Please immediately turn tabs into 8 character hard-tabs, and read the
kernel Documentation/CodingStyle document.
After that, you may have to go to some detox unit to purge yourself of the
habit of 2-character indents, and I realize it will be hard and you'll
feel like shit for a while, but you'll be a better person for it.
It's like kicking a bad drug habit. It may be painful for a while, and you
might wistfully think back on the "happy days" when things went by in a
haze of unclear indentations, but really, it's worth it.
Linus
^ permalink raw reply
* [PATCH] threeway_merge: if file will not be touched, leave it alone
From: Johannes Schindelin @ 2006-10-22 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4ptyjttb.fsf@assigned-by-dhcp.cox.net>
If the merge base _and_ the to-be merged brach have a certain file, but
HEAD has not, do not complain if that file exists anyway. It will not be
overwritten.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Fri, 20 Oct 2006, Junio C Hamano wrote:
> While we are talking about merge-recursive, I could use some
> help from somebody familiar with merge-recursive to complete the
> read-tree changes Linus mentioned early this month.
>
> The issue is that we would want to remove one verify_absent()
> call in unpack-tree.c:threeway_merge(). When read-tree decides
> to leave higher stages around, we do not want it to check if the
> merge could clobber a working tree file, because having an
> unrelated file at the same path in the working tree sometimes is
> and sometimes is not a conflict, depending on the outcome of the
> merge, and that part of the code does not _know_ the outcome
> yet.
How about this? It passes the testsuite, and I tested it with the
test case you did, and with the same test case with recursive
merge.
unpack-trees.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3ac0289..b4994c4 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -658,10 +658,9 @@ int threeway_merge(struct cache_entry **
* up-to-date to avoid the files getting overwritten with
* conflict resolution files.
*/
- if (index) {
+ if (index)
verify_uptodate(index, o);
- }
- else if (path)
+ else if (no_anc_exists)
verify_absent(path, "overwritten", o);
o->nontrivial_merge = 1;
--
1.4.3.1.ga3de1-dirty
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.4.3
From: Anders Larsen @ 2006-10-22 21:09 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <20061021002251.GO20017@pasky.or.cz>
On Sat, 21 Oct 2006 02:22:51 +0200, Petr Baudis wrote:
>> That said, "LESS=FRS" doesn't really help that much. It still clears the
>> screen. Using "LESS=FRSX" fixes that, but the alternate display sequence
>> is actually nice _if_ the pager is used.
>
> Hmm, what terminal emulator do you use? The reasonable ones should
> restore the original screen.
And indeed they do.
The problem is, when the original screen is restored, the diff output that
was paged through less -FRS goes poof as well.
Cheers
Anders
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
From: Jakub Narebski @ 2006-10-22 21:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610221359090.3962@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 22 Oct 2006, Jakub Narebski wrote:
> >
> > To be true I do those "whitespace cleanup" patches when I notice
> > that something is mis-aligned for _my_ tab width (2 spaces).
>
> Oh, wow.
>
> You have clearly been damaged by some nasty GNU coding style or similar.
>
> Please immediately turn tabs into 8 character hard-tabs, and read the
> kernel Documentation/CodingStyle document.
2 character wide spaces are minimal width indent one can work with.
And to reduce line width I use the minimal indent with. Yes, I know
that I should correct coding style instead...
Using 2 characters wide tabs for gitweb stems also from the fact
that I could not configure Emacs and cperl-mode to automatically
indent with tabs (probably because many Emacsers think that
TabsAreEvil); I should probably set some indent/offset variable
to the tab-width value, or something...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Jakub Narebski @ 2006-10-22 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610221331571.3962@g5.osdl.org>
Linus Torvalds wrote:
> Now, "git show" obviously does exactly what you probably wanted, but for
> future reference, the "git log" family of commands also take a "number of
> commits" limiter.
>
> So you can also do things like
>
> git log --cc -1 X
>
> and it will actually do something very similar to "git show". It's not
> _quite_ identical, but it's close - at least for the special case of a
> single commit.
And of course this shortcut is not documented. git-log(1) and
git-rev-list(1) talks only about "--max-count=<n>", and "-n <n>",
and doesn't talk about possible shortcuts "-n<n>" and "-<n>".
Perhaps because those shortcuts are discouraged?
Additionally you can find "-n <n>" shortcut only further on
the git-rev-list(1).
Patch will follow.
BTW. what does "recursive diff" mean (in git)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Johannes Schindelin @ 2006-10-22 22:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehgoii$1ap$1@sea.gmane.org>
Hi,
On Sun, 22 Oct 2006, Jakub Narebski wrote:
> BTW. what does "recursive diff" mean (in git)?
AFAIU it means that the diff code recurses into subdirectories.
Ciao,
Dscho
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Jakub Narebski @ 2006-10-22 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0610230008490.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sun, 22 Oct 2006, Jakub Narebski wrote:
>
>> BTW. what does "recursive diff" mean (in git)?
>
> AFAIU it means that the diff code recurses into subdirectories.
When git-diff _doesn't_ recurse into subdirectories?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Add "next" link to commitdiff view
From: Jakub Narebski @ 2006-10-22 22:37 UTC (permalink / raw)
To: git; +Cc: Junio Hamano
Add a kind of "next" view in the bottom part of navigation bar for
"commitdiff" view.
For commitdiff between two commits:
(from: _commit_)
For commitdiff for one single parent commit:
(parent: _commit_)
For commitdiff for one merge commit
(merge: _commit_ _commit_ ...)
For commitdiff for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
display, everything is perhaps unnecessary esc_html on display.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio (and others), is it what you wanted? The idea was to change
"commitdiff" view only in minimal way, and preserve similarity
to "commit" format.
SHA1 ids are printed in monospace (fixed width) font. BTW. should
we put '...' after shortened SHA1? Should those '...' be included
in link?
gitweb/gitweb.perl | 49 +++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c9e57f0..4241d5c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3280,6 +3280,51 @@ sub git_commitdiff {
if (!%co) {
die_error(undef, "Unknown commit object");
}
+
+ # we need to prepare $formats_nav before any parameter munging
+ my $formats_nav;
+ if ($format eq 'html') {
+ $formats_nav =
+ $cgi->a({-href => href(action=>"commitdiff_plain",
+ hash=>$hash, hash_parent=>$hash_parent)},
+ "raw");
+
+ if (defined $hash_parent) {
+ # commitdiff with two commits given
+ my $hash_parent_short = $hash_parent;
+ if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) {
+ $hash_parent_short = substr($hash_parent, 0, 7);
+ }
+ $formats_nav .=
+ ' (from: ' .
+ $cgi->a({-href => href(action=>"commitdiff",
+ hash=>$hash_parent)},
+ esc_html($hash_parent_short)) .
+ ')';
+ } elsif (!$co{'parent'}) {
+ # --root commitdiff
+ $formats_nav .= ' (initial)';
+ } elsif (scalar @{$co{'parents'}} == 1) {
+ # single parent commit
+ $formats_nav .=
+ ' (parent: ' .
+ $cgi->a({-href => href(action=>"commitdiff",
+ hash=>$co{'parent'})},
+ esc_html(substr($co{'parent'}, 0, 7))) .
+ ')';
+ } else {
+ # merge commit
+ $formats_nav .=
+ ' (merge: ' .
+ join(' ', map {
+ $cgi->a({-href => href(action=>"commitdiff",
+ hash=>$_)},
+ esc_html(substr($_, 0, 7)));
+ } @{$co{'parents'}} ) .
+ ')';
+ }
+ }
+
if (!defined $hash_parent) {
$hash_parent = $co{'parent'} || '--root';
}
@@ -3317,10 +3362,6 @@ sub git_commitdiff {
if ($format eq 'html') {
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $co{'id'});
- my $formats_nav =
- $cgi->a({-href => href(action=>"commitdiff_plain",
- hash=>$hash, hash_parent=>$hash_parent)},
- "raw");
git_header_html(undef, $expires);
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] gitweb: Add "next" link to commitdiff view
From: Jakub Narebski @ 2006-10-22 22:43 UTC (permalink / raw)
To: git
In-Reply-To: <200610230037.57183.jnareb@gmail.com>
BTW there are some errors in displaying commitdiff of initial commit,
take for example a=commitdiff;h=161332a521fe10c41979bcd493d95e2ac562b7f
for git.git repository in gitweb.
Needs fixing.
--
Jakub Narebski
Poland
^ 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