jbernard / dotfiles

Dotfile management made easy
https://pypi.org/project/dotfiles/
Other
579 stars 61 forks source link

dotfiles cli should follow a git push and git pull style #51

Open mayuroks opened 9 years ago

mayuroks commented 9 years ago

After adding dotfiles, doing this is kinda over head

$ cd ~/Dotfiles
$ git add vimrc
$ git commit -m "Added vimrc, welcome aboard!"
$ git push
# Proposed Add behaviour
$ dotfiles -a => should also do git add that file

# Proposed Sync behaviour
$ dotfiles -s => sync from local dotfiles dir
$ dotfiles -s --git-pull => pull from github to local dotfiles dir and then SYNC
$ dotfiles -s --git-pull-push => pull && push to local dotfiles dir and then SYNC to github 
jbernard commented 9 years ago

You raise a good point.

The original intent was to be vcs-agnostic and allow the user to back the repo with whatever they choose and manage it with the native tools. The main argument is that dotfiles would have to make distinct choices about which vcs to support and how changes would be made (commit messages, merge strategy, conflict resolution, etc) - and not everyone will agree with those choices.

But I recently found pass (http://www.passwordstore.org/) and they handle this in a very clean way - the directory is just a password store - unless a .git directory is found, and then vcs commands are issued to keep the repository in sync. If it's done in a modular way, such that git is not a strict dependency, then I think it would be cool.

drozdziak1 commented 9 years ago

I think that the VCS-agnostic approach could be somewhat preserved if you had implemented some kind of VCS profiles for some other popular systems of that kind.

When talking about Git, I'd make Dotfiles only do anything remote-related on --sync when some additional, let's say, --remote <remote name, origin by default> <branch name, current branch by default> flag is added. On such occasion, Dotfiles could do a simple git status, and if there's nothing to track/commit, it would fire up a git pull <remote name> <branch> and then (after asking the user to approve of the present state of their files) push the repo back with the new stuff. Anything else (merges, commits, adding files for staging, conflict resolving) the user can do without unnecessarily involving the script, i.e. using their existing git configuration.

prologic commented 8 years ago

I would like this too!

jbernard commented 8 years ago

Ok, I'll see what I can do. I'm in the middle of some rather large rework and will keep this in mind as things progress.

prologic commented 8 years ago

:+1:

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Thu, Jan 14, 2016 at 4:40 AM, Jon Bernard notifications@github.com wrote:

Ok, I'll see what I can do. I'm in the middle of some rather large rework and will keep this in mind as things progress.

— Reply to this email directly or view it on GitHub https://github.com/jbernard/dotfiles/issues/51#issuecomment-171633475.

cnadiminti commented 8 years ago

I think it should be VCS agnostic.