<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 29, 2017 at 3:13 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-28 19:17 GMT+02:00 Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-m_3828583372685520595m_3920610728017606952gmail-"><br>
<br>
> On 28.04.2017, at 04:41, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
>    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.<br>
<br></span></blockquote><div><br></div><div>That seems horrible, to be forced to merge in someone else's changes into mine before doing a commit to draw a line between my changes and theirs.  </div><div><br></div></div></div></div></blockquote><div><br></div><div>But it's exactly like in Monticello: you can always commit without merging into a separate branch.<br></div></div></div></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The main difference is that branch has to be explicit in git while they are implicit in MC.<br></div></div></div></div></blockquote><div><br></div><div>They way I understood the original request, the analogy would be... being forced to merge-in another persons mcz before being able to first commit your own changes to a separate mcz.  But now I see I misread it, and its just the default being considered, presumably with a "force" option.   So sorry for my angst.  Anyway, this still might be a good workflow... </div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>1. local-commit your own work  <br></div><div>2. get notified that the remote server has moved forward</div><div>3. if required, merge remote server on top of your local-commit</div><div>4. push the result to the server</div><div><br></div><div>cheers -ben</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-m_3828583372685520595m_3920610728017606952gmail-">
</span>Well, frequent merges is kind-of part of git's philosophy.<br>
Also, just getting incoming changes before checking won't buy you anything, because<br>
a merge will surely happen, and it's actually safer to have a commit _before_ merging<br>
with incoming changes. One could surely use rebasing [1], but this can get hairy in cases<br>
of incompatible diffs.<br>
<br>
Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase`<br>
somewhere before the add or commit, but then, when you have incompatible diffs,<br>
it just wouldn't go through with the pull and say that you should commit or stash<br>
away your changes before continuing the 'pull'.<br>
<br>
I would think that'll make things only more annoying.<br>
<br>
Best regards<br>
        -Tobias<br>
<span class="gmail-m_3828583372685520595m_3920610728017606952gmail-"><br>
<br>
><br>
>    second, to eliminate this error message:<br>
><br>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.<br>
> remote: This repository moved. Please use the new location:<br>
> remote:   <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git" rel="noreferrer" target="_blank">https://github.com/OpenSmallt<wbr>alk/opensmalltalk-vm.git</a><br>
> To <a href="http://github.com/OpenSmalltalk/vm" rel="noreferrer" target="_blank">http://github.com/OpenSmalltal<wbr>k/vm</a><br>
><br>
> should I simply edit .git/configure to change<br>
><br>
> [remote "origin"]<br>
>       url = <a href="http://github.com/OpenSmalltalk/vm" rel="noreferrer" target="_blank">http://github.com/OpenSmalltal<wbr>k/vm</a><br>
><br>
> to<br>
><br>
> [remote "origin"]<br>
>       url = <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git" rel="noreferrer" target="_blank">https://github.com/OpenSmallta<wbr>lk/opensmalltalk-vm.git</a><br>
><br>
> ?  Or something else?<br>
><br>
</span>> _,,,^..^,,,_<br>
> best, Eliot<br>
<br>
[1]:  from git's manpage or (<a href="https://git-scm.com/docs/git-rebase" rel="noreferrer" target="_blank">https://git-scm.com/docs/git-<wbr>rebase</a>):<br>
=-=-=-=-=<br>
Assume the following history exists and the current branch is "topic":<br>
<br>
         A---B---C topic<br>
        /<br>
   D---E---F---G master<br>
<br>
>From this point, the result of either of the following commands:<br>
<br>
git rebase master<br>
git rebase master topic<br>
<br>
would be:<br>
<br>
                 A'--B'--C' topic<br>
                /<br>
   D---E---F---G master<br>
<br>
=-=-=-=-=-=<br>
<br>
and this can be made easier with a 'git pull --rebase'<br>
(from git-pull(1):<br>
More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.<br>
).<br>
<br>
So by default `git pull` is<br>
        git fetch<br>
        git merge<br>
but `git pull --rebase` would be<br>
        git fetch<br>
        git rebase<br>
.<br>
=-=-=-=-=-=<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>
<br></blockquote></div><br></div></div>
<br></blockquote></div><br></div></div>