And finally, since github is open to anyone, note that pushing to github means collaboration whether you want it or not. So even if I don't plan to work with anyone on github, someone may be pulling off my github branch without me realizing it (like it more or less happened with me and Pat), and if I were pushing rebases to my branch, i'd screw his branch to no end. This may be incredibly frustrating (ask me how i know :)
On Fri, Jun 13, 2014 at 2:35 PM, Dmitriy Lyubimov <[email protected]> wrote: > Sure. there are exceptions. If i got exactly one commit and it has a > proper message, rebase would do. > > But let's look at pferrel/mahout MAHOUT-1464 PR. There are couple dozen of > working branch commits there. I'd say in such situation squash is a must > (even if they are rebased on top). > > Also keep in mind that rebase of a remote working branch will screw > collaboration (in case there's more than one person working on an issue via > github working branch). Since pushing rebases would imply rewriting remote > history (exactly the reason infra doesn't allow it in git-wip-us). So any > way you look at rebase benefits, it looks like there are increasingly rare > exceptions to admit it to happen in any remote repo and even consider its > worth beyond the boundaries of one's own git repo on local FS. > > > > > On Fri, Jun 13, 2014 at 2:27 PM, Ted Dunning <[email protected]> > wrote: > >> I would accept that argument except that there will be exceptions. >> >> Thus, I would phrase it as a strongly suggested guideline rather than a >> hard and fast rule. >> >> >> >> >> On Fri, Jun 13, 2014 at 11:20 AM, Dmitriy Lyubimov <[email protected]> >> wrote: >> >> > in fact, i'd argue we don't want more than 1 commit per issue -- unless >> > there's a reopening -- and definitely do not want more than 1 commit >> per PR >> > >> > >> > On Fri, Jun 13, 2014 at 11:18 AM, Dmitriy Lyubimov <[email protected]> >> > wrote: >> > >> > > >> > > >> > > >> > > On Fri, Jun 13, 2014 at 11:14 AM, Ted Dunning <[email protected]> >> > > wrote: >> > > >> > >> I think that rebasing cleanly would help at least as much as >> squashing. >> > >> Both are probably good. >> > >> >> > > >> > > Rebasing doesn't get rid of intermediate commits, it only gets rid of >> > > merges. which means you will be left with commits like below sitting >> in >> > > your history anyway as actual commits without clean attribution -- and >> > I'd >> > > argue we don't want that >> > > >> > > * | commit cc9a70ebbdaceb8d5c2fcecd1a8cd9bee67e323e >> > > |/ Author: pferrel <[email protected]> >> > > | Date: Sat Jun 7 13:36:12 2014 -0700 >> > > | >> > > | added .DS_Store to gitignore for pushes from mac >> > > | >> > > >> > > >> > > >> > > >> > >> > >
