A few weeks ago, I had the pleasure of giving an introductory Git workshop at the San Francisco General Assembly. The workshop was a lot of fun, but the most valuable part for me was seeing Git and Axosoft GitKraken through the eyes of first-time users.
That got me thinking about things that could make GitKraken simpler for basic operations. One of the ideas evolved into something that could potentially help with even more advanced Git operations!
In the workshop, we started with modifying a single text file; the steps to commit each change were always: make a change, stage, commit. The staging step seemed extraneous and I wished the class could have committed without that step. In the CLI, you can do this using git commit -a as long as the changed file is already tracked.
A few other GUI clients also make this scenario easier, but not GitKraken.
Ah, an opportunity for improvement!
Think, Think, Think.
I immediately started thinking about how we might be able to make the staging process optional to the user—stage if you want to or just commit if you don’t. But being that I love to generalize things, my next thought was this:
If we could have no staging area, and we could have our usual singular staging area—could we go further and let the user add additional staging areas when needed?
Here is how something like this might work. You start out with your working directory changes, with no staging area:
Image may be NSFW.
Clik here to view.
In this state, committing would automatically commit all of your changes (equivalent to the current Stage All + Commit).
If instead you choose to stage something, you automatically create a staging area. You get a separation of what is staged and unstaged and can choose exactly what goes into the commit, as you typically would with Git.
This would look similar to today’s GitKraken, except we could reinforce that there is a single staging area by including it in the graph; staging / unstaging would be more like moving down / moving up.
In the image below, this is what we might get if we move Ideas.txt and Poem.txt down into a new staging area and type in a commit message:
Image may be NSFW.
Clik here to view.
If we commit now, we would be committing the staged area (as usual). However, suppose we changed our mind, and we wanted to commit Poem.txt separately from Ideas.txt. We can then add a new staging area by moving the change to Poem.txt into a new staging area:
Image may be NSFW.
Clik here to view.
The key advantage here is that we didn’t have to completely redo our single staging area—so everything else we staged (Ideas.txt), as well as the commit message for the initial staging area, remain preserved:
Image may be NSFW.
Clik here to view.
Committing would now turn the lowest staging area into a commit, so we update the message for the lowest change and click commit:
Image may be NSFW.
Clik here to view.
And then you can commit your next, carefully separated change:
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
If you wanted to commit the remaining change, you would just need to type in a message and click “commit” (staging not necessary).
What do you think?
This is just an idea at this point and a lot of details would need to be worked out to see whether this is even feasible (for example: how would we store this state in the repository? How would that interact with other Git clients? How would multiple staging areas affect other Git operations such as stash, etc.?).
I like the prospect of this idea because it would simplify a few scenarios that I run into often:
- I want to commit all of my outstanding changes (I no longer need to stage everything)
- I want to carefully prepare a number of commits (Instead of committing them one by one, then after a few commits realizing that I forgot to add something to an earlier commit, and having to reset, amend, cherry-pick, and/or rebase to correct the problem).
But that’s just me. What do you think; would this make some operations easier? More confusing? Is there something out there that already does this well?
Please let us know in the comments below!
Let’s talk in-person
if you are interested in more ideas related specifically to Git GUIs, check out the session “From CLI to GUI: Overcoming Challenges to Advance Git”, presented by our own John Haley and Hamid Shojaee at Git Merge 2016.
Tune in online starting at 10am EST on April 5th. The talk will be 1:30-2pm EST.