Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
This is a really cool idea, and a Git playground would be useful for the after-school CS program I'm part of. I'm also kind of in awe that you're using C++ for this.
But I have to say that the way branches are modeled here doesn't really line up with how I've come to see them. While it can be sometimes useful to picture them as "lanes," branching in Git only made sense to me when I started picturing them as just pointers to a commit.
(If commits are lanes, what does it look like when a commit is part of multiple branches?)
It's deceptively simple, and for a long time I didn't get that I didn't get it. I had come to Git from Subversion, where branches actually are lanes. Eventually I read Think Like a Git and Git's model finally clicked. Suddenly I was able to branch, merge, cherry-pick and rebase with zero surprises.
It boils down to this: Git has commits, which are full snapshots, and pointers to commits, which give you a way to name them. During a new commit, tags (one type of pointer) stay on the previous commit, and branches (the other kind of pointer) may move to the new one. Only one actually does -- and git calls that the "checked out" branch.
I'm a programmer who likes games, and wants to make games for a living. At the same time, there are some really cool non-game things I want to work on -- especially if they use C or C++.
Yup, branches are pointers to commits, but there are two issues with drawing them like that:
It makes it hard to tell which commits are part of which branches (you need to manually follow them back from the head, and even then it's hard to tell where one branch 'splits' from another)
It makes it much harder to render.
Honestly, the latter was the biggest thing; we tried to get labels pointing at the branch head, but because of all the edge cases it was surprisingly hard to get it happening without making something look weird.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a really cool idea, and a Git playground would be useful for the after-school CS program I'm part of. I'm also kind of in awe that you're using C++ for this.
But I have to say that the way branches are modeled here doesn't really line up with how I've come to see them. While it can be sometimes useful to picture them as "lanes," branching in Git only made sense to me when I started picturing them as just pointers to a commit.
(If commits are lanes, what does it look like when a commit is part of multiple branches?)
It's deceptively simple, and for a long time I didn't get that I didn't get it. I had come to Git from Subversion, where branches actually are lanes. Eventually I read Think Like a Git and Git's model finally clicked. Suddenly I was able to branch, merge, cherry-pick and rebase with zero surprises.
It boils down to this: Git has commits, which are full snapshots, and pointers to commits, which give you a way to name them. During a new commit, tags (one type of pointer) stay on the previous commit, and branches (the other kind of pointer) may move to the new one. Only one actually does -- and git calls that the "checked out" branch.
Yup, branches are pointers to commits, but there are two issues with drawing them like that:
Honestly, the latter was the biggest thing; we tried to get labels pointing at the branch head, but because of all the edge cases it was surprisingly hard to get it happening without making something look weird.