11 ms·
I still don't understand why everyone has this misguided quest for a clean history. An accurate history is much more important. Rebasing destroys historical in
by jamesrom 13y ago
I still don't understand why everyone has this misguided quest for a clean history. An accurate history is much more important.
Rebasing destroys historical information. I can't really see any advantages of rebasing when a merge does the same thing but leaves two things rebasing does not: 1) a point to rollback to if things don't work out, and 2) an explicit entry of when your branch was brought up to date with master.
- a3n 13y agoBecause no one cares about an individual's doodles and false starts on a feature branch, or an exploratory branch off a feature branch, they only care about the final difference between before and after merge. Explorations are an unnecessary distraction.
- sanderjd 13y agoI disagree that categorically "no one cares": https://news.ycombinator.com/item?id=6457243 https://news.ycombinator.com/item?id=6457243
- a3n 13y agoI think phrases like "no one" should be understood as no one modulo a small number of exceptions that does not noticeably affect the majority trend. Always.
- Ygg2 13y agoBecause clean history is easier to bisect. It's easier to visually track problems, (aha so you changed thing A in branch br12 and thing B in branch br13 as opposed to wait so person A branched into br12, then person C branched into br23, then it got merged with br74, which was merged with person D on branch br84..). Less entagled workflow is easier to untangle and consequently understand even if it hides some stuff. Also it's visual clutter. If your history looks like train map, your project is probably a train wreck.
- jamesrom 13y agoI could just as easily say, if you are constantly using bisect on your master branch, then your project is probably a train wreck.
- dasil003 13y agoYes, you could say that if you wanted to set up a straw man that is shockingly close to "we don't need to use version control because our code never has problems".
- jlgreco 13y agoThere is no reason not to enjoy the benefits of modern version control just because some code you inherited is utter shit. On the other hand, being familiar with modern version control is a good idea, if only just in case you inherit code that will be shit. On the other other hand, regressions occur and go unnoticed even on the best of projects.
- barrkel 13y agoThis is an artificial problem. Git has almost all the data needed to present a squashed view - all it's missing is an idea of what commit a branch pointed to throughout history, so that it can merge together commits in in the "bubbles" for presentational purposes. It would be better to fix this, so you get nice diffs, blame etc., than deal with all the other issues rebase causes. I'm not convinced on the bisect issue either. If your app is trivial, sure, but if the features are more complex, the squashed commits will be too chunky to narrow down as usefully as a fuller history can.
- stevenashley 13y agoI'm not convinced on the bisect issue either. I've personally done a bisect spanning 10000 changesets with 50 concurrent branches at the widest point. Found the problem right away. We follow a similar branching model. Master is kept clean. We do all development on feature branches and merge when complete. History is fully preserved. History is a mess but it works well overall.
- callahad 13y agoRebasing feature branches isn't that bad -- it's similar to the workflow you might use when submitting patches to a mailing list or other patch queue: the patch floats on top of master and eventually gets applied. It's the rebase-and-fast-forward merge strategy that causes problems. :)
- untothebreach 13y agoWhen I am working on a feature branch, I often find myself committing experiments, that I possibly undo later in the branch. I don't always focus on making "incremental, atomic" commits, because I am usually focused on the code. When the feature is done (but before I merge it into master), I will usually go through and clean up my meanderings, and turn them into "incremental, atomic" commits, so that my teammates don't need to deal with my meanderings if they ever need to run a bisect over my code. You may say I'm doing it wrong, and that's fine, but it works for me.
- tootie 13y agoIf you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.
- crististm 13y agoAs long as your final commits are logical you don't lose anything. You need clean commits on the history to be able to understand the code later on. During code review at a later time, the history of the experimentation is useless once you find several commits that touch the same code before settling on a final version.
- tootie 13y ago> You need clean commits on the history to be able to understand the code later on. Really? That seems like an extraordinarily obtuse way to understand code. I would think comments directly the source files would be more useful. Commit history shows how they arrived at that result and that's what I would rather see there.
- MatmaRex 13y agoCommit messages I write are often several paragraphs long (and sometimes that's for a one-line change). Including all of the information in comments is not always viable.
- gutnor 13y agoNoise vs Information on a shared project ? Imagine we are both working on a project. I don't care to know that you merged 3 times from master yesterday before pushing your feature. Also I don't care to know details like you forgot to put a config file in your first commit and had to do a second one, or that it took you 3 commits to have the spelling alright in the UI. Mainly that information is useful to you. It is also mostly only usable efficiently by you ( I will read your whole feature, most likely I will not be able to rollback to the middle of your change ) For example I commit several time an hour - my coworkers would be pissed if I make 10 commits for each minor feature I develop.
- crististm 13y agoI silence the noise before merging on a public branch by squashing the "thinking commits" on my private branch. What remains is a clean history of commits. You will not find the oscillating commits on the public branch but you will find them on my private (local) branch. So you do commit early and often, just that nobody else sees your commits until the feature is complete and working. And then only after you rearranged and squashed your commits. From the outside it looks like you always commit top quality code from the first try. $ git rebase -i
- barrkel 13y agoCompany policy: you can't keep branches just private, locally, because they're not backed up. (That's just how it is at my company. PCs aren't backed up, central repos are.)
- lambda 13y agoHow do you enforce that with Git? Any time you create a branch, it's local until you push it. But anyhow, just give people private repos on the server. What I do is push my private WIP branches to my home directory on the server, and once it's ready for code review and merge, push it to the central repository.
- crististm 13y ago
- viraptor 13y agoI'm not sure I understand why you think rebase destroys those things. 1. You rollback exactly to the same point as you would without the rebase - one commit before the merge point. 2. This is also obvious - it was brought up to date one commit before the merge point (by definition of this workflow).
- crististm 13y agoRebasing on a public branch is a big no-no. But rebasing on your private branch helps you catch merge problems early on. Except for the "merge --no-ff" I'm using exactly this model and I think it is great. It can't get any more simple than that and still have a working master. Regarding the "straight line, clean" history, I've found that most people think that a straight line is "the" history to have. I have no idea what to tell them.
- crististm 13y agoO yes, one more thing: before merging back to master I squash the crap out of it's existence. It was invaluable once I've found out how to do it. I've learned about squashing here (the specific page is dead now): http://www.denx.de/wiki/U-Boot/CustodianGitTrees http://www.denx.de/wiki/U-Boot/CustodianGitTrees
- unfletch 13y agoThe dead link, archived: http://web.archive.org/web/20110822174840/http://www.andrewmoore.com/public/index.php/My_git_workflow http://web.archive.org/web/20110822174840/http://www.andrewm...
- tootie 13y agoIf it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?
- reledi 13y ago> rebasing on your private branch Which I assume means it's only you working on it. Not all topic branches have multiple committers.
- crististm 13y agoI don't think a feature branch implies collaboration. Even if more than one developer is involved, the model doesn't change: "master and feature" branches become "feature and developer-private-feature". The developer still relies on a (partial) working feature branch, and his contribution still has to be self-contained. But since you have more developers you will have an out of band sync communication between them.
- reconbot 13y agoPublic history and private history. Or maybe changes to production vs changes as you developed. I care more about the merge then the commits. (In github parlance, the Pull Request) This workflow turns commits throughout time into a single change against the master (while still preserving the commit history). Conceptually this is a lot easier for me to see what's changing, and to deal with issues. So I guess I disagree with point #1) In a continues delivery environment this workflow makes sense because the log accurately shows the history of the changes to the app in production instead of the development environments. (Merge, Merge, Merge) #2 doesn't make sense to me, if you rebase you're up to date with master as of the branching commit. Whatever works best for your team!
- nsfyn55 13y agoI don't understand why people think rebasing destroys history. It doesn't "destroy" anything. Have you ever had an argument that was just mediocre? But later you think of a witty retort that would have been just perfect. Thats what rebasing is. Its re-structuring the conversation the way you would have liked it to go.
- recursive 13y agoRe-structuring a conversation destroys the old bad conversation.
- jlgreco 13y agoExcept that conversation was actually a monologue which you haven't actually performed publicly yet. Rebasing private branches is like editing a speech before you give it: just common sense. If you restructured the "I Have a Dream" speech, you'd be hacking up history. If Martin Luther King Jr restructured the speech prior to August 28, 1963, as I am sure he did many times, history remains untarnished.
- felideon 13y ago#1 and #2 is exactly why you should rebase with --no-ff as the OP states. You get clean history plus a nice empty merge commit to refer to.
- jangel 13y agoMuch in the same way visiting a museum is much more useful for understanding the past than visiting your grandma's attic, I think a curated history is much more useful than an accurate history. When someone says a clean history, I think they're saying a well-curated history. You don't submit your first draft almost anywhere else, why do you think nailed it the first time writing your commits? Sometimes you don't get things right, and rebasing is one of the tools that helps you make sure that the written record of your work is helpful.
- sanderjd 13y agoWow! I love this analogy! Allow me to disagree with you inside the premise of your own analogy. Visiting a museum is a much more useful way to understand past world history, but visiting your grandma's attic is a much more useful way to understand the little twists and quirks of your own family. In much the same way, I think a curated history is very nice for open source projects with lots of committers and constant newcomers, while a history that preserves foibles can be more useful for smaller and tighter teams. It is often very enlightening to see the missteps that were taken on the road to the eventual solution to a problem.
- pfortuny 13y agoWell, that analogy is OK but there is another analogy which comes to mind: keeping track of everything you do may have very useful future side-effects. As any lab researcher will tell you, keeping a strict log of anything you do is the way to both knowledge and reproducibility. So git history is not necessarily "human history" but "engineering history" and as such, may be much more important than you think and "curating" it may be a mistake.
- nvarsj 13y agoIt's pretty simple... readability triumphs. It's a hell of a lot easier examining the history of a project if a feature is condensed into a single or a few easy to read commits. Your personal struggle to implement a feature is far less important than having a clear, readable history. This becomes super important when bisecting, reverting, generating release notes, and a myriad of other things.
- dreamdu5t 13y agoIt's pretty simple... You can maintain an accurate history of commits while using tags to have a clean list of features and/or releases. A clean history of features or releases does not require rebasing.
- e40 13y agoI don't understand why people don't realize there is a place for rebasing and a time for merging. untothebreach explains it well [1]. When you are working on changes which are not public yet, sometimes it's helpful to rebase them into a single or fewer number of commits. Period. No one is arguing to always use rebase and never use merge. [1] https://news.ycombinator.com/item?id=6456434 https://news.ycombinator.com/item?id=6456434
- dreamdu5t 13y agoYou can have both. Use tags for new features and releases, and that way you can have a clean history of featured added while maintaining an accurate commit history. This is what tags are for: Marking an important commit such as a feature or release.
- timmow 13y agoIf you want a completely accurate history I hope you have your editor set to commit after every character you type, in case you need to delete a typo. Ok, thats slightly tongue in cheek, but I think its a subtle balance between clean and accurate history, some people are happy to use rebase to, some are not. In my view, rebasing is no different to using undo in your editor, but I appreciate some people feel differently.