1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Asterisk GIT HOWTO
==================
Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This document will instruct you how to setup a local git mirror of the
Asterisk SVN repository.
Why would you want that? for starters, it's a fast repository browser
and works well even when offline. More on why and why not at 'Pros and Cons'
in the end of this document.
Setup
-----
Make sure you have the package
git-svn
installed. It is part of the standard git distribution and included in
any recent Linux distribution.
TODO: add a few words about gen_authors and -A ../asterisk-tools/AUTHORS
Next, get the files from this repository:
git clone http://git.tzafrir.org.il/git/asterisk-tools.git
Which will create the subdirectory 'asterisk-tools' under your working
directory. For the purpose of this HOWTO I assume that you will later
download Asterisk under the same directory.
Now let's get Asterisk:
git svn clone -r1-47393,47395:HEAD -s http://svn.asterisk.org/svn/asterisk
The explicit list of revisions is intended to avoid one specific revision
that cuases problems if you use git >= 1.6 , as it has an invalid ref
name (a tag name that ends with a '.')
See also below regarding an AUTHORS file if you want revisions to have
proper names and emails in the Author field. Not required, but will
provide you with a nicer log.
This will download the whole /trunk , /tags and /branches hirarchies
to a new git repository under asterisk/ .
This will take a L O N G time. In the order of magnitude of a
day. If it stops: in the middle:
#cd asterisk; git svn fetch -r1-47393 --fetch-all
#cd asterisk; git svn fetch -r47395:HEAD --fetch-all
All commands as of this point are run from the newly-created subdirectory
'asterisk'
cd asterisk
Next make your repository more compact:
FIXME: I now get a .git subdirectory of the size of 210MB . This seems
overly large considering what I got a few monthes ago. Note that with
git >= 1.6 this is already done automatically.
git repack -ad
Now fix the menuselect bits. One possible venue is to use submodules.
This would require setting a separate menuselect repository . And
fixing the submodule references in every new tag to point to the right
place. I gave up at this stage, and instead reimplememented menuselect
cp -a ../asterisk-tools/menuselect menuselect
make -C menuselect dummies
chmod +x menuselect/menuselect
Next thing to do is ignore generated files. .gitignore is somewhat
like svn:ignore . Though it is possible to use one at the top
directory. Hence I decided to make it ignore itself as well:
cp ../asterisk-tools/asterisk_gitignore .gitignore
# To also keep proper email of authors, as above:
git config --add svn.authorsfile AUTHORS
Now let's generate tags that will point to the tags/* branches.
e.g. tag 'v1.4.8' will point to the head of branch tags/1.4.8 .
If you don't like the extra 'v', just edit the sed command.
../asterisk-tools/update-tags
Example configuration (refer to menuselect/menuselelct for more
information). For instance: res_snmp breaks building 1.4 from git:
echo 'exclude res_snmp' >build_tools/conf
Update
------
The main Asterisk repository tends to get new commits occasionally. I
suppose you want those updates in your local copy. The following command
should normally be done from the master branch. If you actually use branches, it is recommended to switch to it beforehand:
git checkout master
Next: get all updates:
git svn rebase --fetch-all
Author Names
------------
With git, every commit is normally identified by an author (with a name
and an email). In SVN commits are only identified by a Subversion
username. git-svn will normally just generate a dummy email from that
username. But in many cases it would be useful to have proper name and
email address for each username from the Subversion repository. This is
normally done with an AUTHORS file: a file that identifies the name an
email of every user. It has lines such as:
jond = John Doe <john_doe@example.org>
The asterisk-tools repository has a script to generate such a file,
mostly from the data in the 'authors' file in the repotools repository:
../asterisk-tools/gen_authors >AUTHORS
Note that this translation is done when revisions are fetched from the
remote SVN repository to your local git repository. That is: for most
revisions this happens at the time of the initial clone. Later on if you
use 'git svn fetch' or 'git svn rebase' it will also be used. It cannot
change the author field for revisions that were already fetched.
To use it in the initial clone:
asterisk-tools/gen_authors >AUTHORS
git svn clone --authors-file AUTHORS -s http://svn.asterisk.org/svn/asterisk
If the repository already exists, you can set the file to be used for
further fetches:
git config --add svn.authorsfile ../AUTHORS
Usage
-----
If you use git from the command-line, it is highly recommended to enable
programmable bash completion. The git command-line is way more complex
than svn, but the completion makes it usable:
asterisk$ git show v1.2.28<tab><tab>
v1.2.28 v1.2.28.1
asterisk$ git show v1.2.28:c<tab><tab>
callerid.c channel.c cli.c coef_out.h contrib/
cdr/ channels/ codecs/ config.c cryptostub.c
cdr.c chanvars.c coef_in.h configs/ cygwin/
asterisk$ git svn<tab><tab>
clone fetch log set-tree
commit-diff find-rev propget show-externals
create-ignore info proplist show-ignore
dcommit init rebase
asterisk$ git svn rebase --f
--fetch-all --follow-parent
Some useful commands:
git svn rebase --fetch-all # pull updates from upstream
man git-FOO # documentation for 'git FOO'
# <tree> is any place on graph of branches: HEAD, name of a branch or
# a tag, commit ID, and some others
git show <tree> # The top commit in this tree (log + diff)
git show <tree>:directory # directory listing
git show <tree>:some/file # get that file
git log <tree> # commit log up to that point
git branch # shows local branches and in which one you are
git branch -r # List remote branches. Such are SVN ones.
For more information, see the man page gittutorial as well as
http://git-scm.com/documentation
Pros and Cons
-------------
===The good:
Working off-line::
If you want to be able to use 'svn log' and 'svn diff' to a different
branch, now you can.
Efficient repository browser::
With git you can effectively browse commit logs and working copies of
various branches. In fact, using it merely as a logs and versions
browser can be useful on its own.
Branches really work::
With SVN merging a branch is complicated. Partially because lack of
separate merge tracking.With git you don't need the extra svnmerge:
changes that don't collide with your branch merge in a quick merge
operation.
===Limitations:
svn:externals ::
does not really work well with git-svn (and similar systems: svk,
bzr-svn and hg-svn). Git has something called submodules that allows
emulating the basic functionality of svn:externals, but is not as
transparent.
Commiting::
Not sure how safe it is to commit from such a copy. In most places I
see that it is not recommended to commit directly from git-svn. OTOH,
git has some tools that make it easy to prepare a patch set out of a
branch (e.g. git format-patch).
IIRC there are also some issues for git-svn with https certificate
authentication in the first place.
Tags::
/tags are branches. SVN tags are really branches that we pretend not
to change. And in fact in Asterisk we practically do change. But see
workaround below to generate tags from the tag branches.
/team branches::
At least with git 1.5.x you can't easily follow all the team branches.
This is due to a bug in their handling of wildcards in branches
description. I believe this has been resolved in 1.6 but I didn't get
to test that. Even if it will, it will require an extra step of manual
editing.
|
