dotfiles icon indicating copy to clipboard operation
dotfiles copied to clipboard

dotfiles cli should follow a git push and git pull style

Open mayuroks opened this issue 10 years ago • 6 comments

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 

mayuroks avatar Mar 05 '15 09:03 mayuroks

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.

jbernard avatar Mar 06 '15 15:03 jbernard

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.

drozdziak1 avatar Aug 17 '15 21:08 drozdziak1

I would like this too!

prologic avatar Jan 14 '16 08:01 prologic

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.

jbernard avatar Jan 14 '16 12:01 jbernard

:+1:

James Mills / prologic

E: [email protected] W: prologic.shortcircuit.net.au

On Thu, Jan 14, 2016 at 4:40 AM, Jon Bernard [email protected] 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.

prologic avatar Jan 14 '16 15:01 prologic

I think it should be VCS agnostic.

cnadiminti avatar May 27 '16 06:05 cnadiminti