Skip to content
This repository has been archived by the owner on Jul 13, 2024. It is now read-only.

Graph rendering fails with basic branching #159

Closed
laymain opened this issue May 5, 2017 · 4 comments
Closed

Graph rendering fails with basic branching #159

laymain opened this issue May 5, 2017 · 4 comments
Labels
🐛 Bug Unexpected behavior to be fixed

Comments

@laymain
Copy link

laymain commented May 5, 2017

Hi,

There's a bug on the graph rendering when a commit is made on a branch
after it has been used to create another branch:

image

var graph1 = new GitGraph({
  elementId: 'badGraph',
  mode: 'compact',
  template: 'blackarrow'
});
var m1 = graph1
  .branch("master")
  .commit();
var r1 = m1
  .branch('1.0.x');
m1.commit();
r1
  .commit()
  .merge(m1);

If we do the commit on the new branch before the commit on the first one, it renders finely:

image

var graph0 = new GitGraph({
  elementId: 'workingGraph',
  mode: 'compact',
  template: 'blackarrow'
});
var m0 = graph0
  .branch("master")
  .commit();
var r0 = m0
  .branch('1.0.x')
  .commit();
m0.commit();
r0.merge(m0);

https://jsfiddle.net/Laymain/k0z0277g/
@nicoespeon
Copy link
Owner

Hi @laymain, thanks for pointing out this issue, this is definitely a bug!

@nicoespeon nicoespeon added the 🐛 Bug Unexpected behavior to be fixed label May 10, 2017
yodalee added a commit to yodalee/gitgraph.js that referenced this issue Jul 22, 2017
@yodalee
fix wrong arrow angle on branching
cd8e4ba 
Relate Issue:
Issue nicoespeon#159

The Problem:
The following source code will create wrong branch arrow.
```
var graph1 = new GitGraph({
  elementId: 'badGraph',
  mode: 'compact',
  template: 'blackarrow'
});
var m1 = graph1.branch("master");
m1.commit();
var r1 = m1.branch('1.0.x');
m1.commit();
r1.commit();
```
The arrow pointed to r1 commit will pointed from second commit of m1
not follow the line from first commit of m1.

The Cause:
When create a commit, if user does not specify parent commit in options
gitgraph.js will execute following code:
```
options.parentCommit = options.parentCommit || _getParentCommitFromBranch(this);
```
to determine the parent commit of the created commit.
In the function `_getParentCommitFromBranch`, it will try to get the last
commit from current branch, then from parent branch. Since `r1.commit()`
is the first commit in its branch `1.0.x`, it will set its parent commit
to last commit of its parent branch, that is `master`. And since master
already add some new commit, the arrow will point from wrong commit, the
last commit of `master` branch.

There is code that deal with branch case:
```
if (options.parentCommit instanceof Commit === false && this.parentBranch instanceof Branch) {
  options.parentCommit = this.parentCommit;
}
```
It set `parentCommit` to the correct commit. However, since
`options.parentCommit` already been set by previous code, this code will
never execute since `options.parentCommit` is always a Commit.

The fix:
The fix is combining two scenario. If current branch already has commits,
the parentCommit will be set to last commit in this branch. Otherwise,
it will set to parent commit of this branch, which will be the correct commit
instead of last commit of parent branch.
yodalee added a commit to yodalee/gitgraph.js that referenced this issue Jul 22, 2017
@yodalee
fix wrong arrow angle on branching
282a672 
Relate Issue:
Issue nicoespeon#159

The Problem:
The following source code will create wrong branch arrow.
```
var graph1 = new GitGraph({
  elementId: 'badGraph',
  mode: 'compact',
  template: 'blackarrow'
});
var m1 = graph1.branch("master");
m1.commit();
var r1 = m1.branch('1.0.x');
m1.commit();
r1.commit();
```
The arrow pointed to r1 commit will pointed from second commit of m1
not follow the line from first commit of m1.

The Cause:
When create a commit, if user does not specify parent commit in options
gitgraph.js will execute following code:
```
options.parentCommit = options.parentCommit || _getParentCommitFromBranch(this);
```
to determine the parent commit of the created commit.
In the function `_getParentCommitFromBranch`, it will try to get the last
commit from current branch, then from parent branch. Since `r1.commit()`
is the first commit in its branch `1.0.x`, it will set its parent commit
to last commit of its parent branch, that is `master`. And since master
already add some new commit, the arrow will point from wrong commit, the
last commit of `master` branch.

There is code that deal with branch case:
```
if (options.parentCommit instanceof Commit === false && this.parentBranch instanceof Branch) {
  options.parentCommit = this.parentCommit;
}
```
It set `parentCommit` to the correct commit. However, since
`options.parentCommit` already been set by previous code, this code will
never execute since `options.parentCommit` is always a Commit.

The fix:
The fix is combining two scenario. If current branch already has commits,
the parentCommit will be set to last commit in this branch. Otherwise,
it will set to parent commit of this branch, which will be the correct commit
instead of last commit of parent branch.
@yodalee yodalee mentioned this issue Jul 22, 2017
Merged
@nicoespeon
Copy link
Owner

Hi @laymain,

Thanks to @yodalee, this should be fixed with v1.11.4 (https://github.com/nicoespeon/gitgraph.js/releases/tag/v1.11.4).

@laymain
Copy link
Author

laymain commented Aug 9, 2017 •
edited
Loading

Hi,

The wrong arrow angle is fixed, that's nice.
But is there any reason why it does not render in the same way
if a commit is made before or after branching?

image

https://jsfiddle.net/Laymain/qd2q91pe/

@nicoespeon nicoespeon mentioned this issue Aug 10, 2017
Closed
@nicoespeon
Copy link
Owner

I guess the reason is that rendering scenario doesn't take the same path and happen to follow a different strategy, which lack consistency.

Hopefully, that doesn't seem to be a big deal. But that is not expected.
I created another issue for this: #174

Thanks 😉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
🐛 Bug Unexpected behavior to be fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@laymain @nicoespeon