[vtk-developers] Stupid git question #2

Biddiscombe, John A. biddisco at cscs.ch
Wed Apr 28 09:20:51 EDT 2010


Berk, 

thanks for the extra details. I shall also do experiments with
"git rebase -i"

No answer is short in the git world it seems.

JB

> -----Original Message-----
> From: Berk Geveci [mailto:berk.geveci at kitware.com]
> Sent: 28 April 2010 14:07
> To: Biddiscombe, John A.
> Cc: VTK Developers
> Subject: Re: [vtk-developers] Stupid git question #2
> 
> Great question. I'll give a short answer. Hopefully, someone with more
> knowledge will elaborate.
> 
> First: In the full-blown workflow we will implement, you would
> implement feature X like this. Branch from master (locally) to
> implement X. Do many commits locally. When you are done, checkout
> next, merge from X. Push to main repo. Check dashboard results. If not
> clean, make fixes on X branch, checkout next, merge from X. Repeat
> until you are convinced X works. Checkout master, merge from X. A few
> things to note: you are not supposed merge/rebase X unless you need a
> feature from another branch (including master). If you want to see how
> X interacts with Y (or next or master), try it out in another branch
> or next. The idea here is that the X branch should depend on branches
> its functionality depends on. Also, you do not push branch X to the
> main repo. If you want to publish it, you either merge to next and
> publish that. Or you publish X on your own gitorious account (which we
> host) or somewhere similar. I have to admit that I don't fully
> understand why we shouldn't push arbitrary branches to the main repo.
> This is workflow git developers follow btw. I think you can get more
> info with "git help worflows".
> 
> Note: Next, master and X are branches.
> 
> Second: You can use "git rebase -i" to merge and/or drop commits in
> your history. NOTE: never do this on a published branch (and republish
> it). You are not supposed to alter published history otherwise people
> would have serious problems when they pull from it. So, in the above
> workflow, you can work locally on your X branch all you want. Then you
> can use rebase -i to interactively cleanup your branch (merge commits,
> change comments etc etc.) and then checkout next, merge, publish etc
> etc. Just make sure that you do not use rebase -i on the published
> part of a branch.
> 
> You are probably thinking that this is not a short answer at all.
> Trust me, it is :-)
> 
> -berk
> 
> On Wed, Apr 28, 2010 at 3:14 AM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
> > 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
> >
> >



More information about the vtk-developers mailing list