mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4 2015-08-09 03:04:31 +00:00 • committed by admin
parent 3cb9c0dd93
commit 7434cc0d72
1 changed files with 7 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
subject="comment 2"
date="2015-08-09T03:04:31Z"
content="""
indeed pull/merge ( ie sync) would often be needed. but the same in regular git workflow - we can't push if remote has new changes. so we know that we need to \" git pull\" ( or alternative merge dance). my whining here is pretty much about dichotomy between regular git command and accompanying annex commands for simple typical workflows - i need to educate people much more beyond \" in your typical use case, when you all collaborate on this repo, just use git annex add to place big files under annex control, and then git annex push to push all your changes\". then if annex push checked first that push of annex branch can't happen and that annex merge is due, and let user know to run it first - they will do, and things will remain clear. now there is a lot of annex uniquely named commands which do not \" correlate\" with git ones even for simple use cases, which makes adoption harder imho.
"""]]