On Thu, 2013-05-30 at 22:29 -0700, PJ Weisberg wrote: > On May 30, 2013 6:32 PM, "Paul Smith" <p...@mad-scientist.net> > > However, I've already pushed my branch to master. I know rebasing stuff > > you've already pushed is considered a no-no in general, but I can't > > avoid it. Does anyone have suggestions for how to make this work > > better? Should I be rebasing to a brand new branch, then merge that to > > master? Just rebase directly to master? None of the above? Something > > else entirely? > > I don't understand why you don't do all this cleanup *before* you > merge into master.
I DO want to do the cleanup before merging to master. If you mean do the cleanup before pushing to the git repo, I can't do it all because it's not until after I push that I can detect build issues on platforms I don't have access to, get feedback in a code review, etc. Sometimes it's useful to keep these changes as separate commits, but often it's not. > There's no problem with rebasing published history per se, only with > rebasing history that someone else might have pulled into their own > history. You can rebase to your heart's content as long as you're on > your own branch, even of it does have to live on a remote server. Certainly others will have pulled the branch: it's in the master repo after all. I guess it's unlikely they'll have checked out my dev branch though, typically. Also, it's not quite so simple: our server has gitolite installed and "push -f" to force move a branch has been disabled. I guess I can do it in two steps: first delete the branch then add it again. Lastly, I've played with rebase -i. It's powerful, but not quite what I was hoping for. I wonder if anyone has any pointers for something like: You start a "rebase --diff" (or whatever) operation. It shows each diff that is part of the branch, and allows you to assign that diff (or just an individual chunk of the diff) to a particular commit, or delete the diff or chunk. It walks through each chunk of each diff like this. At the end any commit with no chunks assigned will be deleted, and the branch will be rebased using the remaining commits. Comment editing, etc. would need to be possible. Since you're actually just looking at chunks in the diff between the first commit and last commit, and not any intermediate commits, I don't think it's possible to get a conflict (although you obviously could get intermediate commits which don't build, if you're not careful, making "git bisect" somewhat tricky). For some kinds of commits, where there are ordered incremental (overlapping) changes that you wanted to preserve this wouldn't work. But if you have a set of non-overlapping changes to different areas needed to make a change or set of changes, it might be a good way to handle rebase. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
