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

51–60 of 64 posts

Re: My Git Habits

#51

Post by gbog »

tikhonj wrote: post #46
gbog wrote: post #41

Earlier quoted context omitted.

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

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.

Re: My Git Habits

#52

Post by ezquerra »

encoderer wrote: post #39
gchpaco wrote: post #32

Earlier quoted context omitted.

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…

Mercurial is more like Git than not. It differs in the way it stores revision history (Git stores files, Mercurial stores deltas, basically). And branching is Mercurial isn't nearly as neatly implemented as it is in Git. But it would seem to address the issues you listed here. For example, you can rollback a commit if you did the "stupid typo" mistake. And you have a lot of power to "change history" and modify the DA…

In my opinion branching _used_ to not be as neatly implemented as it is in Git, but that is no longer the case.

A couple of versions ago a new feature was added into core mercurial, called "bookmarks". Mercurial bookmarks are the same as Git branches.

So now you can use the "git style branches" (i.e. bookmarks) in mercurial, or you can use the regular mercurial-style branches (which I personally prefer to git's anyway). In addition you can use "anonymous" branches, which AFAIK do not exist in git at all.

Re: My Git Habits

#54

Post by yogsototh »

helpbygrace wrote: post #28

By the way, that article page is too hard to read comfortably. Shortened the width of each paragraph and upsize the font will be really good for me to read it. tl;dr , I didn't read that page. :(

You might like this tool (I read the article using this):

http://readable.tastefulwords.com/?setup&change&text...

Re: My Git Habits

#55

Post by sateesh »

jlarocco wrote: post #27
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 also don't see the point. If I need to experiment, I'll create a branch, mess around there, and merge it back when I've figured things out and have everything working. The workflow in the article seems like it's trying to be clever for the sake of being clever. I guess it works for him, but I think most people would find it too confusing to be practical.

Assume that while working on your branch you made a few commits which were not perfect (say you wanted to take a day off and you want a commit point to work from when you are back). This all good and fine, you come back get the code working on your branch, make a commit and merge it to the main branch. When one looks at the commit log in the main branch it would list all the commits you have made (even the ones on which the code was not in a good shape). But at the same time the latest commit on main is good and this not a big problem. But if you really want to keep the history in the main branch to look clean and show only good commits, then it is not the case.

Though I don't follow what the author practices, I don't think it is a practice that is done for sake of cleverness. There is a benefit in keeping the history clean in the main branch. My only wish is probably if git allowed one to achieve the same without so many hoops.

Re: My Git Habits

#56

Post by niyazpk »

sateesh wrote: post #55
jlarocco wrote: post #27

Earlier quoted context omitted.

I also don't see the point. If I need to experiment, I'll create a branch, mess around there, and merge it back when I've figured things out and have everything working. The workflow in the article seems like it's trying to be clever for the sake of being clever. I guess it works for him, but I think most people would find it too confusing to be practical.

Assume that while working on your branch you made a few commits which were not perfect (say you wanted to take a day off and you want a commit point to work from when you are back). This all good and fine, you come back get the code working on your branch, make a commit and merge it to the main branch. When one looks at the commit log in the main branch it would list all the commits you have made (even the ones on wh…

Wouldn't git merge --squash do this for you?

Re: My Git Habits

#57

Post by sateesh »

niyazpk wrote: post #56
sateesh wrote: post #55

Earlier quoted context omitted.

Assume that while working on your branch you made a few commits which were not perfect (say you wanted to take a day off and you want a commit point to work from when you are back). This all good and fine, you come back get the code working on your branch, make a commit and merge it to the main branch. When one looks at the commit log in the main branch it would list all the commits you have made (even the ones on wh…

Wouldn't git merge --squash do this for you?

Thanks, I had never used the 'squash' option and was unaware of it. I think using 'squash' does helps to the history clean.

Re: My Git Habits

#58

Post by swah »

When you guys delete a feature/complex function that you wrote just to discover you don't need it, do you guys mark it somehow to know something that worked was removed in that commit?

Re: My Git Habits

#59

Post by pozorvlak »

ezquerra wrote: post #52
encoderer wrote: post #39

Earlier quoted context omitted.

Mercurial is more like Git than not. It differs in the way it stores revision history (Git stores files, Mercurial stores deltas, basically). And branching is Mercurial isn't nearly as neatly implemented as it is in Git. But it would seem to address the issues you listed here. For example, you can rollback a commit if you did the "stupid typo" mistake. And you have a lot of power to "change history" and modify the DA…

In my opinion branching _used_ to not be as neatly implemented as it is in Git, but that is no longer the case. A couple of versions ago a new feature was added into core mercurial, called "bookmarks". Mercurial bookmarks are the same as Git branches. So now you can use the "git style branches" (i.e. bookmarks) in mercurial, or you can use the regular mercurial-style branches (which I personally prefer to git's anywa…

Anonymous branches are AFAICT the same thing as detached heads. They're discouraged in git, but they work fine.

Re: My Git Habits

#60

Post by pozorvlak »

gbog wrote: post #51
tikhonj wrote: post #46

Earlier quoted context omitted.

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

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.

We tried that - it was called Subversion. The industry's abandoning that way of doing things because the new way is simpler and better.
Post reply on HN