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

On 1/24/26 18:25, Bill Pragnell wrote:

>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.

    And have a look at the ".gitignore" file documentation.

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

    I use this short-circuit:

$ vim groundbase.inc
     ... do some changes, exit vim
     ... run the tracing, look at the result
     ... if the result look correct, then
$ git commit -m "increase holes diameter" groudbase.inc

    And now, I can run the big batch who make my current
    projet: http://maison.tth.netlib.re/v/hc/full.mp4 :)




-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

Post a reply to this message

hi,

tTh <tth### [at] noneinvalid> wrote:
> ...
>     And now, I can run the big batch who make my current
>     projet: http://maison.tth.netlib.re/v/hc/full.mp4 :)

v nice, "sweet"..


regards, jr.

Post a reply to this message

On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:

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

Hmm.  I guess then we'd need to see what the status looks like from each 
branch.  What you're seeing isn't consistent with my experience, at least.



-- 
"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 1/24/26 18:25, Bill Pragnell wrote:
>     And have a look at the ".gitignore" file documentation.

Indeed, in that case I would tend to highly suspect the gitignore, which can
feature very wide filters preventing files of some type of some naming patterns
to be normally flagged as untracked... OR you may also have git stash->pop
....ped over several branches. because stash can act as a bucket to port things
from one branch to another.

If you want to have other graphic views of your repos and stash black box, you
can also try :

* Gitlens with VScode/VSCodium or
* Git kraken, which looks awesome but somewhat limits its longterm featureset in
the long run.

-So Git-Cola rules for its cross platform, and free as in freesdom policies...
But mostly, don't forget its "DAG" visualisation for all your branches.

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:
>
> > 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.
>
> Hmm.  I guess then we'd need to see what the status looks like from each
> branch.  What you're seeing isn't consistent with my experience, at least.

I think that's what I would expect. If the changes don't have conflicts with any
of the other branches then switching branches makes no difference, the changes
will be left alone (unless there is a conflict, then git will warn you to commit
your changes or lose them when switching branch). If you commit the changes to a
branch, then you'll only see those changes on that branch - and now they won't
be listed as changes by 'git status' any more.

An untracked file is just a big change after all.

Bill

Post a reply to this message

On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:
>>
>> > 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.
>>
>> Hmm.  I guess then we'd need to see what the status looks like from
>> each branch.  What you're seeing isn't consistent with my experience,
>> at least.
> 
> I think that's what I would expect. If the changes don't have conflicts
> with any of the other branches then switching branches makes no
> difference, the changes will be left alone (unless there is a conflict,
> then git will warn you to commit your changes or lose them when
> switching branch). If you commit the changes to a branch, then you'll
> only see those changes on that branch - and now they won't be listed as
> changes by 'git status' any more.
> 
> An untracked file is just a big change after all.

But it looks like the file is tracked, so any changes to it made in one 
branch shouldn't affect other branches, unless they're either not tracked 
(which isn't the case) or in .gitignore (which would *probably* require it 
to have been explicitly added in some way, and I expect CR would know if 
he'd done that).
-- 
"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