All geek questions in one place

Git - permutation is taken safely

I found that reordering via git rebase -i may not create the same final result tree when working with remote files - and it can do this without warning or error messages.

Take the following sequence of commits

  A - Add foo1
 B - Add foo2
 C - Remove foo2, Add Foo3

Using git rebase -i to reorder commits from ABC to ACB, in foo2 is present in HEAD.

Is there a way to reorder the commits that bark if a reordering changes the final tree?

I think git rebase internally uses git am to apply patches. I do not see any relevant arguments for git am that can be used to force a crash when deleting a nonexistent file, which I think will be required. Does git source code need to be fixed to get what I want?

+1
source share
2 answers

Did you make the contents of the files different? This can be seen as movement if they are too similar. If you try to apply a patch to delete a file that does not exist, you should end the conflict.

Hope this helps.

0
source

You can reinstall, compare the result, and then possibly reset with the old state. Simple combination

  • git stash save --include-untracked to enter a clean state.
  • git rev-parse HEAD to get the hash of the current commit
  • git rebase to do the real job.
  • git checkout the_previously_saved_hash . to restore state before rebooting
  • git clean -fd to get rid of all the extra files
  • git commit -m "Undoing the changes introduces by rebase." , which may fail if rebase has not made any changes (this failure can be ignored silently)
  • git stash pop to reintroduce contaminated "pollution"

should ... I think I'll try to make a script like this soon, just like what I need.

0
source

Source: https://habr.com/ru/post/1387244/

More articles:


All Articles