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

Git Reflow

github.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Git Reflow

#41

Post by _ikke_ »

jerf wrote: post #36
juped wrote: post #3

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do s…

Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement.

Git allows you to clean up your feature branches to prevent these kind of fix commits.

Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.

Re: Git Reflow

#42

Post by jasode »

alkonaut wrote: post #26
kiallmacinnes wrote: post #17

Earlier quoted context omitted.

Some information is worth loosing. Personally, I get exactly zero value from "Fixed a typo", "Fixed that errant semicolon", "fixed tests broken 3 commits ago" commit messages that come hand in hand with a hard and fast "never rewrite history" policy. If that information is valuable to you, great! This is why we have several ways to do things. The trend you're seeing simply seems to indicate (mildly indicate, at best)…

I think people are talking about different things. No one wants to see any "oops typo" coomits. Those are squashed/amended in the feature branch in all sane workflows. The question is only if you represent each feature with ten commits in the feature branch as one commit in master or as 2 or 3. If a typical feature starts with some cleanup/refactoring, I don't mind seeing that work separated from the new implementati…

>No one wants to see any "oops typo" coomits.

That's what I thought but it's not quite "no one". There are some who'd love to have all git commit history, and if it was possible, the entire editor text buffer histories and keystroke logs of other programmers' work. This was my reply to it:

https://news.ycombinator.com/item?id=11408221

The post I replied to qualified it with "this may be a minority position" but his comment happens to be the topmost comment so lots of HN voters agreed with him.

Based on the repetition of this "git rebase" topic, I can only guess that roughly half of git users want to see all git commits with "oops, stupid typo", and the other half don't want to be inundated with meaningless noise. I really have no idea though.

Re: Git Reflow

#43

Post by jerf »

_ikke_ wrote: post #41
jerf wrote: post #36

Earlier quoted context omitted.

"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do s…

Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement. Git allows you to clean up your feature branches to prevent these kind of fix commits. Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.

"As long as I can bisect, I don't much care about the details."

If I can't bisect, I don't approve. So, by simple logic based on the premise you supply, I also disapprove of large commits.

My point may not be what you expected prior to reading.

Re: Git Reflow

#44

Post by heeen2 »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

If I want to cherry-pick a feature, I want less commits to search for, ideally one big coherent one with maybe a few smaller fixes later on.

Re: Git Reflow

#45

Post by Filligree »

heeen2 wrote: post #44
32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

If I want to cherry-pick a feature, I want less commits to search for, ideally one big coherent one with maybe a few smaller fixes later on.

With feature branches, I can merge the branch. That works just as well.

Re: Git Reflow

#46

Post by takeda »

lotyrin wrote: post #40
tunesmith wrote: post #38

Earlier quoted context omitted.

I think there's an inherent tension between your style, and the style that prefers pushing new branches immediately. I personally like to create a new branch locally - sometimes I'm experimenting and get ahead of my commits, and then I'll make 3-4 commits in bite-sized concepts. Other times I'll commit something that seems like it will probably work, and then I realize it doesn't, so I'm able to revert/reset the comm…

Push after rebase is safe and easy if: You have protection on your remote trunk branches against force push. You have git configured to push only the branch you are on, to the same name on the remote. git rebase; git push -f; It is HARD, DANGEROUS and SHITTY under other configurations. <3 Git.

As long as no one else is using your branch as well, then they'll hate you.

Re: Git Reflow

#47

Post by juped »

jerf wrote: post #43
_ikke_ wrote: post #41

Earlier quoted context omitted.

Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement. Git allows you to clean up your feature branches to prevent these kind of fix commits. Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.

"As long as I can bisect, I don't much care about the details." If I can't bisect, I don't approve. So, by simple logic based on the premise you supply, I also disapprove of large commits. My point may not be what you expected prior to reading.

Then your comment makes no sense in context, because you replied to my complaint that people lose information by doing these giant squash merges and having no nontrivial graph structure in their main project history.

Re: Git Reflow

#48

Post by tunesmith »

takeda wrote: post #46
lotyrin wrote: post #40

Earlier quoted context omitted.

Push after rebase is safe and easy if: You have protection on your remote trunk branches against force push. You have git configured to push only the branch you are on, to the same name on the remote. git rebase; git push -f; It is HARD, DANGEROUS and SHITTY under other configurations. <3 Git.

As long as no one else is using your branch as well, then they'll hate you.

Yeah, basically as soon as you push, then there's no guarantee that someone else hasn't checked it out. That's how I see it anyway.

It'd be nice if git let you push (for backup/protection) without letting other people see it or check it out yet.

Re: Git Reflow

#49

Post by zelos »

tunesmith wrote: post #38
32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I think there's an inherent tension between your style, and the style that prefers pushing new branches immediately. I personally like to create a new branch locally - sometimes I'm experimenting and get ahead of my commits, and then I'll make 3-4 commits in bite-sized concepts. Other times I'll commit something that seems like it will probably work, and then I realize it doesn't, so I'm able to revert/reset the comm…

But leaving a day's work locally on your laptop is dangerous, no? You have to organise some other backup system, instead of pushing to the central, RAIDed, backed up repo.

Re: Git Reflow

#50

Post by JimDabell »

tunesmith wrote: post #48
takeda wrote: post #46

Earlier quoted context omitted.

As long as no one else is using your branch as well, then they'll hate you.

Yeah, basically as soon as you push, then there's no guarantee that someone else hasn't checked it out. That's how I see it anyway. It'd be nice if git let you push (for backup/protection) without letting other people see it or check it out yet.

It's a fairly common practice to prefix branches only intended for your own work with your initials and a slash, e.g. jd/my-work-in-progress. You can't guarantee that nobody else will work off it, but it's their own fault if they do.
Post reply on HN