If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Provide a pretxncommit hook to refrain from accepting changesets which don't rename files correctly

NEW
Unassigned

Status

Developer Services
Mercurial: hg.mozilla.org
7 years ago
3 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/845] )

There are two ways in hg to rename a file.  One of them is the proper way (hg mv) which allows hg to know about the rename operation and preserve it into history, and the other (mv followed by hg addremove) makes hg believe that one file was added and another was removed, and will corrupt the revision history for that file.

We need a pretxncommit hook on hg.mozilla.org (for mozilla-central at least) which investigates the file names in each changeset, looks for added and removed files, and bails out if it finds an added file with the same leaf name as another removed file.

Hopefully this will prevent people from pushing broken changesets in the future.
The trick here would be to use addremove *with* the --similarity option, which will correctly determine rename information.

I'm not sure how many people get this wrong, but I'd be hesitant about adding this as a hook; it only finds the simple cases and potentially misses many others. And it's certainly possible to have false positives.
> I'm not sure how many people get this wrong

Apparently anyone rebasing a changeset that includes renames while using hg 1.2.1, since in that case rebase screws things up, apparently.

But in general, it's happened a number of times during the history of m-c.  We should no longer trust people to get this right, since historically they don't (and broken tools don't help).

More to the point, dealing with a false positive is easy: split it up into a changeset that adds and one that removes.  Dealing with fallout from someone screwing this up is a huge pain; see the m.d.tree-management thread with subject "significant file rename patch landed incorrectly".

While I agree that such a hook won't catch someone renaming nsHttpChannel.cpp to HttpChannel.cpp, it _would_ catch people doing mass-restructuring of directories, which we're definitely going to have more of going forward.
Okay, so, are we sure that rebase has been fixed in later hg? And if so, can we get people to upgrade to newer hg? In the meantime, maybe I'll advocate for addremove to run with --similarity 100 by default.
> Okay, so, are we sure that rebase has been fixed in later hg?

I'm not, but all the information I have is in the thread I mentioned...
Adding gozer & Standard8, as I bet comm-central wants this hook too.
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
(Assignee)

Updated

3 years ago
Product: Release Engineering → Developer Services

Updated

3 years ago
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/106]

Updated

3 years ago
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/106] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/845] [kanban:engops:https://kanbanize.com/ctrl_board/6/106]
(Assignee)

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/845] [kanban:engops:https://kanbanize.com/ctrl_board/6/106] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/845]
You need to log in before you can comment on or make changes to this bug.