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

Git koans

stevelosh.com

Post reply on HN
Print view View original

121–130 of 143 posts

Re: Git koans

#121

Post by porker »

jamesgeck0 wrote: post #106
ollysb wrote: post #82

Earlier quoted context omitted.

Normally I would agree with you that software should be intuitive with a minimum of learning. However git is only used by expert users, people who use it all day every day. There's no doubt that git has a bit of a steep learning curve but the abstraction you're forced to learn is really powerful. Having come from SVN the intuitive abstraction I was used to now seems woefully inadequate.

I am an expert user. I've been using git almost every day for months. I've read about it's underlying data model and could write a tool that used it if I really needed to. I _still_ have to use Google whenever I try to do anything with git that falls outside my normal workflow.

Here Here! Same experience for me

Re: Git koans

#122

Post by Anderkent »

philwelch wrote: post #117
Anderkent wrote: post #102

Earlier quoted context omitted.

No, a possible explanation would be 'that is unnecessary, because: ...'. Except of course tagging commits with branches is not unnecessary, because that's the only way a user might make sense of ancestors of a merge commit... Unless you like manually tracking parents of a commit, and trying to guess which branch is which based on commit messages. Fun! I've seen many workarounds to this clear deficiency, the simplest…

> Unless you like manually tracking parents of a commit Git tracks the parents of a commit. There are ways to visualize that, even with command-line git. When you do this, it's usually clear which branch is master and which branch was the feature branch, and since the merge commit has a default commit message like "merge > to master" it's even easier to figure out. It's also entirely possible to use a Git workflow wh…

Open `git glog` and look at the tree is exactly what I ment by manually tracking parents of a commit. I shouldn't have to do that.

That means that to see commits that were done in a particular feature branch I need to do some magic that walks up the commit tree from a given merge commit, guesses which one of the parents is the master and which one is the feature branch, remembers the commit ids, keeps track of merge commits it hits and makes sure it is still tracking the right branch (merges of master into a feature branch are common, merges of feature branches into other feature branches are occasional), etc.

All because gits branches aren't really branches at all.

As to fast forwarding a feature branch onto master, I can't believe anyone would actually do that. You might as well be developing on the master branch from the beginning there, what's the point of having branches if they disappear from history?

Re: Git koans

#123

Post by Anderkent »

philwelch wrote: post #118
Anderkent wrote: post #103

Earlier quoted context omitted.

Of course everyone who doesn't like your tool is a fool. It's just not possible they'd have different but equally valid requirements!

Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.

>If you actually understand the data model and have reasons for not liking Git, I'm curious what they are.

Well, the fact that I can't easily find what commits were done on a branch, for one. And yes, I understand why it's not possible, they way git does branches.

Or that it doesn't track renames/moves, other than on similarity basis that often fails to detect rename when viewing a file history, for example.

The git answer to both of these is usually 'well your viewer could be doing that', except they don't, because it's hard when you don't track that information in commits.

Re: Git koans

#124

Post by fr0sty »

Anderkent wrote: post #98
wonderzombie wrote: post #72

Earlier quoted context omitted.

The question was not how to just get the current branch, thought, right? As pointed out already, `git branch` does that. The question was how to do it programmatically, and there are multiple ways to do it. You might still call that user interface, but it's that's a stretch; fancy shell magic like branch-in-prompt is typically write-once.

`git branch` doesnt do that. `git branch | less` followed by search might, if I remember some part of the branch name well enough to search for it. Printing all the branches and having me scroll two screens up to find the one that's in color is not a solution to 'what branch am i on'

git branch gives you a nice asterisk too: $git branch * MyBranch NotMyBranch

It prints the branch as the first line of git status: $git status # On branch Foo ...

It also ships with a 'bash-competion' file which gives you a very simple way to disply the current branch (among other things) rather simply.

And of course you can also create your own alias if it is something you wish to do often.

Re: Git koans

#125

Post by philwelch »

Anderkent wrote: post #122
philwelch wrote: post #117

Earlier quoted context omitted.

> Unless you like manually tracking parents of a commit Git tracks the parents of a commit. There are ways to visualize that, even with command-line git. When you do this, it's usually clear which branch is master and which branch was the feature branch, and since the merge commit has a default commit message like "merge > to master" it's even easier to figure out. It's also entirely possible to use a Git workflow wh…

Open `git glog` and look at the tree is exactly what I ment by manually tracking parents of a commit. I shouldn't have to do that. That means that to see commits that were done in a particular feature branch I need to do some magic that walks up the commit tree from a given merge commit, guesses which one of the parents is the master and which one is the feature branch, remembers the commit ids, keeps track of merge…

I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on?

The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway.

It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches. If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master".

Re: Git koans

#126

Post by philwelch »

Anderkent wrote: post #123
philwelch wrote: post #118

Earlier quoted context omitted.

Someone who can't understand the Git data model is, by programmer standards, a fool. If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Unfortunately, most criticisms come from people who can't be arsed to grok how Git works and just ragequit.

>If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Well, the fact that I can't easily find what commits were done on a branch, for one. And yes, I understand why it's not possible, they way git does branches. Or that it doesn't track renames/moves, other than on similarity basis that often fails to detect rename when viewing a file history, for example. The git…

Lets back up: why are you trying to figure out what branch a historical commit was on? What problem does that solve for you? I've never found that information terribly important or interesting.

Re: Git koans

#127

Post by philwelch »

Anderkent wrote: post #98
wonderzombie wrote: post #72

Earlier quoted context omitted.

The question was not how to just get the current branch, thought, right? As pointed out already, `git branch` does that. The question was how to do it programmatically, and there are multiple ways to do it. You might still call that user interface, but it's that's a stretch; fancy shell magic like branch-in-prompt is typically write-once.

`git branch` doesnt do that. `git branch | less` followed by search might, if I remember some part of the branch name well enough to search for it. Printing all the branches and having me scroll two screens up to find the one that's in color is not a solution to 'what branch am i on'

Why are you keeping hundreds of branches open at a time?

Re: Git koans

#128

Post by Anderkent »

philwelch wrote: post #126
Anderkent wrote: post #123

Earlier quoted context omitted.

>If you actually understand the data model and have reasons for not liking Git, I'm curious what they are. Well, the fact that I can't easily find what commits were done on a branch, for one. And yes, I understand why it's not possible, they way git does branches. Or that it doesn't track renames/moves, other than on similarity basis that often fails to detect rename when viewing a file history, for example. The git…

Lets back up: why are you trying to figure out what branch a historical commit was on? What problem does that solve for you? I've never found that information terribly important or interesting.

Say I bisect some issue to a particular commit. Knowing which branch it was made on tells me what issue it was trying to solve, which gives me context for the entire branch.

It also means I can easily request all commits made in the master branch, to see what features were merged in recently.

Re: Git koans

#129

Post by Anderkent »

philwelch wrote: post #125
Anderkent wrote: post #122

Earlier quoted context omitted.

Open `git glog` and look at the tree is exactly what I ment by manually tracking parents of a commit. I shouldn't have to do that. That means that to see commits that were done in a particular feature branch I need to do some magic that walks up the commit tree from a given merge commit, guesses which one of the parents is the master and which one is the feature branch, remembers the commit ids, keeps track of merge…

I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you do…

>I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on?

I shouldn't have manually filter the commit history to get the information that interests me.

>The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you don't know ahead of time. Once they're merged back, you don't necessarily need to record the history of the feature branch separately. Often you're going to squash changes anyway.

But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like.

>It's also a better idea to rebase from master and merge to master, but even if you merge both ways, the commit message still reports the source and destination branches.

Sure, if the rebase is clean, but conflicts are common.

>If you're disciplined about using feature branches, master is the branch with commit after commit saying "merged to master".

Unless you use the github UI, in which case it will say 'Merge pull request ...'. Or you had to hotfix something on master - it happens.

Re: Git koans

#130

Post by philwelch »

Anderkent wrote: post #129
philwelch wrote: post #125

Earlier quoted context omitted.

I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. But they're only going to be merged back to mainline in the order they're completed, which you do…

>I have to admit some confusion. You're not looking through your commit history when you're trying to figure out which branch a historical commit was on? I shouldn't have manually filter the commit history to get the information that interests me. >The reason for the rebase/fastforward workflow is to basically synchronize changes. You might have five developers working on seven different feature branches at a time. B…

> But if you fast forward your changes on top of master and push that out as the new master, you lose all the benefits of branching. You could have as well made your changes on master, do pull --rebase once you've completed and then push out. That's how the history looks like.

Which benefits?

To me, the main benefits of branching happen as I'm developing a feature. I can work on something and quickly context-switch either back to master or to a different feature branch. For instance, if I'm working on a feature but a high-priority bug fix needs to be done first, I can switch back to master, check out a bug fix branch, and keep my feature work separate from it. When the bug fix is done, I merge it in and rebase my feature branch from it. The only thing I really care about historically is that features land in master all-at-once, which squashing, rebasing, and fast-forwarding does for you.

> Sure, if the rebase is clean, but conflicts are common.

You have to resolve conflicts either way though.

> Unless you use the github UI, in which case it will say 'Merge pull request ...'.

Still a recognizable pattern.

> Or you had to hotfix something on master - it happens.

That's called "not being disciplined about using feature branches". I suspect you run into this problem because you're suffering under a self-imposed constraint that branch names have to be globally unique and meaningful throughout your version history.

This isn't a problem unless you want to enforce a workflow where you always merge to master--the rebase/squash/ff workflow wouldn't actually pose a problem here, since all ancestor commits to master were deliberately put on master. My point is, if you follow an inconsistent workflow, no wonder your history is difficult to look through.

Post reply on HN