modulesync icon indicating copy to clipboard operation
modulesync copied to clipboard

Don't blow away uncommitted changes

Open robinbowes opened this issue 9 years ago • 4 comments
trafficstars

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.

robinbowes avatar Sep 12 '16 22:09 robinbowes

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: '[email protected]:'
namespace: voxpupuli
branch: modulesync
message: "Update from voxpupuli modulesync_config"
...
# vim: syntax=yaml

Hopefully this is helpful.

james-powis avatar Jan 05 '17 04:01 james-powis

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

james-powis avatar Jan 05 '17 04:01 james-powis

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.

robinbowes avatar Jan 05 '17 13:01 robinbowes

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).

bittner avatar May 25 '18 09:05 bittner