New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: Released
Owner: ----
Closed: Aug 2016

Sign in to add a comment

Editing a submodule via inline edit doesn't work well

Reported by, Oct 14 2015 Back to list

Issue description

Affected Version: 2.11

What steps will reproduce the problem?
1. Create a change in a project that contains a submodule
2. Edit -> Add -> TheSubmodule
3. Enter a commit hash of the submodule

What is the expected output? What do you see instead?
This hash should be used for the submodule. Instead, some random (?!) hash is used.

Status: AwaitingInformation
I'm not sure if submodules are actually supported in inline edit?

Comment 2 by, Oct 21 2015

If they aren't, the UI should disallow editing of them.

Comment 3 by, Jan 19 2016

It's unlikely that we'll fix this on 2.11.x

Have you tried it on 2.12?

Comment 5 by, Jan 19 2016

It's the same on 2.12.

Comment 6 by, Apr 4 2016


Comment 7 by, Apr 4 2016

I tested it with current master: Here the hash changes immediatly after saving the edit, before publishing it.
The hash one gets is actually stable (meaning: for the same input you always get the same changed hash)

Comment 8 by, Apr 6 2016

I did some further debugging:

1) create a new change from gui
3) switch to edit mode
2) add an existing submodule path
    -> you see the (correct) hash of the submodule project
4) change this to some arbitrary string (e.g. abc)
5) save, close, reopen
   -> You see some other hash
   --> go to the gerrit git folder and do git show <this hash>
       ---> you see the string you entered again.

So there is something quite wrong there.  

Comment 9 by, Apr 7 2016

I took a llok at the code:
When reading the contents for editing, FileContentsUtil correctly special-cases GITLINKS.
When writing we have this code in server/edit/

      ObjectId newTree = writeNewTree(op,
          toBlob(inserter, content));
      if (ObjectId.equals(newTree, prevEdit.getTree())) {
        throw new InvalidChangeOperationException("no changes were made");

My guess is that the toBlob is incorrect for GITLINK (we insert the blob hash instead of the correct raw content). 

Project Member

Comment 12 by, Apr 14 2016

Status: ChangeUnderReview
Project Member

Comment 13 by, Aug 9 2016

Labels: FixedIn-2.13
Status: Submitted
Project Member

Comment 14 by, Sep 22 2016

Status: Released

Sign in to add a comment