| blob | 5449af1899f6588a8ae59e2f9ff4739f105d4599 |
1 <?xml version="1.0" encoding="UTF-8"?>\r
2 <!DOCTYPE sect1 SYSTEM "../../../dtd/dblite.dtd">\r
3 <sect1 id="tsvn-dug-rename">\r
4 <title>Deleting, Moving and Renaming</title>\r
5 <para>\r
6 Unlike CVS, Git allows renaming and moving of files and\r
7 folders. So there are menu entries for delete and rename\r
8 in the TortoiseGit submenu.\r
9 <figure id="tsvn-dug-renaming-dia-1">\r
10 <title>Explorer context menu for versioned files</title>\r
11 <graphic fileref="../images/ContextMenuFileControl.png"/>\r
12 </figure>\r
13 </para>\r
14 <sect2 id="tsvn-dug-rename-delete">\r
15 <title>Deleting files and folders</title>\r
16 <indexterm>\r
17 <primary>delete</primary>\r
18 </indexterm>\r
19 <indexterm>\r
20 <primary>remove</primary>\r
21 </indexterm>\r
22 <para>\r
23 Use\r
24 <menuchoice>\r
25 <guimenu>TortoiseGit</guimenu>\r
26 <guimenuitem>Delete</guimenuitem>\r
27 </menuchoice>\r
28 to remove files or folders from Git.\r
29 </para>\r
30 <para>\r
31 When you \r
32 <menuchoice>\r
33 <guimenu>TortoiseGit</guimenu>\r
34 <guimenuitem>Delete</guimenuitem>\r
35 </menuchoice>\r
36 a file, it is removed from your working tree immediately as well\r
37 as being marked for deletion in the repository on next commit.\r
38 The file's parent folder shows a <quote>deleted</quote> icon overlay.\r
39 Up until you commit the change, you can get the file back using\r
40 <menuchoice>\r
41 <guimenu>TortoiseGit</guimenu>\r
42 <guimenuitem>Revert</guimenuitem>\r
43 </menuchoice>\r
44 on the parent folder.\r
45 </para>\r
46 <para>\r
47 When you\r
48 <menuchoice>\r
49 <guimenu>TortoiseGit</guimenu>\r
50 <guimenuitem>Delete</guimenuitem>\r
51 </menuchoice>\r
52 a folder, it remains in your working tree, but the overlay\r
53 changes to indicate that it is marked for deletion.\r
54 Up until you commit the change, you can get the folder back using\r
55 <menuchoice>\r
56 <guimenu>TortoiseGit</guimenu>\r
57 <guimenuitem>Revert</guimenuitem>\r
58 </menuchoice>\r
59 on the folder itself.\r
60 This difference in behaviour between files and folders\r
61 is a part of Git, not TortoiseGit.\r
62 </para>\r
63 <para>\r
64 If you want to delete an item from the repository, but keep it\r
65 locally as an unversioned file/folder, use\r
66 <menuchoice>\r
67 <guimenu>Extended Context Menu</guimenu>\r
68 <guimenuitem>Delete (keep local)</guimenuitem>\r
69 </menuchoice>.\r
70 You have to hold the <keycap>Shift</keycap> key while right clicking on\r
71 the item in the explorer list pane (right pane) in order to see this\r
72 in the extended context menu.\r
73 </para>\r
74 <para>\r
75 If a <emphasis>file</emphasis> is deleted via the explorer\r
76 instead of using the TortoiseGit context menu, the commit\r
77 dialog shows those files and lets you remove them from\r
78 version control too before the commit. However, if you update\r
79 your working tree, Git will spot the missing file and\r
80 replace it with the latest version from the repository.\r
81 If you need to delete a version-controlled file, always use\r
82 <menuchoice>\r
83 <guimenu>TortoiseGit</guimenu>\r
84 <guimenuitem>Delete</guimenuitem>\r
85 </menuchoice> so that Git doesn't have to guess what\r
86 you really want to do.\r
87 </para>\r
88 \r
89 \r
90 <tip>\r
91 <title>Getting a deleted file or folder back</title>\r
92 <para>\r
93 If you have deleted a file or a folder and already committed\r
94 that delete operation to the repository, then a normal \r
95 <menuchoice>\r
96 <guimenu>TortoiseGit</guimenu>\r
97 <guimenuitem>Revert</guimenuitem>\r
98 </menuchoice>\r
99 can't bring it back anymore. But the file or folder is not\r
100 lost at all. If you know the revision the file or folder got\r
101 deleted (if you don't, use the log dialog to find out) open\r
102 the repository browser and switch to that revision. Then select\r
103 the file or folder you deleted, right-click and select\r
104 <menuchoice>\r
105 <guimenu>Context Menu</guimenu>\r
106 <guimenuitem>Switch/Checkout...</guimenuitem>\r
107 </menuchoice>\r
108 </para>\r
109 </tip>\r
110 </sect2>\r
111 <sect2 id="tsvn-dug-rename-move">\r
112 <title>Moving files and folders</title>\r
113 <indexterm>\r
114 <primary>rename</primary>\r
115 </indexterm>\r
116 <indexterm>\r
117 <primary>move</primary>\r
118 </indexterm>\r
119 <?dbhh topicname="HIDD_RENAME"?>\r
120 <para>\r
121 If you want to do a simple in-place rename of a file or\r
122 folder, use\r
123 <menuchoice>\r
124 <guimenu>Context Menu</guimenu>\r
125 <guimenuitem>Rename...</guimenuitem>\r
126 </menuchoice>\r
127 Enter the new name for the item and you're done.\r
128 </para>\r
129 <!--\r
130 <para>\r
131 If you want to move files around inside your working tree,\r
132 perhaps to a different sub-folder,\r
133 use the right-mouse drag-and-drop handler:\r
134 <orderedlist>\r
135 <listitem>\r
136 <para>\r
137 select the files or directories you want to move\r
138 </para>\r
139 </listitem>\r
140 <listitem>\r
141 <para>\r
142 <action>right-drag</action> them to the\r
143 new location inside the working tree\r
144 </para>\r
145 </listitem>\r
146 <listitem>\r
147 <para>\r
148 release the right mouse button\r
149 </para>\r
150 </listitem>\r
151 <listitem>\r
152 <para>\r
153 in the popup menu select\r
154 <menuchoice>\r
155 <guimenu>Context Menu</guimenu>\r
156 <guimenuitem>Git Move versioned files here</guimenuitem>\r
157 </menuchoice>\r
158 </para>\r
159 </listitem>\r
160 </orderedlist>\r
161 </para>\r
162 -->\r
163 <caution>\r
164 <title>Commit the parent folder</title>\r
165 <para>\r
166 Since renames and moves are done as a delete followed by an\r
167 add you must commit the parent folder of the renamed/moved\r
168 file so that the deleted part of the rename/move will\r
169 show up in the commit dialog. If you don't commit the removed\r
170 part of the rename/move, it will stay behind in the repository\r
171 and when your co-workers update, the old file will not be\r
172 removed. i.e. they will have <emphasis>both</emphasis> the old\r
173 and the new copies.\r
174 </para>\r
175 </caution>\r
176 <!--\r
177 <para>\r
178 You can also use the repository browser to move items around.\r
179 Read <xref linkend="tsvn-dug-repobrowser"/> to find out more.\r
180 </para>\r
181 -->\r
182 <caution>\r
183 <title>Do Not Git Move Submodule</title>\r
184 <para>\r
185 You should <emphasis>not</emphasis> use the TortoiseGit\r
186 <guilabel>Move</guilabel> or <guilabel>Rename</guilabel>\r
187 commands on a folder which has been created using\r
188 <literal>git submodule</literal>.\r
189 <!--\r
190 This action would cause the external item to be deleted from\r
191 its parent repository, probably upsetting many other people.\r
192 If you need to move an externals folder you should use an\r
193 ordinary shell move, then adjust the\r
194 <literal>svn:externals</literal> properties of the source\r
195 and destination parent folders\r
196 -->\r
197 \r
198 </para>\r
199 </caution>\r
200 </sect2>\r
201 <!--\r
202 <sect2 id="tsvn-dug-renameincase">\r
203 <title>Changing case in a filename</title>\r
204 <indexterm>\r
205 <primary>case change</primary>\r
206 </indexterm>\r
207 <?dbhh topicname="HIDD_RENAMEINCASE"?>\r
208 <para>\r
209 Making case-only changes to a filename is tricky with Git\r
210 on Windows, because for a short time during a rename, both filenames\r
211 have to exist. As Windows has a case-insensitive file system,\r
212 this does not work using the usual Rename command.\r
213 </para>\r
214 <para>\r
215 Fortunately there are (at least) two possible methods to rename a file \r
216 without losing its log history. It is important to rename it \r
217 within Git. Just renaming in the explorer will corrupt \r
218 your working tree!\r
219 </para>\r
220 <para>\r
221 Solution A) (recommended)\r
222 <orderedlist>\r
223 <listitem>\r
224 <para>\r
225 Commit the changes in your working tree.\r
226 </para>\r
227 </listitem>\r
228 <listitem>\r
229 <para>\r
230 Rename the file from UPPERcase to upperCASE directly \r
231 in the repository using the repository browser.\r
232 </para>\r
233 </listitem>\r
234 <listitem>\r
235 <para>\r
236 Update your working tree.\r
237 </para>\r
238 </listitem>\r
239 </orderedlist>\r
240 </para>\r
241 \r
242 <para>\r
243 Solution B)\r
244 <orderedlist>\r
245 <listitem>\r
246 <para>\r
247 Rename from UPPERcase to UPPERcase_ with the rename command\r
248 in the TortoiseGit submenu.\r
249 </para>\r
250 </listitem>\r
251 <listitem>\r
252 <para>\r
253 Commit the changes.\r
254 </para>\r
255 </listitem>\r
256 <listitem>\r
257 <para>\r
258 Rename from UPPERcase_ to upperCASE.\r
259 </para>\r
260 </listitem>\r
261 <listitem>\r
262 <para>\r
263 Commit the changes.\r
264 </para>\r
265 </listitem>\r
266 </orderedlist>\r
267 </para>\r
268 </sect2>\r
269 -->\r
270 <!--\r
271 <sect2 id="tsvn-dug-rename-case-conflict">\r
272 <title>Dealing with filename case conflicts</title>\r
273 <para>\r
274 If the repository already contains two files with the same name\r
275 but differing only in case (e.g. <filename>TEST.TXT</filename>\r
276 and <filename>test.txt</filename>), you\r
277 will not be able to update or checkout the parent directory\r
278 on a Windows client. Whilst Git supports case-sensitive\r
279 filenames, Windows does not.\r
280 </para>\r
281 <para>\r
282 This sometimes happens when two people commit, from separate\r
283 working trees, files which happen to have\r
284 the same name, but with a case difference. It can also happen\r
285 when files are committed from a system with a case-sensitive\r
286 file system, like Linux.\r
287 </para>\r
288 <para>\r
289 In that case, you have to decide which one of them you want to \r
290 keep and delete (or rename) the other one from the repository.\r
291 </para>\r
292 <tip>\r
293 <title>Preventing two files with the same name</title>\r
294 <para>\r
295 There is a server hook script available at: \r
296 <ulink url="http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/">\r
297 <citetitle>http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/</citetitle>\r
298 </ulink>\r
299 that will prevent checkins which result in case conflicts.\r
300 </para>\r
301 </tip>\r
302 </sect2>\r
303 -->\r
304 \r
305 <sect2 id="tsvn-dug-rename-repair">\r
306 <title>Repairing File Renames</title>\r
307 <para>\r
308 Sometimes your friendly IDE will rename files for you as part of a refactoring\r
309 exercise, and of course it doesn't tell Git. If you try to commit your\r
310 changes, Git will see the old filename as missing and the new one as\r
311 an unversioned file. You could just check the new filename to get it added in,\r
312 but you would then lose the history tracing, as Git does not know the\r
313 files are related.\r
314 </para>\r
315 <para>\r
316 A better way is to notify Git that this change is actually a rename,\r
317 and you can do this within the <guilabel>Commit</guilabel> and\r
318 <guilabel>Check for Modifications</guilabel> dialogs.\r
319 Simply select both the old name (missing) and the new name (unversioned)\r
320 and use\r
321 <menuchoice>\r
322 <guimenu>Context Menu</guimenu>\r
323 <guimenuitem>Repair Move</guimenuitem>\r
324 </menuchoice>\r
325 to pair the two files as a rename.\r
326 </para>\r
327 </sect2>\r
328 <sect2 id="tsvn-dug-rename-del-unversioned">\r
329 <title>Deleting Unversioned Files</title>\r
330 <para>\r
331 Usually you set your ignore list such that all generated files are ignored\r
332 in Git. But what if you want to clear all those ignored items to produce\r
333 a clean build? Usually you would set that in your makefile, but if you are\r
334 debugging the makefile, or changing the build system it is useful to have a way\r
335 of clearing the decks.\r
336 </para>\r
337 <para>\r
338 TortoiseGit provides just such an option using\r
339 <menuchoice>\r
340 <guimenu>Extended Context Menu</guimenu>\r
341 <guimenuitem>Delete unversioned items...</guimenuitem>\r
342 </menuchoice>.\r
343 You have to hold the <keycap>Shift</keycap> while right clicking on a folder\r
344 in the explorer list pane (right pane) in order to see this in the extended\r
345 context menu.\r
346 This will produce a dialog which lists all unversioned files anywhere in your\r
347 working tree. You can then select or deselect items to be removed.\r
348 </para>\r
349 <para>\r
350 When such items are deleted, the recycle bin is used, so if you make a mistake\r
351 here and delete a file that should have been versioned, you can still recover it.\r
352 </para>\r
353 </sect2>\r
354 </sect1>\r