User:Timothee Flutre/Notebook/Postdoc/2012/08/14 - Revision history

Timothee Flutre: /* About Git */ add tips about ssh tunnel and local branch which tracks remote one

Timothee Flutre — Thu, 11 Apr 2013 02:16:35 GMT

About Git: add tips about ssh tunnel and local branch which tracks remote one

←Older revision		Revision as of 02:16, 11 April 2013
Line 26:		Line 26:
	** undo uncommitted changes: <code>git checkout myfile.txt</code>		** undo uncommitted changes: <code>git checkout myfile.txt</code>
	** split a big commit in several smaller commits: <code>git add -p myfile.txt</code>		** split a big commit in several smaller commits: <code>git add -p myfile.txt</code>
-	** usual config: <code>git config --global user.name 'Timothée Flutre'; git config --global user.email 'timflutre@gmail.com'; git config --global i18n.commitEncoding 'utf8'; git config --global i18n.logOutputEncoding 'utf8'</code>	+	** usual config: <code>git config --global user.name 'Timothée Flutre'; git config --global user.email 'timflutre@gmail.com'; git config --global core.editor emacs; git config --global i18n.commitEncoding 'utf8'; git config --global i18n.logOutputEncoding 'utf8'</code>
		+	** remote via ssh tunnel: first open the tunnel <code>ssh gateway.foo.bar -l tflutre -Nf -L 20400:maincluster:22</code>, then add the remote <code>git remote add mcl ssh://tflutre@localhost:20400/home/tflutre/myproject/.git</code>


Line 68:		Line 69:
	rm -f ~ .aux .dvi .log .pdf .bbl .blg .toc		rm -f ~ .aux .dvi .log .pdf .bbl .blg .toc
	</nowiki>		</nowiki>
		+
		+
		+	* '''Two remotes''': let's imagine that on cluster1 I have 2 branches, "master" and "dev", on github I only have "master", and I want to work with "dev" on cluster2.
		+	** first I log on cluster2 and I clone the repo from github: <code>git clone https://github.com/timflutre/myproject.git</code>
		+	** then I add my repo from cluster1 as a remote: <code>cd myproject/; git remote add cluster1 ssh://tflutre@cluster1:/home/tflutre/myproject/.git</code>
		+	** finally I fetch the remotes and create a "dev" branch which tracks the one on cluster1: <code>git remote update; git checkout -b dev cluster1/dev</code>

	<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->		<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->

Timothee Flutre: /* About Git */ add tip

Timothee Flutre — Tue, 05 Mar 2013 21:26:31 GMT

About Git: add tip

←Older revision		Revision as of 21:26, 5 March 2013
Line 25:		Line 25:
	* '''Tips''':		* '''Tips''':
	** undo uncommitted changes: <code>git checkout myfile.txt</code>		** undo uncommitted changes: <code>git checkout myfile.txt</code>
		+	** split a big commit in several smaller commits: <code>git add -p myfile.txt</code>
	** usual config: <code>git config --global user.name 'Timothée Flutre'; git config --global user.email 'timflutre@gmail.com'; git config --global i18n.commitEncoding 'utf8'; git config --global i18n.logOutputEncoding 'utf8'</code>		** usual config: <code>git config --global user.name 'Timothée Flutre'; git config --global user.email 'timflutre@gmail.com'; git config --global i18n.commitEncoding 'utf8'; git config --global i18n.logOutputEncoding 'utf8'</code>

Timothee Flutre: /* About Git */ add link to example of conflict solving

Timothee Flutre — Wed, 09 Jan 2013 23:33:17 GMT

About Git: add link to example of conflict solving

←Older revision		Revision as of 23:33, 9 January 2013
Line 17:		Line 17:


-	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly. In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be master and branch2 can be dev.	+	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly (but see a concrete example [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging here]). In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be master and branch2 can be dev.
	** The first solution is to edit each conflicted files by hand, then run <code>git add fileX.txt</code> (staging indicates to git that the conflict is resolved) and finally run <code>git commit -m "merge branch2 and solve conflicts" fileX.txt</code>.		** The first solution is to edit each conflicted files by hand, then run <code>git add fileX.txt</code> (staging indicates to git that the conflict is resolved) and finally run <code>git commit -m "merge branch2 and solve conflicts" fileX.txt</code>.
	** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.		** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.

Timothee Flutre: /* About Git */ improve conflicts section

Timothee Flutre — Tue, 08 Jan 2013 22:34:05 GMT

About Git: improve conflicts section

←Older revision		Revision as of 22:34, 8 January 2013
Line 17:		Line 17:


-	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly. In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be ~~tim~~ and branch2 can be ~~master~~.	+	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly. In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be master and branch2 can be dev.
-	** The first solution is to edit ~~the~~ files by hand ~~and choose which version we want~~ to ~~keep for each~~ conflict.	+	** The first solution is to edit each conflicted files by hand, then run <code>git add fileX.txt</code> (staging indicates to git that the conflict is resolved) and finally run <code>git commit -m "merge branch2 and solve conflicts" fileX.txt</code>.
	** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.		** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.
	** The third solution, even more radical, is to "overwrite" all of branch1 with the content of the branch2, all files at once: <code>git reset --hard branch2</code>.		** The third solution, even more radical, is to "overwrite" all of branch1 with the content of the branch2, all files at once: <code>git reset --hard branch2</code>.

Timothee Flutre: /* About Git */ add Makefile for pdf

Timothee Flutre — Tue, 18 Dec 2012 16:53:38 GMT

About Git: add Makefile for pdf

←Older revision		Revision as of 16:53, 18 December 2012
Line 15:		Line 15:

	* '''Need some help''': the learning curve for git is quite steep at the beginning, so it's always worth browsing [https://help.github.com/ help pages], reading [http://gitref.org/ Git Reference], and searching for questions and answers on [http://stackoverflow.com/ stackoverflow].		* '''Need some help''': the learning curve for git is quite steep at the beginning, so it's always worth browsing [https://help.github.com/ help pages], reading [http://gitref.org/ Git Reference], and searching for questions and answers on [http://stackoverflow.com/ stackoverflow].
		+
		+
		+	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly. In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be tim and branch2 can be master.
		+	** The first solution is to edit the files by hand and choose which version we want to keep for each conflict.
		+	** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.
		+	** The third solution, even more radical, is to "overwrite" all of branch1 with the content of the branch2, all files at once: <code>git reset --hard branch2</code>.


Line 39:		Line 45:
	*** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.		*** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.
	*** To merge the content of the recently-updated local "master" into his own local branch, we do: <code>git merge master</code>.		*** To merge the content of the recently-updated local "master" into his own local branch, we do: <code>git merge master</code>.
		+	** Tips: don't version the output pdf in the repository because, as it is binary, git can't merge it properly. But you can add a Makefile (see below) and, by entering <code>make main -i</code> on the command-line, it will compile your pdf document when you need it

		+	<nowiki>
		+	all: main supp

-	* '''Conflicts''': ~~when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly~~. ~~In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be tim and branch2 can be master~~.	+	main:
-	** ~~The first solution is to edit the files by hand and choose which version we want to keep for each conflict~~.	+	latex paper_main.tex
-	** ~~The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX~~.~~txt</code>~~.	+	bibtex paper_main
-	** ~~The third solution, even more radical, is to "overwrite" all of branch1 with the content of the branch2, all files at once: <code>git reset --hard branch2~~</~~code~~>.	+	latex paper_main.tex
		+	latex paper_main.tex
		+	pdflatex paper_main
		+
		+	supp:
		+	latex paper_supplements.tex
		+	bibtex paper_supplements
		+	latex paper_supplements.tex
		+	latex paper_supplements.tex
		+	pdflatex paper_supplements
		+
		+	clean:
		+	rm -f ~ .aux .dvi .log .pdf .bbl .blg .toc
		+	</nowiki>

	<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->		<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->

Timothee Flutre: /* About Git */ put "conflicts" in a separate section

Timothee Flutre — Mon, 17 Dec 2012 14:53:15 GMT

About Git: put "conflicts" in a separate section

←Older revision		Revision as of 14:53, 17 December 2012
Line 39:		Line 39:
	*** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.		*** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.
	*** To merge the content of the recently-updated local "master" into his own local branch, we do: <code>git merge master</code>.		*** To merge the content of the recently-updated local "master" into his own local branch, we do: <code>git merge master</code>.
-	*** In case of conflicts, ~~we have~~ to edit ~~our own~~ files by hand~~. Or we can also~~ choose to ignore the conflicts and overwrite ~~our local~~ files with the content of ~~"master"~~ one file at a time: <code>git checkout --patch ~~master paper_main~~.~~tex~~</code>. ~~Even~~ more radical, ~~we can decide~~ to "overwrite" ~~our personal local branch~~ with ~~our local~~, ~~recently-updated "master" branch (~~all files at once): ~~<code>git checkout colleague1</code> followed by~~ <code>git reset --hard ~~master~~</code>.	+
		+
		+	* '''Conflicts''': when updating one branch with the content of another one (<code>git checkout branch1; git merge branch2</code>), some conflicts can happen, and it is usually hard to know how to solve them properly. In the following, branch1 can be master and branch2 can be origin/master, or branch1 can be tim and branch2 can be master.
		+	** The first solution is to edit the files by hand and choose which version we want to keep for each conflict.
		+	** The second solution is to ignore the conflicts and overwrite the files of branch1 with the content of branch2, one file at a time: <code>git checkout --patch branch2 fileX.txt</code>.
		+	** The third solution, even more radical, is to "overwrite" all of branch1 with the content of the branch2, all files at once: <code>git reset --hard branch2</code>.

	<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->		<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->

Timothee Flutre: /* About Git */ add tip on config

Timothee Flutre — Thu, 06 Dec 2012 01:48:53 GMT

About Git: add tip on config

←Older revision		Revision as of 01:48, 6 December 2012
Line 19:		Line 19:
	* '''Tips''':		* '''Tips''':
	** undo uncommitted changes: <code>git checkout myfile.txt</code>		** undo uncommitted changes: <code>git checkout myfile.txt</code>
		+	** usual config: <code>git config --global user.name 'Timothée Flutre'; git config --global user.email 'timflutre@gmail.com'; git config --global i18n.commitEncoding 'utf8'; git config --global i18n.logOutputEncoding 'utf8'</code>

Timothee Flutre: /* About Git */ add tip

Timothee Flutre — Thu, 15 Nov 2012 14:32:10 GMT

About Git: add tip

←Older revision		Revision as of 14:32, 15 November 2012
Line 15:		Line 15:

	* '''Need some help''': the learning curve for git is quite steep at the beginning, so it's always worth browsing [https://help.github.com/ help pages], reading [http://gitref.org/ Git Reference], and searching for questions and answers on [http://stackoverflow.com/ stackoverflow].		* '''Need some help''': the learning curve for git is quite steep at the beginning, so it's always worth browsing [https://help.github.com/ help pages], reading [http://gitref.org/ Git Reference], and searching for questions and answers on [http://stackoverflow.com/ stackoverflow].
		+
		+
		+	* '''Tips''':
		+	** undo uncommitted changes: <code>git checkout myfile.txt</code>

Timothee Flutre: /* About Git */ improve readability

Timothee Flutre — Thu, 01 Nov 2012 22:48:34 GMT

About Git: improve readability

←Older revision		Revision as of 22:48, 1 November 2012
Line 18:		Line 18:

	* '''Writing a paper''': in this example, I am writing a paper with two colleagues. We decide to do it as a [http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows centralized workflow], the shared repository being hosted by [https://github.com/ github].		* '''Writing a paper''': in this example, I am writing a paper with two colleagues. We decide to do it as a [http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows centralized workflow], the shared repository being hosted by [https://github.com/ github].
-	** Each of us needs to [https://github.com/signup/free create a free account].	+	** Setting up the infrastructure:
-	** I need to upgrade my account in order to have the right to manage private repositories ([https://github.com/plans/ $7/month]).	+	*** Each of us needs to [https://github.com/signup/free create a free account].
-	** I create a private repository named "paper" and add my colleagues as collaborators to it.	+	*** I need to upgrade my account in order to have the right to manage private repositories ([https://github.com/plans/ $7/month]).
-	** I retrieve the repository on my local machine: <code>git clone git://github.com/timflutre/paper.git</code>	+	*** I create a private repository named "paper" and add my colleagues as collaborators to it.
-	** I create my first file, for instance "paper_main.tex", and add it to git in my local repository: <code>git add paper_main.tex</code> followed by <code>git commit -m "first commit" paper_main.tex</code>.	+	*** I retrieve the repository on my local machine: <code>git clone git://github.com/timflutre/paper.git</code>
-	** I create one branch per collaborator (the default branch being "master"): <code>git branch tim</code>, then <code>git branch colleague1</code> and finally <code>git branch colleague2</code>. I can list the local branches with <code>git branch</code> and I can switch to my branch with <code>git checkout tim</code> for instance.	+	*** I create my first file, for instance "paper_main.tex", and add it to git in my local repository: <code>git add paper_main.tex</code> followed by <code>git commit -m "first commit" paper_main.tex</code>.
-	** I push the changes I made from my local repo onto github: <code>git push origin master</code>, this for each branch I created.	+	*** I create one branch per collaborator (the default branch being "master"): <code>git branch tim</code>, then <code>git branch colleague1</code> and finally <code>git branch colleague2</code>. I can list the local branches with <code>git branch</code> and I can switch to my branch with <code>git checkout tim</code> for instance.
-	** I send an email to my colleagues telling them that they can retrieve the content of the repository from github into their local machine(s): <code>git clone https://github.com/timflutre/paper.git</code>.	+	*** I push the changes I made from my local repo onto github: <code>git push origin master</code>, this for each branch I created.
-	** Each of us can make modifications on its own branch, and push them on github in order to allow the others to access the changes: <code>git push origin colleague1</code> for instance.	+	*** I send an email to my colleagues telling them that they can retrieve the content of the repository from github into their local machine(s): <code>git clone https://github.com/timflutre/paper.git</code>.
-	** From time to time, one of us has the responsibility to merge the changes and update the "master" branch with the latest version.	+	** Typical working cycle:
-	** Once this is done, the others need to retrieve the new content of "master" in their local repo: <code>git checkout master</code>, <code>git fetch origin</code>, <code>git diff master origin/master</code>, <code>git merge origin/master</code>.	+	*** Each of us can make modifications on its own branch, and push them on github in order to allow the others to access the changes: <code>git push origin colleague1</code> for instance.
-	** Then, they need to update their local branch with the new content of "master": <code>git checkout colleague1</code>, <code>git diff --name-status colleague1..master</code>. This will list the files having differences between their local branch and the new content of "master".	+	*** From time to time, one of us has the responsibility to merge the changes and update the "master" branch with the latest version.
-	** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.	+	*** Once this is done, the others need to retrieve the new content of "master" in their local repo: <code>git checkout master</code>, <code>git fetch origin</code>, <code>git diff master origin/master</code>, <code>git merge origin/master</code>.
-	** To merge the content of "master" into his own branch, we do: <code>git merge master</code>.	+	*** Then, they need to update their local branch with the new content of "master": <code>git checkout colleague1</code>, <code>git diff --name-status colleague1..master</code>. This will list the files having differences between their local branch and the new content of "master".
-	** In case of conflicts, we have to edit our own files by hand. Or we can also choose to ignore the conflicts and overwrite our local files with the content of "master" one file at a time: <code>git checkout --patch master paper_main.tex</code>. Even more radical, we can decide to "overwrite" our personal local branch with our local, recently-updated "master" branch (all files at once): <code>git checkout colleague1</code> followed by <code>git reset --hard master</code>.	+	*** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.
		+	*** To merge the content of the recently-updated local "master" into his own local branch, we do: <code>git merge master</code>.
		+	*** In case of conflicts, we have to edit our own files by hand. Or we can also choose to ignore the conflicts and overwrite our local files with the content of "master" one file at a time: <code>git checkout --patch master paper_main.tex</code>. Even more radical, we can decide to "overwrite" our personal local branch with our local, recently-updated "master" branch (all files at once): <code>git checkout colleague1</code> followed by <code>git reset --hard master</code>.

	<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->		<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->

Timothee Flutre: /* About Git */ add git reset

Timothee Flutre — Thu, 25 Oct 2012 16:39:00 GMT

About Git: add git reset

←Older revision		Revision as of 16:39, 25 October 2012
Line 32:		Line 32:
	** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.		** One can look at the differences file by file: <code>git diff --color-words colleague1:paper_main.tex master:paper_main.tex</code>. The options "--color-words" is especially useful in LaTeX.
	** To merge the content of "master" into his own branch, we do: <code>git merge master</code>.		** To merge the content of "master" into his own branch, we do: <code>git merge master</code>.
-	** In case of conflicts, we have to edit our own files by hand. Or we can also choose to ignore the conflicts and overwrite our local files with the content of "master": <code>git checkout --patch master paper_main.tex</code>.	+	** In case of conflicts, we have to edit our own files by hand. Or we can also choose to ignore the conflicts and overwrite our local files with the content of "master" one file at a time: <code>git checkout --patch master paper_main.tex</code>. Even more radical, we can decide to "overwrite" our personal local branch with our local, recently-updated "master" branch (all files at once): <code>git checkout colleague1</code> followed by <code>git reset --hard master</code>.

	<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->		<!-- ##### DO NOT edit below this line unless you know what you are doing. ##### -->