[Feature] WIP commit (à la GitKraken)

[BeLi4L]

Background:

I used to be a GitKraken user, and I'm working on a project where I can't use it for compliance reasons.

This led me to try out other git GUIs (SourceTree, Tower, sourcegit, and a few other that I quickly dismissed).

I like sourcegit the most, but there's 1 feature I liked about GitKraken that's missing in sourcegit:

Feature:

I would love to have a WIP entry in the commit graph, so that I can see if my working directory is clean or not, and quickly access the changes & stage/commit them.

In GitKraken, when you click on the "fake commit", it show the stage/unstaged files & the commit title/description textboxes on the right, but in sourcegit it could just open the "changes" tab (at least as a 1st step).

What do you think about having this in sourcegit? 👀

If you like the idea, I may be interested in helping out ;)

[michaelachrisco]

I like that idea. At the moment, the workflow is to go over to "Changes" see the changes and stage from there. It would be nice to know if there is unstaged changes within the histories/graph itself.

[love-linger]

In fact, I do NOT like this design.

• Where to locate the 'WIP commit'? It does not have a exact Author Time or Committer Time. If it is always on the top of graph, what's the point of doing this (or what's the different when compares to the switch button Changes on the left panel)? If not, users need to locate it first then click to open the changes panel - I can not see the advantages of it.
• What actions should bind to the 'WIP commit' since it is not a normal commit? Only open the Changes panel by clicking it or discard changes by context menu?
• When we make a fake commit for WIP changes, how do we set its SHA, Author Time, Committer Time and other properties? Leave it empty?
• When we talking about Deal with local changes, it is not just staging/unstaging files. Users should be able to check the detail changes in a file, and stage/discard/unstage hunks if it is nessary. For example:
  

Although GitKraken is arguably the most powerful GIT workflow tool, some of the designs I never really liked.

[joesponde]

Here is a screenshot of an example of interface where histories and changes are merged in a single interface/window (the tool is named Gittyup), it may answer some of the questions you are raising:

Some benefits of this type of interface:

• it removes the actions of back an forth between Histories and Changes tabs,
• when one want to amend some code, he can directly see if the last commit is actually the one he wants to amend to,
• the existence of changes is more visible with the gitkraken like interface than with the counter in the tab Changes button.

[love-linger]

it removes the actions of back an forth between Histories and Changes tabs,

The UI/UX design is very different between SourceGit and Gittyup/GitKraken. In SourceGit, the commit detail panel is not large enough to display files + diff view + commit message box + commit option bar

when one want to amend some code, he can directly see if the last commit is actually the one he wants to amend to

The example you gave is just a very special case - if there are many of commits in the develop branch that committed after feature/misc branch's head, you can not see the HEAD commit

the existence of changes is more visible with the gitkraken like interface than with the counter in the tab Changes button

I don't think so. In fact, I like Fork more than gitkraken

[love-linger]

Most of the UI design ideas come from the two client sides I have used

• Tower - https://www.git-tower.com/
• Fork - https://git-fork.com/

[joesponde]

As a Linux user, I do not know those clients.
I am more used to Gitkraken and Gittyup interfaces with an all-in-one approach.
I discover that there are (at least?) two "big" families of interfaces in the git clients world.

That said, as a regular user of SourceGit since a couple of weeks now, I take the opportunity of this thread to tell you that your tool is quite impressive.
You've done an awesome job, thanks so much!

[BeLi4L]

+1 for the job on this tool <3

The advantage of the GitKraken approach is that they reduce the number of views: instead of having 3 different tabs (history/local changes/stashes), they only have 1: the "history" view.

They show the "uncommited changes" in a "WIP" entry, and on they move stashes to the left panel (with branches, etc.), and show stashes on the graph, just like that:

This allows them to always show the file tree on the right panel, and the diffs in the center, above the graph, which makes the UI feel really consistent to me, and allows users to always have a feel of where they are on the graph and easily act on every git object.

I understand that maybe it's not your point of view, just wanted to suggest this idea that I really like :P

[love-linger]

First of all, your affirmation of this project makes me feel very honored and happy.

• Using a whole page to display Changes is a common design of many git clients. The purpose is
  • Focusing on local uncommitted changes
  • More space to layout changes list, diff view, commit message box and commit tool bar
  • Easier to manipulate partical changes in a file, such as based on selected lines or hunks.
• Why is Stashes not designed like Tags, but placed in a separate page, the main reasons are
  • Place it under Changes, highlighting the feature that it is an "uncommitted local change"
  • More space to display diff view
  • Convenient search and quick location in case of a large number of stashes

For example, the layout in Tower Git Client