Author Topic: 21.0.2.0: Help with git debugging  (Read 377 times)

Marcel

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
21.0.2.0: Help with git debugging
« on: March 29, 2017, 03:59:41 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1794
  • Hero Points: 70
Re: 21.0.2.0: Help with git debugging
« Reply #1 on: March 29, 2017, 04:03:43 pm »
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

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
Re: 21.0.2.0: Help with git debugging
« Reply #2 on: March 29, 2017, 04:29:20 pm »
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

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
Re: 21.0.2.0: Help with git debugging
« Reply #3 on: March 30, 2017, 02:20:57 pm »
@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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1794
  • Hero Points: 70
Re: 21.0.2.0: Help with git debugging
« Reply #4 on: March 30, 2017, 09:06:35 pm »
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

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
Re: 21.0.2.0: Help with git debugging
« Reply #5 on: March 30, 2017, 09:48:45 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1794
  • Hero Points: 70
Re: 21.0.2.0: Help with git debugging
« Reply #6 on: March 30, 2017, 09:52:12 pm »
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

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
Re: 21.0.2.0: Help with git debugging
« Reply #7 on: March 31, 2017, 12:33:43 am »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1794
  • Hero Points: 70
Re: 21.0.2.0: Help with git debugging
« Reply #8 on: March 31, 2017, 08:35:26 pm »
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

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1794
  • Hero Points: 70
Re: 21.0.2.0: Help with git debugging
« Reply #9 on: April 10, 2017, 07:40:19 pm »
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

  • Senior Community Member
  • Posts: 132
  • Hero Points: 8
Re: 21.0.2.0: Help with git debugging
« Reply #10 on: April 11, 2017, 02:09:48 pm »
This is great news!  Thanks for your help.