<br><font size=2 face="sans-serif">Hi John,</font>
<br>
<br><font size=2 face="sans-serif">git makes it possible to use several
kind of workflows, so I can propose one but others might have other ones.</font>
<br>
<br><font size=2 face="sans-serif">I try to follow the workflow described
here :</font>
<br><font size=2 face="sans-serif">http://www.kernel.org/pub/software/scm/git/docs/v1.7.1/gitworkflows.html<br>
</font>
<br><font size=2 face="sans-serif">The idea is to use the branch and merge
mechanism of git as much as possible : </font>
<br><font size=2 face="sans-serif">you will always have the "master"
branch which is following the official vtk. NEVER merge anything of your
own in this branch, this one will only be used for pulling from origin.</font>
<br><font size=2 face="sans-serif">for each topic you want to work on,
create a branch (called "mywork" here). This branch can be published.</font>
<br><font size=2 face="sans-serif">and create an integration branch (called
"next" here). This one is a throw-away branch from which you
should never base any work. It is used to test merging the master and the
topic(s) branches and its history can be rewritten anytime.</font>
<br>
<br><font size=2 face="sans-serif">The workflow is then :</font>
<br><font size=2 face="sans-serif"># do some work on mywork</font>
<br><font size=2 face="sans-serif">git co mywork</font>
<br><font size=2 face="sans-serif">....</font>
<br><font size=2 face="sans-serif">git add XXX</font>
<br><font size=2 face="sans-serif">git commit</font>
<br>
<br><font size=2 face="sans-serif"># update master</font>
<br><font size=2 face="sans-serif">git co master </font>
<br><font size=2 face="sans-serif">git pull</font>
<br>
<br><font size=2 face="sans-serif">now if you want to test if your branch
and the master branch are compatible, try a merge into next : </font>
<br><font size=2 face="sans-serif">git co next</font>
<br><font size=2 face="sans-serif">git merge master</font>
<br><font size=2 face="sans-serif">git merge mywork<br>
</font>
<br><font size=2 face="sans-serif">in the last two commands, you might
have conflicts to resolve by hand.</font>
<br><font size=2 face="sans-serif">If you do not want to always resolve
the same conflicts again and again, enable the rerere option in git. This
way, git will remember how your resolved a given confict, and will apply
the same resolution if it sees the same confict.</font>
<br><font size=2 face="sans-serif">(see http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html)</font>
<br>
<br><font size=2 face="sans-serif">When you want to push your work, you
can either push the mywork branch to origin/master. In this case, you might
have a lot of conflicts to resolve, especially if you did not enable rerere.</font>
<br><font size=2 face="sans-serif">A better way is to create a branch specifically
for pushing : mywork-push. This one is branched from master</font>
<br><font size=2 face="sans-serif">git co master </font>
<br><font size=2 face="sans-serif">git pull # to be sure you are up to
date on master</font>
<br><font size=2 face="sans-serif">git co -b mywork-push</font>
<br><font size=2 face="sans-serif">git merge mywork # this is when the
conflicts might arise</font>
<br>
<br><font size=2 face="sans-serif">this is basically the equivalent of
rebasing your work on master, but since your mywork branch may have been
published, it is a very bad idea to modify its history.</font>
<br>
<br><font size=2 face="sans-serif">Then you can push : </font>
<br><font size=2 face="sans-serif">git push origin/master</font>
<br>
<br><font size=2 face="sans-serif">As I said, git allows many workflows,
so do not take this as the only possible one. </font>
<br><font size=2 face="sans-serif">For instance, you could rebase your
topic branches on master each time you pull master, but this does not enables
you to publish your topic branches. </font>
<br><font size=2 face="sans-serif">Yet another possibility is to periodically
merge master into mywork, but this way, the history of mywork is cluttered
with all the merge commits, and you cannot rebase mywork on master anymore.</font>
<br>
<br><font size=2 face="sans-serif">Best</font>
<br><font size=2 face="sans-serif">Stephane</font>
<br>
<br><font size=2 face="sans-serif">PS : I used co as an alias for checkout
above. To have the same behavior, do :</font>
<br><font size=2 face="sans-serif">git config --global alias.co checkout<br>
</font>
<table>
<tr valign=top>
<td rowspan=2><font size=2 face="sans-serif"> </font><img src=cid:_1_0953B1940953ADAC002F1F24C1257713><font size=2 face="sans-serif">
</font>
<td><font size=1 face="sans-serif"> </font>
<tr valign=top>
<td><font size=1 color=#ff8100 face="Arial"><b>Stephane PLOIX</b></font><font size=1 color=#ff8100 face="Arial"><b><br>
Pilote Opérationnel - Visualisation scientifique</b></font><font size=1 color=#0062e1 face="Arial"><br>
EDF - R&D<br>
SINETICS<br>
1, Av du Général de Gaulle<br>
92140 Clamart</font><font size=1 color=#0062e1 face="sans-serif"><br>
</font>
<br><font size=1 color=#0062e1 face="Arial"><b>stephane.ploix@edf.fr</b></font>
<br><font size=1 color=#0062e1 face="Arial">Tél. : +33 (0) 1 47 65 51
10</font>
<tr>
<td valign=top><font size=2 face="sans-serif"> </font><img src=cid:_1_0953C0D40953BCEC002F1F24C1257713><font size=2 face="sans-serif">
</font>
<td><font size=1 color=#0062e1 face="Arial">Un geste simple pour l'environnement,
n'imprimez ce message que si vous en avez l'utilité.</font></table>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>biddisco@cscs.ch</b> </font>
<br><font size=1 face="sans-serif">Envoyé par : vtk-developers-bounces@vtk.org</font>
<p><font size=1 face="sans-serif">28/04/2010 09:15</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">A</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">vtk-developers@vtk.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Objet</font></div>
<td><font size=1 face="sans-serif">[vtk-developers] Stupid git question
#2</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>OK, I still don't have my submodule stuff working,
but that's ok, I know that eventually I'll find out how to wipe all my
work and lose everything .... however, in the meantime.<br>
<br>
git encourages you to commit things all the time. Even when you're not
ready.<br>
<br>
If I pull from remote/origin so that I can keep up to date every day, it
likes me to commit my stuff first - or do a stash save, pull, apply, which
is nice and avoids the problem ... but<br>
<br>
I commit "Started work on feature X" , pull, commit "Got
some stuff working", pull, commit "nearly there" etc etc<br>
<br>
now after month of rubbish tiny commits, I finally have my useful implementation
on my branch, and I rebase and want to commit my overall changes to the
official repo, but I want to avoid all the daily commits which are meaningless
on their own, and instead commit my branch feature to the head remote with
a single "New implementation of algorithm X, uses Y, and Z other
algorithms to do this and that and supports options blah"<br>
How can you turn all the little commits into a proper one? - and not lose
all the synchronization of the repositories etc. (For example, I may make
a pull from somewhere else to get something important, and this pull needs
to be preserved in the log history of commits in the remote etc.)<br>
<br>
I know I'm asking too much, but you can say rtfm (with a good link) if
you want.<br>
<br>
JB<br>
<br>
<br>
_______________________________________________<br>
Powered by www.kitware.com<br>
<br>
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<br>
<br>
Follow this link to subscribe/unsubscribe:<br>
http://www.vtk.org/mailman/listinfo/vtk-developers<br>
<br>
</font></tt>
<br><pre>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________
This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
</pre>