Peter Law
2016-09-09 19:13:34 UTC
Hi,
We need to evaluate whether the principle of rebasing branches into
the website repo is something desired under github's model.
For reference: under Gerrit we had the options of (at least) merging
the branch with an ordinary merge, or rebasing the commits from a
branch into master. We had chosen the latter in order to try to keep
the history linear, while accepting the trade-off that the commit Ids
didn't match the branches (though all the commits were individually
replayed).
As we've recently moved to a new website repo I figured I should
probably get a local setup of it running. In doing so I raised a PR
which aimed to improve the README based on my experience and to better
enable others.
Happily this was accepted and closed fairly quickly. The process that
far was remarkably easy [1]. However now that those commits are
accepted in master it was time to close of the branches in my local
clone.
On grabbing the latest chances from the upstream I was surprised that
I was only a couple of commits behind (my branch had 6). Having
(fast-forwards) merged them I was then further confused when I ran:
$ git branch --merged
Which I expected to print out my branch, but didn't. I also tried
running the script I've been using with gerrit which essentially
re-implements `git branch --merged`, but is based on the Change-Id
lines gerrit uses [2]. That also found no results.
I then had a look at the logs of all the branches and was rather
surprised at the result:
$ git show-ref --heads | xargs git log --graph --oneline --decorate
* 7f208b1 (HEAD -> master, <snip>) Fixed kickstart date
* 3fe0ddd Added anchor to competitor FAQ
* 40bd3ea Improve readme (#23)
| * bb949b9 (PeterJCLaw/improve-readme, improve-readme) Exclude the
gems folder from being built
| * dbe1235 Fix list
| * 43b3e00 More details on how to get going
| * 235cb68 Whitespace
| * bd3a8e3 Collapse command to save duplicate typing
| * 5246eac Whitespace
|/
* 15c8830 Add a placeholder event for SR2017 Kickstart (#21)
* b296318 Fix styling on article pages
It looks like the history is being squashed at some point. While the
log message from the 40bd3ea commit does include those from the
branch, it doesn't contain any references to what that branch was.
There is no mention of the original commit ids or branch name, only an
unlabelled reference to the number of the pull request.
I suspect that this is a result of an option in github which controls
how branches are merged, though I'm not sure. Whatever is causing it,
I am glad this has been found on a fairly innocuous branch where the
individual commit history is less important.
Personally I would rather have a history with branches and merges than
this squashed and barely traceable history. That it leaves out any
good way of automatically tracking the squash back to its commits is a
significant blocker to ease of use for developing with feature
branches.
@Jimmy: is this behaviour something you'd expected here? If so, can we
turn it off please?
Thoughts?
Thanks,
Peter
[1] As someone familiar with github and who has it in their general
workflows anyway. I obviously can't provide an objective measure for a
new person.
[2] I can make this available if it would be useful, though I've only
found it useful on gerrit-based workflows.
We need to evaluate whether the principle of rebasing branches into
the website repo is something desired under github's model.
For reference: under Gerrit we had the options of (at least) merging
the branch with an ordinary merge, or rebasing the commits from a
branch into master. We had chosen the latter in order to try to keep
the history linear, while accepting the trade-off that the commit Ids
didn't match the branches (though all the commits were individually
replayed).
As we've recently moved to a new website repo I figured I should
probably get a local setup of it running. In doing so I raised a PR
which aimed to improve the README based on my experience and to better
enable others.
Happily this was accepted and closed fairly quickly. The process that
far was remarkably easy [1]. However now that those commits are
accepted in master it was time to close of the branches in my local
clone.
On grabbing the latest chances from the upstream I was surprised that
I was only a couple of commits behind (my branch had 6). Having
(fast-forwards) merged them I was then further confused when I ran:
$ git branch --merged
Which I expected to print out my branch, but didn't. I also tried
running the script I've been using with gerrit which essentially
re-implements `git branch --merged`, but is based on the Change-Id
lines gerrit uses [2]. That also found no results.
I then had a look at the logs of all the branches and was rather
surprised at the result:
$ git show-ref --heads | xargs git log --graph --oneline --decorate
* 7f208b1 (HEAD -> master, <snip>) Fixed kickstart date
* 3fe0ddd Added anchor to competitor FAQ
* 40bd3ea Improve readme (#23)
| * bb949b9 (PeterJCLaw/improve-readme, improve-readme) Exclude the
gems folder from being built
| * dbe1235 Fix list
| * 43b3e00 More details on how to get going
| * 235cb68 Whitespace
| * bd3a8e3 Collapse command to save duplicate typing
| * 5246eac Whitespace
|/
* 15c8830 Add a placeholder event for SR2017 Kickstart (#21)
* b296318 Fix styling on article pages
It looks like the history is being squashed at some point. While the
log message from the 40bd3ea commit does include those from the
branch, it doesn't contain any references to what that branch was.
There is no mention of the original commit ids or branch name, only an
unlabelled reference to the number of the pull request.
I suspect that this is a result of an option in github which controls
how branches are merged, though I'm not sure. Whatever is causing it,
I am glad this has been found on a fairly innocuous branch where the
individual commit history is less important.
Personally I would rather have a history with branches and merges than
this squashed and barely traceable history. That it leaves out any
good way of automatically tracking the squash back to its commits is a
significant blocker to ease of use for developing with feature
branches.
@Jimmy: is this behaviour something you'd expected here? If so, can we
turn it off please?
Thoughts?
Thanks,
Peter
[1] As someone familiar with github and who has it in their general
workflows anyway. I obviously can't provide an objective measure for a
new person.
[2] I can make this available if it would be useful, though I've only
found it useful on gerrit-based workflows.
--
You received this message because you are subscribed to the Google Groups "Student Robotics Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to srobo-devel+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Student Robotics Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to srobo-devel+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.