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