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