Git, Graphs and Software Engineering
third-bit.com
Git, Graphs and Software Engineering
1–10 of 40 posts
Re: Git, Graphs and Software Engineering
#2Except 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.
Re: Git, Graphs and Software Engineering
#3Except 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…
> - getting a clear status of you repo so you know where you are and what you do;
Me repository?
What's missing from `git status' and `git show-branch'?
> - figure out which one of the various method of undo you need for this specific screw up;
It's not hard. The hard part is to acknowledge that you actually need to understand git's internal data structure. All the rest is very easy, up to and including `git reset --hard'.
> - find a practical way to compare this particular version of a snippet with another particular version of a snippet, and work on the result;
I didn't understand what you mean.
> - merge the terrible mess you coworker rush-pushed to avoid to be the one to have to merge;
Me coworker?
And I again didn't quite get what you mean. You'll have to merge anyway. And it's not specific to git, it was the case for any and all version control systems.
> - 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 ?
What arcanes? It's quite simple thing, especially if you learned how git works.
> - survive a rebase with squashing;
`git tag my-old-head' and work until you're satisfied? What's difficult in that? (Apart from the fact that you need to understand how git works)
> - use the history, trying to look for clues of what the heck is going on with the current version of your code.
How is it specific to git? It was the same for any and all version control systems.
> - setting up those damn editors, viewers, differs, etc.
I didn't set anything up, apart from colours used. Or maybe you're talking about $EDITOR/$VISUAL, which you need for many other console tools anyway?
> [...] every time I go back to give a Git training session, [...] 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.
Maybe because you're teaching them the wrong thing? Git's data structure is a quite simple thing, it should take half an hour to teach. And with understanding this structure, it's impossible to get yourself into such a mess that you couldn't dig yourself out.
Re: Git, Graphs and Software Engineering
#4I 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...
Re: Git, Graphs and Software Engineering
#5Except 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…
I came here to post something similar. I'll add that many of the hard things we do with Git seem to do with re-ordering or re-combining of the underlying changes. If we want to make it easier to reason about changes to a set of changes, then I think we really want those changes to have some properties which they don't currently have.
It's powerful for Git to treat changes as line-by-line text diffs, because it allows us to manage changes to any textual data. But what if, instead, we borrowed an idea from distributed databases, and implemented all changes as commutative operations on a Conflict-free Replicated Data Type (CRDT)?
I think almost every example of difficult rebasing would get significantly easier, but at what cost? We'd have to completely rethink how we write programs, because this would drastically limit the types of changes to a program that were valid. I wouldn't be surprised if this would require us to develop in entirely new languages.
There might be some meat to this idea, but again, I don't think we'd get there by mining existing Git graphs.
Re: Git, Graphs and Software Engineering
#6Except 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…
> Git is merciless with understanding and doesn't allow high level thinking. We have yet to come by with a decent abstraction for it.
I toyed around with Pijul and found it simpler conceptually. It still has a long way to get ready for production, though.
Re: Git, Graphs and Software Engineering
#7Except 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…
> - getting a clear status of you repo so you know where you are and what you do; Me repository? What's missing from `git status' and `git show-branch'? > - figure out which one of the various method of undo you need for this specific screw up; It's not hard. The hard part is to acknowledge that you actually need to understand git's internal data structure. All the rest is very easy, up to and including `git reset --…
I think you're missing OPs point. A git repo's history shows changes to the source code but not necessarily underlying git usage patterns since many git operations don't live in the history.
Re: Git, Graphs and Software Engineering
#8Except 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…
> - 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?
Re: Git, Graphs and Software Engineering
#9Except 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…
> - 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 u…
I really like this. I get overwhelmed by the options and want to be prudent yet have freedom to screw up.
Re: Git, Graphs and Software Engineering
#10Except 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…
To answer just one of your questions, many commands have a patch mode as -p. At this point I rarely just git add, it's always git add -p. A side benefit is that you get a chance to review your own code, make sure you cleaned everything up, and can't accidentally commit something.
And you may be interested in the Gitless papers, they are a very interesting approach. I personally think I've got a good enough sense of Git to generally use it pretty effectively (and I'd say with somewhat high-level thinking, though you may disagree), though I'll admit that's after reading the Git Book a few times.
Honestly, my opinion is that most devs just rush their work all the time, and having a different model of version control can't stop them from doing so. Careful, measured practice is the solution, but that's often a hard argument to make in the current industry.