could you please post the commit ids?

greetings, martin.

On Sat, Sep 06, 2008 at 12:40:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

"Added DMALLOC_USE_HASHBASE mode" is fe982070cac0283b79a3a4a3a54b7865537acab7.

ah, i think i see the problem. it looks like the backports somehow get indicated as whole merges.

not sure what stephen has done here, i thought that backports were added as grafts which is extra data not part of the commits themselves.

take a look at 3ddc88c0499fc084d5ddc3a38cb2620e3cfb4a63 and you see the merge lines that cause the confusion.

stephen, can yopu elaborate on this?

greetings, martin.

As for now, until the fully backport-connected history is finished and the patch to gitk is in, you can reduce the clutter in the gitk view by using: gitk --first-parent 7.8 7.6 7.4 7.2 7.0 0.6 0.5

That doesn't make any difference for my little test case src/pike_memory.c. I use git 1.5.4.3.

Like embee, I'm curious about those backport grafts that appear as merges. Is this only a problem of representation in gitk and git-log? To me it seems odd to describe them as merges since I reckon that content would be identical after a merge.

Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

As for now, until the fully backport-connected history is finished and the patch to gitk is in, you can reduce the clutter in the gitk view by using: gitk --first-parent 7.8 7.6 7.4 7.2 7.0 0.6 0.5

That doesn't make any difference for my little test case src/pike_memory.c. I use git 1.5.4.3.

Well, it should, because it removes all the backport info, but then again maybe not all commands you are using are honouring the --first-parent flag. However, instead of pursuing this...

Like embee, I'm curious about those backport grafts that appear as merges. Is this only a problem of representation in gitk and git-log? To me it seems odd to describe them as merges since I reckon that content would be identical after a merge.

I did some backchecks on the git mailinglist now, and it appears that I was a bit overly optimistic in my assumption that git is able to distinguish between backports and merges based on parenthood alone.

The recommended practice is that for back/forwardports the commit id's of the originating cherry-picked patches are mentioned at the bottom of the new commit message.

Gitweb already automatically transforms them into clickable links, gitk probably still needs patches to make them both clickable as well as draw a visual dotted line in the treegraph to show the relation.

This means that I'll have to regenerate the backport/forwardport way of linking to modify the commit messages instead of the graft/parent list.

actually, there is a concept that could help, in addition to the normall commit hash there is als an object hash that is only made out of the diff and maybe the comment (not sure), now all that is needed is tools to find multiple occurances of these and connect them.

that search could be expensive though, so any commits found would need to be recorded somewhere.

greetings, martin.

A problem is that the diff might not be byte-for-byte equivalent (considering it presumably is stored with offsets and/or context).

There would only be a "semantic" equivalence, which might be abused: People could be tempted to connect wildly different patches in the belief that they have the "same effect", which is probably not a good thing to do. But that's rather a question of policy and judgement.

true, but if the backport was done with a git cherry-pick they would have at least the same author and timestamp. (ok, at that point one might as well explicitly mark the cherry pick...)

greetings, martin.

Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:

...

The recommended practice is that for back/forwardports the commit id's of the originating cherry-picked patches are mentioned at the bottom of the new commit message.

Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again.

No. The backports in Pike would be done in git using "git cherry-pick". And as-is "git cherry-pick" does not create a parent reference, but gives you the option of a textual reference in the free-form commit message. This means that the current practice of creating extra parents for the backports has to be altered into either: - Textual references at the bottom of the commit message. - Or usage of a new (native git) link which I'm trying to get included into git as we speak.

I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports.

That's what I thought first as well, and it might even be true, but it's not what the git community wants to fix. It's either the first or the second option above, and I'm pushing for the second at the moment.

...

This means that I'll have to regenerate the backport/forwardport way of linking to modify the commit messages instead of the graft/parent list.

Correct. And apparently it was/is intended for merges only, even though the diff-machinery already delivers correct results even if it's a cherry-pick instead of a merge.

Does it? That's also a thing that confuses me: Consider commit 1cc21ef0320ecb734d4db5b85dbdc0406815e38e, which is a grafted merge from 7.8 to 7.6.

In gitk, it shows a three-way merge, where the diff from the 7.6 parent shows the patch, as expected. The diff from 7.8 apparently shows whatever differences there are between 7.8 and 7.6 that happens to be in the context of the 7.6 parent diff (e.g. the "verify_mexec_hdr" line).

That's odd imho. Assuming parent pointers mean merges, I'd expect to see all differences between the 7.8 and 7.6 versions of the file. If this was a real merge rather than a cherry-pick, the three-way diff would have a lot of essential information missing.

If, otoh, gitk can tell that the parent pointer into the 7.8 branch is a cherry-pick relation (using a property I've yet to understand), then I'd expect to see a two-way diff on the 7.6 branch only - the differences to 7.8 would just be garbage.

I also get confused with git-log: Look at the same commit with "git log -p 1cc21ef0". Then it doesn't show any diff at all, neither against 7.6 nor 7.8.

What's worse, if I use only "git log -p" on the 7.6 branch and search for the commit there then I don't see the diff either. If I look at the log on a branch, I really expect to see _all_ diffs that leads up to the current content. Maybe this can be explained with that the log due to all the backport merges skips over to the 7.8 tree after a while, but using --first-parent doesn't help.

Btw, speaking of git-log, how does one make it print out the branches like gitk does?

...

If parent pointers are used for both of these, then how would git tell a merge from a cherry-pick?

Well, the difference can be inferred from the content, /.../

I'm curious, how does that work? I guess this could explain the (imo) strange results I'm discussing above.

The properties I'm going to propose are that the link:

• Is called something like "origin".
• That it contains the SHA1 of the commit we're picking from in addition to the --mainline parent-number (in case there are multiple parents).
• A commit can have an arbitrary number of "origin" links.
• The origin link is weak by default, i.e. once inside a repository it will keep alive any referenced commits, but it will not cause the linked to commit to be fetched or pulled from a remote repository automatically.

Sounds sane to me, but I'm only a n00b.

Btw, my main use case for cherry-pick links are, as I've said elsewhere, to get an accurate log of the difference with "git log A..B". I see now that git-log has a --cherry-pick option which claims to detect cherry-picked patches anyway. How does it work? The commit diffs have to be byte-for-byte identical?

--decorate helps a bit, but it still doesn't show the branch(es) each commit is made on. Thanks for the tip anyway.

it would be nice to get an overview of how much of the original code is still left. maybe even for every version, to see the amount of change happening.

greetings, martin.

both actually, while 10% of the current code being original means that there is a lot of new code, it could be that 90% of the original code is still current, which would means that most of the original code survived but the whole codebase grew by a magnitude.

do that for each major revision and we get a nice graph of how the code evolved over time.

greetings, martin.

Oh, and there's 13 years and 1 month of development between "ulpc.0" and today ("ulpc.0" commit date was 1995-08-09).

The copyright statement says 1994, and the archived releases of LPC4 I can find date from April 1994 to September 1994, so end of 1994 sounds about right.

Helper script "count_r2lines" (counts total and original lines for a particular path and revision):

--8<-- #!/bin/sh

if [ "$#" != 2 ]; then echo >&2 "Usage: $0 dir rev" exit 1 fi

dir="$1" rev="$2"

repos="file://"$HOME"/repos/Pike/"

hit=0 tot=0 svn ls -r"$rev" -R "$repos"Pike/"$dir"@"$rev" | sed -e '//$/d' | while read f; do set `svn annotate -r"$rev" "$repos"Pike/"$dir"/"$f"@"$rev" | sed -e 's/^ *([0-9]*) *.*$/\1/' | /usr/xpg4/bin/awk 'BEGIN {x=0} $1=="2" { x++ } END {print x,NR}'` hit=`expr $hit + $1` tot=`expr $tot + $2` echo "$hit" "$tot" done | tail -1 --8<--

Main script (runs the helper script for each pike branch at head, and for the original ulpc checkin):

--8<-- #!/bin/sh

doit() { dir="$1" rev="$2" name="$3" set `./count_r2lines "$dir" "$rev"` echo "$name" "$1" "$2" }

for i in 7.8 7.6 7.4 7.2 7.0 0.6 0.5 ulpc ulpc.old; do doit $i head $i done doit ulpc 2 ulpc.0 --8<--

Pike script for presentation of the raw data generated by the main script:

--8<-- #!/home/marcus/bin/pike

int lcnt0;

int main() { array(string) x = Stdio.read_file("r2lines.data")/"\n"-({""}); sscanf(x[-1], "%*s %*d %d", lcnt0); foreach(x, string y) { string n; int l, t; sscanf(y, "%s %d %d", n, l, t); write("%-8s %5d / %6d %5.1f%% %5.1f%%\n", n, l, t, 100.0*l/t, 100.0*l/lcnt0); } return 0; } --8<--

I ran this on eureka-svn, but if you change the assignment of "repos" to "http://eureka-svn.lysator.liu.se/" it should run anywhere.

Nope. Adapting the sed command to do that is left as an execercise. :-)

Infotastic! Would be interesting to space out the x axis according to release times too, for yet another perspective on the data.