-1

This is a follow-up to this Q&A. The aim is to add an empty commit to a specific file, but it turned out that an actual change is required.

Steps to reproduce

  • Navigate to a git repository
  • run git log
  • the git log will be displayed
  • execute git commit path/to/specific/file --allow-empty -m "Empty commit"

Expected outcome

  • Issue git log path/to/specific/file
  • The Empty commit message will appear
  • The output of git log does NOT contain the Empty commit

Actual outcome

It turned out that the Empty commit resides in the root git log (git log) rather than in the specific file (git log path/to/file)


Discussion

AFAIK git log is a record of commits, which apply to every file in your repository

If one applies a change to path/to/some/file, adds and commits it and subsequently runs git log path/to/some/file then the commit message is shown, but when one issues git log path/to/some/another-file then the commit message is omitted.

Why do you think you need this?

There is a check that inspects whether the user of last commit is the CI user to ensure that there are no libraries that contain unreleased changes. Of course it is possible to add a superfluous space in order to add a new commit to a specific file, but it is preferred to add a new commit without changing the file.

030
  • 10,842
  • 12
  • 78
  • 123
  • 1
    AFAIK `git log` is a record of commits, which apply to _every_ file in your repository. Git is a repo based version control tool; files don't have separate logs, as might have been the case with something like Subversion or Perforce. I also don't know why you would want empty commits there. Why do you think you need this? – Tim Biegeleisen Sep 13 '18 at 13:56
  • 1
    Whats the question here? It just reads as a statement of outcomes. If your asking why it does this, because that's how GIT works. Bear in mind folders do not exist in a GIT repo. GIT stores files and only files, folders are just file meta data in GIT. Files only end up in folders when the repo is extracted. – Liam Sep 13 '18 at 14:09
  • @TimBiegeleisen The question has been updated – 030 Sep 13 '18 at 14:27
  • @Liam The aim is to add a commit to a specific file – 030 Sep 13 '18 at 14:28
  • Reminder: Be nice, even if you think someone is being dumb. – evolutionxbox Sep 13 '18 at 14:45
  • 1
    You cannot add a commit to a specific file. A GIT commit is like a small copy of the entire repo (a snapshot). Individual files are not directly associated with a commit. Basically your thinking about it wrong. Have a read though this https://git-scm.com/book/en/v2/Getting-Started-Git-Basics – Liam Sep 13 '18 at 14:58

1 Answers1

3

There is no such thing as a commit for a specific file. In git, a commit is a snapshot of the entire content. (It is possible to have independent commit graphs in a single repo, which can create a sort of gray area around this statement; but such usages are at best logically equivalent to multiple repos that each behave as I've described, and at worst may work against the grain of git as a source control tool.)

It seems you are being led into thinking otherwise because of the git log -- path syntax. This is not reflective of how commits are structured; it is reflective of how the log command processes commits. See the git log docs ('https://git-scm.com/docs/git-log'):

[--] <path>

Show only commits that are enough to explain how the files that match the specified paths came to be

The log command is still seeing all commits - it navigates the same commit graph it would if you hadn't specified a path - but it filters out anything that didn't affect the specified path(s) and only prints info on the commits that do affect those paths.

But even those commits it prints are full snapshots of the project. They are selected only because they happen to include changes to that path (possibly among other changes).

There is no file-level commit in git, and if you don't include a path restriction you will see all commits in the specified history regardless of what path(s) they affect.

Lastly, if the commit were "empty" (meaning its content is the same as its parent), then any path-based log argument would skip that commit, since by definition it doesn't contribute to understanding how the file got in its current form.

Now, from your explanation of what you're trying to accomplish:

Of course it is possible to add a superfluous space in order to add a new commit to a specific file,

No, it is not. Because there is no such thing as a "commit to a specific file". What this would do is create a new commit that affects that file, and therefore is picked up when you give log that file as a path argument. (But it would also be picked up when you give no path argument.)

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52