schacon

13 ms·

91.
by schacon 2y ago
Git's been around for almost 20 years now. I would say fairly dominant for 15 or so.
92.
by schacon 2y ago
Fun fact, I (original author), wrote the original version of Gist. That was my first project at GitHub. Gist #1 is my claim to fame: https://gist.github.com/schacon/1
93.
by schacon 2y ago
Sorry, "we" is GitHub. I'm the author of the article and one of the GH cofounders.
94.
by schacon 2y ago
I would argue that SF was always pretty shitty, because it focused entirely on advertising. I remember Chris giving a talk comparing the signup process of GitHub and SourceForge. SF had like 8 fields and GitHub had 2. This was because SF wa
95.
by schacon 2y ago
I now realize that it's SourceForge. :)
96.
by schacon 2y ago
This is not my recollection, at least at the time. I remember meeting with one of the SourceForge founders and being a little star struck. SourceForge was a huge deal at the time and we totally felt like we were the underdogs in that arena.
97.
by schacon 2y ago
I'm not sure what "SF" means in this context. San Francisco? I can't figure out what you want to say Google Code was for exactly. If Google launches a major project, I find it hard to believe that it's just for fun.
98.
GitButler is now Fair Source(blog.gitbutler.com)
7 points by schacon 2y ago|1 comments
99.
Post-Open: Towards a Software Commons(openpath.chadwhitacre.com)
1 points by schacon 3y ago|0 comments
100.
by schacon 3y ago
I know that this isn't the point of this post exactly, since this is more of the "free as in speech" argument, but I just want to say that I dislike Discord for lots of reasons but it's _amazing_ as a community engagemen
101.
by schacon 3y ago
I feel like this is much different. We're not saying "patch these things together into a materialized view", we're saying "here is the diff between your working directory and origin/master, which branch owns wh
102.
by schacon 3y ago
I suppose you could do this by shallow cloning and then expanding it multiple times. But yes, the fetch/push protocols really expect smaller repos or really good inet connections and servers.
103.
by schacon 3y ago
I love the GitHub Git blog posts. They should have a bigger audience. Taylor is a machine.
104.
by schacon 3y ago
I dont think I knew this. Great tip, thanks!
105.
by schacon 3y ago
I see. Well then there are some similarities. Though you can use ours with any editor :)
106.
by schacon 3y ago
I think jj is super cool. But I like the idea of a killer GUI that makes so many things so fast and easy to do that I would use it instead of the cli. Ive never used a git gui for more than a day. Ive used GB daily for months and I love my
107.
by schacon 3y ago
Well, two things. They're not on by default, you have to enable them. Both because it means we have to send your code diffs outside your machine, but mostly because lots of people don't want them. The other is that the point is no
108.
by schacon 3y ago
So, yes and no. You should be able to do `reset HEAD^` equivalent by just hitting 'undo', which is essentially what that does. You can then re-commit stuff or drag the newly uncommitted hunks to other branches. But it's only
109.
by schacon 3y ago
Sort of, but it's honestly closer to normal git branches. If I'm not mistaken, you can't have multiple changelists applied simultaneously. You still have to switch between active groups of changes, no?
110.
by schacon 3y ago
Since we write out our virtual branch artifacts into refs/gitbutler/X, you could actually pretty easily setup worktrees from each of them to do this type of work on. Perhaps setup a post-commit hook to update any active worktrees
111.
by schacon 3y ago
I haven't used ClearCase, but from the description, I don't think it's much like a view. It's closer to IntelliJ's changelists, but without many of the limitations. It's effectively a way to take changes you&#x
112.
by schacon 3y ago
This is true. For the use case you're talking about, just sticking some changes in a semi-ignored virtual branch basically will do what you are talking about. :)
113.
by schacon 3y ago
Maybe, but I think most developers are fine jumping to another tool if it makes what they do every day easier or faster. Our goal isn't to replicate all the commands git can do. It's to try to create an interface for writing Git c
114.
by schacon 3y ago
Two things. One is there is a commit dialog per virtual branch. You do a commit on a branch. The selection is all the files/hunks you see on that branch, or you can selectively commit parts of those changes (such as a add -i type commi
115.
by schacon 3y ago
Well, one thing we can do is "merge" together multiple non-conflicting branches in your working directory without creating (or, I suppose, having to undo) merge artifacts. Like if you had three branches and you wanted to see how t
116.
by schacon 3y ago
Just to clarify, yes, in order to work on multiple simultaneous branches, you need a tool that knows what that means, which git does not really. But you can also very easily run 'git checkout main' and do whatever and then go back
117.
by schacon 3y ago
You can switch back and forth rather easily. But if you have multiple branches applied, some git commands wont make any sense.
118.
by schacon 3y ago
But even if you do run “checkout” or “commit”, we still notice that you did that and try to put you in the state you want.
119.
by schacon 3y ago
It works fine. The only thing that is a problem is “branch” and “commit”, things that use the index. But that makes sense. If you have setup two virtual branches and then from the cli run “git commit”, which branch do we commit to?
120.
by schacon 3y ago
One of the first comments was this, and there is a longer answer to why this is different if you’re interested. Short answer is that worktrees dont exist in the same working directory like virtual branches do.

More ›