Short version:
Is there a way to check-in a change to a git repository but "hide" the changeset metadata from general consumption (preserves the prior changeset in the blame, etc.)?
Long version:
I've recently inherited a codebase which, from the looks of it, had an initial team lead who encouraged each of his developers -- as an exercise in spiritual growth -- to forage out into the world and find a formatting style with which they felt most zen-like... really find their various artistic styles, apply them to code formatting, and live the life of an artist as you paint masterpieces of code every day.
Patterns emerged such as random selection of the number of newlines between statements, wrapping every method argument -- declarations and calls... It goes on and on, but basically, I want to set up my formatting preferences in the IDE, turn it loose for a few hours, clean up the places by which it was confused, and commit it. I'm getting some (valid) pushback from the team about losing all of the history in the easily visible "last one touched it" slot that shows up in annotations and such.
Is there any way to make a change that doesn't blow those away? I was also thinking there might be a branching trick out there that could do something like branch, format in the branch, reintegrate the other branch into that one, somehow making my "secret commit" up-rev of the latest that would retain the old ones.
Anyone have any suggestions? I'm perfectly willing to entertain hacks for this one-off. :)
Short: No.
Long: To migrate toward a consistent style, encourage your fellow developers to modify code so that it conforms to your common style when they work on it. That way, the blame attribution stays consistent for the code that has not been changed. For code that is modified, the blame attribution then migrates to the developer who last touched it. You can do this on a more granular basis, such as cleaning up formatting per-function, if you like.
What you're asking for here violates the "spirit" of Git (for lack of a better term).
Git takes its history very seriously. It was a design goal of the system that once published, commits couldn't be changed without anyone noticing. You can see the effects of that design decision in how Git operates. For example, commit messages can't be easily modified, and are virtually impossible to change once pushed.
In other words, silently or covertly committing things to your Git repository won't work.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With