resets local repository to old state about ansible-role-dotfiles HOT 8 CLOSED

I further checked: the state the "henning" branch has been resetted to was the same state the master was in.

It also seems that the dotfile role does nothing but use standard ansible git module, but anyway, it behaves strangely. I see no reason why a branch in my local clone is reset to any older state.

Actually, looking into it further reveals:
The process actually stops when I have uncommitted changes, which is nice.

BUT when I only COMMIT changes, in the current branch and not PUSH them, they are LOST forever! Because, still, the currently checkout out branch, will always be resetted to the state of the master. IMHO this is super bad, and no user of the system can really want that.

And branches that I create in this repository, but are not checked out the moment the role runs, are untouched.
This seems also somehow strange, so the clone is not completely checked out anew, only the currently checked out branch is crippled. This should, IMHO, be prevented somehow.

from ansible-role-dotfiles.

@henning - The idea for the dotfiles repo is that you have a canonical repository on GitHub, and you check it out locally; I use this kind of setup so I can have one configuration for pretty much all tools (Ansible, Terminal, vim, etc.) that I have synced via the git repository to all my computers.

Any time I make a change on any computer, I commit the change and push it up to my dotfiles repo.

That way, whenever the mac-dev-playbook is run, it automatically pulls down the latest changes from the upstream repository.

Automating things this way (e.g. treating all local stuff as destroyable and ready to blow up at any time) forces me to ensure I always have things pushed to GitHub, backed up in multiple places, easily recoverable, etc.

If you would rather not have that kind of setup, and need more customization on each of your computers, then you should use a different dotfiles deployment than the one this role uses.

I also have an upstream issue #15 that should make sure the Git ownership snafu stops occurring... I forgot I hadn't completed the fix for it (removing this line from the defaults https://github.com/geerlingguy/mac-dev-playbook/blob/master/default.config.yml#L13) yet. I'll go over and do that now!

from ansible-role-dotfiles.

Yes I understand whyt the idea of this thing is.

I also understand how it is good to push a configuration on all machines only from a central repository is good. And that especially on servers you want everybody to know that manual changes are forbidden and will be erased next time the config tool runs.

On a desktop machine it is a bit different.

I might add a config change while on a plane. And while I perfectly can commit it then, I cannot push to the cenral repository.

And the way this checkout currently works, my local branch will be overwritten hard, without any warnings and nothing, by whatever is the HESD of the remote branch.

And that's really bad.

By the way this does not happen when I only change a file, but dont commit. A changed but uncommited file will result in an eroor and the process stop

from ansible-role-dotfiles.

You can still use git reflog to retrieve your un-pushed commits. That's the reason git doesn't error out like it does for uncommitted files, the data won't be lost.

from ansible-role-dotfiles.

Hmm, interesting. I didn't try that nor did I knew of the option even though I used git for a few years now. So it might be that many average git users also don#t know of this possibility, and will think, as I did, that their changes to the current branch have simply been overwritten in some way and gone for good.

Again, that's why I insist, the proper usage of this role should be better documented, so that you don't need advanced git skills in order to recover from perceived data loss.

from ansible-role-dotfiles.

Seems you can also do it with log, which is a bit easier than reflog for sure:

$ git log --branches --not --remotes --oneline
6d54cc2 more git aliases

$ git show 6d54cc2

from ansible-role-dotfiles.

@oxyc thanks! I will try to figure that out later! It still looks like advance git command usage that is more than the average user can do...

from ansible-role-dotfiles.

Also note that the downstream project (mac-dev-playbook) added a new configuration variable you can use to disable the dotfiles management; you could run it with it enabled the first time, then set it to no for future deployments if you want to manage dotfiles more manually from that point forward.

from ansible-role-dotfiles.