3 When I interact with vng to make it merge with other repositories my ideal workflow would basically do the following, naturally completely automated so obvious steps can be skipped.
5 * Check if the tree is dirty, if it is then abort.
6 [might replace this with a revert if we manage to make that perfect]
8 * find out which remote repo to use
9 * check config for current repo for previously used ones.
10 * allow user to pass a url as argument, automatically store that in the config
11 * allow user to pass '--set-default' to mark the url we end up selecting as default (i.e. to be used when the user just plainly types 'vng pull')
13 I think ideally we should show a cursor for all the remote urls registered in the config. Allowing the user to choose any of them, delete one and mark/unmark one as default.
16 git ls-remote --heads --tags /home/zander/work/vng/.git
17 1d3c0161f4b64024c8346750afa825b382645d6b refs/heads/master
18 9c3e9dcc62c4b8c26d64f47b670ec1221f9e3091 refs/heads/foo
20 * Figure out which remote branches/tags to download
21 * for each remote branch present a cursor to ask the user to dowload, skip or create a "following" branch.
22 * Don't present any branches that are already up-to-date
24 * git-fetch-pack --no-progress namlook:sources/vng.git refs/heads/master
26 keep 8403e33b330e881694583ab5209b1bf7c0c9dafa
27 cd4a06abc263dcf612a96d77214c1575d6f70607 refs/heads/master
30 * Create a Commit object with the sha1 of the ref (1d3c0161f)
31 * Check where it connects to our local branch so we can select a strategy from there (fast forward, for example)
33 if user passed --try-rebase && the new commit is not a direct ancestor;
34 git update-ref HEAD [sha1]
35 for each commit do a cherry-pick
36 if this fails, then reset to the previous state of the tree.
37 unless the rebase went fine call;
38 git merge --commit -ff --no-summary remote-ref