Hi Mirko,
which version of Git do you use?
i can do a git tag and get the following output:
$ git tag
extra-enforcer-rules-1.0-alpha-1
extra-enforcer-rules-1.0-alpha-2
extra-enforcer-rules-1.0-alpha-3
extra-enforcer-rules-1.0-alpha-4
extra-enforcer-rules-1.0-alpha-5
extra-enforcer-rules-1.0-beta-1
extra-enforcer-rules-1.0-beta-2
extra-enforcer-rules-1.0-beta-3
Furthermore i see the tags via gitk --all directly ?
Kind regards
Karl Heinz Marbaise
On 5/3/15 11:37 AM, Mirko Friedenhagen wrote:
Hello Baptiste,
you are right, there seem to be no real branches, so maybe it's just
the SourceTree visualisation of the tags which look like branches. Or
maybe it is because in line 107 you only push the master branch as far
as I understand it?
I just play around with "git push --all origin", see
https://github.com/mojohaus/convert-to-git/pull/24/files, have not
really time for testing (family dues :)).
The "copy for tag" commits (and the tags) seems not to be part of the
master branch, but seems to be a dangling unnamed branch? I am not a
real git guru, so maybe someone with bigger knowledge might explain
this better.
While on the one hand I see the point to mimic the svn history, the
"copy tag" command is more of a syntax or technical implementation
thing, so I for one could live with forgetting completely about the
copy commit.
E.g.: compare "git show extra-enforcer-rules-1.0-beta-3 -p" to "git
show extra-enforcer-rules-1.0-beta-3^1 -p". I think the second one is
much more informative than the first one.
I just tried "gitk" (which should be available on all platforms) and
the tags just do not show up, only when you use "git tag -l" are they
shown.
My main point is: I would like to see the tags directly when browsing
the master history.
Best Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sun, May 3, 2015 at 9:03 AM, Baptiste Mathus <bmat...@batmat.net> wrote:
Thanks for reviewing Mirko, see below.
2015-05-02 23:45 GMT+02:00 Mirko Friedenhagen <mfriedenha...@gmail.com>:
Hello Baptiste,
first of all, thanks for your efforts, mind-boggling git-vodoo :-).
One thing I noted (when inspecting the repository with SourceTree):
* When I take a look at a repository which was git from the beginning,
tags are modeled differently. Using the maven-release-plugin, they
just are attached to the commit with the message
"[maven-release-plugin] prepare release..."
Yes, this is a SVN specificity, and what you ask is indeed what we'll have
when we start releasing directly from Git.
I just re-checked, and IMO the migration is actually correct: it reflects
the SVN history as-is:
See for example the svn tag extra-enforcer-rules-1.0-alpha-5 (didn't even
intend to choose one with you, was just "serendipity" ;-)):
svn log
file:///home/tiste/MOJOHAUS-TO-GIT/SVN-MOJO-WIP/tags/extra-enforcer-rules-1.0-alpha-5
------------------------------------------------------------------------
r18435 | mfriedenhagen | 2013-06-20 20:48:55 +0200 (jeu. 20 juin 2013) | 1
ligne
[maven-release-plugin] copy for tag extra-enforcer-rules-1.0-alpha-5
------------------------------------------------------------------------
r18434 | mfriedenhagen | 2013-06-20 20:48:33 +0200 (jeu. 20 juin 2013) | 1
ligne
[maven-release-plugin] prepare release extra-enforcer-rules-1.0-alpha-5
* In the converted extra-enforcer-rules-wip, the tags are attached to
the commit with the message "[maven-release-plugin] copy for tag..."
and these commit are in extra branches with just one commit each.
Could you give precisions about that? I just re-cloned from the GH repo to
see what you mean and don't really understand where to look at.
When issuing a simple git branch -a I don't see those branches:
➜ extra-enforcer-rules-wip git:(master) git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/gh-pages
remotes/origin/master
* I do not know how to fix this, but to be consistent with future tags
I think it would be nice if we could get the tag to the "prepare
release" commit :-).
Though I see the point to be consistent with the future, I'm not sure we
should do that. IMO the migration should just mimic the svn history as close
as possible.
If we actually want to do that, it's very possible. We would just have to
overwrite each tag to the most recent "release:prepare" commit.
BUT, we would then lose weird history information like the one for the
extra-enforcer-rules-1.0-alpha-1 tag:
svn log
file:///home/tiste/MOJOHAUS-TO-GIT/SVN-MOJO-WIP/tags/extra-enforcer-rules-1.0-alpha-1
------------------------------------------------------------------------
r15258 | soelvpil | 2011-11-22 12:06:16 +0100 (mar. 22 nov. 2011) | 1 ligne
reverted wrong commit
------------------------------------------------------------------------
r13968 | stephenconnolly | 2011-04-20 11:01:39 +0200 (mer. 20 avril 2011) |
1 ligne
[maven-release-plugin] copy for tag extra-enforcer-rules-1.0-alpha-1
------------------------------------------------------------------------
r13967 | stephenconnolly | 2011-04-20 11:01:32 +0200 (mer. 20 avril 2011) |
1 ligne
[maven-release-plugin] prepare release extra-enforcer-rules-1.0-alpha-1
------------------------------------------------------------------------
Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sat, May 2, 2015 at 7:53 AM, Baptiste Mathus <bmat...@batmat.net>
wrote:
Hi,
I finally wrote a rough script yesterday that seems to work. Please
review.
https://github.com/mojohaus/convert-to-git/blob/master/convert.sh
I currently declare the repo I want to migrate in a dedicated file
(still
needs to be enriched to support sandbox and weird cases, currently only
supports trunk mojos):
https://github.com/mojohaus/convert-to-git/blob/master/repo-infos.csv
What it does currently:
for each line of the csv file above
- create an empty local git repo
- find the associated svn tags in the svn repo
- and create the right git-svn props
- git svn clone
- fix git/svn branches to be real Git tags
- by github api : create the repo under the org
- push them all
end for
The script just worked for the repos I declared (I added a suffix -wip
to
inform people it's not ready yet)
https://github.com/mojohaus/extra-enforcer-rules-wip
https://github.com/mojohaus/build-helper-maven-plugin-wip
WDYT?
Cheers
2015-05-01 21:59 GMT+02:00 Baptiste Mathus <bmat...@batmat.net>:
Hi guys,
Quick reminder, the file
https://github.com/MojoHaus/convert-to-git/blob/master/mojo-committers.list
will be used for the conversion.
For anyone inside that file *without the correct format*, git svn will
stop and refuse to continue.
So, for any line in the above file, the used format will be
"$currentValue
<noemailprovi...@codehaus.org>" (using --authors-prog option for git
svn
fetch).
Cheers
2015-04-12 23:11 GMT+02:00 Jörg Hohwiller <jo...@j-hohwiller.de>:
Hi,
plan sounds great.
+1
do you already have a (rough) roadmap/schedule? When should we stop
working in SVN, wenn will the Git repos be available?
Thanks
Jörg
Am 08.04.2015 um 09:03 schrieb Baptiste Mathus:
Forking the thread to focus around Git tinkering.
FWIW, some of you already noticed and added their mappings (svn
user=Git formatted user), but I created a small repo under MojoHaus
org.
Please contribute the missing mappings for your user id.
I also did a quick and dirty svnadmin load +Git svn clone yesterday.
The resulting (temporary) raw repository is
here: https://github.com/MojoHaus/svnrepo-gitified-wip
Here's a first draft proposal of the technical and organizational
steps we would follow (feedback needed):
1. freeze svn (put it ro and ask for a new dump from Ben)
2. Import it locally
3. Git svn clone it with the user mappings given above (without the
--stdlayout option) + push it to GitHub
Then from this monolithic big repo, write a shell script to do the
following:
4. For each plugin: git filter-branch to create a repo per plugin.
5. For site: filter-branch too
6. Check everything
WDYT?
BTW we need to PoC the site publication too and think about how to
make it not too cumbersome with all those repos there will be. If
someone can have a look that'd be great.
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
