* Bug/Weird behaviour with git pull
@ 2023-04-17 10:34 Berat Özdemir
2023-04-17 11:19 ` Kristoffer Haugsbakk
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Berat Özdemir @ 2023-04-17 10:34 UTC (permalink / raw
To: git@vger.kernel.org
Hi there,
I stumbled on a weird behavior in git with the pull operation.
Imagine the following scenario:
We have a local and a remote repository, with the branches master, develop and f1. We
- cloned the remote repository.
- checked f1 out
- checked develop out
- run git merge f1. Merge was successful.
- Did not pushed
- run git reset --hard origin/develop -> to undo the f1 merge into develop
- run git pull origin f1
What did you expect to happen? (Expected behavior)
I expected that "git pull origin f1" will just update the f1 branch (fetching and merging with origin/f1). In my case I expected nothing to happen since neither local f1 nor origin/f1 did changed while testing. Just develop changed locally, but it was resetted.
What happened instead? (Actual behavior)
"git pull origin f1" created a new commit, which was the previously resetted merge into the develop branch.
What's different between what you expected and what actually happened?
I expected nothing to happen (or if remote f1 changed, that those changes would be present locally) but I got the previously resetted merge into develop redone
Anything else you want to add:
We use git with one remote repository with a master branch, a develop branch and a lot of feature branches.
I was about to write a script, which determines candidate feature-branches, which should be automatically merged into the develop branch.
Our merge-workflow is as follows:
1. Update local repository (pull develop, pull the feature-branch which should be merged)
2. Merge
3. Push
While testing my script, I did not pushed at all, since I didn't want to publish some weird testing stuff to the remote. Therefore every merge I did was locally.
What did you do before the bug happened? (Steps to reproduce your issue)
I pulled develop and feature f1. Then I switched to the develop branch and run "git merge --no-ff f1". The merge was successful. Now I changed my script (git-irrelevant things, like transitioning the corresponding ticket) and wanted to test the script again. To do this I wanted to undo the merge and did a hard reset on the local develop branch to the origin/develop commit. Everything was okay until I ran the script again - it reported that there was already a merge. I checked the git tree - and there it was. I repeated the process with resetting the develop branch and explicitly commented the "git merge" part out of my script. But after running the script, the merge was there again. After trying around I found out, that the "git pull origin f1" command redoes the resetted merge into develop. On the remote nothing changed while I was testing - so I don't get why git pull does anything at all.
I thought, the pull command fetches new commits from the remote and merges tracked remote branch into the local tracking branch.
[System Info]
git version:
git version 2.38.1.windows.1
cpu: x86_64
built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>
Mit freundlichen Grüßen
Kind regards
Berat Özdemir
IT Software Entwicklung
Phone:+49 201 8676 14402
Berat_Oezdemir@deichmann.com
www.deichmann.com
Deichmann SE, Deichmannweg 9, D-45359 Essen
Sitz der Gesellschaft: Essen, Registergericht Essen HRB 21020, USt.-ID-Nr.: DE 119 663 402
Vorsitzender des Verwaltungsrats und der geschäftsführenden Direktoren: Heinrich Otto Deichmann
Geschäftsführende Direktoren:
Alexander Bellin * Samuel Deichmann * Martin Fischer * Dr. Lars Jendrian * Manfred Kroneder
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug/Weird behaviour with git pull
2023-04-17 10:34 Bug/Weird behaviour with git pull Berat Özdemir
@ 2023-04-17 11:19 ` Kristoffer Haugsbakk
2023-04-17 11:57 ` AW: " Berat Özdemir
2023-04-17 12:49 ` Felipe Contreras
2023-04-17 17:08 ` Junio C Hamano
2 siblings, 1 reply; 6+ messages in thread
From: Kristoffer Haugsbakk @ 2023-04-17 11:19 UTC (permalink / raw
To: Berat Özdemir; +Cc: git
Hi
On Mon, Apr 17, 2023, at 12:34, Berat Özdemir wrote:
> Hi there,
What does your Git config for `pull` look like?
--
Kristoffer Haugsbakk
^ permalink raw reply [flat|nested] 6+ messages in thread
* AW: Bug/Weird behaviour with git pull
2023-04-17 11:19 ` Kristoffer Haugsbakk
@ 2023-04-17 11:57 ` Berat Özdemir
0 siblings, 0 replies; 6+ messages in thread
From: Berat Özdemir @ 2023-04-17 11:57 UTC (permalink / raw
To: Kristoffer Haugsbakk; +Cc: git@vger.kernel.org
Hello,
Thank you for the quick response!
The only pull relevant config I can find is
$ git config --get-regexp pull
pull.rebase false
Mit freundlichen Grüßen
Kind regards
Berat Özdemir
IT Software Entwicklung
Phone:+49 201 8676 14402
Berat_Oezdemir@deichmann.com
www.deichmann.com
Deichmann SE, Deichmannweg 9, D-45359 Essen
Sitz der Gesellschaft: Essen, Registergericht Essen HRB 21020, USt.-ID-Nr.: DE 119 663 402
Vorsitzender des Verwaltungsrats und der geschäftsführenden Direktoren: Heinrich Otto Deichmann
Geschäftsführende Direktoren:
Alexander Bellin * Samuel Deichmann * Martin Fischer * Dr. Lars Jendrian * Manfred Kroneder
-----Ursprüngliche Nachricht-----
Von: Kristoffer Haugsbakk <code@khaugsbakk.name>
Gesendet: Montag, 17. April 2023 13:20
An: Berat Özdemir <Berat_Oezdemir@deichmann.com>
Cc: git@vger.kernel.org
Betreff: Re: Bug/Weird behaviour with git pull
EXTERNE E-MAIL:
Klicken Sie keine Links und öffnen Sie keine Attachments, es sei denn Sie kennen den Absender und vertrauen den Inhalten.
EXTERNAL EMAIL:
Do not click any links or open any attachments unless you trust the sender and know the content is safe.
Hi
On Mon, Apr 17, 2023, at 12:34, Berat Özdemir wrote:
> Hi there,
What does your Git config for `pull` look like?
--
Kristoffer Haugsbakk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug/Weird behaviour with git pull
2023-04-17 10:34 Bug/Weird behaviour with git pull Berat Özdemir
2023-04-17 11:19 ` Kristoffer Haugsbakk
@ 2023-04-17 12:49 ` Felipe Contreras
[not found] ` <AS8P194MB157593E9D310D6B03A1E0577E29C9@AS8P194MB1575.EURP194.PROD.OUTLOOK.COM>
2023-04-17 17:08 ` Junio C Hamano
2 siblings, 1 reply; 6+ messages in thread
From: Felipe Contreras @ 2023-04-17 12:49 UTC (permalink / raw
To: Berat Özdemir, git@vger.kernel.org
Berat Özdemir wrote:
> I stumbled on a weird behavior in git with the pull operation.
> Imagine the following scenario:
>
> We have a local and a remote repository, with the branches master, develop and f1. We
>
> - cloned the remote repository.
> - checked f1 out
> - checked develop out
> - run git merge f1. Merge was successful.
> - Did not pushed
> - run git reset --hard origin/develop -> to undo the f1 merge into develop
> - run git pull origin f1
>
> What did you expect to happen? (Expected behavior)
> I expected that "git pull origin f1" will just update the f1 branch (fetching and merging with origin/f1). In my case I expected nothing to happen since neither local f1 nor origin/f1 did changed while testing. Just develop changed locally, but it was resetted.
The first sentence of the documentation says:
Incorporates changes from a remote repository into the current branch.
You are effectively merging origin/f1 into your current.
My recommendation to everyone is simply to not use `git pull`, as a lot of time
(most of the time?) it doesn't do what the user wants. It's much better to just
do `git fetch`+`git merge/rebase`.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug/Weird behaviour with git pull
[not found] ` <AS8P194MB157539251684168156C0EC99E29C9@AS8P194MB1575.EURP194.PROD.OUTLOOK.COM>
@ 2023-04-17 16:21 ` Felipe Contreras
0 siblings, 0 replies; 6+ messages in thread
From: Felipe Contreras @ 2023-04-17 16:21 UTC (permalink / raw
To: Berat Özdemir; +Cc: git@vger.kernel.org
Hi Berat,
Your email contains HTML, the rules of verg.kernel.org explain very
clearly that you must send only plain text:
All email sent to there must be TEXT/PLAIN.
http://vger.kernel.org/majordomo-info.html
On Mon, Apr 17, 2023 at 9:02 AM Berat Özdemir
<Berat_Oezdemir@deichmann.com> wrote:
> what you're writing is the expected behaviour of git pull. In my case origin/f1 equals local f1 so git pull should not change anything at all
I think you misunderstand the purpose of `git pull` (as most people
do): it's *not* meant to update your local branches.
The purpose of `git pull` is to integrate pull requests.
It's irrelevant if your local "f1" equals "origin/f1", because the
command is essentially the equivalent of doing:
git fetch origin
git merge origin/f1
If you are following a feature branch workflow (and it seems you are),
then `git pull` should only be used by the mainter to integrate pull
requests (usually into "master").
If what you want instead is to update your local branches, I suggest
to do something like:
git fetch origin
git switch f1
git merge origin/f1
git switch f2
git merge origin/f2
...
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug/Weird behaviour with git pull
2023-04-17 10:34 Bug/Weird behaviour with git pull Berat Özdemir
2023-04-17 11:19 ` Kristoffer Haugsbakk
2023-04-17 12:49 ` Felipe Contreras
@ 2023-04-17 17:08 ` Junio C Hamano
2 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2023-04-17 17:08 UTC (permalink / raw
To: Berat Özdemir; +Cc: git@vger.kernel.org
Berat Özdemir <Berat_Oezdemir@deichmann.com> writes:
> - cloned the remote repository.
> - checked f1 out
> - checked develop out
OK, so at this point, you have "f1", which is a copy of the origin's
"f1", and you have "develop", which is a copy of the origin's
"develop". And you have "develop" checked out in your working tree.
> - run git merge f1. Merge was successful.
OK. "develop" has one extra commit (i.e. merge of "f1" into it)
relative to the origin's. You made sure automated merge goes well.
> - Did not pushed
OK.
> - run git reset --hard origin/develop -> to undo the f1 merge into develop
OK. Now your "develop" is the same as origin's again.
> - run git pull origin f1
This is "Please fetch f1 from origin, and merge it into the branch
that is currently checked out in my working tree. It may conflict,
or it may not. If merged cleanly, create a new commit and advance
the branch that is currently checked out".
> What did you expect to happen? (Expected behavior)
> I expected that "git pull origin f1" will just update the f1
> branch (fetching and merging with origin/f1). In my case I
> expected nothing to happen since neither local f1 nor origin/f1
> did changed while testing. Just develop changed locally, but it
> was resetted.
The expectation is flawed. What is the closest to what you describe
above is "git fetch" (which would update origin/f1 together with
other remote-tracking branches under origin/).
If you wanted to update your "f1", one procedure you can use is
$ git checkout f1
$ git pull origin f1
"git pull" (and most of the commands that create a new commit based
on what you did, e.g. "git rebase", "git cherry-pick", "git commit",
"git merge") works on the branch that is currently checked out. If
you want to do something to "f1", you would check out that branch
first.
> What happened instead? (Actual behavior)
> "git pull origin f1" created a new commit, which was the
> previously resetted merge into the develop branch.
This is expected (see the explanation for "run git pull origin f1" above).
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-17 17:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-17 10:34 Bug/Weird behaviour with git pull Berat Özdemir
2023-04-17 11:19 ` Kristoffer Haugsbakk
2023-04-17 11:57 ` AW: " Berat Özdemir
2023-04-17 12:49 ` Felipe Contreras
[not found] ` <AS8P194MB157593E9D310D6B03A1E0577E29C9@AS8P194MB1575.EURP194.PROD.OUTLOOK.COM>
[not found] ` <AS8P194MB157539251684168156C0EC99E29C9@AS8P194MB1575.EURP194.PROD.OUTLOOK.COM>
2023-04-17 16:21 ` Felipe Contreras
2023-04-17 17:08 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).