There is a batch file that performs some set of actions. Including there are commits to different branches and creating a tag. The script does NOT push.

I wish that in case of an error at one of the steps all commits and tags created by the script are automatically rolled back. How can this be done?

  • one
    Apparently the easiest way is to make a copy. Nobody bothers you to make a local clone, turn all the changes there, and if all is well, push it. - KoVadim
  • @KoVadim, I run the local batch file anyway. Just uncomfortable to clean his hands. There is no simpler way? - Qwertiy ♦
  • I do not understand what does the local launch batch file. Apparently frightened by what to do push? - KoVadim
  • @KoVadim, as I understand it, you propose to re-clone the repository every time you start it - this is long and inconvenient. - Qwertiy ♦
  • I see there are misunderstandings of the gita. In the gita, you can clone locally from the next folder ( git clone /home/test/myrep ). And to git push --tags accordingly there (just git push --tags ). With the right approach, local cloning is very fast (just copy files). And then you can delete the cloned folder. - KoVadim

2 answers 2

If changes are limited to commits to existing branches and creating labels, you can save a backup copy of the refs directory inside the repository (usually the .git directory). something like:

 $ tar -cf /путь/к/архиву .git/refs

it contains all the pointers (and the commits to which they point) - both branches ( branches ) and tags ( tags ).

if the changes you make affect something more global (renaming / creating / deleting branches or remote repositories, changes in the repository configuration, etc.), you should also save the config file:

 $ tar -cf /путь/к/архиву .git/refs .git/config

to “roll back”, it is enough to delete this directory and restore it from a backup. something like:

 $ rm -r .git/refs; tar -xf /путь/к/архиву

and a working copy can be brought to the desired state, as usual, with the checkout command:

 $ git checkout коммит-или-ветка-или-метка

If desired, the local storage can be “cleaned” by the gc command from the accumulated “garbage”:

 $ git gc
  • bad way. You also need to save files inside .git. at least I would save the config. You also need to think about the purity of the reflog. My way with clone is much better locally. - KoVadim
  • @KoVadim, clone - no doubt more reliable. but the author of the question, judging by the comments, does not suit the time of cloning. // I would save the config - unnecessarily to roll back the voiced actions (commits and labels). - aleksandr barakin
  • I'm afraid the author did not even test a local clone. And files would be better saved. Today he kommitit, and tomorrow and turnip grind. - KoVadim

The correct, high-quality way is to make a local clone. Extra copying should not be

It’s not a problem, but it’s not a problem. The files under .git / objects / directory are hardlinked to save space when possible.

that is, if git can - it will do a hardlink to .git/objects/ - which will ensure fast copying.

If after all the changes you need to roll back - just delete the folder with the cloned turnip. If everything is ok, just do git push and delete the cloned turnip again. Yes, push will need to be done carefully and at least add - --tags . But you can use the renaming trick. That is, the folder with the turnips is deleted, and the newly-renamed one is renamed.

  • Judging by the fact that there are all sorts of batch file, we are talking about Windows. Is git really able to create hard links under Windows? It seems that there is no such mechanism in ntfs. - mymedia
  • In Windows there is exactly the ability to create hard and symbolic links somewhere else from the 2000 version. Whether that will create them git, it is necessary to check. - KoVadim
  • @mymedia is all there . - D-side