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

Git pretty

justinhileman.info

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Git pretty

#41

Post by smt88 »

recursive wrote: post #37
findjashua wrote: post #19

Earlier quoted context omitted.

Sounds more like resistance to change than anything wrong with Git. I used perforce at my previous company, and while Git's learning curve was higher, I definitely see the advantages of a distributed version control system over a centralized one: 1. Not having to check out files means I can work offline. 2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perfo…

Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git.

Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

Re: Git pretty

#42

Post by [deleted] »

bellerocky wrote: post #21
js2 wrote: post #4

This is excellent: opinionated and correct. Guess what happens if you try to git revert a merge? Yeah. Don’t do that. You can, but you really need to understand what happens when you do so, so that you're not confused by future merges from the same branch. Straight from the horse's mouth: https://www.kernel.org/pub/software/scm/git/docs/howto/rever...

Reverting a merge is totally OK if you kept your history clean and rebased the branch you're merging into to get updates instead of merging it into your branch. Like if you created a new branch from master and you have been merging master into your branch to get updates in master, once you merge your branch into master you cannot revert this merge because the act of merging master into your branch changed which branc…

[deleted]

Re: Git pretty

#43

Post by bobthecow »

pjungwir wrote: post #40
js2 wrote: post #4

This is excellent: opinionated and correct. Guess what happens if you try to git revert a merge? Yeah. Don’t do that. You can, but you really need to understand what happens when you do so, so that you're not confused by future merges from the same branch. Straight from the horse's mouth: https://www.kernel.org/pub/software/scm/git/docs/howto/rever...

I've read that doc and other warnings about reverting a merge. But I've found that if you revert the revert, then you avoid the problems they mention. I guess the worry is that you still have to remember to do that, or you'll have commits that silently never merge. But if you do remember, then reverting the revert makes things okay. But I'm no expert. Can anyone else confirm this for me?

Yes, the correct way to do it is to revert the revert. js2's link above outlines how and why in detail.

Re: Git pretty

#44

Post by LandonAB »

apinstein wrote: post #35
LandonAB wrote: post #32

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

I'd counter that these messes aren't caused by git; rather they are messes that without git you wouldn't even bother cleaning up. However, git lets you fix the mess in such a way that you'll have a clean commit history. This is really helpful if you're trying to keep your codebase clean so that `git bisect` will always work nicely, and if you just want to keep your codebase history really grokkable.

Oh, I'm not blaming git. I take full blame but still have a hard time rationalizing the headache.

Re: Git pretty

#45

Post by LandonAB »

chunkstuntman wrote: post #33
LandonAB wrote: post #32

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

I think any version control software needs to address the simple fact that humans will rush through writing and committing code in a way that they may later regret. Dealing with an ugly git log is less trouble than not having versioning software at all.

Yes, you are correct. I'm just not facing the inevitable apparently.

Re: Git pretty

#46

Post by pimlottc »

tarblog wrote: post #9

What does "I don't think it means what you think it means" refer to?

I don't think it's specifically about reverting merge commits but rather the fact that "git revert" is quite different from "svn revert" which may not be immediately clear and may not meet everyone's understanding of the term "revert" - which is to say, it does not simply "get rid of" the unwanted commit but rather creates a new one that has the net effect of undoing that commit's changes.

Re: Git pretty

#47

Post by philsnow »

christop wrote: post #11

"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.

Once upon a time I used darcs, where the interactive staging / interactive committing feels even nicer. Git's "git add -i" stuff has always seemed crufty to me.

For instance, in git add -i, the command to stage changes is called "update". The command to unstage is called "revert". Further, does _anybody_ use interactive adding when not intending to stage individual hunks from some file ? Yet there are all these other commands in there to stage/unstage whole files, which are more easily and uniformly done from the command line tools (well, when you accept that staging is called "add"ding on the command line and unstaging is called "reset"ting).

Re: Git pretty

#48

Post by pimlottc »

smt88 wrote: post #41
recursive wrote: post #37

Earlier quoted context omitted.

Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git. Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

> Before git-based package managers became the norm

When did using git-based package managers become the norm?

> it wasn't uncommon to track/update dependencies manually using command-line git.

Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?

(I'm guessing you're speaking from a JS dev perspective?)

Re: Git pretty

#49

Post by tericho »

LandonAB wrote: post #32

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

I do both enterprise and one person dev studio work and use Git for both.

When I do personal development or small side projects I could care less about my history being clean. Nothing is ever so large or complex that it needs to be fixed in such a meticulous manner. It may feel that way, until you start working on larger software. The stress of a $1,000-$20,000 job is laughable compared to the scale of enterprise failure.

In enterprise, it's often the case that applications are built by teams of people in constant flux. They may need to be patched or rolled back at a moment's notice, and every hour the bug stays live is an hour of enormous financial burden to the client and intense stress on my employer. In this case, having a trustworthy VCS with a clean history in invaluable.

Re: Git pretty

#50

Post by tricolon »

pimlottc wrote: post #46
tarblog wrote: post #9

What does "I don't think it means what you think it means" refer to?

I don't think it's specifically about reverting merge commits but rather the fact that "git revert" is quite different from "svn revert" which may not be immediately clear and may not meet everyone's understanding of the term "revert" - which is to say, it does not simply "get rid of" the unwanted commit but rather creates a new one that has the net effect of undoing that commit's changes.

I keep meaning to make an alias for it called "git anticommit".
Post reply on HN