git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).