[Insight-developers] Plan to host the SimpleITK git repo here at Kitware

[Brad King]

On 06/07/2011 12:42 PM, Bradley Lowekamp wrote:
> First I am wondering what are the current hooks that we have to
> prevent poorly formed commits and commit history?

For each push to an integration branch it ensures that a first-parent
traversal from the new head passes through the old head:

  http://public.kitware.com/Wiki/Git/Workflow/Topic#first-parent_sequence_not_preserved

> Will the stage prevent topic which are based on next getting through?

Yes.  You won't even be able to push the topic to the stage.

> Where can I find the scripts used to perform these checks as it may
> be easier for me to ran them, then have them all described?

The scripts are private to the server and not re-useable elsewhere.
Here is a description of the main checks of the content of commits:

  http://public.kitware.com/Wiki/Git/Hooks#Server

> On Jun 6, 2011, at 1:58 PM, Brad King wrote:
>> One of them is based on next so I named it accordingly.  You'll have to
>> rebase that topic.
> 
> I am trying to correct this topic. The issues with it are that it contains
> numerous topics that were merged into next, but are not currently staged.

If you can identify the heads of those topics, up to the point that they
do not contain 'next', then push them by hand to add names to the stage:

 $ git push stage $sha1_of_head:refs/heads/$topic_name

For example, I just did this one:

 $ git push stage 1c38b263:refs/heads/SIMPLEITK-51_munged_json

I also added "contains-next-SIMPLEITK-92_Python_docstrings" to the stage
which looks like the topic that was started from next.  Run

 $ git fetch stage --prune

to get these branches.

> http://public.kitware.com/Wiki/Git/Workflow/Stage#Abandoning_a_Topic

This works only for topics that were correctly started from master.
It won't work for anything that already contains 'next'.

> Do you have any suggestions on how I  should be able to do this operation?
[snip]
> Also above you mentioned that I should "rebase"  the topic, it's not clear
> to me how that will work with the topic stage workflow.

General answer:

Rebase it on origin/master, push the topic back to the stage (using +HEAD
to force the branch rewrite), and then merge to next.  If the changes are
identical then the merge to next will succeed cleanly because it already
has the changes.  Both versions of the topic will appear in 'next' but
the new one can be merged to 'master'.  This is okay and does not break
the workflow.

Specific answer:

In this case the topic in question contains some pieces based on master,
some based on next, and two merges that resolve conflicts.  Since we just
switched to this repo I think restarting next may be simpler.  After all,
next should always be equal to master + topics-on-stage.

-Brad K