Project

General

Profile

Feature #4000

Make compare more functional

Added by Marcin Kuzminski [staff] over 3 years ago. Updated almost 2 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 PRClosed2016-06-09

History

#1 Updated by Daniel D over 3 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 [staff] over 3 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 [staff] over 3 years ago

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

#4 Updated by Daniel D over 3 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 3 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 [staff] over 3 years ago

  • Target version changed from v4.1 to v4.2
  • Subject changed from regression: using compare losts ability to show commits to Make compare more functional

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 [staff] over 3 years ago

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

#8 Updated by Marcin Kuzminski [staff] about 3 years ago

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

#9 Updated by Marcin Kuzminski [staff] about 3 years ago

  • Target version changed from v4.4 to v4.5
  • Status changed from In Progress to New

I think we can move this outside to next release. Not sure why it;s on 4.4

#10 Updated by Marcin Kuzminski [staff] almost 3 years ago

  • Tracker changed from Bug to Feature

#11 Updated by Marcin Kuzminski [staff] almost 3 years ago

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

#12 Updated by Marcin Kuzminski [staff] almost 3 years ago

  • Status changed from New to In Progress

#13 Updated by Marcin Kuzminski [staff] almost 3 years ago

  • Assignee changed from Daniel D to Marcin Kuzminski [staff]

#16 Updated by Marcin Kuzminski [staff] over 2 years ago

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

#17 Updated by Marcin Kuzminski [staff] over 2 years ago

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

#18 Updated by Marcin Kuzminski [staff] about 2 years ago

  • Status changed from In Progress to New

#19 Updated by Marcin Kuzminski [staff] about 2 years ago

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

#20 Updated by Marcin Kuzminski [staff] almost 2 years ago

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

Also available in: Atom PDF