Hi All,
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.
second, to eliminate this error message:
remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On Thu, Apr 27, 2017 at 07:41:46PM -0700, Eliot Miranda wrote:
Hi All,
first, is there a way we can modify the checkin script (scripts/gitci) tocheck 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.
second, to eliminate this error message:remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
You can view the repository URL(s) with:
git remote -v
and change them with:
git remote set-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git
and of course:
git remote --help
for more information.
Cheers, Alistair
On 28.04.2017, at 04:41, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
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.
Well, frequent merges is kind-of part of git's philosophy. Also, just getting incoming changes before checking won't buy you anything, because a merge will surely happen, and it's actually safer to have a commit _before_ merging with incoming changes. One could surely use rebasing [1], but this can get hairy in cases of incompatible diffs.
Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase` somewhere before the add or commit, but then, when you have incompatible diffs, it just wouldn't go through with the pull and say that you should commit or stash away your changes before continuing the 'pull'.
I would think that'll make things only more annoying.
Best regards -Tobias
second, to eliminate this error message:
remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
_,,,^..^,,,_ best, Eliot
[1]: from git's manpage or (https://git-scm.com/docs/git-rebase): =-=-=-=-= Assume the following history exists and the current branch is "topic":
A---B---C topic / D---E---F---G master
From this point, the result of either of the following commands:
git rebase master git rebase master topic
would be:
A'--B'--C' topic / D---E---F---G master
=-=-=-=-=-=
and this can be made easier with a 'git pull --rebase' (from git-pull(1): 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. ).
So by default `git pull` is git fetch git merge but `git pull --rebase` would be git fetch git rebase . =-=-=-=-=-=
On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 28.04.2017, at 04:41, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
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.
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.
Eliot, I'm never sure how much you've adapted to git thinking or still think in terms of subversion. IIUC a svn commit goes directly to the server and so has immediate public visibility(??) - so merging before a svn-commit may be good policy. But git-commits are local until pushed. So would this be a reasonable alternative workflow... 1. local-commit your own work 2. get notified that the remote server has moved forward 3. if required, merge remote server on top of your local-commit 4. push the result to the server
cheers -ben
Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because a merge will surely happen, and it's actually safer to have a commit _before_ merging with incoming changes. One could surely use rebasing [1], but this can get hairy in cases of incompatible diffs.
Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase` somewhere before the add or commit, but then, when you have incompatible diffs, it just wouldn't go through with the pull and say that you should commit or stash away your changes before continuing the 'pull'.
I would think that'll make things only more annoying.
Best regards -Tobias
second, to eliminate this error message:
remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
_,,,^..^,,,_ best, Eliot
[1]: from git's manpage or (https://git-scm.com/docs/git-rebase):
Assume the following history exists and the current branch is "topic":
A---B---C topic /D---E---F---G master
From this point, the result of either of the following commands:
git rebase master git rebase master topic
would be:
A'--B'--C' topic /D---E---F---G master
=-=-=-=-=-=
and this can be made easier with a 'git pull --rebase' (from git-pull(1): 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. ).
So by default `git pull` is git fetch git merge but `git pull --rebase` would be git fetch git rebase . =-=-=-=-=-=
2017-04-28 19:17 GMT+02:00 Ben Coman btc@openinworld.com:
On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 28.04.2017, at 04:41, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
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.
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.
But it's exactly like in Monticello: you can allways commit without merging into a separate branch. The main difference is that branch has to be explicit in git while they are implicit in MC.
Eliot, I'm never sure how much you've adapted to git thinking or still think in terms of subversion. IIUC a svn commit goes directly to the server and so has immediate public visibility(??) - so merging before a svn-commit may be good policy. But git-commits are local until pushed. So would this be a reasonable alternative workflow...
- local-commit your own work
- get notified that the remote server has moved forward
- if required, merge remote server on top of your local-commit
- push the result to the server
cheers -ben
Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because a merge will surely happen, and it's actually safer to have a commit _before_ merging with incoming changes. One could surely use rebasing [1], but this can get hairy in cases of incompatible diffs.
Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase` somewhere before the add or commit, but then, when you have incompatible diffs, it just wouldn't go through with the pull and say that you should commit or stash away your changes before continuing the 'pull'.
I would think that'll make things only more annoying.
Best regards -Tobias
second, to eliminate this error message:
remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
_,,,^..^,,,_ best, Eliot
[1]: from git's manpage or (https://git-scm.com/docs/git-rebase):
Assume the following history exists and the current branch is "topic":
A---B---C topic /D---E---F---G master
From this point, the result of either of the following commands:
git rebase master git rebase master topic
would be:
A'--B'--C' topic /D---E---F---G master
=-=-=-=-=-=
and this can be made easier with a 'git pull --rebase' (from git-pull(1): 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. ).
So by default `git pull` is git fetch git merge but `git pull --rebase` would be git fetch git rebase . =-=-=-=-=-=
On Sat, Apr 29, 2017 at 3:13 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2017-04-28 19:17 GMT+02:00 Ben Coman btc@openinworld.com:
On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 28.04.2017, at 04:41, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi All,
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.
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.
But it's exactly like in Monticello: you can always commit without merging into a separate branch.
The main difference is that branch has to be explicit in git while they are
implicit in MC.
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...
- local-commit your own work
- get notified that the remote server has moved forward
- if required, merge remote server on top of your local-commit
- push the result to the server
cheers -ben
Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because a merge will surely happen, and it's actually safer to have a commit _before_ merging with incoming changes. One could surely use rebasing [1], but this can get hairy in cases of incompatible diffs.
Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase` somewhere before the add or commit, but then, when you have incompatible diffs, it just wouldn't go through with the pull and say that you should commit or stash away your changes before continuing the 'pull'.
I would think that'll make things only more annoying.
Best regards -Tobias
second, to eliminate this error message:
remote: Resolving deltas: 100% (17/17), completed with 8 local objects. remote: This repository moved. Please use the new location: remote: https://github.com/OpenSmalltalk/opensmalltalk-vm.git To http://github.com/OpenSmalltalk/vm
should I simply edit .git/configure to change
[remote "origin"] url = http://github.com/OpenSmalltalk/vm
to
[remote "origin"] url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
? Or something else?
_,,,^..^,,,_ best, Eliot
[1]: from git's manpage or (https://git-scm.com/docs/git-rebase):
Assume the following history exists and the current branch is "topic":
A---B---C topic /D---E---F---G master
From this point, the result of either of the following commands:
git rebase master git rebase master topic
would be:
A'--B'--C' topic /D---E---F---G master
=-=-=-=-=-=
and this can be made easier with a 'git pull --rebase' (from git-pull(1): 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. ).
So by default `git pull` is git fetch git merge but `git pull --rebase` would be git fetch git rebase . =-=-=-=-=-=
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Ben Coman -
Eliot Miranda -
Nicolas Cellier -
Tobias Pape