feature request: git svn dommit --preserve-timestamps

Hi,

It would be nice, if timestamps could be preserved when rewriting the git-log.

Use case: I often make a dcommit after several days of development
(20 or 30 commits), because
- the users of the svn-server don't need it more often;
- and for the dcommit I need a VPN-connection to a server, that is not
  always available.

Today, after a dcommit, it's no more possible to match a special commit by time and date (for example the time of some email exchange).

TIA for your attention and perhaps the implementation of such a feature.

Kind regards,

Peter Münster <pmlists@free.fr> wrote:

Unfortunately, last I checked (a long time ago!), explicitly setting revprops might require SVN administrators to enable the feature for the repo.

It's been a while and I'm not up-to-date with the latest SVN. Maybe there's a newer/easier way you could give us details about :)

For now, I suggest including the date in the message body itself to record when it was written (perhaps using git-interpret-trailers to enforce, although I'm not familiar with that, either).

On Tue, Jun 07 2016, Eric Wong wrote:

Not the svn-log, only the git-log.

No, sorry. I don't care about the svn-log.

Peter Münster <pmlists@free.fr> wrote:

The git log after dcommit is tied to the SVN log, so git-svn can only reflect changes which appear in SVN.

	Sidenote: The convention is reply-to-all on lists like
	this one which do not require subscription to post.
	It prevents the list from being a single-point-of-failure
	or censorship.

Unfortunately, you would have to care about svn log as long as SVN exists in your workflow and you need to interact with SVN users.

git svn tries hard to work transparently and as close to the behavior of the upstream SVN repo as possible.

Somewhen near June 10, 2016 9:40 PM, Eric Wong wrote:

Having had to deal with this in pure git without factoring in git svn, this seems to be is a matter of policy rather than technical requirement. Various customers of mine have decided that using the commit time as a uniform timestamp to be applied to all files pulled in the specific commit, is the way to go when doing continuous integration. The solution that we ended up with was a step in our Jenkins build jobs that would set the timestamp of all files associated with the specific commit to the time of the commit itself. Any commit not part of the commit that changed that state of the repository was untouched. This became arbitrarily complex when the job was impacted by multiple commits, but the general consensus of those who made the decisions was to apply all timestamps associated with all commits, in order, of application (Jenkins seems happy to deal with this part), so that the files do keep relatively sane from a build perspective. Personally, I am relatively happy with this solution, even if it adds a huge amount of time to the build - generally more than the build itself - so that timestamps are "sane". Doing it for straight clones does not seem worth it, because timestamps don't appear to matter, policy wise, unless official builds are being done. It may be worth considering that in the discussion. 

My comments are just based on a production perspective, rather than development, so I ask forgiveness for any red-herrings that may be involved.

Cheers, Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much.

On Sat, Jun 11 2016, Eric Wong wrote:

You mean, it's impossible, to keep the original timestamps??

Ok, thanks.

In my case, all development happens on Git, SVN is only some sort of copy. And when the original timestamps are lost, I've sometimes some real problems in finding a specific commit that matches another event.

That's why I suggest an option, for use cases as mine. Those, who prefer to keep the current behaviour just won't use it.

If someone could guide me through the code, I could modify it perhaps.

Thanks for your efforts,

Peter Münster <pmlists@free.fr> wrote:

It might be; just not easy; and I haven't looked at the code in ages. But there seems to be similar options for preserving authorship in git-only (see below)

I'm sorry for your situation and hoping you migrate off SVN entirely, soon :)

Maybe you could look at how the _use_log_author and _add_author_from options work. I've forgotten their existence until now and I've never used them myself; but apparently they're still there.

Unfortunately, if you have other users using git-svn; it could be tricky to ensure they can see the same timestamps you see...

On Sat, Jun 11 2016, Eric Wong wrote:

I've done so, but my customer won't. He wants the code in his svn-repo.

That would mean adding "Date: ..." to the log message. Of course, I could do that. But then my customer would get confused about these extra lines in the svn log.

It seems really to complicated, I think I'll just make a script, that saves all important information (date, message, etc.) at every git-commit to some kind of personal log-file, that I can use when I need to search the history by date.

Nevertheless thanks for your efforts. Kind regards,

On Mon, Jun 06 2016, Peter Münster wrote:

Hi,

Or could someone please show me, where the timestamp is rewritten in the code, so that I could change it and compile a local copy of git, that fits my needs? Perhaps I could even create a patch, that implements "--preserve-timestamps" and send it back.

I've already searched in git-svn.perl but without success... :(

TIA for any hints,