<div dir="ltr">It certainly was convenient that the Gerrit pages showed git commands that you could cut-and-paste to the terminal in order to checkout or cherry-pick whatever you were looking at. The ".zip", ".tar.gz", and "Download as" links that GitLab provides are kinda useless to developers.<br><div><br></div><div>Ken, your fork is public and everyone can see it. You can fetch a branch from someone else's fork and push it, with modifications, to your own fork and ask them to take a look.</div><div><br></div><div>The "origin" remote is vtk/vtk, the "gitlab" remote is ken-martin/vtk, and you could add a remote called "dgobbi" which would be my fork. So during collaborations, it will often be necessary to explicitly provide the remote and the branch name (or HEAD, which means "current branch").</div><div><br></div><div> - David</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 12:48 PM, Ken Martin <span dir="ltr"><<a href="mailto:ken.martin@kitware.com" target="_blank">ken.martin@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I apologize if these are stupid questions but I'm exploring this a tad<br>
further as it hits on the basic way we will collaborate on a topic and I<br>
want to make sure I do it the right way.<br>
<br>
So basically<br>
<br>
1) Checkout their topic from their fork of VTK (the topic does not exist yet<br>
on other forks right?)<br>
<br>
2) Do some work<br>
<br>
Then...<br>
<br>
I can push it to their fork if they add me as a developer on their fork.<br>
<br>
Can I push it to my fork even though my fork lacks their topic? Should I?<br>
<br>
They cannot fetch it from me unless I push it someplace public that they can<br>
see right? Where would that be? Github?<br>
<br>
Thanks!<br>
<span class="im HOEnZb">Ken<br>
<br>
Ken Martin PhD<br>
Chairman & CFO<br>
Kitware Inc.<br>
28 Corporate Drive<br>
Clifton Park NY 12065<br>
<a href="mailto:ken.martin@kitware.com">ken.martin@kitware.com</a><br>
<a href="tel:518%20881-4901" value="+15188814901">518 881-4901</a> (w)<br>
<a href="tel:518%20371-4573" value="+15183714573">518 371-4573</a> (f)<br>
<br>
This communication, including all attachments, contains confidential and<br>
legally privileged information, and it is intended only for the use of the<br>
addressee. Access to this email by anyone else is unauthorized. If you are<br>
not the intended recipient, any disclosure, copying, distribution or any<br>
action taken in reliance on it is prohibited and may be unlawful. If you<br>
received this communication in error please notify us immediately and<br>
destroy the original message. Thank you.<br>
<br>
<br>
-----Original Message-----<br>
</span><span class="im HOEnZb">From: Brad King [mailto:<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>]<br>
Sent: Tuesday, March 17, 2015 2:24 PM<br>
To: Ken Martin<br>
Cc: VTK Developers<br>
</span><div class="HOEnZb"><div class="h5">Subject: Re: How to update someone else's topic (or create a new topic off<br>
of theirs)<br>
<br>
On 03/17/2015 02:16 PM, Ken Martin wrote:<br>
> So I was doing a review of someone's merge request and I realized it<br>
> needs some extra changes. Is there a way for me to download their<br>
> topic (cherry pick?), make some more changes and then resubmit it? I<br>
> saw lots of options to download a patch or diff for a topic but I do<br>
> not want to lose their node/hash/whatever it is called. Is there a<br>
> right way to do this. I did check the wiki but did not see a "revise<br>
> someone else's topic".<br>
<br>
This is an area where GitLab's merge request workflow differs from Gerrit's.<br>
In GitLab the original submitter of the merge request is responsible for<br>
pushing all updates to the branch. There are a few options here:<br>
<br>
1. You could checkout the branch locally, make the changes, and then ask<br>
the original submitter to fetch your version of the topic and<br>
'git gitlab-push' it again to update the MR.<br>
<br>
2. You could do the same but instead open your own MR and close the<br>
original.<br>
<br>
3. You could work with the submitter directly in their repository. They<br>
can use the Setting tab in their GitLab fork to make you a developer<br>
that can push directly to their repository. In that case though<br>
the 'git gitlab-push' alias won't help you because it won't be<br>
configured to push to the right place. You'd have to push by hand.<br>
<br>
-Brad<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>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br></div>