FWIW, I pretty much never rebase in my usual development workflow. I'm surprised to hear it became a norm somehow.
On Thu, Jun 5, 2014 at 2:06 PM, roger peppe <rogpe...@gmail.com> wrote: > I'd love to ditch rebasing if it was reasonable to do so. > It just adds overhead to an already tiresome procedure. > > > On 5 June 2014 16:22, Nate Finch <nate.fi...@canonical.com> wrote: >> I am far from a git expert, but it sounds like we can get a bzr-like >> overview of merges to trunk if we give git the right command. This is from >> the canonical-tech discussion: >> >>> (from Dimitri John Ledkov) >>> On Thu, Jun 5, 2014 at 2:26 PM, Ian Booth <ian.bo...@canonical.com> wrote: >>> > >>> > > (from Nate Finch) >>> > > As for bzr versus git, I honestly don't see much of a difference. I >>> > > know >>> > > there are things that bzr does better than git, but they're not >>> > > features I >>> > > really ever used, so I don't miss them. >>> > > >>> > >>> > What about all the complications, hassle, and extra overhead with the >>> > need to >>> > rebase all the time due to git's logging model? There's just no need for >>> > that in >>> > bzr so the workflow is *much* simpler [0]. >>> bzr defaults to showing just the first parent only, but you can see >>> all the glory details with "$ bzr log -n 0". >>> git defaults to glory details, but you can get equivalent to bzr >>> default view as well, e.g. compare output of: >>> $ git log --oneline --graph --decorate >>> with >>> $ git log --oneline --graph --decorate --first-parent >>> If one consistently merges in, individual branches only, git will >>> generate the same graph history as bzr and will be able to present it >>> the same way bzr would. >> >> >> This sounds like it might solve some of the problems we're worrying about >> that get caused by rebasing, such as losing comments etc. >> >> It sounds like this might be a usable workflow: >> >> commit several times to your feature branch. >> rebase into a single commit >> submit pull request >> comment on pull request & commit patches to pull request >> merge pull request as-is (with extra commits after submit) >> >> >> This mashes all your pre-PR commits into one, so hides some commit spam that >> way, but then keeps the post-PR commits, to preserve comments. It sounds >> like we can still get a list of just the merges from git, to exclude all the >> commits during code review. >> >> This sounds like the best of both worlds (or as close as we can get) and >> removes one more step (rebasing after code review changes), which seems like >> a good thing. >> >> Thoughts? >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
