Jim Henderson <nos### [at] nospamcom> wrote:
> On Fri, 23 Jan 2026 00:25:24 -0400, Cousin Ricky wrote:
>
> > On 2026-01-22 22:38 (-4), Shay wrote:
> >> Cousin Ricky <ric### [at] yahoocom> wrote:
> >>> I created a branch, made some changes there, then switched back to the
> >>> main branch, and the changes were also in that branch as well.  Why
> >>> did the changes apply to both branches?  What am I missing?
> >>>
> >>> Most baffling is that I got branches to work just 3 weeks ago.  I
> >>> don't know what I did differently.
> >>
> >> 90% chance you created a branch with `git branch` but then never
> >> checked it out.
> >> Create a branch with `git checkout -b new-branch` to do both at the
> >> same time.
> >
> > Nope, that wasn't it.  It still changes both branches at the same time.
>
> I might be mistaken (it's WAY to early in the morning for me to be
> thinking about this), but if the file isn't added to the repo and just
> lives within the directory, then I don't think any changes get tracked,
> and this is the behavior you would probably see.
>
> Make sure you use `git add <filename>` for anything you want change
> tracking enabled.
>
>
>
> --
> "I learned long ago, never to wrestle with a pig. You get dirty, and
> besides, the pig likes it." - George Bernard Shaw

Also I don't know how bad you feel about using GUI, but I love Git-Cola for
spotting that kind of issue.

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Fri, 23 Jan 2026 00:25:24 -0400, Cousin Ricky wrote:
> > Nope, that wasn't it.  It still changes both branches at the same time.
>
> I might be mistaken (it's WAY to early in the morning for me to be
> thinking about this), but if the file isn't added to the repo and just
> lives within the directory, then I don't think any changes get tracked,
> and this is the behavior you would probably see.
>
> Make sure you use `git add <filename>` for anything you want change
> tracking enabled.

Yes, this was my first thought - you need to commit your changes to the current
branch or nothing gets tracked. Use 'git add <...>' to stage the changes, 'git
commit' to commit them.

Bill

Post a reply to this message

On Sat, 24 Jan 2026 12:25:51 EST, Bill Pragnell wrote:

> Yes, this was my first thought - you need to commit your changes to the
> current branch or nothing gets tracked. Use 'git add <...>' to stage the
> changes, 'git commit' to commit them.

IIRC, 'git status' will show if that's the case, as it shows untracked 
files.


-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Sat, 24 Jan 2026 12:25:51 EST, Bill Pragnell wrote:
>
> > Yes, this was my first thought - you need to commit your changes to the
> > current branch or nothing gets tracked. Use 'git add <...>' to stage the
> > changes, 'git commit' to commit them.
>
> IIRC, 'git status' will show if that's the case, as it shows untracked
> files.

Yep, 'git status' with no other args will list staged files, changed tracked
files and untracked files in separate sections.

This scenario sounds like there would just be items in the 'changes' section,
since these are changes to tracked files. A newly added file would appear in
untracked files.

Bill

Post a reply to this message

On 2026-01-23 10:46 (-4), Jim Henderson wrote:
> 
> I might be mistaken (it's WAY to early in the morning for me to be 
> thinking about this), but if the file isn't added to the repo and just 
> lives within the directory, then I don't think any changes get tracked, 
> and this is the behavior you would probably see.
> 
> Make sure you use `git add <filename>` for anything you want change 
> tracking enabled.

No, the files are definitely part of the repo.

Post a reply to this message

On 2026-01-23 20:15 (-4), Mr wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>>
>> I might be mistaken (it's WAY to early in the morning for me to be
>> thinking about this), but if the file isn't added to the repo and just
>> lives within the directory, then I don't think any changes get tracked,
>> and this is the behavior you would probably see.
>>
>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.
> 
> Also I don't know how bad you feel about using GUI, but I love Git-Cola for
> spotting that kind of issue.

Git-Cola has been wonderful, and it works seemlessly with the CLI.  But
the files in question *are* being tracked.

Post a reply to this message

On 2026-01-24 13:25 (-4), Bill Pragnell wrote:
> 
> Yes, this was my first thought - you need to commit your changes to the current
> branch or nothing gets tracked. Use 'git add <...>' to stage the changes, 'git
> commit' to commit them.

Are you saying that changes will show up in *all* branches until they're
committed to *one* of the branches?

Post a reply to this message

On Sat, 24 Jan 2026 21:29:18 -0400, Cousin Ricky wrote:

> On 2026-01-24 13:25 (-4), Bill Pragnell wrote:
>> 
>> Yes, this was my first thought - you need to commit your changes to the
>> current branch or nothing gets tracked. Use 'git add <...>' to stage
>> the changes, 'git commit' to commit them.
> 
> Are you saying that changes will show up in *all* branches until they're
> committed to *one* of the branches?

Technically, they don't show up in any branch because the file isn't 
tracked.  If a file isn't tracked, it exists outside git's "system", and 
the file will appear the same in all branches (but it's not in any of 
them.  If you wipe the directory and then do a git pull, the file won't be 
there at all).





-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On Sat, 24 Jan 2026 21:13:05 -0400, Cousin Ricky wrote:

> On 2026-01-23 10:46 (-4), Jim Henderson wrote:
>> 
>> I might be mistaken (it's WAY to early in the morning for me to be
>> thinking about this), but if the file isn't added to the repo and just
>> lives within the directory, then I don't think any changes get tracked,
>> and this is the behavior you would probably see.
>> 
>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.
> 
> No, the files are definitely part of the repo.

Do you see them in `git status`?

If you see something like this:

$ git status
On branch electron
Your branch is up to date with 'origin/electron'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	package-lock.json

nothing added to commit but untracked files present (use "git add" to 
track)

Then the file isn't part of the repo (in this case, package-lock.json 
isn't part of the repo I was checking). That would be consistent with what 
you're seeing.

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 2026-01-24 21:56 (-4), Jim Henderson wrote:
> On Sat, 24 Jan 2026 21:13:05 -0400, Cousin Ricky wrote:
> 
>> On 2026-01-23 10:46 (-4), Jim Henderson wrote:
>>>
>>> I might be mistaken (it's WAY to early in the morning for me to be
>>> thinking about this), but if the file isn't added to the repo and just
>>> lives within the directory, then I don't think any changes get tracked,
>>> and this is the behavior you would probably see.
>>>
>>> Make sure you use `git add <filename>` for anything you want change
>>> tracking enabled.
>>
>> No, the files are definitely part of the repo.
> 
> Do you see them in `git status`?
> 
> If you see something like this:
> 
> $ git status
> On branch electron
> Your branch is up to date with 'origin/electron'.
> 
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 	package-lock.json
> 
> nothing added to commit but untracked files present (use "git add" to 
> track)
> 
> Then the file isn't part of the repo (in this case, package-lock.json 
> isn't part of the repo I was checking). That would be consistent with what 
> you're seeing.

------------------------[BEGIN TERMINAL SESSION]------------------------
$ git checkout restored_oc
M       README.md
M       gemcuts.pov
M       gemcuts_description.txt
Switched to branch 'restored_oc'
$ git status
On branch restored_oc
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
        modified:   gemcuts.pov
        modified:   gemcuts_description.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        gem_ring-CSG.inc

no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout main
M       README.md
M       gemcuts.pov
M       gemcuts_description.txt
Switched to branch 'main'
$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
        modified:   gemcuts.pov
        modified:   gemcuts_description.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        gem_ring-CSG.inc

no changes added to commit (use "git add" and/or "git commit -a")
-------------------------[END TERMINAL SESSION]-------------------------

The files README.md, gemcuts.pov, and gemcuts_description.txt were
modified while one branch was checked out, and the changes show in the
other branch as well.

N.B.  Pay no attention to file gem_ring-CSG.inc; it's untracked on
purpose.  It's just a file that I haven't added to .gitignore, and I'm
still trying to decide what to do with it.

Post a reply to this message