Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
>>> "KK" == Konstantin Khomoutov writes: > On Tue, Jul 11, 2023 at 08:20:23PM +0200, Uwe Brauer wrote: >>> Do I assume correctly that you have had that configuration option set in >>> some >>> of the Git configuration sources? >> >> Well I had in my global .gitconfigure file indeed the line >> [pull] >> rebase = true >> >> I forgot it completely, sorry > Nah, that's a good lesson to me, too: I did think of this possibility but has > decided not to mention it to not compilcate matters :-) > Actually, that's one of the problems with `git pull`: it has too much magic > built in. I for one, am in the camp who thinks that `git pull` should be > taught to new users quite late in their Git curriculum, if at all. A good > rundown of these matters (if a tiny bit old) is [1]. I wholeheartedly agree (in mercurial I always use hg pull & hg merge == git fetch & git merge) However I am running experiments for my students next year, who will use matlab's git interface, for sure they prefer to use pull and not fetch and I have to look for a configuration which is the least confusing for them The open question is what happens if a conflicting commit is pulled (I mean what matlab's interface does about it.) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87edle19m2.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
On Tue, Jul 11, 2023 at 08:20:23PM +0200, Uwe Brauer wrote: >> Do I assume correctly that you have had that configuration option set in some >> of the Git configuration sources? > > Well I had in my global .gitconfigure file indeed the line > [pull] > rebase = true > > I forgot it completely, sorry Nah, that's a good lesson to me, too: I did think of this possibility but has decided not to mention it to not compilcate matters :-) Actually, that's one of the problems with `git pull`: it has too much magic built in. I for one, am in the camp who thinks that `git pull` should be taught to new users quite late in their Git curriculum, if at all. A good rundown of these matters (if a tiny bit old) is [1]. 1. https://longair.net/blog/2009/04/16/git-fetch-and-merge/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230711190229.jddlijjlbqset3em%40carbon.
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
> On Mon, Jul 10, 2023 at 09:51:12PM +0200, Uwe Brauer wrote: > [...] > Do I assume correctly that you have had that configuration option set in some > of the Git configuration sources? Well I had in my global .gitconfigure file indeed the line [pull] rebase = true I forgot it completely, sorry -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87wmz61fa0.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
On Mon, Jul 10, 2023 at 09:51:12PM +0200, Uwe Brauer wrote: [...] > I just realized also > > [pull] > rebase = true > > So I will set this to false and see what happens > that was the culprit. > > Thanks all of your for your patience. Should have checked by > configuration first Do I assume correctly that you have had that configuration option set in some of the Git configuration sources? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230711130203.nxylma375k4mbdtf%40carbon.
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
> from https://git-scm.com/docs/git-config > pull.ff > By default, Git does not create an extra merge commit when merging a > commit that is a descendant of the current commit. Instead, the tip > of the current branch is fast-forwarded. When set to |false|, this > variable tells Git to create an extra merge commit in such a case > (equivalent to giving the |--no-ff| option from the command line). > When set to |only|, only such fast-forward merges are allowed > (equivalent to giving the |--ff-only| option from the command line). > This setting overrides |merge.ff| when pulling. > if you run git config pull.ff false a git pull will always default to a > merge commit. Use git config --global to set system wide It did not help, but the message says Unpacking objects: 100% (3/3), 315 bytes | 157.00 KiB/s, done. >From >/home/oub/Mail/Remember/HG-Git/Resolve-Editing-Conflicts-coauthor/Git-fetch-vs-pull/Git-pull-no-ff/Uwe/../Server f18fb04..a709953 default-> origin/default Successfully rebased and updated refs/heads/default. I just realized also [pull] rebase = true So I will set this to false and see what happens that was the culprit. Thanks all of your for your patience. Should have checked by configuration first Regards > On 7/10/23 12:01, Uwe Brauer wrote: -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/871qhf4kb3.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
>>> "CS" == Chris Stone writes: > from https://git-scm.com/docs/git-config > pull.ff > By default, Git does not create an extra merge commit when merging a > commit that is a descendant of the current commit. Instead, the tip > of the current branch is fast-forwarded. When set to |false|, this > variable tells Git to create an extra merge commit in such a case > (equivalent to giving the |--no-ff| option from the command line). > When set to |only|, only such fast-forward merges are allowed > (equivalent to giving the |--ff-only| option from the command line). > This setting overrides |merge.ff| when pulling. > if you run git config pull.ff false a git pull will always default to a > merge commit. Use git config --global to set system wide Hm thanks I try set, but as I said git pull --no-ff Resulted, nevertheless, in a fast-forward and as the above documentation states > of the current branch is fast-forwarded. When set to |false|, this > variable tells Git to create an extra merge commit in such a case > (equivalent to giving the |--no-ff| option from the command line). But I will give it another try. regards -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87a5w34kp7.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
from https://git-scm.com/docs/git-config pull.ff By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to |false|, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the |--no-ff| option from the command line). When set to |only|, only such fast-forward merges are allowed (equivalent to giving the |--ff-only| option from the command line). This setting overrides |merge.ff| when pulling. if you run git config pull.ff false a git pull will always default to a merge commit. Use git config --global to set system wide On 7/10/23 12:01, Uwe Brauer wrote: "KK" == Konstantin Khomoutov writes: On Mon, Jul 10, 2023 at 06:30:04PM +0200, Uwe Brauer wrote: While in mercurial «hg fetch» is equivalent to «hg pull» and «hg merge» it seems that «git pull --no-ff» is not equivalent to «git fetch» and «git merge». This might be wrong expectations. I'll try to explain in simple words. In a VCS which uses cryptographic hashes to refer to commits, a line of history may be fully contained in another, say A --> B --> C --> D fully contains A --> B and A --> B --> C but not, for instance, A --> B --> X A branch fully contained in some other branch is said to be eligible for fast-forwarding to that containing (enclosing) branch. Why is that? Because if we, say, have that A --> B line of commits on some branch, and want that branch to now become A --> B --> C --> D, there's no real need to _actually merge_ that C --> D bit: we can instead just update the branch to point directly at D, with not merge commit involved. Git defaults to this fast-forward behavior in every place merging is involved, and `git pull` is one of such places. So far I had assumed. Going back to our example, if you locally have your "master" to contain A --> B, and "master" in the remote repo contains A --> B --> C --> D, pulling from that branch will by default to a fast-forward merge. The "--no-ff" command-line option for `git pull` is actually passed by that command to `git merge` it eventually calls, and forces the latter to not do a fast-forward and instead record a true merge, resulting in a merge commit recorded, which has two parents: B and D. But that is where my confusing starts I used the "--no-ff" option and nevertheless git performed (at least the graphs looks to me like that) a fast forward. Is there no way to configure pull that it produces the same graph, as git fetch+merge? Mercurial seems to do that and I will ask some mercurial guru how it does it. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/bfefb680-d434-4ae4-7eab-f036ffb1edbf%40gmail.com.
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
>>> "KK" == Konstantin Khomoutov writes: > On Mon, Jul 10, 2023 at 06:30:04PM +0200, Uwe Brauer wrote: >> While in mercurial «hg fetch» is equivalent to «hg pull» and «hg merge» >> >> it seems that «git pull --no-ff» is not equivalent to >> «git fetch» and «git merge». > This might be wrong expectations. > I'll try to explain in simple words. > In a VCS which uses cryptographic hashes to refer to commits, a line of > history may be fully contained in another, say > A --> B --> C --> D > fully contains > A --> B > and > A --> B --> C > but not, for instance, > A --> B --> X > A branch fully contained in some other branch is said to be eligible for > fast-forwarding to that containing (enclosing) branch. Why is that? > Because if we, say, have that A --> B line of commits on some branch, > and want that branch to now become A --> B --> C --> D, there's no real need > to _actually merge_ that C --> D bit: we can instead just update the branch to > point directly at D, with not merge commit involved. > Git defaults to this fast-forward behavior in every place merging is involved, > and `git pull` is one of such places. So far I had assumed. > Going back to our example, if you locally have your "master" to > contain A --> B, and "master" in the remote repo contains A --> B --> > C --> D, pulling from that branch will by default to a fast-forward > merge. > The "--no-ff" command-line option for `git pull` is actually > passed by that command to `git merge` it eventually calls, and forces > the latter to not do a fast-forward and instead record a true merge, > resulting in a merge commit recorded, which has two parents: B and D. But that is where my confusing starts I used the "--no-ff" option and nevertheless git performed (at least the graphs looks to me like that) a fast forward. Is there no way to configure pull that it produces the same graph, as git fetch+merge? Mercurial seems to do that and I will ask some mercurial guru how it does it. -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87fs5v4pds.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] git pull --no-ff is not equivalent to git fetch+merge
On Mon, Jul 10, 2023 at 06:30:04PM +0200, Uwe Brauer wrote: > While in mercurial «hg fetch» is equivalent to «hg pull» and «hg merge» > > it seems that «git pull --no-ff» is not equivalent to > «git fetch» and «git merge». This might be wrong expectations. I'll try to explain in simple words. In a VCS which uses cryptographic hashes to refer to commits, a line of history may be fully contained in another, say A --> B --> C --> D fully contains A --> B and A --> B --> C but not, for instance, A --> B --> X A branch fully contained in some other branch is said to be eligible for fast-forwarding to that containing (enclosing) branch. Why is that? Because if we, say, have that A --> B line of commits on some branch, and want that branch to now become A --> B --> C --> D, there's no real need to _actually merge_ that C --> D bit: we can instead just update the branch to point directly at D, with not merge commit involved. Git defaults to this fast-forward behavior in every place merging is involved, and `git pull` is one of such places. Going back to our example, if you locally have your "master" to contain A --> B, and "master" in the remote repo contains A --> B --> C --> D, pulling from that branch will by default to a fast-forward merge. The "--no-ff" command-line option for `git pull` is actually passed by that command to `git merge` it eventually calls, and forces the latter to not do a fast-forward and instead record a true merge, resulting in a merge commit recorded, which has two parents: B and D. Whether to always opt for "true" merges even if they are "trivial" is an open question. Some workflows explicitly make use of it. My opinion is that it should only be used when what it offers is explicitly understood and sought. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230710175249.shjvm5zvrauioeag%40carbon.
[git-users] git pull --no-ff is not equivalent to git fetch+merge
Hi While in mercurial «hg fetch» is equivalent to «hg pull» and «hg merge» it seems that «git pull --no-ff» is not equivalent to «git fetch» and «git merge». I run an experiment. Set up a local git server, with a couple of commits. Cloned it as user1 cloned it as user2 User1 pushes a (non conflicting) commit to the server now user2 has either to pull --no-ff or fetch+merge. - Here is the graph before the pull/fetch git log --graph --all * commit b178f66fa7cf7759c880ac6e4f388cf5fc590075 (HEAD -> default) | Author: Uwe Brauer | Date: Mon Jul 10 18:21:22 2023 +0200 | | Uwe: Conflict RH is FALSE | * commit 4da587290a2c7024c904d4f4f34420f4a65058b2 (origin/default, origin/HEAD) | Author: Uwe Brauer | Date: Mon Jul 10 18:20:17 2023 +0200 | | 5: Six - here the result of git fetch + merge * commit 063fc6ee19092ae10418064c857d2ff485425dfd (default) (HEAD -> default) |\ Merge: b178f66 d4a687d | | Author: Uwe Brauer | | Date: Mon Jul 10 18:25:15 2023 +0200 | | | | Merge commit 'd4a687dcb' into default | | | * commit d4a687dcb8137f5770fc2bd61beb3552ec8bbb1b (remotes/origin/HEAD) (origin/default, origin/HEAD) | | Author: Bernhard Riemann | | Date: Mon Jul 10 18:21:43 2023 +0200 | | | | Bernhard, Conflict RH is TRUE | | * | commit b178f66fa7cf7759c880ac6e4f388cf5fc590075 (default~1) |/ Author: Uwe Brauer | Date: Mon Jul 10 18:21:22 2023 +0200 | | Uwe: Conflict RH is FALSE This is what I expect from git pull --no-ff However I obtain * commit ca8e85ecab893b1a801e99b916e4274989928a6c (default) (HEAD -> default) | Author: Uwe Brauer | Date: Mon Jul 10 18:27:32 2023 +0200 | | Uwe: Conflict RH is FALSE | * commit 6e8161026dc63f14e250e0eeae14295066de5b34 (remotes/origin/HEAD) (origin/default, origin/HEAD) | Author: Bernhard Riemann | Date: Mon Jul 10 18:27:17 2023 +0200 | | Bernhard, Conflict RH is TRUE | What do I miss here? Thanks and regards Uwe Brauer -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87wmz74tmb.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
