> The date of the commit is not the date it got committed to master, but the
date it got committed to some branch, no longer existing after the commit.
If this is the way GIT works, so be it. I just don't like it. It could not
be more confusing.
A couple of thoughts in case they help you.
1. Git has "author date" and "commit date" for each commit.
* author date is the original date of the first commit, never changes.
* commit date is the last time the commit was modified (e.g. amended,
committed to a branch).
Each date is useful, depending on the situation investigating.
To help with the date displays, which git client(s) do you use?
* For SourceTree (free git UI client from Atlassian), it has a "Display
author date instead of commit date in log" config option. It will also
show both dates in the commit details.
* For CLI, use the log command's "pretty formatter" (use "git help log"
for lots of details in the "pretty formats" section). e.g. "git log
--pretty=fuller" shows both author and commit dates (and authors).
2. DeepGit is a free tool that helps with tracing commits. You may
appreciate it: http://www.syntevo.com/deepgit/
The same company also creates the git UI client "SmartGit", which is free
for non-commercial use. You may appreciate using it or SourceTree.
Please ask for more git help if you like. Many people on the list know it
well, and happy to help your productivity.
(I appreciate the issues you find and fix!)
On Mon, Mar 13, 2017 at 6:49 PM, Christian Schulte <[email protected]> wrote:
> Am 03/11/17 um 22:56 schrieb Stephen Connolly:
> > Hi all,
> >
> > I think it is a good thing if we take stock of where we are and how we
> are
> > doing. I would really appreciate if everyone could take a few minutes to
> > respond with their top three of two areas:
> >
> > * What is working well
>
> The Jenkins support has improved greatly. For me it's very cool to have
> the ITs run on Java 7+8 - Linux+Windows. Too few operating systems.
> Solaris is a must have. OS X would be nice to have. FreeBSD or OpenBSD
> also nice to have.
>
> > * What is not working well
>
> Turns out I just will never become a GIT fan. What works best for me has
> been Subversion on the server and GIT locally using git-svn. Very clean
> history on the Subversion server side because you can clean up commits
> locally (squash, reword, etc.) before committing to the Subversion
> repository. I find it quite hard to follow the commit history in GIT.
> The date of the commit is not the date it got committed to master, but
> the date it got committed to some branch, no longer existing after the
> commit. If this is the way GIT works, so be it. I just don't like it. It
> could not be more confusing.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
