* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Petr Baudis @ 2006-10-24 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01thbvb.fsf@assigned-by-dhcp.cox.net>
On Tue, Oct 24, 2006 at 07:17:28PM CEST, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> > Would it even be necessary to use any SHA-1 name in these cases,
> >> > I wonder. Would it make the page less useful if we replace all
> >> > of the above _commit_ with a fixed string, say, "parent"?
> >
> > I really disagree here - what's the point of not using SHA-1? The extra
> > string carries zero information in comparison with the previous state
> > and I just can't see how it *improves* stuff. If you're walking in a
> > maze and making marks on walls, it's still more useful if you have
> > corridors named by "A", "B", "C", "D" on junctions if you sometimes want
> > to walk back to the marked corridors.
>
> I think people would recognize A B C D as names but not 40- or
> 8- hexadecimal letters.
40-digit hex numbers is insane, I agree. But at least I personally tend
to recognize 8-digit hex numbers when dancing around them intensively
for a few minutes. Besides, it can be just "now I took the 8c5 way",
which is much easier to train your neurons too than "now I took the
fourth, uh, or was it the fifth parent? one, two, three, four, fifth...
hmm, what's in the statusbar?".
My point is that this does not improve the situation, and some people
(me) think it makes it worse, so what's the point of the change?
> I do not care much either way, actually, but I think it might
> make more sense to use abbreviated object names. On the other
> hand it may be Ok to have full 40 letters depending on the
> layout (e.g. the set of merge parents are shown on a single line
> in which case it would not fit, etc.).
Yes, I'm all for abbreviated names, but I'm against just writing
"parent" everywhere.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Pushing vs. alternates
From: Petr Baudis @ 2006-10-24 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmblhc3y.fsf@assigned-by-dhcp.cox.net>
On Tue, Oct 24, 2006 at 07:12:17PM CEST, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Tue, Oct 24, 2006 at 07:29:45AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> Petr Baudis <pasky@ucw.cz> writes:
> >>
> >> > I don't have time to code that myself right now, so I'm just tossing
> >> > an idea around - pushing to a directory with alternates set up should
> >> > avoid sending objects that are already in the alternate object database.
> >>
> >> That is probably only relevant for the first time, since
> >> subsequent pushes have refs from its own repository that tracks
> >> the tips of branches that was pushed for the last time.
> >
> > Well, I would send haves for the alternate repository anyway,...
>
> While I agree it would be an optimization if it worked, there is
> one conceptual problem here though, coming from old warts. It's
> not alternate "repository" but it is alternate object store.
Yes. Which is ugly but it may make sense in case of really having things
like "portable objects database" on your usbflash or whatever else
insane. ;-) Still,
> There is no guarantee that refs/ directory that is next to the
> objects/ alternate points at is related to that object store,
> for historical reasons (i.e. we have separate GIT_DIR and
> GIT_OBJECT_DIRECTORIES). So unless we declare that objects that
> are reachable from the refs/ *must* be fully connected in
> objects/ when objects/ has refs/ next to it, sending HAVEs from
> that refs/ can break the push, since that refs/ you are looking
> at may not be related to the alternate objects/ at all. I do
> not think it is a big restriction at all, but it is a new
> restriction you are adding to the repository layout.
I think this situation (having something that looks like a Git
repository with objects/ inside that does *not* belong to this
repository) _is_ totally insane and such a restriction is fine. Who
thinks otherwise?
If this really bothers anyone (I can't see why), we could have something
like [ -e objects/info/standalone ] to prohibit receive-pack from ever
thinking of checking if the object database belongs to a repository. We
could of course keep the behaviour as is and make the new one optional,
but I believe that the new one is more sensible.
> > ... You can only push if your login access is reduced to
> > git-shell, and something external could've set up your alternates.
>
> Ok, I was not thinking about "something external".
Also, if you can push, that does not imply at all that you can fetch as
well. In plenty of situations you can't; most UNIX machines do have ssh
running, but that's not very useful when they're behind a NAT or just a
restrictive firewall. And with my notebook, I'm almost always behind a
NAT.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Junio C Hamano @ 2006-10-24 17:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061024114923.GD20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> > Would it even be necessary to use any SHA-1 name in these cases,
>> > I wonder. Would it make the page less useful if we replace all
>> > of the above _commit_ with a fixed string, say, "parent"?
>
> I really disagree here - what's the point of not using SHA-1? The extra
> string carries zero information in comparison with the previous state
> and I just can't see how it *improves* stuff. If you're walking in a
> maze and making marks on walls, it's still more useful if you have
> corridors named by "A", "B", "C", "D" on junctions if you sometimes want
> to walk back to the marked corridors.
I think people would recognize A B C D as names but not 40- or
8- hexadecimal letters.
I do not care much either way, actually, but I think it might
make more sense to use abbreviated object names. On the other
hand it may be Ok to have full 40 letters depending on the
layout (e.g. the set of merge parents are shown on a single line
in which case it would not fit, etc.).
^ permalink raw reply
* Re: Pushing vs. alternates
From: Junio C Hamano @ 2006-10-24 17:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061024112028.GY20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Tue, Oct 24, 2006 at 07:29:45AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Petr Baudis <pasky@ucw.cz> writes:
>>
>> > I don't have time to code that myself right now, so I'm just tossing
>> > an idea around - pushing to a directory with alternates set up should
>> > avoid sending objects that are already in the alternate object database.
>>
>> That is probably only relevant for the first time, since
>> subsequent pushes have refs from its own repository that tracks
>> the tips of branches that was pushed for the last time.
>
> Well, I would send haves for the alternate repository anyway,...
While I agree it would be an optimization if it worked, there is
one conceptual problem here though, coming from old warts. It's
not alternate "repository" but it is alternate object store.
There is no guarantee that refs/ directory that is next to the
objects/ alternate points at is related to that object store,
for historical reasons (i.e. we have separate GIT_DIR and
GIT_OBJECT_DIRECTORIES). So unless we declare that objects that
are reachable from the refs/ *must* be fully connected in
objects/ when objects/ has refs/ next to it, sending HAVEs from
that refs/ can break the push, since that refs/ you are looking
at may not be related to the alternate objects/ at all. I do
not think it is a big restriction at all, but it is a new
restriction you are adding to the repository layout.
> ... You can only push if your login access is reduced to
> git-shell, and something external could've set up your alternates.
Ok, I was not thinking about "something external".
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Junio C Hamano @ 2006-10-24 17:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, git
In-Reply-To: <20061024113924.GC20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> Think of a future when you can shallowly clone near the tip of
>> git repository that does not have shell-script git-branch.sh
>> anymore. You cannot expect to already have the preimage of the
>> patch in such a case. You would still want to be able to revert
>> the change with "git apply -R".
>
> Hmm, how is this argument not applying to binary diffs you can't revert
> either?
Earlier you cannot, but because now you can, perhaps? ;-)
^ permalink raw reply
* [PATCH qgit] Change also tag marks when changing graph size
From: Marco Costalba @ 2006-10-24 16:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Josef Weidendorfer
When changing graph size with CTRL+ and CTRL-
update also tag/branch marks.
Also little cleanup.
---
Hi Josef,
please tell me if you are working on the same files, in this case I
will step back and wait you to finish your patch series and eventually
resubmit this one at the end.
Marco
src/listview.cpp | 116 ++++++++++++++++++++++++++++-------------------------
src/listview.h | 11 ++---
2 files changed, 66 insertions(+), 61 deletions(-)
diff --git a/src/listview.cpp b/src/listview.cpp
index 7251b97..1e33ac0 100644
--- a/src/listview.cpp
+++ b/src/listview.cpp
@@ -224,8 +224,7 @@ void ListView::on_newRevsAdded(const Fil
for (uint i = lv->childCount(); i < shaVec.count(); i++) {
lastItem = new ListViewItem(lv, lastItem, git, shaVec[i],
- d->m()->gm.laneWidth,
- evenLine, secs, fh);
+ d->m()->gm.laneWidth, evenLine, secs, fh);
evenLine = !evenLine;
}
}
@@ -539,24 +538,23 @@ #undef R_CENTER
}
-
void ListViewItem::paintGraph(const Rev& c, QPainter* p,
- const QColorGroup& cg, int width) {
+ const QColorGroup& cg, int width) {
- static QColor colors[COLORS_NUM] = {Qt::black, Qt::red, DARK_GREEN,
- Qt::blue, Qt::darkGray, BROWN,
- Qt::magenta, ORANGE};
+ static QColor colors[COLORS_NUM] = { Qt::black, Qt::red, DARK_GREEN,
+ Qt::blue, Qt::darkGray, BROWN,
+ Qt::magenta, ORANGE };
QListView* lv = listView();
if (!lv)
return;
QColorGroup::ColorRole crole = QColorGroup::Base;
- if ( isSelected() && lv->allColumnsShowFocus() )
- crole = QColorGroup::Highlight;
+ if (isSelected() && lv->allColumnsShowFocus())
+ crole = QColorGroup::Highlight;
- QBrush back = cg.brush( crole );
- p->fillRect( 0, 0, width, height(), back );
+ QBrush back = cg.brush(crole);
+ p->fillRect(0, 0, width, height(), back);
const QValueVector<int>& lanes(c.lanes);
uint laneNum = lanes.count();
@@ -567,27 +565,24 @@ void ListViewItem::paintGraph(const Rev&
break;
}
- int x1 = 0, x2;
- for (uint i = 0; i < laneNum && x1 < width; i++, x1 = x2) {
- x2 = x1 + laneWidth;
+ int x1 = 0, x2 = 0;
+ for (uint i = 0; i < laneNum && x1 < width; i++) {
+
+ x1 = x2;
+ x2 += laneWidth;
int ln = lanes[i];
if (ln == EMPTY)
- continue;
-
- int type = ln;
- if (ln == CROSS)
- type = NOT_ACTIVE;
+ continue;
int col = ( isHead(ln) || isTail(ln) || isJoin(ln)
- || ln == CROSS_EMPTY) ? mergeLane : i;
-
- paintGraphLane(p, type, x1, x2,
- colors[col % COLORS_NUM], back);
+ || ln == CROSS_EMPTY) ? mergeLane : i;
- if (ln == CROSS)
- paintGraphLane(p, CROSS, x1, x2,
- colors[mergeLane % COLORS_NUM], back);
+ if (ln == CROSS) {
+ paintGraphLane(p, NOT_ACTIVE, x1, x2, colors[col % COLORS_NUM], back);
+ paintGraphLane(p, CROSS, x1, x2, colors[mergeLane % COLORS_NUM], back);
+ } else
+ paintGraphLane(p, ln, x1, x2, colors[col % COLORS_NUM], back);
}
}
@@ -601,7 +596,7 @@ void ListViewItem::paintCell(QPainter* p
setupData(c);
if (column == GRAPH_COL) {
- paintGraph(c, p, _cg, width);
+ paintGraph(c, p, _cg, width);
return;
}
@@ -615,6 +610,8 @@ void ListViewItem::paintCell(QPainter* p
// tags, heads, refs and working dir colouring
if (mycolumn == LOG_COL) {
+ paintTagMarks(column, c);
+
if (isHighlighted) {
QFont f(p->font());
f.setBold(true);
@@ -638,37 +635,56 @@ void ListViewItem::paintCell(QPainter* p
p->restore();
}
-void ListViewItem::addTextPixmap(SCRef text, const QColor& color, bool bold) {
+void ListViewItem::paintTagMarks(int col, const Rev& c) {
- int col = LOG_COL + (fh ? 0 : -1);
- QStringList sl = QStringList::split('\n', text);
- loopList(it, sl) {
- QPixmap* pm = doAddTextPixmap(*it, color, col, bold);
- setPixmap(col, *pm);
- delete pm;
+ if (!pixmap(col) && !c.isBranch && !c.isCurrentBranch && !c.isTag && !c.isRef)
+ return; // common case
+
+ QPixmap* newPm = new QPixmap();
+
+ if (c.isBranch || c.isCurrentBranch) {
+ QColor color(c.isCurrentBranch ? Qt::green : DARK_GREEN);
+ addTextPixmap(&newPm, c.branch, color, c.isCurrentBranch);
}
+ if (c.isTag)
+ addTextPixmap(&newPm, c.tag, Qt::yellow);
+
+ if (c.isRef)
+ addTextPixmap(&newPm, c.ref, PURPLE);
+
+ if (!pixmap(col) || (newPm->rect() != pixmap(col)->rect()))
+ setPixmap(col, *newPm);
+
+ delete newPm;
+}
+
+void ListViewItem::addTextPixmap(QPixmap** pp, SCRef text, const
QColor& color, bool bold) {
+
+ QStringList sl = QStringList::split('\n', text);
+ loopList(it, sl)
+ doAddTextPixmap(pp, *it, color, bold);
}
-QPixmap* ListViewItem::doAddTextPixmap(SCRef text, const QColor&
color, int col, bool bold) {
+void ListViewItem::doAddTextPixmap(QPixmap** pp, SCRef text, const
QColor& color, bool bold) {
- const QPixmap* oldPm = pixmap(col);
QFont fnt(listView()->font());
if (bold)
fnt.setBold(true);
QFontMetrics fm(fnt);
+ QPixmap* pm = *pp;
+ int ofs = pm->isNull() ? 0 : pm->width() + 2;
int spacing = 2;
int pw = fm.boundingRect(text).width() + 2 * (spacing + int(bold));
int ph = fm.height() + 1;
- int ofs = oldPm ? oldPm->width() + 2 : 0;
- QPixmap* pm = new QPixmap(ofs + pw, ph);
+ QPixmap* newPm = new QPixmap(ofs + pw, ph);
QPainter p;
- p.begin(pm);
- if (oldPm) {
- pm->fill(isEvenLine ? EVEN_LINE_COL : ODD_LINE_COL);
- p.drawPixmap(0, 0, *oldPm);
+ p.begin(newPm);
+ if (!pm->isNull()) {
+ newPm->fill(isEvenLine ? EVEN_LINE_COL : ODD_LINE_COL);
+ p.drawPixmap(0, 0, *pm);
}
p.setPen(Qt::black);
p.setBrush(color);
@@ -676,7 +692,9 @@ QPixmap* ListViewItem::doAddTextPixmap(S
p.drawRect(ofs, 0, pw, ph);
p.drawText(ofs + spacing, fm.ascent(), text);
p.end();
- return pm;
+
+ delete pm;
+ *pp = newPm;
}
bool ListViewItem::changedFiles(SCRef c) {
@@ -708,16 +726,6 @@ void ListViewItem::setupData(const Rev&
}
setText(LOG_COL + adj, c.shortLog());
setText(AUTH_COL + adj, c.author());
-
- if (c.isBranch || c.isCurrentBranch) {
- QColor color(c.isCurrentBranch ? Qt::green : DARK_GREEN);
- addTextPixmap(c.branch, color, c.isCurrentBranch);
- }
- if (c.isTag)
- addTextPixmap(c.tag, Qt::yellow);
-
- if (c.isRef)
- addTextPixmap(c.ref, PURPLE);
}
const QString ListViewItem::timeDiff(unsigned long secs) const {
@@ -739,5 +747,3 @@ const QString ListViewItem::timeDiff(uns
tmp.append(QString::number(sec) + "s");
return tmp;
}
-
-
diff --git a/src/listview.h b/src/listview.h
index eafb7c2..b1f1011 100644
--- a/src/listview.h
+++ b/src/listview.h
@@ -33,12 +33,11 @@ public:
private:
void setupData(const Rev& c);
- 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);
+ void paintGraphLane(QPainter* p, int t, int x1, int x2, const
QColor& c, const QBrush& b);
+ void paintGraph(const Rev& c, QPainter *p, const QColorGroup& cg, int width);
+ void paintTagMarks(int col, const Rev& c);
+ void addTextPixmap(QPixmap** pp, SCRef text, const QColor& color,
bool bold = false);
+ void doAddTextPixmap(QPixmap** pp, SCRef text, const QColor& color,
bool bold);
const QString timeDiff(unsigned long secs) const;
bool changedFiles(SCRef c);
--
1.4.3.GIT
^ permalink raw reply related
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-24 16:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, bazaar-ng, git, Erik Bågfors
In-Reply-To: <Pine.LNX.4.64.0610232239220.3962@g5.osdl.org>
On Mon, Oct 23, 2006 at 10:42:23PM -0700 I heard the voice of
Linus Torvalds, and lo! it spake thus:
>
> Well, I would use the globally unique ones, certainly. It's the only
> thing that makes sense.
So would I, and it is.
> Using the _same_ names everywhere is just better.
This is just where we split on it. All else being equal, sure, but
all else is never equal. Most of my time is spent working forward
along one branch (different branches at different times, of course,
but at any given moment I'm almost certainly only concerned about one
branch), and having a different and advantageous localized naming
scheme there is a benefit I celebrate. If most of my time were
instead spent comparing and contrasting and intersecting and
cross-breeding branches, it would probably be as worthless to me as it
apparently is to you.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-24 16:34 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610240853160.10841@qynat.qvtvafvgr.pbz>
On Tue, Oct 24, 2006 at 08:58:56AM -0700 I heard the voice of
David Lang, and lo! it spake thus:
>
> one key difference is that with bzr you have to do this chopping by
> creating the branches at the time changes are done,
HUH? Why on earth do you think that?
To do this in a git data model, you point at 2 (or 3, or 4, or...)
revisions, anywhere in the revision-space universe. You derive back a
DAG of the history from each of them by recursing over parent links.
You figure out where (if anywhere) those DAG's intersect. And based
on that, you alter what and how you display; including or excluding
certain revs, changing the angles of lines or columnation of dots in a
graph, etc.
To do it in a bzr data model, you would follow *EXACTLY* the same
steps. As in, you do EXACTLY (a), then EXACTLY (b), then...
> what people are saying is that it doesn't easily support a truely
> distributed workflow. this is a very different statement.
And it's one that carries around a lot of unstated assumptions about
what "truely distributed" means, which *I*'m certainly not
understanding, because any meaning I can apply to the term doesn't
lead me to the conclusions it does you. Certainly, depending on your
workflow, certain parts of the UI are of lesser utility than they are
in mine, down to and including zero. And it's probably certain that
some parts of the UI aren't up to handling various workflows, too,
including OUR workflow. That's kinda what "in development" means...
But that's a very different statement from the claim that they CAN'T
be without changes to the conceptual model underneath. Just because a
UI is built around maintaining the fiction of a mainline doesn't mean
the system requires it. All you'd have to do to abandon it is write a
different log formatter that didn't show revnos and didn't nest merge
commits, and change (or add an option to) 'merge' to fast-forward if
possible. The difference between the views on how the pieces should
fit together really IS just that fine.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: David Lang @ 2006-10-24 15:58 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <20061024002622.GC17019@over-yonder.net>
On Mon, 23 Oct 2006, Matthew D. Fuller wrote:
> But I don't understand how bzr-the-abstract-data-model makes such
> things impossible, or even significantly different than doing so in
> git. In git, you're just chopping off one DAG where another one
> intersects it (or similar operations). To do it in bzr, you'd do...
> exactly the same thing. The revnos, or the mainline, are completely
> useless in such an operation of course, but they don't hurt it; the
> tool would just just ignore them like it does the SHA-1 of files in
> the revision.
one key difference is that with bzr you have to do this chopping by creating the
branches at the time changes are done, with git you do this chopping after the
fact when you are displaying the results.
As such you can chop and compare things in ways that were never contemplated by
anyone at the time changes are made.
>
>> See? When you visualize multiple branches together, HAVING
>> PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid
>> and interesting operation to do.
>
> I wouldn't be so absolutist about it, but certainly they're of
> extremely limited utility if of any at all in such cases. And yes, it
> can be an interesting operation. But what does that have to do with
> using revnos in other cases? You keep saying "having" where I would
> say "using".
and the bzr tools strongly encourage the use of these numbers
> I care about that first parent line. Therefore, I require my tool to
> at least _pretend_ to care. I'm not aware of any way in which the
> fundamental bzr structures care, but the UI is chock full of
> pretending. A necessary part of that pretending is not changing my
> mainline unless I specifically ask for it, and that means a
> merge-vs-pull distinction needs to be there. That's a _technical_
> sign that the tool is ready to work with me the way I want to work. A
> lack of it is a _technical_ sign that it's not suitable.
nobody is saying that the bzr approach is invalid for your workflow.
what people are saying is that it doesn't easily support a truely distributed
workflow. this is a very different statement.
your workflow isn't truely distributed so you bzr's model works well for you. no
problem, just don't claim that becouse you haven't run into any problems with
your workflow that there are no problems with bzr with other workflows.
David Lang
^ permalink raw reply
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Petr Baudis @ 2006-10-24 15:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610241359.57389.jnareb@gmail.com>
Dear diary, on Tue, Oct 24, 2006 at 01:59:57PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> >>> Would it even be necessary to use any SHA-1 name in these cases,
> >>> I wonder. Would it make the page less useful if we replace all
> >>> of the above _commit_ with a fixed string, say, "parent"?
> >
> > I really disagree here - what's the point of not using SHA-1? The extra
> > string carries zero information in comparison with the previous state
> > and I just can't see how it *improves* stuff. If you're walking in a
> > maze and making marks on walls, it's still more useful if you have
> > corridors named by "A", "B", "C", "D" on junctions if you sometimes want
> > to walk back to the marked corridors.
>
> That's why instead of resending the patch/amending the commit, I have
> put changing shortened SHA1 to constant name in new patch.
Huh, I don't quite understand. You threw away all the "A", "B", "C", "D"
and kept only the marks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Linus Torvalds @ 2006-10-24 15:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Josh Triplett, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0610241654060.2106@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 24 Oct 2006, Johannes Schindelin wrote:
>
> On Mon, 23 Oct 2006, Linus Torvalds wrote:
>
> > Although I think that somebody (Dscho?) also had a patch to remove
> > multiple identical parents, which he claimed could happen with
> > simplification otherwise. I didn't look any closer at it.
>
> IIRC It only happened when full history was wished for, _and_ path
> limiting. And Junio said that in that case, culling identical parents
> would be the wrong thing to do.
Yeah, with full history, you might as well keep the trivially identical
parents too. In the "nice rewrite", you'd get rid of them, but you'd get
rid of them not because they are trivially identical, but because they are
just the trivial case of "one parent totally dominates the other".
Sadly, while it may be the _trivial_ case in --full-history, it's probably
not even the common case, at least if you have lots of merges (because you
end up having one parent point to one merge, and the other to another, and
you need to simplify things in multiple passes).
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-24 15:15 UTC (permalink / raw)
To: David Rientjes; +Cc: Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64N.0610232336010.30334@attu2.cs.washington.edu>
On Mon, 23 Oct 2006, David Rientjes wrote:
>
> Some of the internal commands that have been coded in C are actually much
> better handled by the shell in the first place. It's much simpler to
> write and extend as well as being much more traceable for runtime
> problems.
Yes. However, from a portability (to Windows) standpoint, shell is just
about the worst choice.
Not that perl/python/etc really help - unless the _whole_ program is one
perl/python thing. Windows just doesn't like pipelines etc very much.
So I'd like all the _common_ programs to be built-ins..
Linus
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Johannes Schindelin @ 2006-10-24 14:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Josh Triplett, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610231237080.3962@g5.osdl.org>
Hi,
On Mon, 23 Oct 2006, Linus Torvalds wrote:
> Although I think that somebody (Dscho?) also had a patch to remove
> multiple identical parents, which he claimed could happen with
> simplification otherwise. I didn't look any closer at it.
IIRC It only happened when full history was wished for, _and_ path
limiting. And Junio said that in that case, culling identical parents
would be the wrong thing to do.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix regression tests on Cygwin
From: Johannes Schindelin @ 2006-10-24 14:53 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <11616320733093-git-send-email-hjemli@gmail.com>
Hi,
On Mon, 23 Oct 2006, Lars Hjemli wrote:
> On Cygwin, "make test" failes due to missing ".exe" a couple of places.
Last time I made "test" on cygwin, it did not complain. "../git" works
perfectly here.
Ciao,
Dscho
^ permalink raw reply
* Re: Question about commit message conventions
From: Tobias Toedter @ 2006-10-24 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <ehl6n6$6jn$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Tuesday 24 October 2006 16:08, Jakub Narebski wrote:
> Tobias Toedter wrote:
> > although I've read the documentation of git very carefully
[...]
> From Documentation/SubmittingPatches:
D'oh! Thanks.
Regards,
Tobias
--
Tobias Toedter | "I don't care to belong to a club that accepts people
Hamburg, Germany | like me as members." -- Groucho Marx
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about commit message conventions
From: Erik Mouw @ 2006-10-24 14:08 UTC (permalink / raw)
To: Tobias Toedter; +Cc: git
In-Reply-To: <200610241549.48238.t.toedter@gmx.net>
On Tue, Oct 24, 2006 at 03:49:44PM +0200, Tobias Toedter wrote:
> although I've read the documentation of git very carefully, I could not find
> anything related to certain commit message conventions. It would be great
> if someone here could explain a few things, maybe this could be added to
> the wiki afterwards (<http://git.or.cz/gitwiki/CommitMessageConventions>).
>
> First of all, what's the intended use of the "Signed-off-by:" lines? Does it
> make sense to add my name there, even when I'm listed as the author or
> committer of a commit? I thought that they are intended mostly to note the
> approval of other developers.
See Documentation/SubmittingPatches. You basically say you have the
right to submit the patch.
> On the other hand, concerning the approval of other developers, what's the
> difference between "Signed-off-by:" and "Acked-by:"? Are there any
> more "*-by:" fields that are in use?
Acked-by is usually used when someone (not the upstream maintainer the
patch was send to) agrees with the patch. I.e.: (s)he says the content
of the patch is OK without actually acknowledging something about the
right to submit.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: Question about commit message conventions
From: Jakub Narebski @ 2006-10-24 14:08 UTC (permalink / raw)
To: git
In-Reply-To: <200610241549.48238.t.toedter@gmx.net>
Tobias Toedter wrote:
> Hi,
>
> although I've read the documentation of git very carefully, I could not find
> anything related to certain commit message conventions. It would be great
> if someone here could explain a few things, maybe this could be added to
> the wiki afterwards (<http://git.or.cz/gitwiki/CommitMessageConventions>).
>
> First of all, what's the intended use of the "Signed-off-by:" lines? Does it
> make sense to add my name there, even when I'm listed as the author or
> committer of a commit? I thought that they are intended mostly to note the
> approval of other developers.
>
> On the other hand, concerning the approval of other developers, what's the
> difference between "Signed-off-by:" and "Acked-by:"? Are there any
> more "*-by:" fields that are in use?
>From Documentation/SubmittingPatches:
(6) Sign your work
[...]
The sign-off is a simple line at the end of the explanation for
the patch, which certifies that you wrote it or otherwise have
the right to pass it on as a open-source patch.
"Acked-by:" is used to notify that patch was accepted by somebody,
which usually is maintainer of part affected by patch.
I have seen exactly on "Cheered-on-by:", and there are probably some
"Noticed-by:" there.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Question about commit message conventions
From: Tobias Toedter @ 2006-10-24 13:49 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi,
although I've read the documentation of git very carefully, I could not find
anything related to certain commit message conventions. It would be great
if someone here could explain a few things, maybe this could be added to
the wiki afterwards (<http://git.or.cz/gitwiki/CommitMessageConventions>).
First of all, what's the intended use of the "Signed-off-by:" lines? Does it
make sense to add my name there, even when I'm listed as the author or
committer of a commit? I thought that they are intended mostly to note the
approval of other developers.
On the other hand, concerning the approval of other developers, what's the
difference between "Signed-off-by:" and "Acked-by:"? Are there any
more "*-by:" fields that are in use?
Regards,
Tobias
--
Tobias Toedter | "I don't care to belong to a club that accepts people
Hamburg, Germany | like me as members." -- Groucho Marx
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
From: Uwe Zeisberger @ 2006-10-24 13:09 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20061024095037.GA15936@soma>
Eric Wong wrote:
> I incorrectly thought this was hopelessly broken in svn 1.4.0,
> but now it's just broken in that the old method didn't work. It
> looks like svn propdel and svn propset must be used now and the
> (imho) more obvious svn rm --force && svn add no longer works.
>
> make -C t full-svn-test should now work
works for me, so ...
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
BTW: make -C t full-svn-test ran the test suite several times, which is
fine. But if I read correctly, half of the runs are superfluous if the
perl SVN libraries are not installed. Probably it's not worth fixing...
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=0+degree+Celsius+in+kelvin
^ permalink raw reply
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Jakub Narebski @ 2006-10-24 11:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061024114923.GD20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Use fixed string instead of shortened SHA1 identifier of commit
>> as a name for "mext" link in commitdiff view.
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>
> So I've read what the patch actually does this time, and I really
> dislike it.
>
>> Junio C Hamano wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
[...]
>>>> For commitdiff for one merge commit
>>>> (merge: _commit_ _commit_ ...)
[...]
>>>> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
>>>> display, everything is perhaps unnecessary esc_html on display.
>>>
>>> I always hated gitweb diffs that prefix each filepair with their
>>> full 40-byte SHA-1 blob object names. It just adds noise to the
>>> output without adding any meaningful information.
>
> I agree, using the shortened SHA1 would be definitely an improvement
> here, but
I'm planning on revamping gitweb diff output. Any ideas?
>>> Would it even be necessary to use any SHA-1 name in these cases,
>>> I wonder. Would it make the page less useful if we replace all
>>> of the above _commit_ with a fixed string, say, "parent"?
>
> I really disagree here - what's the point of not using SHA-1? The extra
> string carries zero information in comparison with the previous state
> and I just can't see how it *improves* stuff. If you're walking in a
> maze and making marks on walls, it's still more useful if you have
> corridors named by "A", "B", "C", "D" on junctions if you sometimes want
> to walk back to the marked corridors.
That's why instead of resending the patch/amending the commit, I have
put changing shortened SHA1 to constant name in new patch.
By the way, because those links to parents commitdiffs are just ordinary
links, you can see when those links are visited.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 0/3] gitweb: Improvements to commitdiff oview
From: Jakub Narebski @ 2006-10-24 11:49 UTC (permalink / raw)
To: git
This series (patch 2 to be more exact) fixes error seen for example in
a=commitdiff;h=161332a521fe10c41979bcd493d95e2ac562b7f
in git.git repository.
Shortlog:
[PATCH 1/3] gitweb: Get rid of git_print_simplified_log
[PATCH 2/3] gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
[PATCH 3/3] gitweb: Print commit message without title in commitdiff only if there is any
Diffstat:
gitweb/gitweb.perl | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 3/3] gitweb: Print commit message without title in commitdiff only if there is any
From: Jakub Narebski @ 2006-10-24 11:55 UTC (permalink / raw)
To: git
In-Reply-To: <200610241349.54685.jnareb@gmail.com>
Print the rest of commit message (title, i.e. first line of commit
message, is printed separately) only if there is any.
In repository which uses signoffs this shouldn't happen, because
commit message should consist of at least title and signoff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a88e0a8..e35ecb4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3360,9 +3360,11 @@ sub git_commitdiff {
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
git_print_authorship(\%co);
print "<div class=\"page_body\">\n";
- print "<div class=\"log\">\n";
- git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
- print "</div>\n"; # class="log"
+ if (@{$co{'comment'}} > 1) {
+ print "<div class=\"log\">\n";
+ git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
+ print "</div>\n"; # class="log"
+ }
} elsif ($format eq 'plain') {
my $refs = git_get_references("tags");
--
1.4.2.1
^ permalink raw reply related
* [PATCH 2/3] gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-24 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <200610241349.54685.jnareb@gmail.com>
Filter out commit ID output that git-diff-tree adds when called with
only one <tree-ish> (not only for --stdin) in git_commit and
git_commitdiff.
This also works with older git versions, which doesn't have
--no-commit-id option to git-diff-tree.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8ac60be..a88e0a8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3009,6 +3009,9 @@ sub git_commit {
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
+ # filter out commit ID output
+ @difftree = grep(!/^[0-9a-fA-F]{40}$/, @difftree);
+
# non-textual hash id's can be cached
my $expires;
if ($hash =~ m/^[0-9a-fA-F]{40}$/) {
@@ -3327,7 +3330,9 @@ sub git_commitdiff {
while (chomp(my $line = <$fd>)) {
# empty line ends raw part of diff-tree output
last unless $line;
- push @difftree, $line;
+ # filter out commit ID output
+ push @difftree, $line
+ unless $line =~ m/^[0-9a-fA-F]{40}$/;
}
} elsif ($format eq 'plain') {
--
1.4.2.1
^ permalink raw reply related
* [PATCH 1/3] gitweb: Get rid of git_print_simplified_log
From: Jakub Narebski @ 2006-10-24 11:52 UTC (permalink / raw)
To: git
In-Reply-To: <200610241349.54685.jnareb@gmail.com>
Replace calls to git_print_simplified_log with its expansion,
i.e. with calling git_print_log with appropriate options.
Remove no longer used git_print_simplified_log subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 13 ++-----------
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0a7d65c..8ac60be 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1697,15 +1697,6 @@ sub git_print_log ($;%) {
}
}
-sub git_print_simplified_log {
- my $log = shift;
- my $remove_title = shift;
-
- git_print_log($log,
- -final_empty_line=> 1,
- -remove_title => $remove_title);
-}
-
# print tree entry (row of git_tree), but without encompassing <tr> element
sub git_print_tree_entry {
my ($t, $basedir, $hash_base, $have_blame) = @_;
@@ -2995,7 +2986,7 @@ sub git_log {
"</div>\n";
print "<div class=\"log_body\">\n";
- git_print_simplified_log($co{'comment'});
+ git_print_log($co{'comment'}, -final_empty_line=> 1);
print "</div>\n";
}
git_footer_html();
@@ -3365,7 +3356,7 @@ sub git_commitdiff {
git_print_authorship(\%co);
print "<div class=\"page_body\">\n";
print "<div class=\"log\">\n";
- git_print_simplified_log($co{'comment'}, 1); # skip title
+ git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
print "</div>\n"; # class="log"
} elsif ($format eq 'plain') {
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Petr Baudis @ 2006-10-24 11:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610240008.08325.jnareb@gmail.com>
Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Use fixed string instead of shortened SHA1 identifier of commit
> as a name for "mext" link in commitdiff view.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
So I've read what the patch actually does this time, and I really
dislike it.
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >> Add a kind of "next" link 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.
> >
> > I always hated gitweb diffs that prefix each filepair with their
> > full 40-byte SHA-1 blob object names. It just adds noise to the
> > output without adding any meaningful information.
I agree, using the shortened SHA1 would be definitely an improvement
here, but
> > Would it even be necessary to use any SHA-1 name in these cases,
> > I wonder. Would it make the page less useful if we replace all
> > of the above _commit_ with a fixed string, say, "parent"?
I really disagree here - what's the point of not using SHA-1? The extra
string carries zero information in comparison with the previous state
and I just can't see how it *improves* stuff. If you're walking in a
maze and making marks on walls, it's still more useful if you have
corridors named by "A", "B", "C", "D" on junctions if you sometimes want
to walk back to the marked corridors.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ 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