On Fri, 20 Dec 2013 04:58:03 -0800 (PST)
Gabriel Angeli <rockfl...@gmail.com> wrote:
> I have a problem with case changes made automatically by the VB6 IDE:
> It changes all the names of my variables (intellisense), sometimes
> from lower to upper-case, sometimes from upper to lower. My team uses
> the Stash and the SmartGIT tools, so before we Commit/PUSH the
> changes, we need always to remember to correct these changes made on
> the case, keeping only the "real" change made.
> The SmartGit has an option to ignore case changes, so it is easy to
> see exactly the point modified by the programmer. But the Stash does
> not, so when we compare the changes made, all the code is highlighted
> ("diffs"), it is why we need to correct the changes before
> We have a particularity that makes necessary to us to use the
> Stash... and this (annoying) bug on the VB6 IDE is taking too much
> time from my team.
> Anyone knows if exists a parameter to set on the GIT to ignore these
> case changes, and how can I do it?
For Git to ignore the case changes in your identifiers, it would
require it to be aware of the format of files it manages, that is it
basically would need to be able to parse VB6. Having skimmed throught
the `git-config` manual page for an option starting with "diff." prefix
which would tell Git to ignore any changes involving only case mapping
(a pretty weird would-be setting, I should admit), I came empty handed
so you seem to be out of lack on this front.
On the other hand, I can think of two possibilities to explore.
First, Git supports custom merge tools, and those might be configured
to run the so-called "text conversion" on the blobs to compare before
actually comparing them -- look for the diff.<driver>.textconv
configuration option. So I fancy you could setup a merge driver which
would case-normalize the blob before attempting to generate the diff.
Second, Git supports filtering blobs before checking them out of the
object database to the work tree and before putting them into the
object database from the work tree. See the gitattributes(5) manual
page for more info -- look for the "filter" word. I'm not sure this
machinery is involved when producing diffs but it worth trying IMO.
Having said that, I still want to point out that in my opinion your
workflow if broken and you're trying to work around this issue rather
than fix it. The problem is that these case changes are nevertheless
committed, and they are the noise, bogus changes. What about adopting
a policy on writing identifiers matching that used by intellisense and
just fix any code not following it before it's committed? That would
produce sensible commits and obviate the need for inventing mechanisms
to make diffing machinery ignore case mapping changes.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.