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