
Git, Graphs and Software Engineering - tsemple
http://third-bit.com/2017/09/30/git-graphs-and-engineering.html
======
sametmax
Except most hard but interesting operations with Git are not very visible in
histories.

They are:

\- getting a clear status of you repo so you know where you are and what you
do;

\- figure out which one of the various method of undo you need for this
specific screw up;

\- find a practical way to compare this particular version of a snippet with
another particular version of a snippet, and work on the result;

\- merge the terrible mess you coworker rush-pushed to avoid to be the one to
have to merge;

\- rediscover the arcanes required to save only what you want. Maybe I should
branch and commit. Or stash. Or reset and add. Or do an interactive thingy ?

\- survive a rebase with squashing;

\- use the history, trying to look for clues of what the heck is going on with
the current version of your code.

\- setting up those damn editors, viewers, differs, etc.

So I LOVE your idea, because having a set in stone subset of git for most
projects that give you one, and only one, obvious way to do X is really
needed.

But I don't think stats will help you. You need a LOT more than that. You need
several people that have tried it all, can agree on a solid, versatile yet
definitive workflow that will work in the pareto case. And then a UX designer
that can sculpt that into something.

And right now, I have tried every single git UI under the sun, command line
and not, and they all fall short outside of the basic use cases.

Some manage to prevent the user from screwing up too much (github client),
some have a nice overview window (kraken), some have defined a clear subset of
operations (GUM), some are productive (smart git), some are well integrated to
the file explorer (git tortoise) or the IDE (vscode)...

But basically, every time I go back to give a Git training session, I have to
start with the classic cmd client. Because that's the only one I can trust to
do the job perfectly. But I also have to provide such a long cheat sheet it's
not even funny. And it's useless before each student perfectly understand
what's going on anyway.

Git is merciless with understanding and doesn't allow high level thinking. We
have yet to come by with a decent abstraction for it.

~~~
jancsika
> \- rediscover the arcanes required to save only what you want. Maybe I
> should branch and commit. Or stash. Or reset and add. Or do an interactive
> thingy ?

Here's something I'm trying:

1\. Always branch and commit.

2\. Push branch as a work in progress.

3\. When branch seems ready to merge, make a new branch from that branch.

4\. In the new branch, go crazy. Squash, reorder, whatever the heck.

5\. If you screw something up royally in #4, delete that new branch and go
back to step #3.

6\. If CI succeeded for new branch, merge new branch.

7\. Delete work-in-progress branch.

What kind of situations aren't covered by this approach?

~~~
viraptor
Once you're comfortable with the destructive commands, you could even drop the
temporary branch and rely just on reflog for the undo. But I understand how
this could be easier at the beginning.

~~~
mcny
> Once you're comfortable with the destructive commands, you could even drop
> the temporary branch and rely just on reflog for the undo. But I understand
> how this could be easier at the beginning.

Ideally, we'd make each of these "feature" branches as short and
straightforward as possible but then we are out of git territory and into some
kind of project management territory?

The one thing I don't like about destructive commands is that once you publish
to a branch that others are working on, you should rarely* use them.

* I'd say never but I usually don't like talking in absolutes.

------
fovc
I think Tarsius already did this and called the result Magit. For bonus points
he made it perfectly interoperable with git

Edit: Kickstarter campaign going on with 23h left
[https://www.kickstarter.com/projects/1681258897/its-magit-
th...](https://www.kickstarter.com/projects/1681258897/its-magit-the-magical-
git-client?ref=ewctvn)

~~~
Tenobrus
For clarity, Tarsius is not the original creator of Magit, that would be
Marius Vollmer ([https://github.com/mvollmer](https://github.com/mvollmer)).
Tarsius is "just" the current maintainer and most prolific contributor. I'd
strongly recommend contributing to the kickstarter if you use Magit, however.
I donated $100 and felt that was not near what it's actually been worth to me.
Don't think that just because it's fully funded you shouldn't bother, there's
good reason to keep contributing:
[https://www.reddit.com/r/emacs/comments/71viq3/the_magit_kic...](https://www.reddit.com/r/emacs/comments/71viq3/the_magit_kickstarter_has_reached_its_goal_heres/)

~~~
tarsius
Indeed I would not have created Magit from scratch. From the campaign
description:

"I would like to thank [Marius] and the maintainers who came later, for I
would not even have known that I needed something like Magit had they not laid
the groundwork in the early days of Git."

Not trying to undersell my own work - elsewhere I also write:

"Despite all this, it would be wrong to assume that Magit started out with a
predefined set of interface concepts and abstractions, and all that was left
to be done was incrementally filling in the gaps."

Oh, and thanks for you contribution.

------
luckydude
So Git is what Linus thinks is good. What I think is good, and this was Git's
inspiration, is at [http://bitkeeper.org](http://bitkeeper.org)

It's very different from Git. Git versions the tree, BK versions the tree and
versions files. The difference is profound. In BK, you debug by looking at the
file history and then zooming out to the commit history. Git can't do that. Or
it fakes it and gets it wrong. Same with merges, renames, creates, deletes,
Git gets all that wrong.

I know it won and there is no hope that things can get better but if you want
to see what better looks like, check out BK.

~~~
corndoge
you said git is wrong but don't explain why bk is right

~~~
luckydude
It's all about what is recorded, git records less information.

Git has no versioned file object, it has one graph for the whole repository,
there are no per file graphs. Which means there are no create/delete/rename
events, git guesses at that information.

BK has a graph per file in addition to the repository graph. The pathname is
an attribute of the file, just like the contents.

The per file graph means the GCA you use when you merge is the correct one for
this file, not the one for the repository. The two might be miles apart, so we
make merging easier.

One more: it's easy to write (and we did) a bk fast-export and have it work
deterministically so that incremental exports work correctly even when done in
parallel in trees not at the same place.

We wrote a bk fast-import but we can't get it to work correctly incrementally,
git doesn't record enough information.

At this point, I really wish Linus had just copied our tech, the world would
have improved. Git is a step, a big step, backwards and we are stuck with it.

------
skrebbel
I feel like most comments in this thread focus on the process mining, whereas
IMO they are missing the core idea of this article:

> Build a tool that provides those, _and only those_ , to users.

The author probably assumes that it is obvious that this means that the UI of
such a tool (be it a CLI or a UI) can be simpler. So much simpler, that it in
turn can be made much more powerful. So much more powerful, that maybe, just
_maybe_ , one day there will be a time where programmers won't have to spend
serious effort on learning and doing source control anymore.

~~~
reificator
I don't think you'll ever not need to learn version control, because it helps
you by adding to the list of things you can accomplish.

I do think there's a lot of room for UX improvement such that the learning
goes (significantly) faster, but I don't think it will go away.

Also most of what you need to know with git can be taught in an afternoon. If
you end up with an ugly history, guess what? History has always been ugly.

------
nichochar
> (To increase the likelihood of your proposal being funded, say that you’re
> using machine learning rather than statistics.) Aha, so true, so true...

------
tasuki
Git is very simple and elegant. It's only its interface that sucks. I found
people who try to use git without understanding its internals often fail.

You can grok git internals quite easily from:
[https://www.chromium.org/developers/fast-intro-to-git-
intern...](https://www.chromium.org/developers/fast-intro-to-git-internals)

