[jira] Commented: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems

["Nigel Magnay (JIRA)" <ji...@codehaus.org>]

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

Nigel Magnay commented on SCM-444:
----------------------------------

>Currently releasing an artifact means that it gets tested, tagged and then (with mvn release:perform)a clean checkout happens into 
> target/checkout! How should we do the clean checkout if we do not push the tag into the upstream repo?

>From the _local_ repository. 

I don't think any of release:prepare or release:peform should ever think about touching the upstream repository - that should be an entirely user-decided thing. Several reasons:

1) There may not *be* an upstream repository. Or there may be several -- choosing one is purely arbitary
2) the whole release:prepare-> screwup... release:rollback thing is a nightmare with SVN entirely because it has to make a change in the remote repository, which if it goes wrong leaves cruft for all to see.
3) Because I want to squash several release activities together locally into one commit before sending it upstream. Consider:

If I have a multimodule project, with _master_ currently containing
Project A : 1.0-SNAPSHOT
Project B : 3.0-SNAPSHOT

ProjectB depends on ProjectA.

I'm going to do *2* releases
Project A 1.0 -> 1.1-SNAPSHOT
Project B 3.0 -> 3.1-SNAPSHOT

*BUT* as far as the project is concerned, I only want *1* branch. I.E:

master containing 1.1-SNAPSHOT and 3.1-SNAPSHOT
release-tag-whatever containing 1.0 and 3.0

Currently this would be a bit of a mess.. but that's ok if you don't push upstream. I can use git merge and squash magic to create this result.




> 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