Closed Bug 943563 Opened 11 years ago Closed 1 month ago

Verbatim is committing surpisingly many merge commits

Categories

(Webtools Graveyard :: Verbatim, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: clouserw, Unassigned)

Details

It looks like moz-verbatim is committing to more than just L10n files.  It's doing merge commits and stuff.  I've seen it once a while ago, this is the most recent example:

https://github.com/mozilla/fireplace/compare/fd52b54334...8afba161cc

It should only be touching .po files
Component: Other → Verbatim
Product: Mozilla Localizations → Webtools
Version: unspecified → other
Can you detail on what's happening? I look at the comparison, and it claims that it changed two files. It'd be helpful to learn what you're expecting.

Please file bugs in the verbatim component, this is not about unknown localizations.
I'm not expecting those 8 merge commits to be there.  The sum total is that it changed those two files, but it did it with a bunch of merge commits cluttering up the history.
Resummarizing.

Dwayne, have concerns like this been raised in other setups, or is that something we're doing?

Here's my speculation: For some reason, we have a merge commit in the local repo, but don't push that. At that point, everytime that a localizer goes in and updates from VCS, we get a merge of that merge.

If that's true, can we avoid having local merge commits around without pushing them upstream?
Flags: needinfo?(dwayne)
Summary: Verbatim is committing more than just L10n → Verbatim is committing surpisingly many merge commits
Axel,

Haven't seen this in any other setup.  We introduced the separate VCS_DIRECTORY in 2.5 so we should have a clean checkout in that directory which should never have any kind of merge conflict.  Since we update that repo then export what we want to commit, then commit.

I guess there is the possibility that between an update and a commit a change could happen upstream in which case we might get a merge commit (this is me as a non-Git expert speaking).

The first step, I think, is to check the repo in VCS_DIRECTORY to see if it is in some odd state.  If it is then I think we can try the next steps which is to clean that up. We might want to change Pootle to prevent that happening again.  If it is OK we'll need to look elsewhere.
Flags: needinfo?(dwayne)
Matjaz, can you check on Dwayne's suggestions?
Flags: needinfo?(m)
Yes. I checked the fireplace repo and everything looks fine ATM:

[verbatim@verbatim1 fireplace]$ git status
# On branch master
nothing to commit (working directory clean)
Flags: needinfo?(m)
Product: Webtools → Webtools Graveyard
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.