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