3

I have a "main" repository, I clone it and make some changes in the clone. In the meantime, there are other changes in "main", so I pull them and merge them in my clone. I make more changes in the clone, and merge any other new changes from "main". This gives me this graph:

enter image description here

When I finish my work in the clone, I push to the main repository and now the graph in "main" looks like this:

enter image description here

I know they're topologically the same, but to me the first one is clearer (this one is a very simple case, but things could get more complicated).

Is there any way to prevent this? I've found this question about reordering the graph after the fact, but I was thinking maybe there's a problem in my workflow or something I could change to prevent it.

Community
  • 1
  • 1
MikMik
  • 3,426
  • 2
  • 23
  • 41

1 Answers1

4

The problem is that the graph is sorted by the revision number, not by the revision date. This is effectively sorting by the date/time that the revisions appeared in the current repository. There is an outstanding issue on the thg project to allow sorting of the list by revision date but one of the developers said that this change would need to involve hiding the graph as he thinks that the re-write of the grapher would be too complicated for too little gain (the issue is here).

There is no workflow involving merge that I know of to fix it because the revisions will never be in the same order on different repositories if work is carried out on more than one repo.

One way to neaten up the tree would be to use rebase instead of merge after pulling your changes. This would result in a single branch with no merges as it re-writes history to make it appear as though your draft revisions were implemented after the changes that you just pulled. If you want to read up on rebase, that info is here.

Steve Kaye
  • 6,262
  • 2
  • 23
  • 27