61–70 of 390 posts
I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.
Earlier quoted context omitted.
I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it…
It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to corre…
Git as a whole:
* Makes it really hard for you to do something you really shouldn't be doing
* Forces you to stay "clean" and guides you to working well with other repository copies (i.e. the whole point of Git).
* Warns you and makes suggestions when you make a mistake, from silly typos to incorrect command flags.
* Makes it easy to guess how the command should be formatted or how certain structures are formatted based on convention.
They decided to rename certain features that not only give you the wrong idea of what's actually going on, but will no doubt make it extremely hard to research any errors if something goes wrong. A good example of thing is gitless' "fusing" feature. It's just rebasing stuff. Why rename it? Why rename "checkout" with "switch", when this semantic is used throughout git?
And then you have completely brain-damaged concepts such as this:
>(i.e., a file can be untracked on some branch but tracked on another and Gitless will remember this):
Honestly? There was no better way to indicate to me that you're just trying to make git fit some erroneous concepts in your head, and that you don't really understand what you're doing. This combined with the "auto-save" feature seems like a terribly, terribly bad idea and is just begging for a lazy developer who didn't take the time to understand his tools to completely shit on the repository he's working on, locally or remotely.
Take the time to understand your tools. Git is incredibly simple underneath. It's not complicated.
Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…
Which you can later squash via interactive rebase.
Git is bottom up. Understand the inner workings and you know what you can do. But coming from a user perspective there is a gap - first one needs to wrap ones head around the tool. Git imho. is more a framework than a tool. On Stackoverflow simple questions yield different answers all yielding results but having various trade-offs. Usability is also about orthogonality and looking from a user perspective (not an implementation perspective) Git offers often quite a number of paths getting to a certain goal.
Individuals, teams and tooling all trying to settle on certain workflows enabled by git effectively deciding to use only a subset. Particularly when it comes to teams agreeing on workflows becomes important. Git as a tool is here helpful in the sense that it enables almost everything. But for a team it takes more than agreeing on using Git. Other tools come with more comprehensive practices.
See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git" https://news.ycombinator.com/item?id=12612333 (1 day ago, 106 comments)
And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.
Earlier quoted context omitted.
It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to corre…
Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.
This is generally where I point people who have a technical background
Earlier quoted context omitted.
Now, this is a UI problem, you don't need to change git, you just need something higher level. Git is fine the way it is, but it targets power users. Most people don't need that power. In that sense, gitless has a proper approach even if I don't like the result.
I tend to agree with you that most people don't need that power but I think the problem is just that it IS a CLI interface, not that it's a particularly bad one. A GUI is the perfect tool to deal with discoverability and providing an easier interface for non-technical users. A CLI wrapper is just making things more confusing. I don't really understand what problem gitless seems to be solving...
When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…
Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching. The only feature I noticed missing, is…
> Both of the solutions above are really cumbersome and prevent easy context switching. Too frequent context switching might actually be perjudicial for your productivity and health, while increasing stress levels. So git not making it trivial might not be a bad thing, in my opinion.