If you push the shared branch back to origin (yes bad practice I know... so requires that everyone involved knows that the foo-feature branch will have rewrites before merge back to master)
Ordinarily you would mandate that once a commit is pushed upstream it will not be rewritten. But if you put in place a policy whereby you allow such rewrites during the merge back to master phase you can, via policy and procedures, allow such rewriting. I wouldn't be happy with such a usage myself, but I have seen people use that workflow quite successfully. On 30 April 2013 09:28, Jörg von Frantzius <joerg.frantz...@aperto.de>wrote: > Hi Stephen, > > this could probably be handled by buildnumber-plugin using the SHA by > default, and only given some optional parameter it would prefix it with the > commit number? > > Out of curiosity, how exactly is the branch shared among the team? Using a > shared filesystem? If everybody simply has a clone of that shared branch, > my guess is that still nobody should change the history of already pushed > commits. > > Regards, > Jörg > > > On 29.04.2013 20:56, Stephen Connolly wrote: > >> So you don't see a team working on a shared branch and then squashing the >> 5 >> commits it took to fix FOO-345 and re-ordering commits before pushing to >> master? >> >> All this could take place on origin too... Not saying its recommended >> workflow, but tools should be defensive otherwise you have no tools when >> things go wrong >> >> On Monday, 29 April 2013, Jörg von Frantzius wrote: >> >> Hi Stephen, >>> >>> squashing commits and so decreasing build numbers should only affect >>> builds from your local repository, as other people's or systems' builds >>> can >>> be affected only by pushing (and squashing commits after they were pushed >>> is out of question, right?) >>> >>> Then how about counting commits only of the "origin" remote repo, which >>> should not be affected by decreasing commit numbers? This would mean that >>> build numbers can increase only on fetch from origin, which would be very >>> similar to how things currently work with buildnumber-plugin and SVN. >>> >>> Technically it is of course possible to clone a repository where commits >>> get squashed after cloning or fetching, but from my understanding that >>> sounds like an insane setup. >>> >>> Regards, >>> Jörg >>> >>> On 29.04.2013 15:28, Stephen Connolly wrote: >>> >>> I don't like it as squash and rebase can result in the number decreasing >>>> again. >>>> >>>> If you want strictly increasing numbers with DVCS systems you need >>>> either: >>>> >>>> 1. A central server that hands out build numbers (SPoF anyone?) >>>> or >>>> 2. A build number based on the system time (e.g. number of seconds since >>>> the release tag was cut) >>>> >>>> Basing the number on the commit distance from the last release tag will >>>> not >>>> help when people decide to re-order their commits and squash them down >>>> to >>>> merge them to master. >>>> >>>> I favour either releasing more often (thereby removing the need to hand >>>> -SNAPSHOTs around) or just changing the way you work. >>>> >>>> To my mind, the benefits that DVCS gives far far outweigh the loss of a >>>> "commit number". YMMV and if you really cannot eliminate the need then >>>> you >>>> may be better suited to a non D VCS. >>>> >>>> [Others with stronger git-foo than me may have some nicer solutions] >>>> >>>> -Stephen >>>> >>>> >>>> On 29 April 2013 13:49, Jörg von Frantzius <joerg.frantz...@aperto.de >>>> >>>>> wrote: >>>>> >>>> [Crossposting fromu...@mojo.codehaus.org, since no reply or other >>>> >>>>> traffic over there...] >>>>> >>>>> Hi, >>>>> >>>>> it's a common requirement to automatically have sequential (i.e. >>>>> strictly >>>>> increasing) version numbers being generated, e.g. based on SVN revision >>>>> numbers. Such sequential version numbers can then be used for detection >>>>> of >>>>> updates of software modules, e.g. Netbeans modules or Magnolia modules. >>>>> >>>>> While the buildnumber-plugin does provide this for Subversion, it >>>>> doesn't >>>>> do so for Git, and there is a corresponding open issue for the >>>>> buildnumber-pluginhttps://jira**.codehaus.org/****browse/** >>>>> MBUILDNUM-93 <http://jira.codehaus.org/****browse/MBUILDNUM-93>< >>>>> https://jira.**codehaus.org/**browse/**MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93> >>>>> > >>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93> >>>>> <https://**jira.codehaus.org/browse/**MBUILDNUM-93<https://jira.codehaus.org/browse/MBUILDNUM-93> >>>>> > >>>>> >>>>> . >>>>>> >>>>> There wasn't progress on that issue since a patch was supplied one year >>>>> ago, and the problem with that patch seems to be that it replaces the >>>>> currently used SHA entirely with the number of commits. >>>>> >>>>> Git itself does provide a similar feature with git describe ( >>>>> https://www.kernel.org/pub/******software/scm/git/docs/git-******<https://www.kernel.org/pub/****software/scm/git/docs/git-****> >>>>> describe.html<https://www.**kernel.org/pub/**software/scm/** >>>>> git/docs/git-**describe.html<https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html> >>>>> > >>>>> <https://www.**kernel.org/pub/**software/scm/**git/docs/git-** >>>>> describe.html<http://kernel.org/pub/software/scm/**git/docs/git-describe.html> >>>>> <https://www.**kernel.org/pub/software/scm/** >>>>> git/docs/git-describe.html<https://www.kernel.org/pub/software/scm/git/docs/git-describe.html> >>>>> > >>>>> >>>>> ), >>>>>> >>>>> where a buildnumber is composed from commit number followed by short >>>>> SHA. A >>>>> resulting artifact version would look like this: "1.0.4-14-g2414721", >>>>> where >>>>> "1.0.4" is a manually maintained version number, and "14-g2414721" is >>>>> what >>>>> the buildnumber plugin could generate. >>>>> >>>>> For the same Git branch, resulting version numbers are strictly >>>>> increasing and can sensibly be compared and sorted. For different Git >>>>> branches, or the same branch evolving differently in separated >>>>> repositories, they at least remain distinguishable due to their SHA >>>>> short >>>>> hash. >>>>> >>>>> I'd be curious whether others also think that this approach would be >>>>> suitable for the buildnumber plugin? >>>>> >>>>> Thanks for any thoughts, >>>>> Jörg >>>>> >>>>> -- >>>>> *Dipl. inf. Jörg von Frantzius, System Architect* >>>>> >>>>> Emailmailto:joerg.frantzius@**aperto.**de <joerg.frantz...@aperto.de> >>>>> >>>>> Phone +49 30 283921-318 >>>>> Fax +49 30 283921-29 >>>>> >>>>> Aperto AG - In der Pianofabrik >>>>> Chausseestraße 5, D-10115 Berlin-Mitte >>>>> http://www.aperto.de >>>>> http://www.facebook.com/aperto >>>>> https://www.xing.com/******companies/apertoag<https://www.xing.com/****companies/apertoag> >>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag> >>>>> > >>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag> >>>>> <https://**www.xing.com/companies/**apertoag<https://www.xing.com/companies/apertoag> >>>>> > >>>>> >>>>> HRB 77049, AG Berlin Charlottenburg >>>>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen >>>>> Aufsichtsrat: Bernd Hardes (Vorsitzender) >>>>> >>>>> >>>>> -- >>> *Dipl. inf. Jörg von Frantzius, System Architect* >>> >>> Emailmailto:joerg.frantzius@**aperto.de<emailmailto%3ajoerg.frantz...@aperto.de> >>> >>> Phone +49 30 283921-318 >>> Fax +49 30 283921-29 >>> >>> Aperto AG - In der Pianofabrik >>> Chausseestraße 5, D-10115 Berlin-Mitte >>> http://www.aperto.de >>> http://www.facebook.com/aperto >>> https://www.xing.com/****companies/apertoag<https://www.xing.com/**companies/apertoag> >>> <https://**www.xing.com/companies/**apertoag<https://www.xing.com/companies/apertoag> >>> > >>> >>> HRB 77049, AG Berlin Charlottenburg >>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen >>> Aufsichtsrat: Bernd Hardes (Vorsitzender) >>> >>> > > -- > *Dipl. inf. Jörg von Frantzius, System Architect* > > Email mailto:joerg.frantzius@aperto.**de <joerg.frantz...@aperto.de> > Phone +49 30 283921-318 > Fax +49 30 283921-29 > > Aperto AG - In der Pianofabrik > Chausseestraße 5, D-10115 Berlin-Mitte > http://www.aperto.de > http://www.facebook.com/aperto > https://www.xing.com/**companies/apertoag<https://www.xing.com/companies/apertoag> > > HRB 77049, AG Berlin Charlottenburg > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen > Aufsichtsrat: Bernd Hardes (Vorsitzender) > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > >
