Berk said you should not rebase any work that has been published.  Well, since we're using submodules, the VTK repo is 'published' in the eyes of your local ParaView repo.<br><br>I'll preface this comment with 'I could be wrong and totally confused', but as far as I can tell, you need to be very careful rebasing the VTK repository.  If you rebase VTK then you are left with commits in the ParaView repository that refer to your old VTK commits, not the rebased commits.  The old VTK commits become dangling pointers, so to speak.  Git doesn't delete these dangling pointers right away though, so the ParaView repo won't complain, it will just happily checkout your old VTK commits when you run git submodule update.<br>
<br>Pat<br><br><div class="gmail_quote">On Wed, Apr 28, 2010 at 9:20 AM, Biddiscombe, John A. <span dir="ltr"><<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Berk,<br>
<br>
thanks for the extra details. I shall also do experiments with<br>
"git rebase -i"<br>
<br>
No answer is short in the git world it seems.<br>
<br>
JB<br>
<div><div></div><div class="h5"><br>
> -----Original Message-----<br>
> From: Berk Geveci [mailto:<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>]<br>
> Sent: 28 April 2010 14:07<br>
> To: Biddiscombe, John A.<br>
> Cc: VTK Developers<br>
> Subject: Re: [vtk-developers] Stupid git question #2<br>
><br>
> Great question. I'll give a short answer. Hopefully, someone with more<br>
> knowledge will elaborate.<br>
><br>
> First: In the full-blown workflow we will implement, you would<br>
> implement feature X like this. Branch from master (locally) to<br>
> implement X. Do many commits locally. When you are done, checkout<br>
> next, merge from X. Push to main repo. Check dashboard results. If not<br>
> clean, make fixes on X branch, checkout next, merge from X. Repeat<br>
> until you are convinced X works. Checkout master, merge from X. A few<br>
> things to note: you are not supposed merge/rebase X unless you need a<br>
> feature from another branch (including master). If you want to see how<br>
> X interacts with Y (or next or master), try it out in another branch<br>
> or next. The idea here is that the X branch should depend on branches<br>
> its functionality depends on. Also, you do not push branch X to the<br>
> main repo. If you want to publish it, you either merge to next and<br>
> publish that. Or you publish X on your own gitorious account (which we<br>
> host) or somewhere similar. I have to admit that I don't fully<br>
> understand why we shouldn't push arbitrary branches to the main repo.<br>
> This is workflow git developers follow btw. I think you can get more<br>
> info with "git help worflows".<br>
><br>
> Note: Next, master and X are branches.<br>
><br>
> Second: You can use "git rebase -i" to merge and/or drop commits in<br>
> your history. NOTE: never do this on a published branch (and republish<br>
> it). You are not supposed to alter published history otherwise people<br>
> would have serious problems when they pull from it. So, in the above<br>
> workflow, you can work locally on your X branch all you want. Then you<br>
> can use rebase -i to interactively cleanup your branch (merge commits,<br>
> change comments etc etc.) and then checkout next, merge, publish etc<br>
> etc. Just make sure that you do not use rebase -i on the published<br>
> part of a branch.<br>
><br>
> You are probably thinking that this is not a short answer at all.<br>
> Trust me, it is :-)<br>
><br>
> -berk<br>
><br>
> On Wed, Apr 28, 2010 at 3:14 AM, Biddiscombe, John A. <<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>><br>
> wrote:<br>
> > OK, I still don't have my submodule stuff working, but that's ok, I know<br>
> that eventually I'll find out how to wipe all my work and lose everything<br>
> .... however, in the meantime.<br>
> ><br>
> > git encourages you to commit things all the time. Even when you're not<br>
> ready.<br>
> ><br>
> > If I pull from remote/origin so that I can keep up to date every day, it<br>
> likes me to commit my stuff first - or do a stash save, pull, apply, which<br>
> is nice and avoids the problem ... but<br>
> ><br>
> > I commit "Started work on feature X" , pull, commit "Got some stuff<br>
> working", pull, commit "nearly there" etc etc<br>
> ><br>
> > now after month of rubbish tiny commits, I finally have my useful<br>
> implementation on my branch, and I rebase and want to commit my overall<br>
> changes to the official repo, but I want to avoid all the daily commits<br>
> which are meaningless on their own, and instead commit my branch feature to<br>
> the head remote with a single "New implementation of algorithm X, uses Y,<br>
>  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<br>
> all the synchronization of the repositories etc. (For example, I may make a<br>
> pull from somewhere else to get something important, and this pull needs to<br>
> 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<br>
> want.<br>
> ><br>
> > JB<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
> ><br>
> > Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
> ><br>
> > Follow this link to subscribe/unsubscribe:<br>
> > <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
> ><br>
> ><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br>