Project

General

Profile

Feature #4000

Make compare more functional

Added by Marcin Kuzminski [CTO] over 4 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
08.06.2016
Due date:
% Done:

0%

Estimated time:
Sorting:
Commit Number:

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 ?


Related issues

Related to RhodeCode CE/EE - Bug #4002: [ce] Got whole page inlined at commit list when creating PRClosedDaniel D09.06.2016

Actions
#1

Updated by Daniel D over 4 years ago

The interesting thing is that commits will show for some comparisons with merge=0, eg:

https://internal-code.rhodecode.com/rhodecode-control/compare/tag@1.4.0...tag@v1.5.0?target_repo=rhodecode-control&merge=

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.

#2

Updated by Marcin Kuzminski [CTO] over 4 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

#3

Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Related to Bug #4002: [ce] Got whole page inlined at commit list when creating PR added
#4

Updated by Daniel D over 4 years ago

These tag comparisons show what happens when 2 refs had commits in one not the other:

The way the logic worked before, I have a feeling our compare with merge=0 did not show 8 commits, only 7

#5

Updated by Daniel D over 4 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.

#6

Updated by Marcin Kuzminski [CTO] over 4 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

#7

Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Target version changed from v4.2 to v4.3
#8

Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Target version changed from v4.3 to v4.4
#9

Updated by Marcin Kuzminski [CTO] over 4 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

#10

Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Tracker changed from Bug to Feature
#11

Updated by Marcin Kuzminski [CTO] over 4 years ago

  • Target version changed from v4.5 to v4.6
#12

Updated by Marcin Kuzminski [CTO] about 4 years ago

  • Status changed from New to In Progress
#13

Updated by Marcin Kuzminski [CTO] about 4 years ago

  • Assignee changed from Daniel D to Marcin Kuzminski [CTO]
#16

Updated by Marcin Kuzminski [CTO] about 4 years ago

  • Target version changed from v4.6 to v4.7
#17

Updated by Marcin Kuzminski [CTO] almost 4 years ago

  • Target version changed from v4.7 to v4.10
#18

Updated by Marcin Kuzminski [CTO] over 3 years ago

  • Status changed from In Progress to New
#19

Updated by Marcin Kuzminski [CTO] over 3 years ago

  • Target version changed from v4.10 to v4.11
#20

Updated by Marcin Kuzminski [CTO] over 3 years ago

  • Target version changed from v4.11 to v5.0

Also available in: Atom PDF