Feature #4000
open
Make compare more functional
Added by Marcin Kuzminski [CTO] almost 8 years ago. Updated over 6 years ago.
0%
Description
Go to this url: https://internal-code.rhodecode.com/rhodecode-control/compare/tag@v1.5.0...branch@default
Observe that diff is generated properly, however there are no commits to display. they show up when using ?merge=1 param.
That's a regression and in such way it's not very usable to not seen a commits between a branch and a tag.
Should we always use merge flag ?
Updated by Daniel D almost 8 years ago
The interesting thing is that commits will show for some comparisons with merge=0, eg:
We can probably force compare on same repo to use merge=1, this means we are expecting a common ancestor, actually in some weird cases 2 commits can not share same ancestor - so this is not good either.
Updated by Marcin Kuzminski [CTO] almost 8 years ago
Hmm it looks like it shows when same branch is used comparing tags uses same branch compare tag with branch uses compare stable with default
Updated by Marcin Kuzminski [CTO] almost 8 years ago
- Related to Bug #4002: [ce] Got whole page inlined at commit list when creating PR added
Updated by Daniel D almost 8 years ago
These tag comparisons show what happens when 2 refs had commits in one not the other:
- compare b4 to b5 merged 7 commits in b5 not in b4
- compare b5 to b4 merged 1 commit in b4 not in b5
- compare b4 to b5 unmerged - 14 files changed: 61 inserted, 181 deleted
- compare b5 to b4 unmerged - 14 files changed: 181 inserted, 61 deleted
The way the logic worked before, I have a feeling our compare with merge=0 did not show 8 commits, only 7
Updated by Daniel D almost 8 years ago
- Status changed from New to In Progress
Doing a check on a RC3.8 instance shows that the old behaviour was to show 7 commits.
Updated by Marcin Kuzminski [CTO] almost 8 years ago
- Subject changed from regression: using compare losts ability to show commits to Make compare more functional
- Target version changed from v4.1 to v4.2
So we identified it's actually not a regressions. We discussed it with Dan, and think we should improve the UI to be able to decide if you want to view this as merge or not.
Probably a checkbox checked by default would be a good start + some text explaning how the diffs are different
Updated by Marcin Kuzminski [CTO] almost 8 years ago
- Target version changed from v4.2 to v4.3
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Target version changed from v4.3 to v4.4
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Status changed from In Progress to New
- Target version changed from v4.4 to v4.5
I think we can move this outside to next release. Not sure why it;s on 4.4
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Tracker changed from Bug to Feature
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Target version changed from v4.5 to v4.6
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Status changed from New to In Progress
Updated by Marcin Kuzminski [CTO] over 7 years ago
- Assignee changed from Daniel D to Marcin Kuzminski [CTO]
Updated by Redmine Integration over 7 years ago
Commit 8e9f93ec94b2 by Marcin Kuzminski marcin@rhodecode.com on default branch references this issue. https://internal-code.rhodecode.com/rhodecode-enterprise-ce/changeset/8e9f93ec94b2214b5c48738fd3af551a41e2b5ef
Updated by Redmine Integration over 7 years ago
pullrequest merged by marcink (status: approved). https://internal-code.rhodecode.com/rhodecode-enterprise-ce/pull-request/2833
Updated by Marcin Kuzminski [CTO] about 7 years ago
- Target version changed from v4.6 to v4.7
Updated by Marcin Kuzminski [CTO] about 7 years ago
- Target version changed from v4.7 to v4.10
Updated by Marcin Kuzminski [CTO] over 6 years ago
- Status changed from In Progress to New
Updated by Marcin Kuzminski [CTO] over 6 years ago
- Target version changed from v4.10 to v4.11
Updated by Marcin Kuzminski [CTO] over 6 years ago
- Target version changed from v4.11 to v5.0