Arquivo da categoria: Controle de Versão

Delete commits from a branch in Git

Careful: git reset –hard WILL DELETE YOUR WORKING DIRECTORY CHANGES. Be sure to stash any local changes you want to keep before running this command.

Assuming you are sitting on that commit, then this command will wack it…

git reset --hard HEAD~1

The HEAD~1 means the commit before head.

Or, you could look at the output of git log, find the commit id of the commit you want to back up to, and then do this:

git reset --hard <sha1-commit-id>

If you already pushed it, you will need to do a force push to get rid of it…

git push origin HEAD --force

However, if others may have pulled it, then you would be better off starting a new branch. Because when they pull, it will just merge it into their work, and you will get it pushed back up again.

If you already pushed, it may be better to use git revert, to create a “mirror image” commit that will undo the changes. However, both commits will be in the log.

FYI — git reset –hard HEAD is great if you want to get rid of WORK IN PROGRESS. It will reset you back to the most recent commit, and erase all the changes in your working tree and index.

Lastly, if you need to find a commit that you “deleted”, it is typically present in git reflog unless you have garbage collected your repository.

Delphi XE2 changes DFM even though nothing has been changed

This is just a consequence of how Delphi’s form streaming mechanism works.

When you open a form in the Delphi designer, the .dfm file is used to create instances of each component on the form. In your case, the form designer will instantiate each of the objects in the .dfm file. Each property in the .dfm file will be read in.

Then, if you do anything in the designer that marks the form as having been modified, for example changing the active tabsheet, then the designer will re-create the .dfm file when you save. And it re-creates the .dfm file by asking the in-memory components to save themselves. This saving process makes no account of what the .dfm file on disk looks like. Each component just saves its properties as they are at that point in time.

So, in summary, there’s really nothing you can do to change Delphi’s behaviour. The best you can do is to work around it to minimise the impact.

If your forms have Scaled=True then you should make sure that all developer machines use the same font scaling. Otherwise when developer A saves at one font scaling, that .dfm file will be completely different from the one that developer B saves at a different font scaling. All positions will be altered. It sounds as though you have some developers that use 120dpi font scaling. And that’s going to give you no end of grief.

If benign edits to the form file result in large changes, commit those changes. Once you have every developer machine configured the same way, you’ll find things settle down. Those benign edits should no longer result in .dfm file changes.

This is just one of the occupational hazards of visual design with Delphi. You need to pay lots of care and attention to your .dfm files whenever you commit. I regularly find myself reverting changes to .dfm files from the Tortoise commit dialog. I also often elect to modify the .dfm file in a text editor rather than using the form designer!

https://stackoverflow.com/questions/12911124/delphi-xe2-changes-dfm-even-though-nothing-has-been-changed