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

71–80 of 80 posts

Re: Git Reflow

#71

Post by adrianratnapala »

mikepurvis wrote: post #59
ghayes wrote: post #55

Earlier quoted context omitted.

I agree here. Be a good steward of your commits, and let `rebase -i` be your tool for that. A bunch of "err, try this instead" should be washed away, but it doesn't help to commit "Add Huge Feature" +10,000/-2,000 because "I should squash my feature"

If you're putting up 10k lines of code in a single review, you're doing it wrong anyway. Why wouldn't you have multiple reviews that each add different parts of a feature and link to the same ticket?

If I wanted to review 200 lines of changes, then I would still prefer to see it as a series of patches, each maybe with 1-20 lines changed and each with a clear purpose.

Re: Git Reflow

#72

Post by jon-wood »

Kiro wrote: post #22
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…

> 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. I'm the complete opposite. When I do a blame I want to see a direct link to the feature. I couldn't care less about the specific commit that changed the line.

I've wanted both at different times, they answer different questions. The feature answers what it was added for, the commit answers the question of why.

Re: Git Reflow

#73

Post by alkonaut »

jasode wrote: post #42
alkonaut wrote: post #26

Earlier quoted context omitted.

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…

> The post I replied to qualified it with "this may be a minority position"

Madness.

I did qualify my suggestion that no one wants "oops typo"-commits with "in any sane workflow" :)

Re: Git Reflow

#74

Post by jerf »

juped wrote: post #47
jerf wrote: post #43

Earlier quoted context omitted.

"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.

There are positions other than the extremes. My position makes sense, yes, in context too.

Re: Git Reflow

#75

Post by andrewaylett »

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.

We treat branches for tickets (prefixed with the ticket ID) as owned by the owner of the ticket: feel free to check out, but if the owner changes it underneath you, tough.

Re: Git Reflow

#76

Post by jordigh »

amk_ wrote: post #52
CJefferson wrote: post #12

Earlier quoted context omitted.

I agree, I wish some VCS would figure out how to do a "history of history". I hate every time in git I destroy history (delete a branch, do a force push / update), but it is almost impossible to use git without doing these things, particularly when committing to another project.

git reflog https://git-scm.com/docs/git-reflog

That's not the same thing as a metahistory. It doesn't tell you which commit(s) replaces with commit(s). Mercurial Evolve, for example, will record if a commit was split into several commits or if a commit was folded (squashed) into a single commit. Thus you can trace the history of a commit as it, well, evolves. You can't easily do this with git reflog, because it doesn't store that information.

Re: Git Reflow

#77

Post by cyphar »

junke wrote: post #70
cyphar wrote: post #68

Earlier quoted context omitted.

I never liked git bisect skip, becuase the bug you're tracking down somehow always manages to be in a set of 3 or 4 commits, of which you can't build 2. Maybe I'm just lucky.

You can't blame git bisect skip for that. Note also that many other commits that could not build did not contain the bugs ;-) (Speaking of luck, I worked with a codebase where the bug was always inside a jumbo commit involving at least a hundred of files)

I know, but I prefer codebases where skipping a commit isn't necessary -- because it always fills me with dread. ;)

Re: Git Reflow

#78

Post by hobarrera »

npsimons wrote: post #15
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…

> But there are so many people into it, that I feel I must be missing something obvious and it bothers me. As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history, especially if I'm browsing history or bisecting a bug. That's noise - useless data. OTOH, commits should be the Minimum Necessary Change to accomplish a well-defined goal. The c…

> The code itself should always be clear on what it is doing

Yes, but WHY it does that may not be obvious. "Oh, this code checks for a funny condition, but why would we care about that?". That's what commit messages are for.

Re: Git Reflow

#79

Post by amk_ »

jordigh wrote: post #76
amk_ wrote: post #52

Earlier quoted context omitted.

git reflog https://git-scm.com/docs/git-reflog

That's not the same thing as a metahistory. It doesn't tell you which commit(s) replaces with commit(s). Mercurial Evolve, for example, will record if a commit was split into several commits or if a commit was folded (squashed) into a single commit. Thus you can trace the history of a commit as it, well, evolves. You can't easily do this with git reflog, because it doesn't store that information.

> because it doesn't store that information

Is there something about the Hg architecture that makes it easier to plug in something like Evolve than with Git? Evolve isn't enabled out of the box on Mercurial either.

Re: Git Reflow

#80

Post by jordigh »

amk_ wrote: post #79
jordigh wrote: post #76

Earlier quoted context omitted.

That's not the same thing as a metahistory. It doesn't tell you which commit(s) replaces with commit(s). Mercurial Evolve, for example, will record if a commit was split into several commits or if a commit was folded (squashed) into a single commit. Thus you can trace the history of a commit as it, well, evolves. You can't easily do this with git reflog, because it doesn't store that information.

> because it doesn't store that information Is there something about the Hg architecture that makes it easier to plug in something like Evolve than with Git? Evolve isn't enabled out of the box on Mercurial either.

All of the actual infrastructure for evolve is actually in hg core. This is the obsolescence markers and the logic for hiding obsolete commits. This infrastructure makes it so that all hg commands see a filtered set of commits if any are obsolete and "unreferenced" (hg doesn't really find commits by referencing, but the logic for when an obsolete commit is hidden is similar to git's referencing logic).

The "only" thing the Evolve extension does is expose a UI for creating and manipulating obsolete commits, but it's not the only extension that does it.

So, I guess you could build Evolve for git, if you absolutely cannot be persuaded to use anything but git. You would need to build obsolescence markers, and the proper logic for exchanging them between clones. Getting this right has taken a lot of work for hg, but maybe now that the ideas are mostly there, it would be easy to replicate them.

Post reply on HN