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

Understanding the Git Workflow

sandofsky.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Understanding the Git Workflow

#61

Post by chousuke »

eropple wrote: post #23
gruseom wrote: post #20

Earlier quoted context omitted.

What exactly does Mercurial do differently that is better?

Short of explicitly installing a rebase extension, it simply does not allow you to do this sort of mucking about with the commit history. For "oops, typo" commits, you can very quickly (and I mean, "it's a button in Tortoise" quickly) roll back your change and keep it in abeyance until you've fixed the typo.

So basically you reject a powerful tool out of idealism ("must never ever edit history") and fix your commits manually, also forgoing the possibility of fixing earlier unpublished commits.

Instead you could code and commit (you know, use the VCS :P) without worry in a private branch, checking for problems afterwards and fixing them using rebase prior to merging the commits into the main branch. (where "must never ever edit history" actually applies)

Sorry if I sound snarky, but that's what this seems like to me.

Re: Understanding the Git Workflow

#62

Post by baha_man »

pyre wrote: post #50
westi wrote: post #30

Earlier quoted context omitted.

I completely agree with this. If a change was worth committing then it is worth sharing that commit with everyone. Otherwise you run the very real risk of loosing important information about the design of a feature the bugs that were found and addressed during development. Every change should been accompanied by a well described commit message and big changes are much harder to review. I can see a very small positive…

> If a change was worth committing then it is worth > sharing that commit with everyone You're misunderstanding some of the workflows that people are discussing. Sometimes I commit things that are half-finished, or even half-baked because I know that when it comes time to push I can rewrite things into a set of commits that makes sense. This workflow makes sense because rewriting is easy enough. Obviously, I might no…

"But then I would just resort to using something like quilt to manage patches onto of SVN, which is ridiculous."

This is exactly the way Mercurial patch queues work:

http://mercurial.selenic.com/wiki/MqExtension

Re: Understanding the Git Workflow

#63

Post by koopajah »

planckscnst wrote: post #35
eropple wrote: post #25

Earlier quoted context omitted.

I dunno, I think the claim that those commits "waste time" (in the sense of any meaningful amount of time, even cumulatively) is a little hyperbolic. I guess you view history differently than I do: I consider all development history to be "public history" regardless of whether it was pulled in from a clone or not. If you commit it to a repository I am going to be fulfilling a pull request from, I want the history the…

So, let's get down to business here, then. What specifically is better about this: commit 123facdf Add asynchThingerBopper() to Thinger class. commit 9f9babd8 Forgot to add Thinger.h file to 1123facdf compared with this: commit 123facdf Add asynchThingerBopper() to Thinger class. What specific value does the first scenario add that the second does not?

It can help for git bisect for example to avoid having half of your commit not compiling properly because half the time you forgot to add one of the files to your commit.

Re: Understanding the Git Workflow

#64

Post by fr0sty »

koopajah wrote: post #63
planckscnst wrote: post #35

Earlier quoted context omitted.

So, let's get down to business here, then. What specifically is better about this: commit 123facdf Add asynchThingerBopper() to Thinger class. commit 9f9babd8 Forgot to add Thinger.h file to 1123facdf compared with this: commit 123facdf Add asynchThingerBopper() to Thinger class. What specific value does the first scenario add that the second does not?

It can help for git bisect for example to avoid having half of your commit not compiling properly because half the time you forgot to add one of the files to your commit.

> It can help for git bisect

Not if the first commit doesn't compile.

Indelible history is good for public projects (and no one is arguing about that) and for change control systems but less good, in my estimation, in cases where mistakes are easily made, have small to non-existent consequenses, and serve no historic purpose.

Re: Understanding the Git Workflow

#65

Post by fr0sty »

eropple wrote: post #55
pilif wrote: post #29

Earlier quoted context omitted.

and you will get that history. But you will get it in the form that I would like you to have it, not as it happened. But there is no way for you to know besides the fact that all commits you are going to pull are self-contained and none of them breaks the build. Would you reject perfect looking commits, self-contained, perfectly documented and forming a perfect temporal history based on the fact that they are too per…

> But you will get it in the form that I would like you to have it, not as it happened. And that's actually a very large part of why I don't use something that makes rebase easy. Because, fundamentally, I do not care how you "want" me to get it. I want to get it how it was put into the repository to begin with. I want to get it how it was committed--because how it was done matters to me, as a developer and as a perso…

If your workflow or VCS doesn't allow rebase natively then people will implement it in the filesystem by never committing.

Git's approach to committing is: "commit early, commit often". The coro;lary is: "don't worry about perfection, we can fix it later". Such flexibility to me is very enabling and allows for a lot of very beneficial experimentation in the process of developing features.

Honestly, I don't understand your fascination with the sausage-making. If I were to give you the pre-rebase and post-rebase version of patches I would wager you would find much more value in the latter. And if not. Even if seeing the wandering, hacking, slashing, typoing, re-indenting, etc. is instructive to you, any future maintainer of the code will be far less pleased.

Re: Understanding the Git Workflow

#66

Post by astine »

eropple wrote: post #55
pilif wrote: post #29

Earlier quoted context omitted.

and you will get that history. But you will get it in the form that I would like you to have it, not as it happened. But there is no way for you to know besides the fact that all commits you are going to pull are self-contained and none of them breaks the build. Would you reject perfect looking commits, self-contained, perfectly documented and forming a perfect temporal history based on the fact that they are too per…

> But you will get it in the form that I would like you to have it, not as it happened. And that's actually a very large part of why I don't use something that makes rebase easy. Because, fundamentally, I do not care how you "want" me to get it. I want to get it how it was put into the repository to begin with. I want to get it how it was committed--because how it was done matters to me, as a developer and as a perso…

"I want to get it how it was committed--because how it was done matters to me, as a developer and as a person."

Or as a micro-managing boss. I don't need someone staring over my shoulder as I work or after I work. My mistakes aren't your business and I find your attitude unpleasant.

Re: Understanding the Git Workflow

#67

Post by pyre »

westi wrote: post #56
pyre wrote: post #50

Earlier quoted context omitted.

> If a change was worth committing then it is worth > sharing that commit with everyone You're misunderstanding some of the workflows that people are discussing. Sometimes I commit things that are half-finished, or even half-baked because I know that when it comes time to push I can rewrite things into a set of commits that makes sense. This workflow makes sense because rewriting is easy enough. Obviously, I might no…

My point is that these interim commits are useful information for other people too not just you. They help show how the feature developed, what other implementation ideas you tried along the way etc.

Personally, I think that this idea of somewhat bogus:

1) In most cases, all of those extra commits are just noise. They make it really confusing to determine what actually changed from point A to point B because of all of the dead ends that were hit and backed out in between.

2) This is like saying that every time that someone produces anything they should be required to save all of their dead ends for people that look at their work in the future. If a carpenter at a building site cuts a piece of wood wrong, should he just recut it correctly, or set it aside so that on the off-chance that someone needs to see how he mis-cut the piece of wood, they can?

3) The fundamental flaw here is that you're trying to use the tool to enforce the workflow. Would you feel the same way if the next version of Ubuntu enforced that no image files could be placed anywhere on disk except ~/Photos just because someone determined that that's what 'makes sense?'

Re: Understanding the Git Workflow

#68

Post by gruseom »

andrew311 wrote: post #53

I'm wondering how people address one of the scenarios raised in the post, specifically this: "It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it. You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up yo…

Whether a branch is private and therefore can be rebased has nothing to do with whether there's a copy of it on the server. I push my work-in-progress to the server often for backup purposes anyway. If I want to rebase, I just push -f.

I can't think of why that would be a problem, but if someone objected to push -f on a private branch, I'd just make a new branch with a new name and push that. And if that were a problem, I'd just find another server to push -f to and only ever commit to master on the official server. But these are silly workarounds. Why make things harder than they need to be?

Re: Understanding the Git Workflow

#69

Post by westi »

chousuke wrote: post #59
westi wrote: post #56

Earlier quoted context omitted.

My point is that these interim commits are useful information for other people too not just you. They help show how the feature developed, what other implementation ideas you tried along the way etc.

How are they useful? Why would anyone care about how you developed a single bugfix or a feature? In your model, often the commits are not even sequential in the log because you might find a mistake only after committing several other changes. I can't see how not rebasing makes commit history better in any way at all . I would like to hear your reasoning. The way I see it, instead of a series of commits that implement…

> How are they useful? Why would anyone care about how you developed a single bugfix or a feature?

In my opinion in a collaborative environment it is immensely useful to know about how a feature / bug fix was developed.

Hiding away the development of a feature into one large commit makes it harder for people to review.

> I do not think that this is a matter of opinion or preference. That would imply that both approaches are equally valid.

I think it is a matter of preference and opinion and this is why we have such diametrically opposed views on the subject.

Re: Understanding the Git Workflow

#70

Post by andrew311 »

gruseom wrote: post #68
andrew311 wrote: post #53

I'm wondering how people address one of the scenarios raised in the post, specifically this: "It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it. You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up yo…

Whether a branch is private and therefore can be rebased has nothing to do with whether there's a copy of it on the server. I push my work-in-progress to the server often for backup purposes anyway. If I want to rebase, I just push -f. I can't think of why that would be a problem, but if someone objected to push -f on a private branch, I'd just make a new branch with a new name and push that. And if that were a probl…

This is true. If the assumption is that it's a private branch, then other people shouldn't care if you push -f because no one else should be using it.

Sometimes there are cases where people want to pull a private branch because they are working on something that is in the same code path but will be deployed after the private branch is integrated and deployed. They want to work off the newest code and avoid a larger merge to their private branch later. Would rebasing that private branch make their life harder? If so, one could always stage changes in a feature branch at stable points for them. Thoughts?

Basically, my understanding is that push -f can be a hassle for others to pull if they made commits to the same branch already. You're totally right that if it's truly a private branch, though, this should be irrelevant.

Post reply on HN