* File missing from git branch
[not found] <1964163554.5326830.1735643984559.ref@mail.yahoo.com>
@ 2024-12-31 11:19 ` Prasad Pandit
2025-01-01 16:53 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Prasad Pandit @ 2024-12-31 11:19 UTC (permalink / raw)
To: git@vger•kernel.org
Hi,
Kernel-ark -> https://gitlab.com/cki-project/kernel-ark/
* I have forked the kernel-ark git repository. The forked tree is regularly updated by pulling commits from its upstream repository above. I have added/committed couple of config files under '../arch/x86/configs/' directory in the forked tree, not in the above upstream repository. Let's say
Fork was created on - day-0
Files were added on - day-1
Updates are pulled - day-2, day-3, day-4 ... day-n
* The issue is: the config files I added are visible only in the main (os-build) branch. If I create a new branch with
$ git branch new-branch <commit-hash/merge-hash/commit-tag/>
Those config files are not visible/accessible under '../arch/x86/configs' directory.
Note => Files are added and branches are created on the same forked tree.
* Generally committed local changes are visible across local branches, right? Is there a way to see/access those locally added files across local branches?
* Is there a different way to do this?
Thank you.
---
-Prasad
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File missing from git branch
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
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2025-01-01 16:53 UTC (permalink / raw)
To: Prasad Pandit; +Cc: git@vger•kernel.org
Prasad Pandit <pjp@fedoraproject•org> writes:
> * Generally committed local changes are visible across local
> branches, right? Is there a way to see/access those locally added
> files across local branches?
Not at all.
In fact, the contents on branch A is unmolested by the act of
committing changes on branch B. They are independent lines of
development. Otherwise your version control system is broken.
Until you decide to consolidate the change you made on branch A
into branch B, that is. People call that operation "merging branch
A to branch B".
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File missing from git branch
2025-01-01 16:53 ` Junio C Hamano
@ 2025-01-02 10:11 ` Prasad Pandit
2025-01-02 11:40 ` Chris Torek
0 siblings, 1 reply; 5+ messages in thread
From: Prasad Pandit @ 2025-01-02 10:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger•kernel.org
On Wednesday 1 January, 2025 at 10:24:08 pm IST, Junio C Hamano <gitster@pobox•com> wrote:
>> * Generally committed local changes are visible across local branches, right?
>
>Not at all.
>
>In fact, the contents on branch A is unmolested by the act of
>committing changes on branch B. They are independent lines of
>development. Otherwise your version control system is broken.
>
* Sorry, my question was wrong. Let's say
day-0:
- Fork is created
day-1:
- upstream commits pulled into 'main' branch
- new files are committed into 'main' branch
day-2:
- upstream commits pulled into 'main' branch
- 'new-branch-1' created from 'main' branch
day-3:
- upstream commits pulled into 'main' branch
- 'new-branch-2' created from 'main' branch
...
day-n
- upstream commits pulled into 'main' branch
- 'new-branch-n' created from 'main' branch
* Generally committed local changes are visible across _new_ branches created from the local branch, right? ie. 'new-branch-1', 'new-branch-2', 'new-branch-n' all created from the 'main' branch, should have the files which were committed into 'main' branch on day-1, right? That is not happening.
Thank you.
---
-Prasad
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File missing from git branch
2025-01-02 10:11 ` Prasad Pandit
@ 2025-01-02 11:40 ` Chris Torek
2025-01-03 10:26 ` Prasad Pandit
0 siblings, 1 reply; 5+ messages in thread
From: Chris Torek @ 2025-01-02 11:40 UTC (permalink / raw)
To: Prasad Pandit; +Cc: Junio C Hamano, git@vger•kernel.org
On Thu, Jan 2, 2025 at 2:11 AM Prasad Pandit <pjp@fedoraproject•org> wrote:
> * Generally committed local changes are visible across _new_ branches created from the local branch, right?
The answer here is both no and yes. [1]
Your issue here lies in a misunderstanding of how Git (mis?)uses
the word "branch".
** branches **
In some other version control system, a branch is a very real,
concrete thing. Creating a branch makes something permanent.
New commits, once made, are on *that* branch, and those commits
are *only* that branch.
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*.
I find that to really get people to understand this, it helps
to start them out by having them forget about the word "branch"
entirely. They should instead think of commits -- which in
Git, are found by their big ugly hash IDs -- as the unit of
storage in Git. (This is *mostly* accurate, though we can get
picky about other units of storage, but let's not do that here.)
So given a hash ID like 0f2ec7a4eeeec3045d7680e98f958740cd29bd77
-- which is too big and ugly for people to deal with, but we
can shorten it to say 0f2ec7a4eee -- we've found one specific
commit, assuming it exists. That commit contains a complete
snapshot of every file that Git "knew about" at the time you
(or whoever) made that commit. That's most of what most people
care about.
But that commit also contains some metadata: information such
as the name and email address of the person who made the commit,
and some date-and-time stamps, and so forth. 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 way Git stores "history" is precisely through these parent
IDs. That is, given one commit ID like 0f2ec7a4eee, Git can
find *that* commit. But that commit tells which commit comes
before it: 114193fd391, for instance. Git can then find *that*
commit, which has another parent, which Git can find, which
has yet another parent, and so on. By working backwards, one
commit at a time, Git finds the history of the repository.
And *now* it's time to consider the word "branch". This word
has two meanings: it means both 0f2ec7a4eee, the *last* commit
on the branch, and also 0f2ec7a4eee, plus 114193fd391, plus
whatever comes before that, plus everything all the way back
in time to the very first commit ever. So if this is "br-1",
then "br-1" means both "0f2ec7a4eee" and "everything leading up
to 0f2ec7a4eee". Which meaning gets used depends on context.
But there's another funny thing here. When you're on "br-1"
and you make a *new* commit, two things happen:
1. The new commit gets 0f2ec7a4eee as its list-of-previous
commit hash IDs. That means whatever hash ID the new
commit has -- let's say a5678xxx... -- Git will be able to
work backwards to 0f2ec7a4eee and 114193fd391 and so on.
2. The branch name, "br-1", is rewritten to mean a5678xxx.
No *existing* commit changes at all. In fact, it's impossible
to change a commit. When you use "git commit --amend", you're
participating in a lie (a useful little lie to be sure, but a
lie): you don't change the existing commit, you just make a new
and improved commit, whose parent is the same as the parent of
the current commit. The current commit then gets shoved out
of the way so that the new commit links to the current commit's
parent, instead of the current commit itself. Graphically,
Git might replace this:
... <- 114193fd391 <- 0f2ec7a4eee <-- br-1
with this:
0f2ec7a4eee [lost / abandoned]
/
... <- 114193fd391 <- b0123456789 <-- br-1
If there's any *other* way to find 0f2ec7a4eee, however, well,
it's still there, still holding (forever) all the files that
it holds.
Anyway, once you grasp this, it becomes possible to understand
what happens with files when you make commits. But now we have
to dive into another aspect of Git.
** your working tree **
The files stored under a commit's hash ID are permanent and
unchanging. This is just what we want for revision control: we
*want* to get the old files back, even if there are mistakes in
them. But it's not what we want to do *new work*: we need to be
able to rewrite files to correct mistakes and/or add new stuff.
To enable this, Git will "check out" a commit by copying, from
the permanent store, the contents of all the committed files.
These copies to into your "working tree" or "work-tree", and
here they take the form of ordinary files, which you can modify
to your heart's content.
In other version control systems, that's the end of the story
because you make new commits from your working tree. Git again
differs here, as it has a thing it calls the "index" or "staging
area", but we won't get into these details here other than to
mention that "git add" is mostly necessary. You "git add" any
updates and then run "git commit" and Git makes a new commit:
... <- 114193fd391 <- 0f2ec7a4eee <- a1234567890 <-- br-1
If you added a totally-new file to commit a1234567890, well,
it's there in that commit. If you check out that commit,
that file comes out into your working tree. If you make
a new branch name *now*, well, let's draw that:
... <- 114193fd391 <- 0f2ec7a4eee <- a1234567890 <-- br-1
\
`- br-2
Your new branch name *also identifies the new commit* by its
hash ID, so it will contain the new file. But suppose you make
the new branch name *before* this point? That is, you have:
... <- 114193fd391 <- 0f2ec7a4eee <-- br-1
\
`- br-2
If you now make a new commit while "on" branch br-1, you get:
... <- 114193fd391 <- 0f2ec7a4eee <- a1234567890 <-- br-1
\
`- br-2
The name br-2 still identifies commit 0f2ec7a4eee, which does
not have the new file in it.
To make things still-more-confusing, if you create new files in
your working tree, but *do not* commit them, Git doesn't "know
about" the files and does not store them in the commits. (This
is where "git add" comes in again: if you didn't use it, Git
treats this as an "untracked file".) Any such file just hangs
around in your working tree: Git neither modifies nor removes
the untracked file.[2]
** that's why this is a bit messy **
Given the dual meaning of the word "branch" and the fact that
we don't know whether you meant one specific commit hash ID,
or some other specific commit hash ID, or a chain of commits
ending in a specific hash ID, we can't really say what "should"
happen. But you can find out by use of this principle. Use
git rev-parse main
to find out which commit hash ID "main" means right now, and use
similar "git rev-parse" commands to find out which specific commit
hash IDs other names mean right now. Or: use "git log --graph
--decorate --oneline --branches" to help you visualize the
chain(s) of commit(s) reachable by starting at any particular
branch label and working backwards.
** footnotes **
[1]: https://www.reddit.com/r/lotr/comments/1608zdc/question_on_advices_from_elves/
[2] There's an exception to this rule. Suppose some historical
commit has a file with the same name as some existing untracked
file, and you ask Git to check out the historical commit. Git
must replace the untracked file with the historically-tracked file
in that old commit. If you then switch *back* to the newest
commit, in which the file doesn't exist, Git has to remove the
historical-commit-copy that it copied out to the working tree,
which in turn destroyed the unsaved work that was hanging around
as an untracked file. Git has a number of precautions against
this kind of clobbering unsaved work, but there are some corner
cases here that are problematic. If you need to work with a
historical commit *and* a more recent commit that might have files
with colliding names, consider using "git worktree" to make a
place to examine the historical commits.
Chris
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File missing from git branch
2025-01-02 11:40 ` Chris Torek
@ 2025-01-03 10:26 ` Prasad Pandit
0 siblings, 0 replies; 5+ messages in thread
From: Prasad Pandit @ 2025-01-03 10:26 UTC (permalink / raw)
To: Chris Torek; +Cc: Junio C Hamano, git@vger•kernel.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-01-03 10:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox