search

MestreLion / git-tools

Assorted git tools, including git-restore-mtime
GNU General Public License v3.0
295 stars 74 forks source link

git-restore-mtime: add flag to allow using commit time #19

Closed dwfreed closed 8 years ago

dwfreed commented 8 years ago

This allows using commit time for mtimes, which is often more monotonically increasing.

MestreLion commented 8 years ago

Thanks for the contribution!

I often find commit time not to be very useful, as operations such rebase change them (cherry-pick too IIRC), while the author time is usually "preserved" in such operations, so author time tends to reflect the "original" file mtime more closely.

But this is subjective, and should be left for the user's discretion, so such a flag is very welcome, thanks!

MestreLion commented 8 years ago

I believe this also warrants a change in the manpages, no?

If so, care to check PR #18 and perhaps incorporate his changes/improvements so we can have unified set of manpages to include here?

dwfreed commented 8 years ago

We'll be using it in Gentoo to provide a more monotonically increasing mtime for files checked out from git, as we use newest mtime to optimize some processes. Author time can go backwards easily, which is bad, but in a distributed development environment, commit time will almost always increase for every commit (biggest exception is developers not having properly synced clocks, but that has only happened a few times).

MestreLion commented 8 years ago

Oh, I see. That's a different use-case then, I guess.

MestreLion commented 8 years ago

Hum, maybe you have a very good point there: a 2010 commit in a feature branch that was rebased/cherry-picked to master in 2015 will, by default, have a 2010 timestamp even if changed a, say, 2013 file. And this is not desirable even in my use-case. So the "integration" date should take priority.

For merges (I believe the most common form of "integration") this can be mitigated by using --merge, but now I wonder if your --commit-time should be the default. (and change the flag to -a|--author-time, or perhaps -a|--use-author-time)

dwfreed commented 8 years ago

For most use cases, whether the mtime is author or commit doesn't really matter. We use --merge, but development is often done with rebasing instead of merging, so for us, commit time is better.

MestreLion commented 8 years ago

What do you think about making it the default?

dwfreed commented 8 years ago

eh, I don't think it's warranted

MestreLion commented 8 years ago

Well, if that is the most common use, it does. It would be a bummer if, say 95%, of the users always used as --commit-time. This is still a young tool, have only been packaged to debian last year, so time to break the API for the better is now :)