1

I have repo where I don't track .gitignore, someone committed node_modules folder and later we decided to untrack it. Now same person(new to git) committed '.gitignore' for few commits before untracking it again. Now we have situation where if we checkout old commits, it deletes several files from repo that were not tracked and it also creates situation where 'vs code' slows down due to thousands of untracked files. What's the best way to handle this situation? I think I will need to squash those commits and keep them on seperate branch so no one checks it out accidentally. Do I have any other options?

As things happened,

.gitignore was never tracked
node_modules were tracked
.gitignore was tracked
node_modules was untracked
.gitingore was untracked
chadedgar
  • 111
  • 1
  • 6
  • Why are you not tracking `.gitignore`? You could interactively rebase the affected branch and remove the files that were tracked by accident. When you do this, please inform all developers that the history of this remote (possibly long-living) branch got rewritten so they can properly deal with it. – Matt Jun 02 '21 at 13:08
  • Another point... if you practice pull/merge request approvals, then a reviewer can spot such things before merging them on a long-living branch. – Matt Jun 02 '21 at 13:11
  • @Matt In my case, checking out old branches was creating issue with newly added files that were ignored. From what I searched at the time, it was fine to not track .gitignore. So instead we have gitignore.txt that we track and .gitignore needs to be updated manually. This repo has several months of commits but luckily only now team is going to work on it, so it won't be that hard to fix the issue. – chadedgar Jun 02 '21 at 13:19
  • I strongly suggest that you track `.gitignore` itself instead of manually updating it with contents of a `gitignore.txt`. Other developers will definitely not keep `.gitignore` updated since they would always need to compare it. This step is automated when you track it directly. I do not see a disadvantage doing this and it would actually prevent the problem you are now facing from happening again in the future. – Matt Jun 02 '21 at 13:26
  • If I track .gitingore now, won't it just get deleted any time I checkout old commits? We need old commits to bisect, untracked files will always get in way while going through commits. – chadedgar Jun 02 '21 at 13:27
  • 1
    Yes, it will be removed but according to your previous workflow, you would need to update it anyways with the content of the txt-file (now you need to `cp gitignore.txt .gitignore` instead). So as long as you need to go back to these commits, this step would be necessary... unless you rewrite the history and add the `.gitignore` in an earlier commit. Depending on the amount of developers and involved local repositories, a rewrite could be considered. For the future... always add `.gitignore` as one of the first steps after creating a repository. – Matt Jun 02 '21 at 13:33

1 Answers1

1

Form what you have described top of master is fixed and problem is only is someone checks out old version of code where stuff are broken.

There is no easy way to fix it. For that you need rewrite whole history and make sure that all copies of repository are updated with new history. This is organization nightmare you will always miss one repo which will be pushed back to main repository and you will come back to initial state. So do not try that.

The only reasonable solution is address scenario when someone checks out old version of code. If this is some branch, like: release-1.x.x then just cherry pick a commit which fixes this issue to that branch.

If developers have to checkout code to specific version/commit, they have to live with this problem as long this version of code needs some maintenance.

Important is to learn some lesson from this kind of problems:

  • always create and check in .gitignore to repository when only you start new project.
  • git hooks are a bit harder to configure, but are great solution to protect repo from unwanted corruptions
    • note there are tools github/gitlab/bitbucket/... which allows you to configure pull requests and configure git hooks to protect specific branches. Passing pull request code review is great way to protect you from unexpected (not covered by .gitignore and git hooks) bad changes
  • when intern is joining a project make sure his git skills are at least a basic and he understands what should be tracked by repository and what should not be tracked.
Marek R
  • 32,568
  • 6
  • 55
  • 140
  • 1
    I can't stress the last point enough. Time and time again we see questions here on Stack Overflow where the first and usually *only* reaction to "my git repository looks corrupted after I did something" is "I'll just try a few more random commands I can find online". This never goes well, never. The first and only step is to step away and get help. By the very nature of "you did something", you don't know what you're doing, so doing more is not going to help and usually the mess just gets even more complex. So learn basic stuff at least. – Lasse V. Karlsen Jun 02 '21 at 13:23
  • Thanks, luckily this happened before everyone started working on the project, so it won't affect anyone if I rewirte the history now. – chadedgar Jun 02 '21 at 13:30
  • 1
    If you are only user of the repo or this problematic changes are not shared then great. Interactive rebase is what you need. If your git skills are basic ask someone in real life to help you with that. This feature requires at leas medium skill in git. It is hard to understand at first approach, but later turns out quite cool. As `Lasse V. Karlsen` wrote trying random commands will end badly. – Marek R Jun 02 '21 at 13:34
  • @MarekR Thanks, I managed squash all bad commits. Had to try and practice few times on temp branch but ya it is great feature. – chadedgar Jun 02 '21 at 17:24