search

rubicon-oss / LicenseHeaderManager

Manage license headers for your source code files in Visual Studio
179 stars 41 forks source link

Ability to preserve existing header dates #185

Open FF-Brown opened 10 months ago

FF-Brown commented 10 months ago

After reading through the documentation, I'm still not sure whether it's possible to do what I'm hoping for. I've got existing headers on some files which may include either a year (2020) or a range of years (2015,2021). In these cases I'd like to preserve the starting date and add the current year to make a range (2015,2023). Any idea if this is possible with this extension?

MichaelKetting commented 10 months ago

Hi @FF-Brown, thanks for the question!

No, this is not possible directly. You can use expressions (https://github.com/rubicon-oss/LicenseHeaderManager/wiki/Expendable-Properties) to insert the creation year and last modification year, which may be what you are looking for.

FF-Brown commented 10 months ago

@MichaelKetting Thanks for the response! That expression looks promising. Do you know where it gets the creation year from? Because if it's from the file system, the creation year would just be the year I cloned the repo rather than when the file was actually created.

MichaelKetting commented 10 months ago

@FF-Brown ah, yes, you're correct about that. We're using the file system information and git does not update the properties based on the history.

FF-Brown commented 10 months ago

If this is a change that might be considered, we could update the existing %CreationYear% or add a new %GitAddYear% (and month, day, etc). Something like git log --diff-filter=A --reverse --date=format:'%Y' --format="%ad" -- <file_path> | grep -m 1 "" (putting the whole command here mostly for my own benefit, so I don't forget)

MichaelKetting commented 10 months ago

@FF-Brown Yes, contributions are welcome (https://github.com/rubicon-oss/LicenseHeaderManager/wiki/Pull-Requests)

I believe new properties make the most sense (symmetric with the Creation properties), though we would need to fallback to the file's creation date if the file has not been added to Git which is true for any file that gets the license header during file creation. For performance reasons, we should only read the git log if the property is actually evaluated for a specific file. I haven't looked into how to best design this.

I also recommend doing only the git log part and grepping and date-parsing inside of c#, e.g. via a regex and DateTime.Parse.