21.0.2.0: Help with git debugging

[Marcel]

I am trying to track down a git problem (missing log history for moved files) and wanted to enable logging to see what commands are being issued.  I set

def_debug_logging=1
def_git_debug=1

but didn't see a log file (.../logs directory) being generated. What am I missing?

Thanks

[Dan]

For this one it's "def_svc_debugging".  Set that to 1 and you should get a svc.log.

What problem are you having?

[Marcel]

When files get moved in the repository (e.g. Java refactoring), SE loses the commit history, it only shows the commit that did the move. From the command line, you can get the entire history with 'git log --follow <filename>', so SE should do the same. I tried to patch git.e to do just that but didn't have any success. The debug log will show me if I botched the macro update.

[Marcel]

@dan: Unfortunately, the GitGetHistoryInfo() function that needs fixing is in the filewatcher.dll and patching it is a bit too messy for me.
Could you add the --follow argument to its git log calls for the next point release?

Thanks,
Marcel

[Dan]

If we do one, yes.  What platform are you on?

The question is whether to add an option for it.  On Subversion we've always used --stop-on-copy (so you just see the current branch, and it won't traverse back to the trunk).  I have a user who wants that shut off, but it has been that way long enough I need to be optional.

[Marcel]

Both Windows and Linux, with a somewhat higher priority to Windows.
A configuration option or a def...-style macro variable would be fine.  The change will only impact the log history, however I can't imagine someone preferring to see the truncated change history for a file vs the complete one.

Marcel

[Dan]

Well, there's goods and bads.  Occasionally, I'm on a branch and I want to see past where the branch was created... but on the other hand we have files that date back... let's just say a long time   And to wait for the history to go all the way back when what you want to see is actually on that branch can be a pain.

[Marcel]

When you rename a file in git, the commit history does not follow the file to its new path.  I am currently working on a project where the repo structure needed to be changed to conform to [gradle] build tool standards, something like this:

project/src/com/acme/something
project/src/main/java/com/acme/something

This moved a large number of files (git mv oldfile newfile) to a new path, leaving their commit history behind (all of it).  The git folks added the --follow option for exactly that case (Linus' objections not withstanding).  Most of the git graphical UI's have an option like "follow renames" to use the option when pulling the history for an individual file. 
I am heavily reliant on seeing at least the last dozen or so commits. I can fire up SmartGit or use the command line to get the history, but I'd rather stay in SE and avoid the detour. 

Marcel

[Dan]

Bit of a problem here... We use the --reverse option.  It may just be for convenience, I'll have to check.

But, when you use --follow with --reverse, you only get the first entry.  I'll have to see how much work it is to stop using --reverse.

[Dan]

I added this into 21.0.3.  You have to turn it on - I think it makes the history look a little weird, but it looks the same as the command line output, so it is correct.

[Marcel]

This is great news!  Thanks for your help.

[Marcel]

Thanks for adding the history "follow" option in 21.0.3.0, it is a big time saver for me. 
A little wrinkle, though:  The diff operation doesn't work for renamed files, i.e. accessing commits under the original filename is not supported (For motivation, Tortoise can do it).  Any chance you could look into it?

Thanks,
Marcel

[Dan]

This is if you're in the history dialog and click the Diff button, but go back far enough the name has changed?

[Marcel]

Correct, if you go prior to the point where the file was renamed.

[Dan]

I will look into it.  I have to push through what I'm working on right now first, so it will be a bit.  Hopefully it is hotfixable.