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

> 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.

Reply via email to