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.
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.
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...
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:
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.
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:
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.
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.
Thanks for your advice though!
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot