undefined | Better HN

0 pointsmikeash10y ago0 comments

Doesn't the merge commit for a branch like that serve the same purpose as your rebased commit, but without destroying the underlying history?

0 comments

soyiuz10y ago

I agree with mkeash's comment. Isn't this also the whole point of the staging area? "Stage multiple fixes into a single coherent commit," is the underlying model. Instead, in the above example there are many granular commits, with rebasing used to then clump them into a logical grouping.

This would indicate to me that you are committing too often or not using the staging area properly.

jh310y ago

Committing often allows you to remember the small changes you made throughout the feature. If you let a file sit in the staging area for hours, days, weeks, you will most likely have a hard time remembering why you made all the changes.

Is there a way to do this with the staging area? o.O

kansface10y ago

Merge commits, particularly those that merged master multiple times effectively destroy history (by preserving it). For that matter, many projects maintain all commits to master should work! Unless you advocate only committing entirely working states (unlikely for large features), you'd have to rebase.

mikeashOP10y ago

Can you explain what you mean by effectively destroying history by preserving it? That doesn't make any sense to me. And I also don't understand the link between merge commits and a failure to ensure that all commits to master should work. If you make changes in a branch, get everything up and running there, then merge to master, does that not ensure that everything on master works?

j / k navigate · click thread line to collapse