Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 368927 - Commit is drawn on the lane of the wrong branch
Summary: Commit is drawn on the lane of the wrong branch
Status: RESOLVED FIXED
Alias: None
Product: JGit
Classification: Technology
Component: JGit (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.1   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 373281 382204 398274 417479 (view as bug list)
Depends on:
Blocks: 373281
  Show dependency tree
 
Reported: 2012-01-18 04:49 EST by Vadim Dmitriev CLA
Modified: 2013-09-26 17:58 EDT (History)
8 users (show)

See Also:

Attachments
Test repository (22.62 KB, application/zip)
2013-03-17 03:08 EDT, Vadim Dmitriev CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vadim Dmitriev CLA 2012-01-18 04:49:48 EST 
How history graph should look:
|
o       1
|
|  o    2
|  |
o  |    3
 \ |
 | o    4
 o |    5
 | o    6

 
How JGit plots it:
|
o       1
|
o--.    2
|  |
o  |    3
 \ |
 | o    4
 o |    5
 | o    6
 
o.e.jgit.revplot.PlotCommitList#nextFreeLane() method doesn't consider free lane at specific repo timeline (i.e. lane 1 between commits 1 and 3 is not vacant, however when resolving child of the "4" commit this lane is already freed).
I already patched this method to take commit time into account when fixing bug 365460, but reverted changes to reduce changes cause by method signature change and to avoid possible computation overhead. It if is an acceptable solution and if eclipse hasn't purged this class' local history, I'll upload the patch.
Comment 1 Vadim Dmitriev CLA 2012-01-18 15:18:11 EST 
Could it be that there is no reliable and easy way to assert that commit X will be drawn above commit Y and below commit Z in the history graph in jgit? I just understood that the fix I was talking about will work only in very special cases. It is an interesting issue to fix, but I'm stuck at calculating closest "past" (drawn below) commit with direct childs in the future (dawn above) relative to the commit X.
Comment 2 Vadim Dmitriev CLA 2012-04-26 02:36:39 EDT 
It seems that bug 377532 could be affected by this issue too. Devs? Anyone? :)
Comment 3 Robin Rosenberg CLA 2013-03-16 18:20:20 EDT 
Can you provide a test repo for this?
What I did for 373281 was to add grafts to eliminate parts of the graph by running git filter-branch. I also used git-filter branch to remove the conten, leaving only the history.
Comment 4 Vadim Dmitriev CLA 2013-03-17 03:08:23 EDT 
Created attachment 228538 [details]
Test repository
Comment 5 Vadim Dmitriev CLA 2013-03-17 03:12:34 EDT 
Commit "4" (master) is drawn on the lane of "branch1" as a merge, but it is obviously not.
Comment 6 Robin Rosenberg CLA 2013-03-17 09:00:24 EDT 
*** Bug 373281 has been marked as a duplicate of this bug. ***
Comment 7 Robin Rosenberg CLA 2013-03-17 16:03:21 EDT 
Please have a look at https://git.eclipse.org/r/11257
Comment 8 Robin Stocker CLA 2013-05-03 11:09:20 EDT 
*** Bug 382204 has been marked as a duplicate of this bug. ***
Comment 9 Robin Rosenberg CLA 2013-05-23 15:00:42 EDT 
*** Bug 398274 has been marked as a duplicate of this bug. ***
Comment 10 Robin Stocker CLA 2013-09-18 04:22:04 EDT 
*** Bug 417479 has been marked as a duplicate of this bug. ***
Comment 11 Eike Stepper CLA 2013-09-18 08:40:27 EDT 
If this happens, is it safe to push to remote?
I.e. is it "just" kind of a visual problem?
Comment 12 LUGAN Anne-Laure CLA 2013-09-18 08:55:04 EDT 
Yes, it was only a visual problem in the history view.
(In reply to Eike Stepper from comment #11)
> If this happens, is it safe to push to remote?
> I.e. is it "just" kind of a visual problem?
Comment 13 Matthias Sohn CLA 2013-09-26 17:58:16 EDT 
merged as a065a06c2aefd0f5c5fc70d3410c3202f4d03268