231–240 of 294 posts
This may be sacrilege on here, but at my previous job I really enjoyed TFS. It's been awhile but the workflow felt a little more intuitive than git. And some of the merging features were nicer.
I find TFS the slowest of the lot, by quite a large margin.
Earlier quoted context omitted.
The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite. While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area a…
Sure. I can get the same result I can get with simple staging with a complicated squash workflow. But why would I do that? I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.
Earlier quoted context omitted.
> UI (which is irrelevant part) UI usability is irrelevant... ?!?? > isn't that how every programming tutorial works Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design. Secondly, even programming language designe…
Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works? Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.
I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the dangers of those internals on a day-to-day basis - it doesn't supply me with a loaded foot gun. Sadly, I use Git every day, and rarely Mercurial, because that's what the masses have chosen and I've found using in-between compat tools not to be worth the extra hassle for me.
I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…
Earlier quoted context omitted.
"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.
`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.
In hierarchical logs, a merge commit stands for the series of commits that are being merged. You can then unfold such commits and view the series of commits as a nested list of commits (which may again contain merge commits).
Think of a merge commit as the equivalent of a procedure call where the procedure body is the series of commits being merged.
(Note that there are other ways to visualize version graphs with merge commits; this is just the simplest way to do it and could actually be easily added on top of Git.)
Rebasing has two problems. It discards the original version structure and it can create commits that never build or don't pass tests (because they never existed as such).
Frequent use of rebasing is almost always an indication that a VCS is lacking important functionality.
This may be sacrilege on here, but at my previous job I really enjoyed TFS. It's been awhile but the workflow felt a little more intuitive than git. And some of the merging features were nicer.
My ranking is Perforce > Git > TFS > SVN. I haven't used Mercurial. I like Perforce the best because of its clean UI, its explicit checkout mechanism (all files are read-only by default, and you have to check out anything before you can edit), the integration tool GUI, and the ability to cloud-save work without submitting it. TFS is nice because it has built-in code review, but the UI isn't nearly as clean as Perforce.
Earlier quoted context omitted.
Does anyone who's downvoting this comment care to explain why?
I did not downvote the parent comment but I find > Git has good documentation too. hilarious. Git has a sprawling mess of disorganised man pages. I find calling that "good documentation" insulting to people who care about documenting things.
This is extremely unfounded. You're basically just making shit up with baseless platitudes.
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'.…
Unfortunately this is simply the reality for many developers. 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…
>> And the Git staging area should be an opt-in feature. Thousands of yes! `git commit -a` just doesn't add the untracked files it is the most annoying misfeature of any version control system. Oh, I added unwanted project directories? I would then just remove them and put them to `.gitignore`, or create a `.gitignore` prior to `init`. Of course I could just alias `add -A . && commit -m` on every machine I ever conne…
Maximally practical or not, if you don't already have a repository for configuration files, shell scripts, aliases, and other little quality of life enhancements then create one today. Your git workflow isn't the only thing that will benefit.
Next time you're hassled to do yet another "git config --global user.name" compare it to the hypothetical overhead of typing "git clone foo/homedir.git ~/homedir && ~/homedir/prep" to get both your name and aliases setup.
I never thought I needed a dotfile repo, but once I made it I realized I waited way too long. It doesn't have to be anything fancy, just take 10 minutes and lay the groundwork to help yourself develop more quickly.
Earlier quoted context omitted.
> I don't think it's as appreciated that git's complexity generally discourages people from trying things out. For me, at least, the underlying model actually makes it easier to try things out. As long as my work is in commits and I have refs that point to those commits, I can be pretty sure that I'm not going to lose anything. I also take a fair amount of comfort in the fact that (unlike, say, SVN), any remote actio…
> I don't think it's as appreciated that git's complexity generally discourages people from trying things out. Personally, I'm not shy about recursively copying the entire repository on disk to run potentially destructive experiments in a duplicated environment. Also, once you understand how to pull things out of the reflog, it's usually not hard to restore to a sane state.
Agreed.
> Also, once you understand how to pull things out of the reflog,
That, and I'll also dump a git log of the last couple dozen commits into an editor buffer so that I can hang onto the commit ids. Until a GC cycle occurs, you don't lose the commits even if they aren't reachable through normal paths.