4 ms·

> Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've se

> Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've seen anything like that. About the only case I can think of where Git insists on "modifying" random files is when line endings are mismatched, and the repo is not configured properly. But even then it's not lossy. Git does this by design. There seems to be no concept of line-item uploads - either you have to push the whole fork or none of it. There seems to be no concept of "I haven't modified this file", and an assumption that a user will frequently be fetching and aware of the entire code base. Some tools help with this awareness, by auto-fetching frequently, so you know when others have uploaded code and you need to merge the master back into your branch. (Err diff the mainline against your development copy, so you can integrate the upstream changes into yours.) Mandatory workflows like this should be automated as part of the tool, but here they are very clearly left manual.

int_19h 9y ago
If the developer is working in their own branch, as is the normal scenario with Git, then they can push that branch to their heart's content - nothing is magically changing there. They will, of course, need to merge it with the primary branch eventually - but that's the thing, you merge branches (or rebase them), you don't just replace one with the other... and it's not like the latter is easy to do accidentally. And when you merge, of course, it will only merge the diffs, so the concept of "I haven't modified this file" is inherent. If your fork has only modified the files that no-one else touched, then it doesn't really matter how old it is - it'll still be able to merge; you don't need to be frequently syncing with the main branch. If the developer is working directly in the main branch, then what you describe can happen - although even then, if someone else makes changes there, there would be a divergence, and push would simply fail, instead of overwriting those changes (unless you explicitly force it by using -f... but the whole point of having that switch is to be a safeguard against destructive operations). So I'm still confused about the exact scenario here.

int_19h 9y ago

If the developer is working in their own branch, as is the normal scenario with Git, then they can push that branch to their heart's content - nothing is magically changing there. They will, of course, need to merge it with the primary branch eventually - but that's the thing, you merge branches (or rebase them), you don't just replace one with the other... and it's not like the latter is easy to do accidentally. And when you merge, of course, it will only merge the diffs, so the concept of "I haven't modified this file" is inherent. If your fork has only modified the files that no-one else touched, then it doesn't really matter how old it is - it'll still be able to merge; you don't need to be frequently syncing with the main branch. If the developer is working directly in the main branch, then what you describe can happen - although even then, if someone else makes changes there, there would be a divergence, and push would simply fail, instead of overwriting those changes (unless you explicitly force it by using -f... but the whole point of having that switch is to be a safeguard against destructive operations). So I'm still confused about the exact scenario here.