Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't blow away uncommitted changes #87

Open
robinbowes opened this issue Sep 12, 2016 · 4 comments
Open

Don't blow away uncommitted changes #87

robinbowes opened this issue Sep 12, 2016 · 4 comments

Comments

@robinbowes
Copy link

I just managed to blow away all the uncommitted changes on a local feature branch with modulesync.

Surely it should detect uncommitted changes and abort rather than just dropping them so it can checkout the modulesync branch?

R.

@james-powis
Copy link
Member

howdy robin, if you reference some of the documentation in modulesync_configs and modulesync typically running msync is done from outside of the typical working directory this ensures the msync does not conflict with any work in progress.

My personal workflow is this:
live development in: ~/git/my_funky_project
modulesync_configs in: ~/git/modulesync_configs

cd ~/git/modulesync_configs
msync update -f my_funky_project

I also highly recommend configuring a modulesync.yml file documented here: https://github.com/voxpupuli/modulesync

Reference the one used by voxpupuli:

---
git_base: 'git@github.com:'
namespace: voxpupuli
branch: modulesync
message: "Update from voxpupuli modulesync_config"
...
# vim: syntax=yaml

Hopefully this is helpful.

@james-powis
Copy link
Member

Please also reference: https://github.com/voxpupuli/modulesync_config

@robinbowes
Copy link
Author

Thanks @james-powis, I've already reached out elsewhere to try and understand the workflow required to use modulesync as I'm clearly not quite getting it. (To be fair, I've spent very little time trying to use it).

Thanks again,

R.

@bittner
Copy link
Contributor

bittner commented May 25, 2018

Yet still, when uncommitted changes are present modulesync should abort instead of blowing up the universe. I think this is a fair expectation. Software should be safe to use.

Basically, if there are any changes in a module cloned by modulesync the script should abort (or ask whether the repo should be cloned afresh). IIUC, currently we're even merging changes from a hard-coded origin, as pull = fetch && merge. We probably shouldn't do anything to the cloned repo locally. It could be an unfortunate coincidence or a bug (e.g. cd fails unnoticed) if Git finds local changes.

Abort instead throw away

Can't we change the current implementation so that we first check whether there are any local changes, and abort? Instead of "Overriding any local changes ...".

Also, it should be possible to omit the hardcoded origin value and let Git use the configured default (e.g. by running git reset @{upstream}, with or without --hard).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants