4 ms·

The proliferation of "git tips", and "my git habits", "git best practices" articles, make me think that Git is too complicated for its own good to need all thos

by batista 15y ago

The proliferation of "git tips", and "my git habits", "git best practices" articles, make me think that Git is too complicated for its own good to need all those. (Maybe "need" is a bad choice of words: maybe it doesn't need those articles, but it's too complicated if it gets to have them. You don't get such avalanche of advice for a simple, no BS, tool). Now, the complicated part means it's flexible --in the rare cases you need it to be. But it could probably use a facade that makes the common use cases more intuitive (there are some half-baked attempts that I'm aware of). Personally, I use mercurial.

msbarnett 15y ago
It's not exactly hard to find people discussing different best practices and their own individual workflows in Mercurial, either[1]. The existence of these articles doesn't tell us anything negative about Mercurial, or Git, it merely tells us that these tools are powerful enough to be used for Real Work in Real Workflows, and that there are few things people love more than talking about their workflows. [1]: Random examples: http://stackoverflow.com/questions/448567/best-practices-in-mercurial-branch-vs-clone-and-partial-merges http://stackoverflow.com/questions/448567/best-practices-in-... http://mercurial.selenic.com/wiki/WorkingPractices http://mercurial.selenic.com/wiki/WorkingPractices http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu... https://blogs.oracle.com/kto/entry/mercurial_best_practices https://blogs.oracle.com/kto/entry/mercurial_best_practices http://mercurial.808500.n3.nabble.com/Best-practices-for-merging-td2989382.html http://mercurial.808500.n3.nabble.com/Best-practices-for-mer... http://www.stevestreeting.com/2010/04/22/mercurial-queues-just-clicked/ http://www.stevestreeting.com/2010/04/22/mercurial-queues-ju...
gbog 15y ago
Had to switch from mercurial to git. Both are nice, neither is perfect. I long for the time when we won't have to do so much ancillary work to just sync up files. My bet: In 5 years, all these contrived workflows will be replaced by: sync file1 file2 "fix bug 5782"
- tikhonj 15y ago
  You know, syncing is the least I do with Git. In fact, for my personal projects, the syncing is entirely incidental--just a lazy way to publish and back up my files. In addition to syncing, I use Git to keep track of my history, to maintain multiple versions in parallel, to work on different features at the same time without interfering with each other and probably a bunch of other things I'm forgetting. All this just for projects with one programmer--for work and group projects, I use even more complicated features. So yes, if all you want is syncing, perhaps Git is contrived. But if you actually want version control, it's actually pretty simple.
  - gbog 15y ago
    I see what you mean but one could consider version control as a subproduct of syncing a working directory with a trunk. That do not need to mean syncing between different user's working directories.
    - pozorvlak 15y ago
      We tried that - it was called Subversion. The industry's abandoning that way of doing things because the new way is simpler and better.
eridius 15y ago
The proliferation of "photoshop tips", "photoshop tutorials", etc, make me think that Photoshop is too complicated for its own good to need all those. </snark>
- batista 15y ago
  Probably you meant to use the </misguided snark> tag. The Photoshop Tips and Tutorials are about doing something new in a realm with inherently infinite possibilities, that is bitmap editing/drawing. Managing source code shouldn't have "infinite possibilities" -- there are a few common use cases, and several more uncommon. If you have "infinite flexibility" in your source code management system, you are doing it wrong, or at least inefficiently structured or streamlined, that is, in the wrong end of the scale of 1 => you do everything by hand, 100 => the computer does all for you as you want it to. Not all workflows can fit an one-size-fits-all team, sure. But that doesn't mean that you should have to micromanage the workflow even in the most common use cases. I.e Git is more of a "source code management DIY kit" than a "source code management tool".
  - eridius 15y ago
    Some people like micromanaging their workflow. Apparently Mark Dominus is one of them. Other people don't like managing their workflow, and thus they end up with just `git commit -a; git push` as the entirety of what they use. Just because some people micromanage their workflow doesn't mean everyone has to.
Osiris 15y ago
One thing that I read about Git is that Git is really just a document store, not a version control system. That means that you can use the document store to do whatever you want. It's up to you to decide the workflow that you want to use. In my team we've had long discussions about how we want to code, what to branch, when to branch, when to merge, etc. all about how to keep things organized. I think people like Git because of the flexibility. Different people and teams can use it in different ways. They don't feel boxed in to a predefined workflow.
crusso 15y ago
Not sure why you were downvoted, gitfanbois I guess. I've used both git and mercurial. I would tend to agree that git has more of a feel of non-conformity when it comes to best practices and default ways that it behaves. That said, mercurial has an equally bewildering array of choices when it comes to all the different add-ons that you can install to do similar things. I think they're both great tools and I love the way that they've both innovated ahead of each other and copied the best of each other.

by batista 15y ago

msbarnett 15y ago

It's not exactly hard to find people discussing different best practices and their own individual workflows in Mercurial, either[1]. The existence of these articles doesn't tell us anything negative about Mercurial, or Git, it merely tells us that these tools are powerful enough to be used for Real Work in Real Workflows, and that there are few things people love more than talking about their workflows. [1]: Random examples: http://stackoverflow.com/questions/448567/best-practices-in-mercurial-branch-vs-clone-and-partial-merges http://stackoverflow.com/questions/448567/best-practices-in-... http://mercurial.selenic.com/wiki/WorkingPractices http://mercurial.selenic.com/wiki/WorkingPractices http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu... https://blogs.oracle.com/kto/entry/mercurial_best_practices https://blogs.oracle.com/kto/entry/mercurial_best_practices http://mercurial.808500.n3.nabble.com/Best-practices-for-merging-td2989382.html http://mercurial.808500.n3.nabble.com/Best-practices-for-mer... http://www.stevestreeting.com/2010/04/22/mercurial-queues-just-clicked/ http://www.stevestreeting.com/2010/04/22/mercurial-queues-ju...

gbog 15y ago

Had to switch from mercurial to git. Both are nice, neither is perfect. I long for the time when we won't have to do so much ancillary work to just sync up files. My bet: In 5 years, all these contrived workflows will be replaced by: sync file1 file2 "fix bug 5782"

tikhonj 15y ago
You know, syncing is the least I do with Git. In fact, for my personal projects, the syncing is entirely incidental--just a lazy way to publish and back up my files. In addition to syncing, I use Git to keep track of my history, to maintain multiple versions in parallel, to work on different features at the same time without interfering with each other and probably a bunch of other things I'm forgetting. All this just for projects with one programmer--for work and group projects, I use even more complicated features. So yes, if all you want is syncing, perhaps Git is contrived. But if you actually want version control, it's actually pretty simple.
- gbog 15y ago
  I see what you mean but one could consider version control as a subproduct of syncing a working directory with a trunk. That do not need to mean syncing between different user's working directories.
  - pozorvlak 15y ago
    We tried that - it was called Subversion. The industry's abandoning that way of doing things because the new way is simpler and better.

eridius 15y ago

The proliferation of "photoshop tips", "photoshop tutorials", etc, make me think that Photoshop is too complicated for its own good to need all those. </snark>

batista 15y ago
Probably you meant to use the </misguided snark> tag. The Photoshop Tips and Tutorials are about doing something new in a realm with inherently infinite possibilities, that is bitmap editing/drawing. Managing source code shouldn't have "infinite possibilities" -- there are a few common use cases, and several more uncommon. If you have "infinite flexibility" in your source code management system, you are doing it wrong, or at least inefficiently structured or streamlined, that is, in the wrong end of the scale of 1 => you do everything by hand, 100 => the computer does all for you as you want it to. Not all workflows can fit an one-size-fits-all team, sure. But that doesn't mean that you should have to micromanage the workflow even in the most common use cases. I.e Git is more of a "source code management DIY kit" than a "source code management tool".
- eridius 15y ago
  Some people like micromanaging their workflow. Apparently Mark Dominus is one of them. Other people don't like managing their workflow, and thus they end up with just `git commit -a; git push` as the entirety of what they use. Just because some people micromanage their workflow doesn't mean everyone has to.

Osiris 15y ago

One thing that I read about Git is that Git is really just a document store, not a version control system. That means that you can use the document store to do whatever you want. It's up to you to decide the workflow that you want to use. In my team we've had long discussions about how we want to code, what to branch, when to branch, when to merge, etc. all about how to keep things organized. I think people like Git because of the flexibility. Different people and teams can use it in different ways. They don't feel boxed in to a predefined workflow.

crusso 15y ago

Not sure why you were downvoted, gitfanbois I guess. I've used both git and mercurial. I would tend to agree that git has more of a feel of non-conformity when it comes to best practices and default ways that it behaves. That said, mercurial has an equally bewildering array of choices when it comes to all the different add-ons that you can install to do similar things. I think they're both great tools and I love the way that they've both innovated ahead of each other and copied the best of each other.