3 ms·

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at t

by nupark2 15y ago

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. Just commit as you go along. If you're doing something that outright breaks the build or is disruptive, then create a branch -- it's not hard (see below). > It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch. I don't really understand why git users keep repeating this trope. Here's my SVN branching process: svn cp ^/trunk ^/branches/some-branch svn switch ^/branches/some-branch And then at some future time (or many future times) I can merge in the latest trunk changes (or vis versa). SVN has merge tracking, so it Just Works: svn merge ^/trunk I can only assume that this idea that "branches are hard in SVN" is a relic of a time when SVN didn't have merge tracking -- the feature was introduced nearly 4 years ago. > Git can basically support the same workflow as a centralized system, but it also supports other scheme. It can, but with more work. I guess I could just alias 'git commit' to 'git commit && git push', but then why am I not just using SVN?

deleted 15y ago
[deleted]
chousuke 15y ago
> This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P > Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained. You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective. It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)
- eropple 15y ago
  > Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. Disagree, because the commits are merged in and I can clearly walk through them. You should think very carefully about what you're committing and when--but that doesn't make rebase a license to do stupid things to make life harder for other developers, and personally I am completely and entire convinced that that's really all rebase does; I consider it one of the biggest brain damages of git and in pushing the SVN->git migration crusade (because even with rebase stupidity it's vastly better than SVN--I'd prefer Hg, but that ship has sailed) at my current employer I'm pushing to have "don't mash your commits" made into policy. > How the development actually happened is completely uninteresting in git. "In git" has no bearing on what is interesting in the development cycle, and it's a little arrogant to claim that that's the case. My version control system does not decide what I find interesting.
sjwright 15y ago
> I don't really understand why git users keep repeating this trope. You can create a branch in Git without having to touch the main repository. It's a lot cheaper mentally to create a local branch than a globally viewable one. In particular, it's a lot cheaper to create a branch when you don't have to think about whether the work is important enough to deserve one, or if your crazy idea might end up being an embarrassing failure. When a decision only affects yourself, it's a lot easier to be bold. > SVN has merge tracking, so it Just Works: SVN can branch easily, and it remembers how a merge went down, but it doesn't know how to merge a branch back into the truck when the truck has since progressed. When SVN merges, it doesn't know if a difference between the two branches is because it was changed on the trunk or on the branch. It just sees a difference. Git can replay the changes made in the branch on the updated trunk, or vice versa.

by nupark2 15y ago

deleted 15y ago

[deleted]

chousuke 15y ago

> This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P > Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained. You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective. It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)

eropple 15y ago
> Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. Disagree, because the commits are merged in and I can clearly walk through them. You should think very carefully about what you're committing and when--but that doesn't make rebase a license to do stupid things to make life harder for other developers, and personally I am completely and entire convinced that that's really all rebase does; I consider it one of the biggest brain damages of git and in pushing the SVN->git migration crusade (because even with rebase stupidity it's vastly better than SVN--I'd prefer Hg, but that ship has sailed) at my current employer I'm pushing to have "don't mash your commits" made into policy. > How the development actually happened is completely uninteresting in git. "In git" has no bearing on what is interesting in the development cycle, and it's a little arrogant to claim that that's the case. My version control system does not decide what I find interesting.

sjwright 15y ago

> I don't really understand why git users keep repeating this trope. You can create a branch in Git without having to touch the main repository. It's a lot cheaper mentally to create a local branch than a globally viewable one. In particular, it's a lot cheaper to create a branch when you don't have to think about whether the work is important enough to deserve one, or if your crazy idea might end up being an embarrassing failure. When a decision only affects yourself, it's a lot easier to be bold. > SVN has merge tracking, so it Just Works: SVN can branch easily, and it remembers how a merge went down, but it doesn't know how to merge a branch back into the truck when the truck has since progressed. When SVN merges, it doesn't know if a difference between the two branches is because it was changed on the trunk or on the branch. It just sees a difference. Git can replay the changes made in the branch on the updated trunk, or vice versa.