On Mon, May 30, 2016 at 5:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Robert Dailey <rcdailey.lists@xxxxxxxxx> writes: > >> I like your solution better than mine because it utilizes the rules >> defined in .gitattributes. > > A difference that may be more important is that I do not do > generation of a patch or application of it without ignoring > whitespaces with things like -w and --ignore-whitespace. That way, > if my edit is a correction of existing whitespace breakage (e.g. I > noticed a line that is indented by 8 spaces, and I corrected it by > replacing them with one tab), that is shown as a change by "diff" > and kept in the result. I suspect that your "diff -w | apply --ignore" > will ignore that manual fix? > >> What does the checkout at the end do? That part confuses me (granted >> I'm not well-versed with bash script). > > I correct whitespace-broken updates the user (i.e. I) made in her > working tree file by adding a corrected version to the index, and > then I checkout the result out of the index to the working tree. > > That corrects the breakage in both the index and the working tree, > so that my further edit to the file will start from a ws-corrected > version. Ah, I think I get it now. I was confused, you and I are apparently trying to accomplish two different things. My alias stages changes EXCEPT whitespace fixes. In this case, I've already made the whitespace corrections (by hand) in the working tree. I want to stage the changes EXCEPT whitespace. This will allow me to do 1 commit without whitespace, and another with just the whitespace. So yes, my patch is deliberately ignoring whitespace because I do not want it in the index for the first commit. Yours seems to take exactly what is in the working tree and make further modifications to it as it is added to the index. That is, to correct whitespace errors as defined by the gitattributes file. When I tested your alias, all changes in my working tree were added to the index, where I expected the index to contain everything except whitespace modifications. But honestly your solution is a little better, even if it requires me to change my process, because: - You don't depend on external tooling to correct whitespace - Splitting whitespace & real changes to two commits is probably superfluous; my original goal was to make diffing the actual changes easier, but since 'git diff -w' exists this is moot. So I guess it's not bad practice to mix whitespace changes in with real diffs, given the flexibility of Git (in previous VCS such as Git and perforce I didn't do it this way). I have a similar habitual carry-over from SVN where I do file moves/renames in separate commits before I modify file contents. Again with Git, probably not as necessary to do this. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html