search

JetpackDuba / Gitnuro

A FOSS Git multiplatform client for newbies and pros
https://gitnuro.com/
GNU General Public License v3.0
872 stars 44 forks source link

Rebase is unusable #142

Closed Mingun closed 1 year ago

Mingun commented 1 year ago

Is your feature request related to a problem? Please describe. The current implementation of rebase are complete useless. Current problems:

  1. There are different menu items when you click on a branch name in graph (Rebase branch) or other commit area (Rebase interactive). I see no reasons to give such differentiation. Both options should be available in both places (although I personally does not see the point for the Rebase branch command)
  2. Interactive rebase does not allow to move commits which is the most needed option
  3. Interactive rebase does not allow to select multiple commits and choose action for all of them (and move them due to the previous point)
  4. I think it is better to show commits down-to-up as in a graph instead of current up-to-down, but that can be configurable
  5. There are no ability to skip commit

Describe the solution you'd like Take an example from TortoseGit where everything is done wisely

Describe alternatives you've considered None

JetpackDuba commented 1 year ago

Calling completly useless the implementation seems way too dramatic and such a very rude to describe it. If you don't like my job you can use another tool or fix it yourself.

Lack of maners aside and answering your points:

  1. It's intentional and I don't plan to change it. If you want to rebase a specific commit, create a branch on it. Rebasing branches is the most common method for Git CLI users and even the most mentioned in its documentation https://git-scm.com/docs/git-rebase. You can also rebase a commit if you wish (using CLI) but that would mean keep adding extra entries to the context menu, which is far from ideal because there already multiple planned to be added and the list would be way too long. Having features is nice but overwhelming the user with minnor stuff that affects the UX is not worth.
  2. There is an already existing issue about it https://github.com/JetpackDuba/Gitnuro/issues/66
  3. Also intentional, there are no plans to do a "bulk" operation, as it's something specific. I would recomend using the CLI for such use cases.
  4. Also intentional following the order of Git CLI and its namings (fixup wouldn't make sense if it the list is reverted).
  5. There is also an existing issue about it https://github.com/JetpackDuba/Gitnuro/issues/65

Take an example from TortoseGit where everything is done wisely

Perhaps TortoiseGit is a better tool for your workflow.

Mingun commented 1 year ago

Calling completly useless the implementation seems way too dramatic and such a very rude to describe it.

Sorry, didn't know you would take it so close to heart. In Russian this is a usual phrase so I don't know what can be wrong with it. Sorry, if it offends you. I just want to say, that current UX is very bad because does not cover frequent use cases (I cannot imagine that someone does not reorder commits during rebase, for example. This is the reason №1 for rebase, I think)

  1. That is simply illogical. Why I can interactively rebase over random unnamed commit, but cannot do the same over named commit? Of course, if you click to "unnamed" part of commit in the graph, it will show menu for unnamed commits, but this is just bad UX, I think. I don't want to control where I clicked, I just want to click on a commit and do an action. Some actions can be added for named commits, but no one should be removed
  2. Ok, just want to emphasis that having buttons are also important. Drag-n-drop implementation only can be painly when you have a long list of commits that does not fit into the screen and you should somehow move commits over that border. Most implementations start scrooll when pointer is near to the border, but do that either too slowly or too fast. Also drag-n-drop is hard to use on a touchpad.
  3. It's depressing. My ordinary use case is to rebase several branches that is based on each other over a new master. Because commits are not always skipped automatically by TortoiseGit, I select a range of a "parent" branch when do rebase of a "child" branch and mark all of them as Skip (they are already applied during rebase of "parent" branch). Another use case is when I do a rebase and want to check that all my commits is in a buildable state (my commits are always in that state with rarely exceptions). I select all commits and mark them as Edit and then build project on each step
  4. This is just a little inconvenient when in the graph you see commits in the one order, and when rebasing in the opposite. CLI here is not a very argument, since usually graph is not shown in a console. I think, you can borrow many useful UX practices from TortoiseGit :) It is a mature project and I'm sure their current UI looks as it looks today not by chance
  5. Ok. Strange that search does not show this issue

Perhaps TortoiseGit is a better tool for your workflow.

Indeed, but unfortunately it is only for Windows :(, so I'm looking for alternatives

Mingun commented 1 year ago

If you don't like my job you can use another tool or fix it yourself.

On the contrary, I really like your project, but it is still very raw. I would contribute, but not yet ready to learn yet another language and its environment. So maybe later