[vtk-developers] RE Stupid git question #2

Wed Apr 28 04:36:40 EDT 2010

Hi John,

git makes it possible to use several kind of workflows, so I can propose 
one but others might have other ones.

I try to follow the workflow described here :
http://www.kernel.org/pub/software/scm/git/docs/v1.7.1/gitworkflows.html

The idea is to use the branch and merge mechanism of git as much as 
possible : 
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.
for each topic you want to work on, create a branch (called "mywork" 
here). This branch can be published.
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.

The workflow is then :
# do some work on mywork
git co mywork
....
git add XXX
git commit

# update master
git co master 
git pull

now if you want to test if your branch and the master branch are 
compatible, try a merge into next : 
git co next
git merge master
git merge mywork

in the last two commands, you might have conflicts to resolve by hand.
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.
(see http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html)

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.
A better way is to create a branch specifically for pushing : mywork-push. 
This one is branched from master
git co master 
git pull # to be sure you are up to date on master
git co -b mywork-push
git merge mywork # this is when the conflicts might arise

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.

Then you can push : 
git push origin/master

As I said, git allows many workflows, so do not take this as the only 
possible one. 
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. 

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.

Best
Stephane

PS : I used co as an alias for checkout above. To have the same behavior, 
do :
git config --global alias.co checkout

Stephane PLOIX
Pilote Opérationnel - Visualisation scientifique
EDF - R&D
SINETICS
1, Av du Général de Gaulle
92140 Clamart

stephane.ploix at edf.fr
Tél. : +33 (0) 1 47 65 51 10

Un geste simple pour l'environnement, n'imprimez ce message que si vous en 
avez l'utilité.

biddisco at cscs.ch 
Envoyé par : vtk-developers-bounces at vtk.org
28/04/2010 09:15

A

cc
vtk-developers at vtk.org
Objet
[vtk-developers] Stupid git question #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.

git encourages you to commit things all the time. Even when you're not 
ready.

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

I commit "Started work on feature X" , pull, commit "Got some stuff 
working", pull, commit "nearly there" etc etc

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"
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.)

I know I'm asking too much, but you can say rtfm (with a good link) if you 
want.

JB

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100428/418234a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1816 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100428/418234a5/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1151 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100428/418234a5/attachment-0003.gif>