[L2Ork-dev] git rebase

Albert Graef aggraef at gmail.com
Tue Jul 7 15:36:04 EDT 2020


By the magic of "Markdown Here", here's the same properly formatted from
the original comment written in Markdown (and with typos fixed by the magic
of google mail ;-):

At some point I’d like you to show me how to do this.

Well, it’s not that hard, git rebase A just replays your commits on the
currently checked out branch (say, B) on top of A, starting from the point
where A and B diverge. The end result is the same as with git merge A (and
you’ll have to fix pretty much the same conflicts if both branches modify
the same file in different ways), only that you now have all the commits of
B positioned neatly *after* the commits of A, instead of being a jumbled
mess. The price you pay is that you’re rewriting history on B, so you’ll
have to use git push -f (force push) to get your branch updated on the
remote. At which point other people having checked out your B branch and
working on it may get angry at you. ;-) But that’s expected with the kind
of temporary branches you create for doing merge requests, where you
usually rebase just once directly before your branch is merged. If it’s a
bigger, more permanent branch with many people working on it, however, then
it’s probably better to use git merge like on the master branch, and you
can actually protect a branch to enforce that policy (at least I can do
that on Github and Bitbucket, I think that it’s possible on Gitlab as well).

In practice this means that, instead of, say, running git merge master on
your feature branch, you’d be running git rebase master instead, and fixing
any conflicts. At which point your feature branch should neatly merge into
the master branch, basically it’s just a fast-forward now. So you either
directly merge into master yourself (if you’re Jonathan and can push to
master), or force-push your feature branch (git push -f) to your remote
branch, prepare a merge request for it, and wait for Jonathan to come
along. If your feature branch has to wait a wee bit longer than expected,
and other stuff goes into master in the meantime, then you just redo the
rebase and force-push once again, to have the branch and merge request
updated accordingly.

The web interface has an option for this too, I believe. But I strongly
prefer to do all this kind of stuff in my local clone where I can quickly
and easily create backup branches, test things out and inspect the results,
and just redo everything from scratch if things go awry.

I got stuck in a weird rebase state that consequently caused me to lose
some data in the working directory of a completely different branch.

Yeah, if you completely mess up and suspect that your branches are in an
inconsistent state, then it’s often easier to check out a completely fresh
clone and just start over. It’s been a while that I had to do this, though,
so either git, or I, or we both got better. ;-)

On Tue, Jul 7, 2020 at 9:26 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> Moving Albert's response to my question about git rebase here on the list:
>
> Albert wrote:
> > Thanks!
>
> >> At some point I'd like you to show me how to do this.
>
> > Well, it's not that hard, git rebase A just replays your commits on the
> currently checked out branch (say, B) on top of A, starting from the point
> where A and B diverge. The end result is the same as with git merge A (and
> you'll have to fix pretty much the same conflicts if both branches modify
> the same file in different ways), only that you now have all the commits of
> B positioned neatly after the commits of A, instead of being a jumbled
> mess. The price you pay is that you're rewriting history on B, so you'll
> have to use git push -f (force push) to get your branch updated on the
> remote. At which point other people having checked out your B branch and
> working on it may get angry at you. ;-) But that's expected with the kind
> of temporary branches you create for doing merge requests, where you
> usually rebase just once directly before your branch gets merged. If it's a
> bigger, more permanent branch with many people working on it, however, then
> it's probably better to use git merge like on the master branch, and you
> can actually protect a branch to enforce that policy (at least I can do
> that on Github and Bitbucket, I think that it's possible on Gitlab as well).
>
> > In practice this means that, instead of, say, running git merge master
> on your feature branch, you'd be running git rebase master instead, and fix
> any conflicts. At which point your feature branch should neatly merge into
> the master branch, basically it's just a fast-forward now. So you either
> directly merge into master yourself (if you're Jonathan and can push to
> master), or force-push your feature branch (git push -f) to your remote
> branch, prepare a merge request for it, and wait for Jonathan to come
> along. If your feature branch has to wait a wee bit longer than expected,
> and other stuff goes into master in the meantime, then you just redo the
> rebase and force-push once again, to have the branch and merge request
> updated accordingly.
>
> > The web interface has an option for this too, I believe. But I strongly
> prefer to do all this kind of stuff in my local clone where I can quickly
> and easily create backup branches, test things out and inspect the results,
> and just redo everything from scratch if things go awry.
>
> >> I got stuck in a weird rebase state that consequently caused me to lose
> some data in the working directory of a completely different branch.
>
> > Yeah, if you completely mess up and suspect that your branches are in an
> inconsistent state, then it's often easier to check out a completely fresh
> clone and just start over. It's been a while that I had to do this, though,
> so either git, or I, or we both got better. ;-)
>
> The problem I ran into is that an error about a botched rebase on a
> throwaway branch followed me around when I checked out a completely
> unrelated branch. Since I had already made some changes to files on
> the new branch before staging them, apparently the only "right"
> solution after that was to copy all my changed files to a directory
> outside of the repo, abort the rebase from the other branch, then
> paste everything back. Then I'd be doing ad hoc version-control to
> avoid losing data in a version-control system, which should never have
> to happen.
>
> -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200707/95ef570c/attachment-0001.html>


More information about the L2Ork-dev mailing list