CODEWITHSUNDEEP
windowsgitbashcommand-linecommand-line-tool
Chris J
Chris J

Reputation: 1

Error with colon in git commit name

The command git diff "??/??/15 - 12:34" "??/??/?? - 03:21" throws an error. It seems that : is the culprit.

The client that handles git for me, didn't throw and error with the colon in the commit name, but git Bash for Windows won't let me get access to the commit using the command line options. I've tried ':' or ":" or \: and none of those options worked.

How would someone use a colon on the command line or how would someone escape the colon character?

* EDIT *

Here's a copy of the output from git log --oneline

9c34cd9 git merge
f1195c7 09/04/2015 - 15:05
db38edb 09/03/15 - 17:28
c20dea6 09/02/15 - 19:43
e33cd9c 08/28/15 - 00:12
48692a9 08/26/15 - 16:02
8072375 08/25/15 - 19:58
c6babf3 08/25/15 - 12:12
ff6afbf 08/14/15 - 19:43
a0ccc60 08/08/15 - 13:43
9b446ae 08/04/15 - 16:11
34a7dfe 08/02/15 - 21:09
f6005ba 07/31/15 - 16:12
18dc958 07/31/15 - 16:11
3d4c7fb 07/31/15 - 13:48
c6c9ef9 07/25/15 - 22:42
9fd46df 07/25/15 - 15:23
78fa4ed 07/20/15 - 12:27
af399b7 07/16/15 - 17:00
33fbd24 07/14/15 - 17:46
458bb5e 07/14/15 - 12:32
418a92d 07-13-15 - EOD
72b1408 07/13/15 - 17:43
a6bc32f Merge https://github.com/halcyonsystems/amelia
ec27a81         new file:   assets/css/main.css         
new file:         assets/im2ff9bc3 Initial commit

Upvotes: 0

Views: 2065

Answers (1)

cfi
cfi

Reputation: 11298

From the help page (git help diff):

NAME
       git-diff - Show changes between commits, commit and working tree, etc

SYNOPSIS
       git diff [options] [<commit>] [--] [<path>...]
       git diff [options] --cached [<commit>] [--] [<path>...]
       git diff [options] <commit> <commit> [--] [<path>...]
       git diff [options] <blob> <blob>
       git diff [options] [--no-index] [--] <path> <path>

So you can specify two different path options. If those are timestamps you have to get them into the right syntax. See git help revisions:

   <refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
       A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g.  {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26
       18:30:00}) specifies the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log
       ($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at
       commits made during certain times, see --since and --until.

This works well for a single file as refname.

If you want to really diff all the changes in your full repo between two times, see this question and this question

Update based on the update of the question and clarifications in the comments:

As the dates appear in the first line of the commit message, you first have to search for the matching date (=commit message) in your repository to determine the unique checksum that identifies the respective commit just as Wumpus explained in the comments:

git log --oneline --grep='07/25/15 - 22:42'

This should work in your case. In the general case where the date or the search string cannot be found in the first line of the commit message use:

git log --grep='07/25/15 - 22:42'

If you have multiple branches and don't know on which branch the respective commit is to be found, add the --all switch.

On the output you will find the checksum, e.g. 3d4c7fb. This is the unique identifier which you can then feed into git diff. Note that the full checksum is actually a bit longer, but abbreviations are fine as long as they are unambiguous. Usually the first four to six digits are sufficient, depending on the amount of commits done in the past.

As Wumpus already said: This is awful. Do not add the commit date to the log message. It is redundant and therefore meaningless: git already maintains two dates for each commit: The author date and the commit date. For the first commit of a changeset these two are identical. During operations that integrate one commit onto a different branch (and generating a new commit checksum), the commit date represents the timestamp of the operation while the author date remains the same old. As I explained above you can refer to a file at a certain timestamp with filename@{timestamp}. See git help revisions to learn about the details of what you can do with the syntax. It's neat and quite flexible.

Upvotes: 1

Related Questions