Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Git Habits

blog.plover.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: My Git Habits

#41

Post by gbog »

batista wrote: post #38

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 ca…

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"

Re: My Git Habits

#42

Post by eridius »

batista wrote: post #38

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 ca…

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

Re: My Git Habits

#43

Post by Osiris »

batista wrote: post #38

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 ca…

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.

Re: My Git Habits

#45

Post by batista »

eridius wrote: post #42
batista wrote: post #38

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 ca…

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

Probably you meant to use the 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".

Re: My Git Habits

#46

Post by tikhonj »

gbog wrote: post #41
batista wrote: post #38

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 ca…

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"

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.

Re: My Git Habits

#47

Post by emddudley »

gchpaco wrote: post #32
Osiris wrote: post #4

I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how importan…

Here are some of the situations I run into on a regular basis at my current company, which is Perforce based, where I wish we were git based instead. This would be as true in Subversion. They might be maybe less true in Mercurial or Bzr, I'm not as familiar with those ones. * I am hacking on some bit of code, so I set up a Perforce branch. While I'm at it I notice some ugliness and want to refactor it. I could make a…

I also hate the "forget to add a file" issue in Perforce.

How about trying to rename a file and change the class name at the same time? That always gives me trouble.

Re: My Git Habits

#48

Post by tmoertel »

Osiris wrote: post #4

I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how importan…

I've been streamlining my commit histories this way for several years now, and it's worth the effort.

I do it pretty much the same way the author does (only I use Emacs and Magit mostly). The reason I do it is because my work has to make sense to other people, and also to me six months later. So I think of my commit histories as stories that must tell people how my software got from point A to B, and tell them clearly.

The chronological history of how I wrote some batch of code is just the first draft of the story. It's messy. It contains WIP commits, false starts, backtracking, and all sorts of cruft that tells more about the noise of software development (and when I stopped for dinner) than about how the software logically moved from one sensible point to another.

Once I've got a chuck of work all figured out, all that noise has to go. It must be edited away before I publish the work upstream. Otherwise, I'm just weighing down everybody who has to understand the work later (including me).

Re: My Git Habits

#49

Post by eridius »

batista wrote: post #45
eridius wrote: post #42

Earlier quoted context omitted.

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

Probably you meant to use the 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 ine…

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.

Re: My Git Habits

#50

Post by technomancy »

tmoertel wrote: post #48
Osiris wrote: post #4

I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how importan…

I've been streamlining my commit histories this way for several years now, and it's worth the effort. I do it pretty much the same way the author does (only I use Emacs and Magit mostly). The reason I do it is because my work has to make sense to other people, and also to me six months later. So I think of my commit histories as stories that must tell people how my software got from point A to B, and tell them clearl…

I can't imagine applying a workflow like this without magit. It sounds like so much grunt work.
Post reply on HN