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

Squash your commits

github.com

Post reply on HN
Print view View original

341–350 of 350 posts

Re: Squash your commits

#341

Post by WorldMaker »

radarsat1 wrote: post #314
sulam wrote: post #152

Earlier quoted context omitted.

caveat: I was responsible for code review for 2000+ developers. We only allowed squash commits on master because of what you're describing. That is the level where history "made sense". However, for code review, we wanted to support both styles, because there is an advantage sometimes to seeing the sausage being made. For instance someone will refactor something -- maybe change a method name. Then they apply that ref…

In that sense it would be cool if git supported something more like "branch collapsing," which could be used instead of squashing a branch and rebasing that on master. It should be possible to "view" a branch as if it were a single commit on master, with its own comments etc (from the merge commit perhaps) and then expand it. Perhaps this is just a UI problem..

I do think this is mostly a UI problem. As someone else suggested in this thread sites like GitHub which show only a linear list of commits should probably default to something more like `git log --first-parent`.

There also sounds like a need for `git bisect` to be smarter about DAG traversal, in that it seems to treat the branch as if it were a flattened linear list rather than taking advantage of the merge structure of a branch. This also sounds like something that should be relatively easy to make smarter.

Re: Squash your commits

#342

Post by WorldMaker »

ris wrote: post #334
brianpan wrote: post #246

Earlier quoted context omitted.

Isn't that exactly what the original commenter is suggesting? > no rebases, no squashes, sometimes not even fast-forwards

I think the implication is rebases or squashes of already published work.

Thanks, that was indeed the primary implication.

That said, I've been happy to debate the larger implications that there are UI/UX tweaks/story-telling that could make even the work-in-progress non yet published stuff more appealing to publish without needed to mutate it from its as-developed states... But yes, I was mostly speaking to published commits.

Re: Squash your commits

#343

Post by WorldMaker »

chris_wot wrote: post #292
InclinedPlane wrote: post #109

Earlier quoted context omitted.

What annoys me is that so many people take the position that there's no other way to improve the experience except for building an hazardous and error prone system into the core workflow of a tool that should ideally deal primarily with immutable history, rather than building better tooling to manage that complexity and present history in a useful way other than a raw list of commits. I mean, who would build such too…

What do you propose? If you want to err on the side of commits that show a clear unit of change, with a clear commit message and you make a syntax error by accident, do you seriously think it's a good idea to force a dodgy "oops, syntax error" commit into the mainline code branch? I agree that code once committed to master should be immutable, but your own private commits should be maleable. It's not a matter of feel…

I absolutely agree that private commits should be malleable and sometimes you do want to just pretend that you wrote things smartly the first time...

That said, there are certainly ways to better handle the "Oops, syntax error" style of commits than blowing them out after the fact. Some of that is better acknowledging the existing DAG structure of git and realizing that you don't need to 'depth-first search' the commit log every time you look at the commit log. Tools could default to views more like `git log --first-parent` and then let you expand out from there, for instance.

There's also the idea of better drawing lines between the code work and "story telling work" of a commit. Certainly today you could do all your work in progress in a branch and then `git merge --no-ff` it into another branch and there tell the completed story of that commit set after all the "dust has settled" on the stuff that was done in the heat of progress.

It's as much a matter of tooling support and community support (we all make mistakes so we aren't going to dunce cap anyone for making mistakes) as it is a technical problem.

I think we can see that "not all commits are equal" and maybe we want a system for "color these commits as work in progress" followed by "here's the final story for these commits, color it as presentable and ready for code review". I think it's an interesting discussion to continue to have and an opportunity to really think what we want in our source control tools and how they can better help us tell the stories of the code we are working on, for our reviewers and even maybe for our code archeologists.

Re: Squash your commits

#344

Post by EdHominem »

WorldMaker wrote: post #59

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…

> to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list.

Err, it doesn't make it look like the "lie of a" straight line, it makes it into a straight line. Whatever the other developers do, I move the project forward one ball of functionality at a time when their changes are useful to mainline.

When you use software, why do you run a "release" instead of whatever happens to be in the dev's directory when they leave for lunch? Don't you feel dishonest getting the version without the bugs?

> Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful

Perhaps if I was going to hire you it'd be interesting to glance at how you work with nobody looking. Do you keep your desk tidy or not?

But it's absolutely irrelevant to the final project and as such, it shouldn't be stored.

> I trust that. It's real and visceral and how software is actually made

You should read Tracy Kidder's _The Soul of a New Machine_, it's a good read about sausage.

But it's not how you should work because you have choice now.

Re: Squash your commits

#345

Post by forrestthewoods »

exDM69 wrote: post #340
forrestthewoods wrote: post #338

Earlier quoted context omitted.

You can shelve a changelist in P4. And any other user can unshelve it. I'm not sure how different that is from creating/sending patches? Especially if done from the cmdline. This has been a fun, educational HN thread. Thanks for sharing!

> You can shelve a changelist in P4. And any other user can unshelve it. I know, and we use this sometimes. It's just not as easy as pushing to a dev branch in Git creating a patch with "git am" and emailing/copy-pasting to a pastebin or whatever. Thanks for sharing your point of view and making a very civilized discussion from obviously differing opinions :)

I've never tried this. But it looks like if you run "p4 diff -du file" it creates a patch that could be pastebinned.

https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_di...

Branching still sucks in P4. But if it improves your work flow at all I figured it's worth mentioning.

Re: Squash your commits

#346

Post by WorldMaker »

DougWebb wrote: post #208
WorldMaker wrote: post #59

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…

Do you see the commit history as a piece of living art, a representation of the community and culture that has produced it, or do you see it as a tool? I'm an engineer, and I see the commit history as a tool. When I want to know what a block of code is for and why it was written the way it was, the commit history (if it is clean and granular) will tell me a lot about that, and will point me to authors, issues, featur…

I suppose I see commit history more interesting as works of art and archeology. Code history will be read more often than it will likely ever be interacted with. Like the scuffs in the marble, the fingerprints and brush strokes and little hairs in watercolor and oil painting, there can be beauty in the little flaws.

I've had it put to me that an Architect deals solely with the art of a project and a Scientist deals solely with the science and theory; it's the work of an Engineer to deal in the practical middle where art meets science (meets the real world).

Sometimes it is easy to overlook (or to want to overlook) the little bits of humanity in the machine; the various sorts of creative chaos in the vast ordered systems; the parts of the code that are art.

There's no easy answers to much of this thread, because it is art, it is aesthetics. There's no "right" answer, just "this looks good and pleasing to me and my team" and working to find that practical Engineering border space between the unwavering art of the Architect and the similarly unwavering logic and discipline of the Scientist.

Re: Squash your commits

#347

Post by WorldMaker »

Daviey wrote: post #271
WorldMaker wrote: post #59

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…

Projects that use a rich code review tool like Gerrit, such as Android, OpenStack and wikipedia keep the truth in the code review tool.. but the actual git tree is kept minimal and clean. If you want to dig into the actual commit, and the dirty truth under the surface - use Gerrit.. you can even use git itself to pull down the truth. I'm expecting this github feature to be the same, the pull request probably keeps th…

I see this as a tooling problem. Why use two tools when you can use one? Why is "code review" not a first class citizen in your source control world?

I don't have all the answers of what the tooling should be, I just think this is as a good an opportunity to discuss it as any.

GitHub's long-standing --no-ff merges at least are one way of preserving the code review and it's internal changes directly into the git DAG. This mostly works except for tools like git bisect that treat the DAG as if it were a straight line, rather than making use of the fact that the system already supports complicated graphs.

Furthermore, along the questions of why use two tools to navigate the code repository: I sort of wish that things like GitHub PR comments and code annotations made their way somehow into nodes in the git DAG.

Re: Squash your commits

#348

Post by teacup50 »

jasode wrote: post #332
teacup50 wrote: post #329

Earlier quoted context omitted.

What you're missing is that "gotchas in the code" are not always known when the code is being written. Very often, you have to piece together what happened and why from the record of what people actually did. There's no such thing as "personal history" with the code in the context of SCM commits. It's all project history. This new idea is both deceptive, and honestly, shocking. No SCM system previously has ever been…

>There's no such thing as "personal history" with the code in the context of SCM commits. It's all project history. Yes, there absolutely is "personal history" with DVCS. Your rigid mental model for "SCM commits" is relevant for older tools like cvs/svn with lock-checkout-checkin-unlock procedures. The "commits" in those centralized SCMs are a Really Big Deal. DVCS is different. When a programmer decides to "fork" a…

No, programming process is not different.

I'm very aware of what DVCS is. It doesn't require breaking our collaborative processes just because changes are staged locally first.

Re: Squash your commits

#349

Post by jasode »

teacup50 wrote: post #348
jasode wrote: post #332

Earlier quoted context omitted.

>There's no such thing as "personal history" with the code in the context of SCM commits. It's all project history. Yes, there absolutely is "personal history" with DVCS. Your rigid mental model for "SCM commits" is relevant for older tools like cvs/svn with lock-checkout-checkin-unlock procedures. The "commits" in those centralized SCMs are a Really Big Deal. DVCS is different. When a programmer decides to "fork" a…

No, programming process is not different. I'm very aware of what DVCS is. It doesn't require breaking our collaborative processes just because changes are staged locally first.

>our collaborative processes just because changes are staged locally first.

The keystrokes of ^H Backspace are not a "collaborative process". The idiosyncratic persistence of RAM buffers of a text editor is also not a "collaborative process". Why do you think "git commit" on a local unpublished repo is collaborative? I can only guess that it's because the word "commit" is in "git commit"? Well, syntax is not semantics.

>I'm very aware of what DVCS is.

I think many people with your position know the commands syntax of DVCS but don't actually grok the "draft work" philosophy of DVCS. Therefore you assign label of "collaborative process" to unrelated concepts such as the typing habits the programmer happens to execute on his laptop's harddrive. Unfortunately, the programmer persisting his editor's RAM buffers to disk happens to use the command "git commit" which distorts the thinking and causes people to label that action as "collaborative"!

The "pull request" and "merge" is collaborative. The raw "git commit" is not.

Re: Squash your commits

#350

Post by kylnew »

teacup50 wrote: post #187
kylnew wrote: post #67

Earlier quoted context omitted.

Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log

As someone who has spent a lot of time tracking down the origin of source code changes -- and the reasons for them, and the implications of the change -- by reviewing commit logs, I can think of little worse, short of no commit history at all, than trying to derive anything remotely useful from a commit history that has been condensed down to a product change log. Even commits that lack good commit messages provide v…

Ugh, the thought of scouring through commits with messages like "fixed", "oops", "done" is like fingernails on a chalkboard to me. What I read is a LACK of thought process, when you can't squash and justify your changes susinctly
Post reply on HN