Patrick Lauer: > On Sunday 14 September 2014 15:42:15 hasufell wrote: >> Patrick Lauer: >>>> Are we going to disallow merge commits and ask devs to rebase local >>>> changes in order to keep the history "clean"? >>> >>> Is that going to be sane with our commit frequency? >> >> You have to merge or rebase anyway in case of a push conflict, so the >> only difference is the method and the effect on the history. >> >> Currently... CVS allows you to run repoman on an outdated tree and push >> broken ebuilds with repoman being happy. Git will not allow this. > > iow, git doesn't allow people to work on more than one item at a time? >
Completely the opposite. You can work on 400 packages, accumulate the changes, commit them and push them in one blow instead of writing fragile scripts or Makefiles that do >400 pushes, fail at some point in the middle because of a conflict and then try to figure out what you already pushed and what not. > That'd mean I need half a dozen checkouts just to emulate cvs, which somehow > doesn't make much sense to me ... > checkouts? You probably mean that you have to rebase your changes in case someone pushed before you. That makes perfect sense, because the ebuild you just wrote might be broken by now, because someone changed profiles/. We are talking about a one-liner in the shell that will work in the majority of the cases. If it doesn't work (as in: merge conflict), then that means there is something REALLY wrong and 2 people are working uncoordinated on the same file at a time.
