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.

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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

Post a reply to this message

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

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

On 2026-01-26 18:44 (-4), 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.

This is exactly what I've seen since Sunday.

> An untracked file is just a big change after all.

Post a reply to this message

On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:
>>
>> 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'm sensing disagreement in what "tracked" means.  Jim is using
"tracked" the way I've understood it, but Bill is describing the
behavior I'm seeing from git.

But .gitignore is one aspect of git that has never given me any surprises.

Post a reply to this message

On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:

> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>> On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:
>>>
>>> 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'm sensing disagreement in what "tracked" means.  Jim is using
> "tracked" the way I've understood it, but Bill is describing the
> behavior I'm seeing from git.
> 
> But .gitignore is one aspect of git that has never given me any
> surprises.

Can you describe the workflow you're using, step by step - commands 
executed, and so on - in order to try to reproduce what you're seeing?


-- 
"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 Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
> > On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> >> But it looks like the file is tracked, so any changes to it made in one
> >> branch shouldn't affect other branches,

Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
git-speak) refers to an edit, without any git interaction, which is what I've
been assuming. A change to a branch is usually called a 'commit', and that will
indeed be unique to the branch.

> > I'm sensing disagreement in what "tracked" means.  Jim is using
> > "tracked" the way I've understood it, but Bill is describing the
> > behavior I'm seeing from git.

I think git itself may also be confusing the issue here. 'Tracked' just means
the file has been added to the repo. If I add a new file to a project (without
git interaction - just make a new file within a repo), it is listed as
'untracked' because it does not yet have an entry in the repo - its entire
contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
then 'tracked' as part of that branch from that point on. But you could say that
even an 'untracked' file is tracked in the sense of git being aware of it,
because it appears in the status. Only files/directories in .gitignore are truly
untracked because edits to them will be ignored.

Uncommitted changes (i.e. edits to a file) will not be affected by switching
branches, unless there is a conflict - i.e. if the edits apply to a section of a
file that is different in the two branches. In that case, git will not switch
branches, but instead tell you to commit or 'stash' your changes before
switching (stashing is saving your changes on a temp stack rather than
committing them).

Sorry if I'm muddying the water here! I remember being quite confused about how
git worked when I first started using it.

Bill

Post a reply to this message

On Fri, 30 Jan 2026 21:42:09 EST, Bill Pragnell wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
>> > On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>> >> But it looks like the file is tracked, so any changes to it made in
>> >> one branch shouldn't affect other branches,
> 
> Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> git-speak) refers to an edit, without any git interaction, which is what
> I've been assuming. A change to a branch is usually called a 'commit',
> and that will indeed be unique to the branch.

No, that's what I'm calling a change - an edit to the file.

>> > I'm sensing disagreement in what "tracked" means.  Jim is using
>> > "tracked" the way I've understood it, but Bill is describing the
>> > behavior I'm seeing from git.
> 
> I think git itself may also be confusing the issue here. 'Tracked' just
> means the file has been added to the repo. If I add a new file to a
> project (without git interaction - just make a new file within a repo),
> it is listed as 'untracked' because it does not yet have an entry in the
> repo - its entire contents are a 'change'. If I 'git add' and then 'git
> commit' that file, it is then 'tracked' as part of that branch from that
> point on. But you could say that even an 'untracked' file is tracked in
> the sense of git being aware of it, because it appears in the status.
> Only files/directories in .gitignore are truly untracked because edits
> to them will be ignored.

Hmmm.  I just created a quick test repo, and it's not working the way I 
remembered it, but it is working the way you're describing and CR is 
saying is happening for his setup, too.

> Uncommitted changes (i.e. edits to a file) will not be affected by
> switching branches, unless there is a conflict - i.e. if the edits apply
> to a section of a file that is different in the two branches. In that
> case, git will not switch branches, but instead tell you to commit or
> 'stash' your changes before switching (stashing is saving your changes
> on a temp stack rather than committing them).

This is what I'm used to seeing.  But my usage generally had me making 
changes within a branch, not creating the branch myself, and then the 
developer who created the branch would merge things back (my main use case 
for this was years ago creating in-product text strings for documentation 
purposes - tooltips and the like).

I've used it a fair bit on my own since then, but generally haven't needed 
to branch since the stuff I'm using it for is all for my own amusement.

> Sorry if I'm muddying the water here! I remember being quite confused
> about how git worked when I first started using it.
> 
> Bill

No worries, you got me to actually try it and see, and it wasn't matching 
my memory.  Show now I need to figure out why my memory is different than 
what I actually saw in my simple test.



-- 
"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 31 Jan 2026 00:52:22 -0500, Jim Henderson wrote:

> This is what I'm used to seeing.  But my usage generally had me making
> changes within a branch, not creating the branch myself, and then the
> developer who created the branch would merge things back (my main use
> case for this was years ago creating in-product text strings for
> documentation purposes - tooltips and the like).

I think I understand better now - once I committed the changes to master, 
then the branch I created (test1) "reverted" to what was originally in the 
file when I branched it (ie, it was empty).



-- 
"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 31 Jan 2026 00:55:13 -0500, Jim Henderson wrote:

> On 31 Jan 2026 00:52:22 -0500, Jim Henderson wrote:
> 
>> This is what I'm used to seeing.  But my usage generally had me making
>> changes within a branch, not creating the branch myself, and then the
>> developer who created the branch would merge things back (my main use
>> case for this was years ago creating in-product text strings for
>> documentation purposes - tooltips and the like).
> 
> I think I understand better now - once I committed the changes to
> master, then the branch I created (test1) "reverted" to what was
> originally in the file when I branched it (ie, it was empty).

So it seems to be that once a file is modified and then committed to a 
branch, then changes to it will require a stash or commit before changing 
branches again.

I probably never ran into this since the files I was modifying had already 
been through many iterations by the time I saw them.  But it makes logical 
sense to me that each branch isn't a full copy of everything in the state 
at which it was first added, and that it would be consistent across 
branches until it was changed in one of them.

I'd guess that if a change were committed in 'branch1' and you switched 
back to 'master' where it wasn't committed, and created a new branch 
'branch2', that the behavior would be consistent as well, at least until 
'branch1' was merged back into 'master'.



-- 
"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-30 22:42 (-4), Bill Pragnell wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
>>> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>>>> But it looks like the file is tracked, so any changes to it made in one
>>>> branch shouldn't affect other branches,
> 
> Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> git-speak) refers to an edit, without any git interaction, which is what I've
> been assuming. A change to a branch is usually called a 'commit', and that will
> indeed be unique to the branch.
> 
>>> I'm sensing disagreement in what "tracked" means.  Jim is using
>>> "tracked" the way I've understood it, but Bill is describing the
>>> behavior I'm seeing from git.
> 
> I think git itself may also be confusing the issue here. 'Tracked' just means
> the file has been added to the repo. If I add a new file to a project (without
> git interaction - just make a new file within a repo), it is listed as
> 'untracked' because it does not yet have an entry in the repo - its entire
> contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
> then 'tracked' as part of that branch from that point on. But you could say that
> even an 'untracked' file is tracked in the sense of git being aware of it,
> because it appears in the status. Only files/directories in .gitignore are truly
> untracked because edits to them will be ignored.
> 
> Uncommitted changes (i.e. edits to a file) will not be affected by switching
> branches, unless there is a conflict - i.e. if the edits apply to a section of a
> file that is different in the two branches. In that case, git will not switch
> branches, but instead tell you to commit or 'stash' your changes before
> switching (stashing is saving your changes on a temp stack rather than
> committing them).
> 
> Sorry if I'm muddying the water here! I remember being quite confused about how
> git worked when I first started using it.

No, this is very helpful!  Thank you!

(And I just watched a video about how pilots and air traffic controllers
unknowingly disagreed on definitions of terms, and the result was a
major crash, all souls lost.)

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2026-01-30 22:42 (-4), Bill Pragnell wrote:
> > Jim Henderson <nos### [at] nospamcom> wrote:
> >> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
> >>> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> >>>> But it looks like the file is tracked, so any changes to it made in one
> >>>> branch shouldn't affect other branches,
> >
> > Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> > git-speak) refers to an edit, without any git interaction, which is what I've
> > been assuming. A change to a branch is usually called a 'commit', and that will
> > indeed be unique to the branch.
> >
> >>> I'm sensing disagreement in what "tracked" means.  Jim is using
> >>> "tracked" the way I've understood it, but Bill is describing the
> >>> behavior I'm seeing from git.
> >
> > I think git itself may also be confusing the issue here. 'Tracked' just means
> > the file has been added to the repo. If I add a new file to a project (without
> > git interaction - just make a new file within a repo), it is listed as
> > 'untracked' because it does not yet have an entry in the repo - its entire
> > contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
> > then 'tracked' as part of that branch from that point on. But you could say that
> > even an 'untracked' file is tracked in the sense of git being aware of it,
> > because it appears in the status. Only files/directories in .gitignore are truly
> > untracked because edits to them will be ignored.
> >
> > Uncommitted changes (i.e. edits to a file) will not be affected by switching
> > branches, unless there is a conflict - i.e. if the edits apply to a section of a
> > file that is different in the two branches. In that case, git will not switch
> > branches, but instead tell you to commit or 'stash' your changes before
> > switching (stashing is saving your changes on a temp stack rather than
> > committing them).
> >
> > Sorry if I'm muddying the water here! I remember being quite confused about how
> > git worked when I first started using it.
>
> No, this is very helpful!  Thank you!
>
> (And I just watched a video about how pilots and air traffic controllers
> unknowingly disagreed on definitions of terms, and the result was a
> major crash, all souls lost.)

Yes, that's good clear explanations, the topic itself is complex, and there is a
threshold to it, a kind of "Gestalt" that needs to be reached before one starts
to feel you gain more with all that complexity despite it's learning curve, and
after you reach it, you don't have to become expert/power-user to be okay. you
end up developing a cautious intuition of what features to stay away from vs the
ones to dive into until you do have more time :-D  I still consider myself very
much of a beginner, but still admire and enjoy this tool!

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> But .gitignore is one aspect of git that has never given me any surprises.

The way it had for me, if my poor memory is correct, was some kind of wildcard
that I wasn't aware I had used, and could apply ignore to a whole type of files
instead of specific ones. But you're probably more cautious than that. :-)

Post a reply to this message

One other thing I notice when quickly going through this discussion, has been
left out of it, maybe because too "obvious" or people around here generally
better at it than I was (^-^), also you'd have had other issues if that was your
blind spot... but I remember it was one of the slightly confusing cornerstones
for me initially, so I do feel compelled to write about it:

....Just make sure you fully grasp the distinction and nature of Commit versus
push!

Post a reply to this message

On 2026-02-03 05:57 (-4), Mr wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> But .gitignore is one aspect of git that has never given me any surprises.
> 
> The way it had for me, if my poor memory is correct, was some kind of wildcard
> that I wasn't aware I had used, and could apply ignore to a whole type of files
> instead of specific ones. But you're probably more cautious than that. :-)

Matter of fact, the wildcard feature has been a great organizational
tool for me.  My typical .gitignore entries include:
  *~
  /*/*
  /test_*

(The /*/* entry works for my Object Collection projects because Object
Collection contributions have no directory structure.)

Post a reply to this message

On Tue,  3 Feb 2026 05:08:03 EST, Mr wrote:

> ....Just make sure you fully grasp the distinction and nature of Commit
> versus push!

100%.  I actually did my little test a few days ago without a remote even 
configured - because you can use git that way. :)



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