Thinking of changing the order of relation chain

[Chris Poucet]

Hi,

Currently the relation-chain on gerrit shows the latest patch first instead of the first patch first. This doesn't align with the typical order of review, nor the order of patches in emails nor order of `git rebase -i`.

I'm considering reversing the order of the dependency chain to make these more aligned. I thought I'd reach out to hear what people think of this.

Thanks

 - simply, chris

Chris Poucet | Core Developer | poucet@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Edwin Kempin]

On Tue, Jul 19, 2022 at 9:12 AM 'Chris Poucet' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Hi,

Currently the relation-chain on gerrit shows the latest patch first instead of the first patch first. This doesn't align with the typical order of review, nor the order of patches in emails nor order of `git rebase -i`.

I'm considering reversing the order of the dependency chain to make these more aligned. I thought I'd reach out to hear what people think of this.

The relation chain is meant to reflect the order of 'git log' and I think long-term Gerrit users (like myself) would be confused if we would change the order here (but I'm still open to considering changing it).

I agree that for new users it's not obvious what the order is, and it would be great to make this more obvious.

FWIW, from the very early days of Gerrit, there was the wish to visualize the relation chain as a Git graph, but back then nobody had the skills to implement this properly. IIRC the branch-network plugin [1] was an attempt to implement Git graph visualization, but I don't know how far it got and what's its current state.

[1] https://gerrit-review.googlesource.com/admin/repos/plugins/branch-network,general 

 

Thanks

 - simply, chris

Chris Poucet | Core Developer | poucet@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAN9%2B7Xfdsm_OeCjiJFdYW2Vs%2BA3KLivEuYP2zvZzDBSg%2Bug-%3Dw%40mail.gmail.com.

[Chris Poucet]

Thanks for the input.

I think one key difference between git log and git rebase/relation chain on gerrit is that Git log is past-orienteded where gerrit relation-chain and rebase -i is future oriented (not yet submitted changes). I think that merits a distinction.

 - simply chris
---
I'm always looking for feedback, you can provide it anonymously at go/poucet-feedback

[David Ostrovsky]

eke...@google.com schrieb am Dienstag, 19. Juli 2022 um 09:50:56 UTC+2:

On Tue, Jul 19, 2022 at 9:12 AM 'Chris Poucet' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Hi,

Currently the relation-chain on gerrit shows the latest patch first instead of the first patch first. This doesn't align with the typical order of review, nor the order of patches in emails nor order of `git rebase -i`.

I'm considering reversing the order of the dependency chain to make these more aligned. I thought I'd reach out to hear what people think of this.

The relation chain is meant to reflect the order of 'git log' and I think long-term Gerrit users (like myself) would be confused if we would change the order here (but I'm still open to considering changing it).

I would also like to keep the current behavior, or to make it configurable,

whatever the default would be. Also note, in case of very deep relation

chain, 50-100 changes, the list is abbreviated and the user would have to

press NEXT button to scroll it to the bottom. Right now we don't care, but

if the order of the changes is reversed, then the user would always need

to press NEXT button, to get to the latest changes in the relation chain.

[Matthias Sohn]

On Tue, Jul 19, 2022 at 4:16 PM David Ostrovsky <david.o...@gmail.com> wrote:

eke...@google.com schrieb am Dienstag, 19. Juli 2022 um 09:50:56 UTC+2:

On Tue, Jul 19, 2022 at 9:12 AM 'Chris Poucet' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Hi,

Currently the relation-chain on gerrit shows the latest patch first instead of the first patch first. This doesn't align with the typical order of review, nor the order of patches in emails nor order of `git rebase -i`.

I'm considering reversing the order of the dependency chain to make these more aligned. I thought I'd reach out to hear what people think of this.

The relation chain is meant to reflect the order of 'git log' and I think long-term Gerrit users (like myself) would be confused if we would change the order here (but I'm still open to considering changing it).

I would also like to keep the current behavior, or to make it configurable,

whatever the default would be. Also note, in case of very deep relation

chain, 50-100 changes, the list is abbreviated and the user would have to

press NEXT button to scroll it to the bottom. Right now we don't care, but

if the order of the changes is reversed, then the user would always need

to press NEXT button, to get to the latest changes in the relation chain.

+1 for keeping the current order newest at the top or making that configurable

When we introduced interactive rebase in EGit we initially showed commits to be rebased in the same order as shown by native git.

We got a lot of complaints from users who were confused by different sort order in history view and rebase view.

We fixed that by adding a toggle action for the sort order in the interactive rebase view, clicking the corresponding column header

now toggles the sort order.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/4c3dd740-0754-448f-ab44-299e6fe56dc4n%40googlegroups.com.

[Jonathan Nieder]

Matthias Sohn wrote:

> When we introduced interactive rebase in EGit we initially showed commits to be rebased in the same order as shown by native git.
> We got a lot of complaints from users who were confused by different sort order in history view and rebase view.

> We fixed that by adding a toggle action for the sort order in the interactive rebase view, clicking the corresponding column header

> now toggles the sort order.

Interesting! This argues for wanting a better interactive rebase and history editing experience in Git. See also https://lore.kernel.org/git/49bf5848-b8b0-13b0...@gmail.com/.

In graphical contexts, I agree with Edwin's point that showing parent relationships in the UI would make this less ambiguous for people (and would make the connection between unmodified history and history being modified a little clearer).

Thanks,

Jonathan

[Antoine Musso]

Le 19/07/2022 à 09:12, 'Chris Poucet' via Repo and Gerrit Discussion a écrit :

Hi,

Currently the relation-chain on gerrit shows the latest patch first instead of the first patch first. This doesn't align with the typical order of review, nor the order of patches in emails nor order of `git rebase -i`.

I'm considering reversing the order of the dependency chain to make these more aligned. I thought I'd reach out to hear what people think of this.

Hello Chris,

Ben Rohlfs asked about small UI annoyances back in October 2020 at https://groups.google.com/g/repo-discuss/c/hbvSHHM8sVQ/m/jZUPmKyBBgAJ I did comment there about the order being a bit confusing. I think it might be addressable by adding the parent merged change at the bottom which will give an indication the changes are ordered from most recent to oldest (topology wise).  The comment I made at the time:

Relation chain order

On a change view there might be an entry for related changes. They are changes linked to each other, or more or less a feature branch.  The current change is marked with an arrow, but there is no way to determine whether the change above is a child or an ancestor. Example: https://gerrit-review.googlesource.com/c/gerrit/+/283236

Maybe adding below the common ancestor (merge-base) between the change and the target branch would solve that? Given:

* (master) I am the tip
|  * Change 2
|  * Change 1
* / Initial commit

Currently when looking at Change 1 the table would show:

     Change 2
  -> Change 1

Adding the common ancestor might help, and maybe also indicate where the tip is. Something such as:

     Change 2 (top of chain)
  -> Change 1
     Initial commit (master fork point)

At least between Gerrit 2.16 and Gerrit 3.2, a lot of improvements have been made to indicate which are merged, the indirect ancestor and so on. That already made my life easier.

-- 
Antoine "hashar" Musso
Release Engineering

[Chris Poucet]

Thank you Antoine and everyone for the input!

Chris Poucet | Core Developer | poucet@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Ayke Halder]

Warming up this old discussion:
How about rendering the relation chain as a tree? A tree view would make the relations properly visible.

Feature: render "Relation chain" as tree in PolyGerrit UI:
https://issues.gerritcodereview.com/issues/381696872