From: Prasad Pandit <pjp@fedoraproject.org>
To: Chris Torek <chris.torek@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: File missing from git branch
Date: Fri, 3 Jan 2025 10:26:10 +0000 (UTC) [thread overview]
Message-ID: <394850972.5946685.1735899970546@mail.yahoo.com> (raw)
In-Reply-To: <CAPx1GvdmrTn0x-F8yOoGrSrhXPN6At54svch=Wf=9rcz9Ri=7Q@mail.gmail.com>
Hello Chris,
* Thank you for the elaborate reply, I appreciate it.
On Thursday 2 January, 2025 at 05:10:26 pm IST, Chris Torek <chris.torek@gmail.com> wrote:
>Git is different. A branch is -- depending on your point of
>view -- simply a *temporary name* for *one particular commit*.
>From another point of view, it is *that commit and every
>commit reachable by working backwards from that commit's
>history*.
>
...
>One of these metadata items is a list of raw hash IDs of
>*previous* commits, usually exactly one entry long.
>We call that hash ID the parent, or parents if it's
>longer than one entry, of the commit.
* The parent-child connection between commits is fairly convoluted and unintuitive to understand. Especially when user does not even see the parent of non-merge commits easily. For merge commits git-log(1) shows parents.
* In my case what seems to happen is, the commits pulled from upstream repository come with their own parent commits and my local commits in the 'main' branch are not merged with them OR those pulled commits are not linked with the local commits history. Something like say
main-branch -> uc1 ... ucN <= forked and upstream repository are same.
We add local commits to it
main-branch -> lc1 -> lc2 -> uc1 ... ucN
Here lc1 and lc2 are local commits and uc1 onward are upstream commits. After $ git pull from upstream repository maybe it changes to
lc1 -> lc2
/ \
main-branch -> uc1 -> uc2 -> [mc] -> - - -> uc3 ... ucN (<= earlier uc1 becomes uc3 here)
* I wonder if there's a way to merge those histories with git pull(1) as
main-branch -> uc1 -> uc2 -> lc1 -> lc2 -> uc3 ... ucN
And whether that wouldn't create new issues of it's own. I guess the diversion comes because of the merge commits '[mc]', which essentially creates two paths to traverse history. And as the number of merge commits '[mc]' increase, number of paths also increase.
Thank you.
---
-Prasad
prev parent reply other threads:[~2025-01-03 10:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1964163554.5326830.1735643984559.ref@mail.yahoo.com>
2024-12-31 11:19 ` File missing from git branch Prasad Pandit
2025-01-01 16:53 ` Junio C Hamano
2025-01-02 10:11 ` Prasad Pandit
2025-01-02 11:40 ` Chris Torek
2025-01-03 10:26 ` Prasad Pandit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=394850972.5946685.1735899970546@mail.yahoo.com \
--to=pjp@fedoraproject.org \
--cc=chris.torek@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pj.pandit@yahoo.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).