Add support --branch together with --all mentioned in #253 #552
Conversation
There was a problem hiding this comment.
Independent of the technical issues I presented inline. I am concerned with a program overriding my explicit commands. I would be ok with a check to ensure that the branch existed on all effected repos and then executed accordingly or failed with a message telling me where it was missing, but to fall back to the previously configured branch after overriding it does not feel like an ok thing to do without direct user interaction. And as this run on multiple OS with multiple versions of bash getting user feedback is extraordinarily hard.
| @@ -694,6 +690,16 @@ subrepo:fetch() { | |||
| error "Can't fetch subrepo. Remote is 'none' in '$subdir/.gitrepo'." | |||
| fi | |||
|
|
|||
| if $all_wanted && [[ -n $subrepo_branch ]]; then | |||
| o "Check if the remote branch ($subrepo_branch) exists." | |||
| OUT=true RUN git ls-remote --heads "$subrepo_remote" "$subrepo_branch" | |||
There was a problem hiding this comment.
There is already a command for this git:branch-exists see 644 for an example
| o "Check if the remote branch ($subrepo_branch) exists." | ||
| OUT=true RUN git ls-remote --heads "$subrepo_remote" "$subrepo_branch" | ||
| if [[ -z $output ]]; then | ||
| SAY=false OUT=true RUN git config --file="$gitrepo" subrepo.branch |
There was a problem hiding this comment.
There is a function to read the gitrepo file read-gitrepo-file
| @@ -694,6 +690,16 @@ subrepo:fetch() { | |||
| error "Can't fetch subrepo. Remote is 'none' in '$subdir/.gitrepo'." | |||
| fi | |||
|
|
|||
| if $all_wanted && [[ -n $subrepo_branch ]]; then | |||
There was a problem hiding this comment.
Wouldn't something similar be necessary in subrepo:push?
There was a problem hiding this comment.
I'm not sure. I don't think anything is missing in subrepo:push. It's works fine with --all.
|
I'll try to understand you. I'm using subrepo in different use case for me it is meaningful to do this by this way. Every command I'm using is somehow dangerous. This is life. This one could be dangerous also. But preventing users from doing stupid things is preventing them from doing the smart ones. This command potentially do what you might not want. But it is everything in git, everything is revertible. Need for user interaction is not the way IMHO. There must be good feedback and user must know what has been done. |
No description provided.