31–40 of 40 posts
You can grok git internals quite easily from: https://www.chromium.org/developers/fast-intro-to-git-intern...
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,…
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.
Earlier quoted context omitted.
Curious, have you compared this idea to what Darcs does (I don't know Darcs well enough to do justice to it, but it sounds related).
An example of what I'm thinking about, which I don't think Darcs can do (I'd love to be wrong): Alice and Bob both branch off of master at the same point. In Alice's branch, she moves function `foo` into a different module/file. In Bob's branch, he changes `foo` to handle a new condition. Both wish to merge into master. Whoever merges later is going to have a merge conflict, and have to resolve it manually, using the…
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…
> - 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…
Earlier quoted context omitted.
> - 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…
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.
So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at 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,…
you said git is wrong but don't explain why bk is right
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.
Earlier quoted context omitted.
> - 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…
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.
That new branch is the one that receives comments and revisions from all developers-- ideally none of that gets squashed or rebased.
The danger is that you silently drop data when trying to make the new branch pretty. But even in that case you still have the old WIP branch as backup, at least until you do a release. And hopefully by that time you've tested the code and had other people look at it and use it.
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…
> - 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…
Earlier quoted context omitted.
An example of what I'm thinking about, which I don't think Darcs can do (I'd love to be wrong): Alice and Bob both branch off of master at the same point. In Alice's branch, she moves function `foo` into a different module/file. In Bob's branch, he changes `foo` to handle a new condition. Both wish to merge into master. Whoever merges later is going to have a merge conflict, and have to resolve it manually, using the…
There is a product called semanticmerge that does this.
Earlier quoted context omitted.
you said git is wrong but don't explain why bk is right
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…