On Wed, 16 Oct 2019, 05:17 Johan Ouwerkerk, <jm.ouwerk...@gmail.com> wrote:
> On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer <schwar...@kde.org> > wrote: > > Now I will fix my latest revision and merge to master. Still: 19 commits > > are not compiling anymore. > > > > Or am I missing something here? > > > > How would we deal with that? Is "short-lived branches" (as you stated > > below) enough to reduce the risk? > > > > To answer in reverse order: > > Yes. On the one hand short-lived branches reduce this risk > considerably: this scenario applies to breaking changes in master > which fundamentally alter the way the application works. It's like a > core library upgrade or, in this case, a major UX rewrite: something > fairly fundamental to the application changes in master. It is > unlikely that this should happen overnight without any kind of prior > review. > > Still, this can and does happen and will happen some day to you if you > contribute enough :) However this gets back at the git rebase bit. > > So yes, you rebase your feature on master as per normal, fix transient > merge conflicts and then what? Well, then you still have to compile & > test. At which point you notice breakage. How do you recover? As you > would: you begin the porting effort, either changes from master to > your new feature way of doing things (in case *you* are the one doing > the UX rewrite/major refactoring), or vice versa you apply the new > world order from master to your feature. > > What I like to do during this process is to avoid committing these > fixes just yet. I want to get a feel for the total diff, in particular > the total git diff --stat that I accumulate. Then I can identify on a > file-by-file basis using something like git log -3 path/to/file or so > what the likely commit is which should have been amended. Sometimes > you notice the diff for a file should be spread over multiple commits > according to your prior log, so what you do next is you use git add > like this: git add -p path/to/file. You only select the bits for which > you have identified a particular commit, you commit those added hunks > and here I like to leave a note in the first line of the commit to the > effect of "fixup <hash>" or "squash <hash>" or "<delete hash>". > > In this way you build up a bunch of commits which cover your fixes. > Next up, you turn to git rebase again, using e.g. git rebase -i > master. Now you can interactively fold the commits into the history as > "it ought to be" and this is where I use my notes to help me decide > how to proceed. Note you don't have to get everything just right, and > note that this rebasing itself may introduce transient merge conflicts > you need to fix: so if the diff stat was large it makes sense to split > this up into multiple git rebase -i runs just to give yourself a break > in between. Finally perhaps you rebase again to touch up a few commit > messages or something, and if this whole process took considerable > amount of time you want to verify that upstream master has not yet > moved on by that point. > > So in this more complex case you can adopt a correspondingly more > complex git workflow and use rebase to produce clean commits. Now, > sometimes you decide this is all too much work, and too much bother. > What you can do in such a scenario instead is to create a fresh new > branch from master and effectively re-create commits there. In those > cases git cherry-pick and git checkout -p <branch> -- path/to/file > come in handy > > Ultimately whether or not a scrupulously clean commit log is worth the > effort or whether you might decide to simplify things a little and > accept a few broken commits in between mostly depends on the needs of > your project and how many people work on it. > It was complexity of that degree that I was primarily concerned about when people started pushing for being able to force push and use a rebase workflow. For a first time contributor or anyone who isn't familiar with working with Git rebase, that sort of workflow is incredibly daunting, downright scary and is likely to push them in the direction of simply not contributing at all. As I'm sure we can all agree, that isn't something we want at all - we want it to be easy and straight forward to get involved for everyone. In cases such as the one you have above, I think a simple merge commit would be completely fine in that instance, especially given it is an uncommon event. > Regards, > > -Johan > Cheers, Ben >
