[ 
http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172771#action_172771
 ] 

Matthew McCullough commented on SCM-444:
----------------------------------------

I'd be more inclined for the quick-and-easy solution of having the plugin read 
a parameter/flag that just disables the push entirely.  Then, the release 
plugin user can turn it off for branches he/she does not want to push, and can 
push at their leisure later.

In fact, I find not pushing to be much more in line with the idea of git to 
"Play local until confident, push only when ready".  After all, we worked so 
hard to get an SCM system that finally doesn't require us to have connectivity 
to any remote servers, and having the release plugin PUSH kind of interrupts 
that achievement.

A simple do-no-push flag seems like a quick solution.

> Git provider does 'git push' during 'mvn release:prepare' which causes 
> unwanted problems
> ----------------------------------------------------------------------------------------
>
>                 Key: SCM-444
>                 URL: http://jira.codehaus.org/browse/SCM-444
>             Project: Maven SCM
>          Issue Type: Bug
>          Components: maven-scm-provider-git
>    Affects Versions: 1.1
>            Reporter: Petter Måhlén
>            Assignee: Olivier Lamy
>            Priority: Minor
>             Fix For: 1.3
>
>
> When doing 'mvn release:prepare' with a Git provider, a 'git push' command is 
> executed. This is not ideal because the push command can fail or push things 
> from the local repository that are not needed/wanted in the remote 
> repository. Some examples are:
> 1. The local repository has two branches: master (tracking origin/master) and 
> dummy (tracking origin/dummy). The release is being made on the master 
> branch, and the dummy and origin/dummy branches have diverged. Running 
> 'release:prepare' causes a 'git push', which will succeed for the master 
> branch (assuming that the release preparation has been made correctly) and 
> fail for the dummy branch (the two branches have diverged and need to be 
> merged or rebased). The release preparation aborts and the directory is left 
> in a somewhat inconsistent state where manual cleaning up is needed (removing 
> pom.xml.next files, changing versions to <new>-SNAPSHOT, etc.)
> 2. The local repository has two branches: master (tracking origin/master) and 
> localtest (not in the origin repository). The localtest branch shouldn't be 
> published because it is just used for some temporary testing and doesn't even 
> work. It will be pushed during 'release:prepare'.
> Suggested behaviour: use 'git push origin <currentbranch>:<currentbranch>', 
> or even better, query for which remote repository to push to (found in 
> .git/config) and which branch to push from and to. For me, it would be great 
> to have a 'confirm push' before doing it so as to keep things clean, but 
> maybe that is quite complex.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to