Open Stack

On Tue, 2012-09-11 at 10:22 -0500, Monty Taylor wrote:
> 
> On 09/11/2012 09:56 AM, Mark McLoughlin wrote:
> > On Tue, 2012-09-11 at 14:43 +0000, Jeremy Stanley wrote:
> >> On 2012-09-11 12:15:37 +0000 (+0000), Jeremy Stanley wrote:
> >>> It appears that git-patch-id is fairly inflexible in this regard,
> >>> taking no options to alter its whitespace-ignoring behaviors. It's
> >>> doing something akin to diff's -w whereas the behavior we'd want is
> >>> more likely along the lines of -BEb instead... or maybe even none at
> >>> all, since this also has implications for work which could in fact
> >>> be whitespace-only (PEP 8 conformance fixes, for example).
> >> [...]
> >>
> >> Based on a quick IRC discussion on -infra it sounds like the next
> >> step would be to implement a new CLI option in git-patch-id, causing
> >> it to consider all whitespace changes substantive (and then see if
> >> we can get this feature merged upstream in Git as well).
> > 
> > Sounds difficult.
> > 
> > Any thoughts on the point about rebase-detection not being so important
> > now that git-review no longer rebases gratuitously?
> 
> I think the two are orthogonal - I don't think the auto-rebase was the
> cause of all of our rebases. If we can get this to not ignore
> whitespace, I think it'll still be quite helpful in the cases where it
> matches.

For the record, rebase detection is proving useful where there are
multiple patches in a series and you need to fix one of the earlier
patches

i.e. you rebase, fix an earlier patch, re-upload and any +1/+2s you
received on later patches aren't lost

Is there a bug to track the whitespace ignoring issue?

Cheers,
Mark.