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@xxxxxxxxx> 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
