0

We have an issue where one of our devs has committed some changes which have in effect bypassed a bunch of other commits by the rest of the team.

You can see this in the image where K has a commit on 14/05/2021 which loops back past the other commits to their previous commit on 30/04/2021.

Git Log

As a result all the other commits between 30/04/2021 and 14/05/2021 are being removed when we do a pull.

Is there anything we can do to reinsert the changes made between these 2 dates or remove the change which caused this?

Many Thanks

SwissCodeMen
  • 4,222
  • 8
  • 24
  • 34
Stephen Caulfield
  • 1
  • It's a little unclear what you mean. If all of those commits are being removed, then they would not exist in this history. By the graph, they share the same history which means this developer either merged or rebased with your main branch, so those commits should be visible. Where are they being removed? – Kraigolas May 14 '21 at 18:19
  • 1
    Indeed, `0624fbaf`, the commit at the very top, looks like a merge commit that brings it all together, combining both histories. Does it not contain all the code contributed by the commits you say were removed? – joanis May 14 '21 at 18:31
  • It's when I do a pull, the files which were added in commits are marked as to be deleted. But I think I know what the problem might be. I believe that they may have committed their own changes but not the changes that were made as a result of them pulling from the master. If that is the reason I will post next week once we have looked at it. – Stephen Caulfield May 14 '21 at 18:47
  • If you see files as to-be (or actually) deleted, that means someone *deleted those files*. But that's not a big deal, because *every commit contains every file*, or rather, every-file-it-has. Deleting a file and then committing means the new commit *doesn't have the file*, but all the *old* commits still do. Merging that commit merges the deletion operation, but you can bring the file back from any of the old commits that have it. – torek May 14 '21 at 19:24
  • In general, a branch someone made that bogusly deletes files shouldn't be merged: make *them* fix their branch first. But if it comes down to it, you can merge it anyway, and then *you* can fix the mess. That's what a good version control system does for you (one of many things, really). It lets you make them fix their mess, but if you can't (they got run over by a truck), it lets you fix their mess. – torek May 14 '21 at 19:25
  • If you don’t like what 0624fbaf did, you can just make a commit that reverses it. – matt May 15 '21 at 01:18

0 Answers0