docs/repository.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   2 <html lang="en">
   3 <head>
   4   <meta http-equiv="content-type" content="text/html; charset=utf-8">
   5   <title>Source Code Repository</title>
   6   <link rel="stylesheet" type="text/css" href="mesa.css">
   7 </head>
   8 <body>
   9
  10 <div class="header">
  11   The Mesa 3D Graphics Library
  12 </div>
  13
  14 <iframe src="contents.html"></iframe>
  15 <div class="content">
  16
  17 <h1>Source Code Repository</h1>
  18
  19 <p>
  20 Mesa uses <a href="https://git-scm.com">git</a>
  21 as its source code management system.
  22 </p>
  23
  24 <p>
  25 The master git repository is hosted on
  26 <a href="https://www.freedesktop.org">freedesktop.org</a>.
  27 </p>
  28
  29 <p>
  30 You may access the repository either as an
  31 <a href="#anonymous">anonymous user</a> (read-only) or as a
  32 <a href="#developer">developer</a>
  33 (read/write).
  34 </p>
  35
  36 <p>
  37 You may also
  38 <a href="https://gitlab.freedesktop.org/mesa/mesa"
  39 >browse the main Mesa git repository</a> and the
  40 <a href="https://gitlab.freedesktop.org/mesa/demos"
  41 >Mesa demos and tests git repository</a>.
  42 </p>
  43
  44
  45 <h2 id="anonymous">Anonymous git Access</h2>
  46
  47 <p>
  48 To get the Mesa sources anonymously (read-only):
  49 </p>
  50
  51 <ol>
  52 <li>Install the git software on your computer if needed.
  53 <li>Get an initial, local copy of the repository with:
  54     <pre>git clone https://gitlab.freedesktop.org/mesa/mesa.git</pre>
  55 <li>Later, you can update your tree from the master repository with:
  56     <pre>git pull origin</pre>
  57 <li>If you also want the Mesa demos/tests repository:
  58     <pre>git clone https://gitlab.freedesktop.org/mesa/demos.git</pre>
  59 </ol>
  60
  61
  62 <h2 id="developer">Developer git Access</h2>
  63
  64 <p>
  65 If you wish to become a Mesa developer with gitlab merge privilege, please
  66 follow this procedure:
  67 </p>
  68 <ol>
  69 <li>Subscribe to the
  70 <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">mesa-dev</a>
  71 mailing list.
  72 <li>Start contributing to the project by
  73 <a href="submittingpatches.html" target="_parent">submitting patches</a>.  Specifically,
  74 <ul>
  75 <li>Use <a href="https://gitlab.freedesktop.org/">gitlab</a> to create your merge requests.
  76 <li>Wait for someone to review the code and give you a <code>Reviewed-by</code>
  77 statement.
  78 <li>You'll have to rely on another Mesa developer to push your initial patches
  79 after they've been reviewed.
  80 </ul>
  81 <li>After you've demonstrated the ability to write good code and have had
  82 a dozen or so patches accepted, a maintainer may use their discretion to give
  83 you access to merge your own code.
  84 </ol>
  85
  86 <h2>Pushing code to your gitlab account via HTTPS</h2>
  87
  88 <p>Useful for people behind strict proxies</p>
  89
  90 You can use <a href="https://gitlab.freedesktop.org/profile/personal_access_tokens">personal access tokens</a>
  91 to push over HTTPS if ssh will does not suit your needs.
  92 In this case, create a token, and put it in the url as shown here:
  93 <pre>
  94 git remote set-url --push <em>origin</em> https://<em>USER</em>:<em>TOKEN</em>@gitlab.freedesktop.org/your~user~name/mesa.git
  95 </pre>
  96
  97 <h2>Windows Users</h2>
  98
  99 <p>
 100 If you're <a href="https://git.wiki.kernel.org/index.php/WindowsInstall">
 101 using git on Windows</a> you'll want to enable automatic CR/LF conversion in
 102 your local copy of the repository:
 103 </p>
 104 <pre>
 105 git config --global core.autocrlf true
 106 </pre>
 107
 108 <p>
 109 This will cause git to convert all text files to CR+LF on checkout,
 110 and to LF on commit.
 111 </p>
 112 <p>
 113 Unix users don't need to set this option.
 114 </p>
 115
 116
 117 <h2>Development Branches</h2>
 118
 119 <p>
 120 At any given time, there may be several active branches in Mesa's
 121 repository.
 122 Generally, <code>master</code> contains the latest development (unstable)
 123 code while a branch has the latest stable code.
 124 </p>
 125
 126 <p>
 127 The command <code>git branch</code> will list all available branches.
 128 </p>
 129
 130 <p>
 131 Questions about branch status/activity should be posted to the
 132 mesa-dev mailing list.
 133 </p>
 134
 135 <h2>Developer Git Tips</h2>
 136
 137 <ol>
 138 <li>Setting up to edit the master branch
 139 <p>
 140 If you try to do a pull by just saying<code> git pull </code>
 141 and git complains that you have not specified a
 142 branch, try:
 143 <pre>
 144 git config branch.master.remote origin
 145 git config branch.master.merge master
 146 </pre>
 147 <p>
 148 Otherwise, you have to say<code> git pull origin master </code>
 149 each time you do a pull.
 150 </p>
 151 <li>Small changes to master
 152 <p>
 153 If you are an experienced git user working on substantial modifications,
 154 you are probably
 155 working on a separate branch and would rebase your branch prior to
 156 merging with master.
 157 But for small changes to the master branch itself,
 158 you also need to use the rebase feature in order to avoid an
 159 unnecessary and distracting branch in master.
 160 </p>
 161 <p>
 162 If it has been awhile since you've done the initial clone, try
 163 <pre>
 164 git pull
 165 </pre>
 166 <p>
 167 to get the latest files before you start working.
 168 </p>
 169 <p>
 170 Make your changes and use
 171 <pre>
 172 git add &lt;files to commit&gt;
 173 git commit
 174 </pre>
 175 <p>
 176 to get your changes ready to push back into the fd.o repository.
 177 </p>
 178 <p>
 179 It is possible (and likely) that someone has changed master since
 180 you did your last pull.  Even if your changes do not conflict with
 181 their changes, git will make a fast-forward
 182 merge branch, branching from the point in time
 183 where you did your last pull and merging it to a point after the other changes.
 184 </p>
 185 <p>
 186 To avoid this,
 187 <pre>
 188 git pull --rebase
 189 git push
 190 </pre>
 191 <p>
 192 If you are familiar with CVS or similar system, this is similar to doing a
 193 <code> cvs update </code> in order to update your source tree to
 194 the current repository state, instead of the time you did the last update.
 195 (CVS doesn't work like git in this respect, but this is easiest way
 196 to explain it.)
 197 </p>
 198 <p>
 199 In any case, your repository now looks like you made your changes after
 200 all the other changes.
 201 </p>
 202 <p>
 203 If the rebase resulted in conflicts or changes that could affect
 204 the proper operation of your changes, you'll need to investigate
 205 those before doing the push.
 206 </p>
 207 <p>
 208 If you want the rebase action to be the default action, then
 209 <pre>
 210 git config branch.master.rebase true
 211 git config --global branch.autosetuprebase=always
 212 </pre>
 213 <p>
 214 See <a href="https://www.eecs.harvard.edu/~cduan/technical/git/">Understanding Git Conceptually</a> for a fairly clear explanation about all of this.
 215 </p>
 216 </ol>
 217
 218 </div>
 219 </body>
 220 </html>