[vtk-developers] Stupid git question #2

[Berk Geveci]

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
>
>