Can I commit an unchanged file?

[Config Manager]

Is there any way I can force Git to commit files that have not been changed since last committed?

Here is the background:

I have a lot of files in a single commit on a branch, and I want to "copy" some of the changed files to another branch. If I wanted all of the changed files, I could merge the branch or cherry-pick the commit. But I only want some of them.

One way to do this would be to touch the required files in some way (perhaps by adding a space or a blank line), commit and cherry-pick the commit (bash "touch" will not do the job, btw).

But if I could commit the required files without modifying them, that would be best, avoiding a spurious file content modification - hence my question.

[Config Manager]

Hmm. I was thinking about that but I can't as the commits have been shared amongst several users. The only other approach I can think of is to modify every file by adding a blank line or space and committing them back, either in known groups or one by one.

Messy ...

Thanks for your advice though!

[Mike Friedrich]

Ok. You still can compare your effort for these dummy changes versus the developers effort for an extra merge after you did the reset. I guess both is messy in your case and you need to choose your poison ;)

[Mike Friedrich]

Can you use git log commands to find the files you are interested in?

[Config Manager]

Hi again Mike,

I appreciate you trying to help but I think we are not really getting anywhere due to your unfamiliarity with the exact circumstance I have and processes we use.

Let me restate the problem in a different way which may help you to understand my predicament:

• Many code changes were made as individual commits on a branch in Visual SourceSafe ("check-ins" in VSS parlance).
• The latest version of every modified file was migrated over to Git in a single commit on a feature branch
• I now want to merge a subset of the original check-ins across to a different branch for testing prior to merging back to master for release (and then later repeat with a different subset, and so on).

The previous action that makes this non-trivial is the including of all files in a single commit. My thought was to make a new commit with just the files I need (I know the list of files BTW), and I was looking for an easy way to create this new commit.

Regards, John

[Mike Friedrich]

I would recomment to split your commits, i dont see how elso to do this. (git reset + add + commit)

[Mike Friedrich]

Usually I leave all merges and especially conflict resolution to developers (using Stash pull requests) and we run all builds/tests on one branch. We use the branch based on the workflow: a feature branch if want to test the developers work prior to his merge, the develop branch after the merge, the master or a release branch (branched from develop) if we decide to release.

We never had a scenario where we would need to exclude files or revert changes for testing only. That's why I don't understand what you try to do.

[Mike Friedrich]

Why do you need to merge for "ready for testing and release"?

Can you not just take the repo as-is and run your tests and create tags if ok?

Are you using the git-flow model?

[Config Manager]

I just knew that once I started sharing some detail that more questions would result. To answer them properly would need much more explanation of our development, build, test and release process so I'm going to give point answers and no detail beyond:

Why do you need to merge for "ready for testing and release"?

• To merge parallel BAU changes into the refactoring changes and then test them. Then release them. The merge them back to master. Doesn't everyone work like that?

Can you not just take the repo as-is and run your tests and create tags if ok?

• Because the refactoring project is being merged, tested and released (sic) in phases and at any phase I won't need all the other changes in the refactoring branch.

Are you using the git-flow model?

• No but one day, maybe...

[Mike Friedrich]

Committing without changing is not possible and defeats the purpose of a change control system. Touch will not help either, because timestamps are used by git for any change also when using checkout (e.g. to support incremental builds).

What you should try is to use smaller commits, which then will allow you to cherry pick. But I do not understand if this is what you really want.

Instead of explaining the solution, maybe you try to explain the problem you want to solve. Maybe we can suggest something then.

[Config Manager]

Hi Mike,

Thanks for your thoughts; I understand your concern and will now go into a bit more detail - well, a lot actually...

This is basically a short-term situation which over time will resolve itself into a normal way of working (smaller commits and cherry-picking, as you suggest). I have recently migrated many thousands of files from Visual SourceSafe into Git. I only migrated the latest version of each file rather than 10 years of history, and these now reside in a few dozen repos. The files migrated into each repo were added in a single commit, but modifications to these files since have used a normal Git style of working.

In parallel with "business as usual", we have a refactoring project going on which started some months ago on SourceSafe branches, and which modified copies of many of these files whilst in SourceSafe. Just like the main migration, I took the latest version of each file in these SourceSafe branches into a specific Git branch in each affected Git repository with a single commit. Work on the project has then proceeded in Git on those branches.

Now we are approaching the time where this parallel project needs to be merged ready for testing and release. For any files committed to the Git branch SINCE the migration, I can just cherry-pick the commit and only get what I need. But all file changes that were made and completed before the migration reside in a single commit, and if I cherry pick that I will get ALL the changes at the point of migration, most of which I don't want and many of which were incomplete anyway.

Ok, you might consider that the method of migration from SourceSafe to Git was a little flawed, but there is no point in reviewing that because we are now some weeks past that and can't go back. Suffice it to say that with over 13000 files spread over 120 repos, the method used seemed optimum at the time.

So, back to my original brief... I have a single commit on a branch with a quite lot of files - typically a few dozen - and I want to merge some of these files to another branch for testing before the eventual merge to master for release. I know that I can't merge the whole commit, nor can I pull it apart. So I need to find the best way of referencing a subset of the files in the commit. If the only way is to make a non-impacting source file change to each file needed and create a new commit, then so be it. But I'm looking for a quicker and easier solution!

Any further thoughts welcome...

Regards, John