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 <[email protected]> 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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
