21–30 of 294 posts
The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting solution. If hg supports to strip a remote repo, it would be just fantastic! hg evolve is awesome and topics are fantastic, but a `hg strip ` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!
If you requested save in your favorite GUI application,
text editor, etc and it popped open a select the
changes you would like to save dialog, you would
rightly think just save all my changes already,
dammit
That is, by and large, the quick sanity check of "these are the things you did?" is actually quite valuable. Regardless of any annoyance it may give. Similar to the "did you mean to print all 500 pages?" warning you can get if you print something huge. Sometimes, yes. Yes I did. Often times, no, not what I intended.
It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…
I mean, you could just checkout a new branch and push that, right?
I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.
Is today's Subversion fast enough? My first impression of Mercurial moving from Subversion was that it's much faster compared to Subversion (I know, Subversion over HTTP at that time was nothing more than WebDAV :-); I'd migrated all my repositories at the day 1. I later noticed that it noticably slows down with larger repositories and that became a good reason to try Git out (only to be displeased with its interface…
It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…
> A better VCS isn't going to solve that! It might! I feel like a "language aware" VCS would be able to help a lot in this area. I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features. Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with langu…
The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…
The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even be counterproductive [1].
Contrast this with, say, Smalltalk's ENVY: saving a method automatically versioned the method (without the need of providing any other metadata), but you could also separately create system snapshots as named versions.
Common Git usage is to squash checkpoint commits, anyway, with individual commit messages often disappearing in the process.
The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…
But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion.
And, honestly, 90% of all commits I've seen use crap messages like "stuff", "fixes", or "change 357" that are so devoid of useful content that I'd argue that those commits would be better off with no message at all. Just date and author. At least then you won't be distracted by contentless messages that can't even be self-consistent most of the time. This isn't a swing at those people, I'm just being realistic.
It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…
> A better VCS isn't going to solve that! It might! I feel like a "language aware" VCS would be able to help a lot in this area. I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features. Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with langu…
VCS would have to be much more than "language aware" to even begin to help in this area.
The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…
I have worked with multiple people whose commit logs would look something like...
> e96ddd0 update code
> 65c3072 update code
> dd9ccc1 update code
> 7992ef8 update code
> 6c536e6 update code
> ...
Over and over several dozen commits. Which is technically fine if they know how to rebase. The overwhelming majority of my commits are simply 'git commit -a -m "CI-WIP"` (check-in work in progress), rarely do I realistically revert to any of them.
Unfortunately, a lot of developers aren't willing to learn the 4 or 5 basic commands which make for a clean git history.
And when I have to work with them, I really would prefer if git had something like `git save`. Which in the backend kept doing something like `git commit -a --amend`.
The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting solution. If hg supports to strip a remote repo, it would be just fantastic! hg evolve is awesome and topics are fantastic, but a `hg strip ` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!
2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users.
3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.