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
|
Source Code Repository
======================
Mesa uses `git <https://git-scm.com>`__ as its source code management
system.
The master git repository is hosted on
`freedesktop.org <https://www.freedesktop.org>`__.
You may access the repository either as an :ref:`anonymous
user <anonymous>` (read-only) or as a :ref:`developer <developer>`
(read/write).
You may also `browse the main Mesa git
repository <https://gitlab.freedesktop.org/mesa/mesa>`__ and the `Mesa
demos and tests git
repository <https://gitlab.freedesktop.org/mesa/demos>`__.
.. _anonymous:
Anonymous git Access
--------------------
To get the Mesa sources anonymously (read-only):
#. Install the git software on your computer if needed.
#. Get an initial, local copy of the repository with:
::
git clone https://gitlab.freedesktop.org/mesa/mesa.git
#. Later, you can update your tree from the master repository with:
::
git pull origin
#. If you also want the Mesa demos/tests repository:
::
git clone https://gitlab.freedesktop.org/mesa/demos.git
.. _developer:
Developer git Access
--------------------
If you wish to become a Mesa developer with gitlab merge privilege,
please follow this procedure:
#. Subscribe to the
`mesa-dev <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`__
mailing list.
#. Start contributing to the project by :doc:`submitting
patches <submittingpatches>`. Specifically,
- Use `gitlab <https://gitlab.freedesktop.org/>`__ to create your
merge requests.
- Wait for someone to review the code and give you a ``Reviewed-by``
statement.
- You'll have to rely on another Mesa developer to push your initial
patches after they've been reviewed.
#. After you've demonstrated the ability to write good code and have had
a dozen or so patches accepted, a maintainer may use their discretion
to give you access to merge your own code.
Pushing code to your gitlab account via HTTPS
---------------------------------------------
Useful for people behind strict proxies
You can use `personal access
tokens <https://gitlab.freedesktop.org/profile/personal_access_tokens>`__
to push over HTTPS if ssh will does not suit your needs. In this case,
create a token, and put it in the url as shown here:
::
git remote set-url --push origin https://USER:TOKEN@gitlab.freedesktop.org/your~user~name/mesa.git
Windows Users
-------------
If you're `using git on
Windows <https://git.wiki.kernel.org/index.php/WindowsInstall>`__ you'll
want to enable automatic CR/LF conversion in your local copy of the
repository:
::
git config --global core.autocrlf true
This will cause git to convert all text files to CR+LF on checkout, and
to LF on commit.
Unix users don't need to set this option.
Development Branches
--------------------
At any given time, there may be several active branches in Mesa's
repository. Generally, ``master`` contains the latest development
(unstable) code while a branch has the latest stable code.
The command ``git branch`` will list all available branches.
Questions about branch status/activity should be posted to the mesa-dev
mailing list.
Developer Git Tips
------------------
#. Setting up to edit the master branch
If you try to do a pull by just saying\ ``git pull`` and git
complains that you have not specified a branch, try:
::
git config branch.master.remote origin
git config branch.master.merge master
Otherwise, you have to say\ ``git pull origin master`` each time you
do a pull.
#. Small changes to master
If you are an experienced git user working on substantial
modifications, you are probably working on a separate branch and
would rebase your branch prior to merging with master. But for small
changes to the master branch itself, you also need to use the rebase
feature in order to avoid an unnecessary and distracting branch in
master.
If it has been awhile since you've done the initial clone, try
::
git pull
to get the latest files before you start working.
Make your changes and use
::
git add <files to commit>
git commit
to get your changes ready to push back into the fd.o repository.
It is possible (and likely) that someone has changed master since you
did your last pull. Even if your changes do not conflict with their
changes, git will make a fast-forward merge branch, branching from
the point in time where you did your last pull and merging it to a
point after the other changes.
To avoid this,
::
git pull --rebase
git push
If you are familiar with CVS or similar system, this is similar to
doing a ``cvs update`` in order to update your source tree to the
current repository state, instead of the time you did the last
update. (CVS doesn't work like git in this respect, but this is
easiest way to explain it.)
In any case, your repository now looks like you made your changes
after all the other changes.
If the rebase resulted in conflicts or changes that could affect the
proper operation of your changes, you'll need to investigate those
before doing the push.
If you want the rebase action to be the default action, then
::
git config branch.master.rebase true
git config --global branch.autosetuprebase=always
See `Understanding Git
Conceptually <https://www.eecs.harvard.edu/~cduan/technical/git/>`__
for a fairly clear explanation about all of this.
|
