Second attempt to implement inline edit feature in Gerrit

[David Ostrovsky]

As you may know much effort has been made[1] to implement inline edit feature in Gerrit,

that means to edit files directly in browser in cm3 editor with syntax highlighting.

Technically revision edits are different from regular patch sets:

* they don't exist in the db

* they are stored on the "refs/edits/" in Git with user id inside

Unfortunately the old series was targeting the old change screen, that is dead now.

So we can not really reuse much code. The tasks remain the same, off the top of my head:

Ground work:

* Provide RevisionEditInserter & RevisionEditReader.

* Extend PatchSet.Id to represent RevisionEdit:

  regular patch set 1,1 (exists in the db) vs.

  patch set 1,1+ virtual patch set (doesn't exist in the db).

REST API:

* Extend detail change endpoint to retrieve revision edits (new option or per default?).

* PutContent endpoint: change a resource inside existing revision edit or create a new revision edit

* GetContent endpoint: retrieve a resource from revision edit or from a

  revision if there is no revision edit for this revision and user (already there?).

* Publish revision edit: promote it to be a regular patch set.

* Discard revision edit: delete it.

CS2:

* File table header, right to "Diff against": add "Edit mode" button to switch file table in edit mode.

  In edit mode:

  ** reviewed checkbox is replaced with change icon in front of each path

  ** Edit mode button is replaced with "Review mode"

  ** on history header, right to "Expand all" button: new href appears "+ click to add a file".

  ** if "+ click to add a file" clicked, open a popup box where directory name and new file name can be entered.

* If clicked n edit icon in front of a path or on "+", open cm3 editor in a popup with change/cancel buttons.

  Alternatively dispatch to a new screen with cm3 editor and file content.

  (User preferences?)

* Extend core UiActions list to support PublishRevisionEdit & DiscardRevisionEdit if currently loaded patch set is a revision edit.

* Extend "Patch Set" & "Diff against" drop downs to show not only regular patch sets but also revision edits: 1/2, 1+/2

Syde by Side 2:

* Extend revision list to show not only regular patch sets but also revision edits,

  to allow the compare revision edit against previous (regular patch set), e. g.

  left side: 1,2,3, right side: 1,2,3,3+

* Make dispatcher revision edits aware to understand the token: "2..2+", to compare the revision edit on top of ps 2 with ps 2.

* [optionally] add Edit button to the Header (side b) to edit the file directly in cm3.

  Wenn the edit button is activated, switch to edit mode, load the whole content,

  disable/hide side a and add change/cancel buttons.

Now that we know what TODO (it took some time to figure that out ;-) we can easily parallelize the work,

so your help is appreciated to make inline edit in Gerrit reality.

[1] https://gerrit-review.googlesource.com/#/q/topic:inline,n,z

[David Ostrovsky]

Am Mittwoch, 11. Dezember 2013 17:19:03 UTC+1 schrieb David Ostrovsky:

As you may know much effort has been made[1] to implement inline edit feature in Gerrit,

that means to edit files directly in browser in cm3 editor with syntax highlighting.

 
[...]

Ground work:

* Provide RevisionEditInserter & RevisionEditReader.

Done in [1].
 

REST API:

* Extend detail change endpoint to retrieve revision edits (new option or per default?).

* PutContent endpoint: change a resource inside existing revision edit or create a new revision edit

* GetContent endpoint: retrieve a resource from revision edit or from a

  revision if there is no revision edit for this revision and user (already there?).

* Publish revision edit: promote it to be a regular patch set.

* Discard revision edit: delete it.

REST endpoints can be implemented now and can be considered as easy hack tasks.

[1] https://gerrit-review.googlesource.com/52890

[David Ostrovsky]

Done in [1]. Here is the first screen shot: revision edit in CS2 [2].

It can be used already, even without CS2/SBS2 extension:

edit content of file foo and upload it as new revision edit on top of ps 1,1

  curl --digest --user joe:secret -X PUT --data-binary @foo --header "Content-Type: text/plain" http://lserver:port/a/changes/1/revisions/1.edit/files/foo/content

Note: this can be repeated multiple times (amending the revision edit)

After refreshing of browser cache the revision edit should be displayed in CS2 and can be published or deleted.

TODO:

* make CS2 and SBS2 revision edit aware

[1] https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:inline-2,n,z

[2] http://imgur.com/t2sBCbf

[David Ostrovsky]

Am Sonntag, 15. Dezember 2013 22:41:09 UTC+1 schrieb David Ostrovsky:

Am Freitag, 13. Dezember 2013 13:12:54 UTC+1 schrieb David Ostrovsky:

Am Mittwoch, 11. Dezember 2013 17:19:03 UTC+1 schrieb David Ostrovsky:

As you may know much effort has been made[1] to implement inline edit feature in Gerrit,

that means to edit files directly in browser in cm3 editor with syntax highlighting.

 
[...]

Ground work:

* Provide RevisionEditInserter & RevisionEditReader.

Done in [1].
 

REST API:

* Extend detail change endpoint to retrieve revision edits (new option or per default?).

* PutContent endpoint: change a resource inside existing revision edit or create a new revision edit

* GetContent endpoint: retrieve a resource from revision edit or from a

  revision if there is no revision edit for this revision and user (already there?).

* Publish revision edit: promote it to be a regular patch set.

* Discard revision edit: delete it.

REST endpoints can be implemented now and can be considered as easy hack tasks.

Done in [1]. Here is the first screen shot: revision edit in CS2 [2].

[...]

TODO:

* make CS2 revision edit aware

Done in [1]. Revision edits can be created, deleted and published in CS2, to test:

* Apply the series

* Upload a change

* Switch file table into Edit Mode: edit icons appear instead of checkboxes in front of path names

* Click edit icon

* Edit popup dialog with the file content appears

* Change content

* Click Save button: revision edit is created, reloaded and shown as ps+, e. g. "1+" in Patch Sets drop down

* <Repeat the last steps for the same file or different files>: revision edit is amended and reloaded

* Delete and Publish buttons appear in revision action panel

* Click Publish button: new ps with changes made in revision edit created

or

* Click Delete Revision button: revision edit is discarded, bringing you back to the base ps, e. g. from 1+ to 1.

TODO:

SBS2, CM3 integration

[David Ostrovsky]

SBS2 integration

Done in [1]. Revision edits appear in SBS2 now and can be selected and compared in CM3.

Given it is already big series i wonder if we can review/polish/merge it as is and do CM3 integration later?

[David Pursehouse]

> Given it is already big series i wonder if we can review/polish/merge it
> as is and do CM3 integration later?
>

I think this is a good idea. Otherwise you'll just be rebasing and
reuploading the whole series again and again. Merging it as it is will
allow others to contribute enhancements and fixes. We saw this with the
initial implementation of the new change screen.

I've checked out the series and done some quick tests locally. It all
seems to work as expected and looks good so far. There are a few nits
and glitches (list below) but as mentioned above I think it's reasonable
to merge as is and fix those in follow-up changes.


- There are a couple of warnings in Eclipse after checking out the
series. I've added inline comments on the relevant parts on the code
review.

- In "Edit Mode", after opening a file in side-by-side view by clicking
on the filename, and then clicking the "Up to change" icon, the change
screen goes back in Review Mode. It might be better to make the mode
persistent.

- The "Save" button has the tool tip "Create new patch set with updated
commit message".

- After making changes in the file, then pressing "Reload", the "Save"
button is still enabled.

- Upon publishing an edit and creating a new patch set, the review
comment "Published new edits" is added. It would be better if this were
more consistent with the existing messages that are posted when doing
some action in the UI. For example on creating patch set 2 by editing
the commit message, the message is "Patch Set 2: Commit message was
updated".

- In Edit Mode, it doesn't make sense to be able to select the "Diff
against" revision option.

- To edit the commit message while in Edit Mode, the user must still use
the "Edit Message" button on the commit message box. It would be better
if there were also an edit icon beside the commit message in the file list.

- When adding a new file in Edit Mode, the pop up dialog does not have
any labels on the input fields.

- After adding a new file, the change screen goes back to "Review Mode".

- Since we can add files, should we also be able to remove files from
the change? If so, should it completely remove the file, or only undo
the changes that were added?

- Similarly, should we be able to rename files?

[Thomas Swindells (tswindel)]

> - Since we can add files, should we also be able to remove files from the
> change? If so, should it completely remove the file, or only undo the
> changes that were added?

[Thomas Swindells] +1 for a quick and easy means to undo changes added to an erroneously checked in file (ie local change to logging config) - in the case of a newly added file this would be an equivalent of a remove. It's probably very very rare to actually want to delete a file outright so I'm less bothered if inline editing doesn't support that.

>
> - Similarly, should we be able to rename files?

[Thomas Swindells] This is probably slightly more common than deleting files (at least for us we have sql patch files where the name needs to match the patch it is against) however again I don't think it is essential, I don't think we are aiming for a full development environment, just a means to perform quick simple changes.

[David Ostrovsky]

Thanks for testing it. See my comments below.

On Thursday, December 19, 2013 7:13:54 AM UTC+1, David Pursehouse wrote:

> Given it is already big series i wonder if we can review/polish/merge it
 > as is and do CM3 integration later?
 >

I think this is a good idea.  Otherwise you'll just be rebasing and
reuploading the whole series again and again.  Merging it as it is will
allow others to contribute enhancements and fixes.  We saw this with the
initial implementation of the new change screen.

Agreed.

 

I've checked out the series and done some quick tests locally.  It all
seems to work as expected and looks good so far.  There are a few nits
and glitches (list below) but as mentioned above I think it's reasonable
to merge as is and fix those in follow-up changes.


- There are a couple of warnings in Eclipse after checking out the
series.  I've added inline comments on the relevant parts on the code
review.

this is a bug.

 

- In "Edit Mode", after opening a file in side-by-side view by clicking
on the filename, and then clicking the "Up to change" icon, the change
screen goes back in Review Mode.  It might be better to make the mode
persistent.

Agreed. We already passing some information back from SBS2 to CS2, e. g. "Diff Against"

version, so it should be easy to extend it and pass Edit Mode too.

- The "Save" button has the tool tip "Create new patch set with updated
commit message".

Copy/paste ;-)

 

- After making changes in the file, then pressing "Reload", the "Save"
button is still enabled.

this is a bug.

 

- Upon publishing an edit and creating a new patch set, the review
comment "Published new edits" is added.  It would be better if this were
more consistent with the existing messages that are posted when doing
some action in the UI.  For example on creating patch set 2 by editing
the commit message, the message is "Patch Set 2: Commit message was
updated".

Agreed.

 

- In Edit Mode, it doesn't make sense to be able to select the "Diff
against" revision option.

Agreed.

 

- To edit the commit message while in Edit Mode, the user must still use
the "Edit Message" button on the commit message box.  It would be better
if there were also an edit icon beside the commit message in the file list.

Missing feature, and can be done later. There are some other corner cases,

which we probably want to disable too, in edit mode.

 

- When adding a new file in Edit Mode, the pop up dialog does not have
any labels on the input fields.

Missing feature.

 

- After adding a new file, the change screen goes back to "Review Mode".

Agreed, we should find a way to preserve the state.

Note: adding new file amends the revision edit and reload

the change screen.

- Since we can add files, should we also be able to remove files from
the change?  If so, should it completely remove the file, or only undo
the changes that were added? 

- Similarly, should we be able to rename files?

Missing features.

We should have them all: Remove the file from repository and remove it from the change.

Why not to put four icons in front of path: [EDIT], [REMOVE from REPO], [REMOVE from CHANGE], [RENAME].

Renaming can be even done in place: the row can be switched into inline edit field and after changing the name and clicking enter,

the file is renamed.

But as you said, let's do that later.

[Nasser Grainawi]

Granted I haven't played with this so the terms aren't entirely familiar to me, but does removing this retain the ability to see the diff of your edits? Similar to the idea of 'git diff --cached' locally?

 

- To edit the commit message while in Edit Mode, the user must still use
the "Edit Message" button on the commit message box.  It would be better
if there were also an edit icon beside the commit message in the file list.

Missing feature, and can be done later. There are some other corner cases,

which we probably want to disable too, in edit mode.

 

- When adding a new file in Edit Mode, the pop up dialog does not have
any labels on the input fields.

Missing feature.

 

- After adding a new file, the change screen goes back to "Review Mode".

Agreed, we should find a way to preserve the state.

Note: adding new file amends the revision edit and reload

the change screen.

- Since we can add files, should we also be able to remove files from
the change?  If so, should it completely remove the file, or only undo
the changes that were added? 

- Similarly, should we be able to rename files?

Missing features.

We should have them all: Remove the file from repository and remove it from the change.

Why not to put four icons in front of path: [EDIT], [REMOVE from REPO], [REMOVE from CHANGE], [RENAME].

Renaming can be even done in place: the row can be switched into inline edit field and after changing the name and clicking enter,

the file is renamed.

But as you said, let's do that later.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

hosted by The Linux Foundation

[David Ostrovsky]

Yeah, you are right, let me take the above "Agreed" back ;-)

It is needed to be able to compare the edit with the based ps itself:

ps1+ <== edit

ps1

base

"Diff Against" must be selected to ps1 to see only changes in edit. 

[David Ostrovsky]

Am Donnerstag, 19. Dezember 2013 07:13:54 UTC+1 schrieb David Pursehouse:

[...] 

- There are a couple of warnings in Eclipse after checking out the
series.  I've added inline comments on the relevant parts on the code
review.

Done.

 

 

- The "Save" button has the tool tip "Create new patch set with updated
commit message".

Done.

 

- After making changes in the file, then pressing "Reload", the "Save"
button is still enabled.

Done.

 

- Upon publishing an edit and creating a new patch set, the review
comment "Published new edits" is added.  It would be better if this were
more consistent with the existing messages that are posted when doing
some action in the UI.  For example on creating patch set 2 by editing
the commit message, the message is "Patch Set 2: Commit message was
updated".

Done.

 

- In Edit Mode, it doesn't make sense to be able to select the "Diff
against" revision option.

It turns out it does, see comments above.

 

- When adding a new file in Edit Mode, the pop up dialog does not have
any labels on the input fields.

Done.

 

- Since we can add files, should we also be able to remove files from
the change?  If so, should it completely remove the file, or only undo
the changes that were added?

[partially] Done.

Edit mode was extended to enable file removal [1]. Once the file is removed,

no editing of this file is possible. The same holds true for the files

that were already removed in the patch set the edit is based on.

[1] http://imgur.com/m01HW1P

[Bruce Zu]

 about the code style, want to know does it apply "gerrit/tools/GoogleFormat.xml" to edit part automatically? 

[David Ostrovsky]

On Thursday, January 2, 2014 6:42:10 AM UTC+1, Bruce Zu wrote:

 about the code style, want to know does it apply "gerrit/tools/GoogleFormat.xml" to edit part automatically? 

Currently it doesn't do any magic. Just let you edit a file in a text area. The plan is to integrate it with CM3

and enable content type specific syntax highlighting mode.

[Zu, Bruce]

Thanks David, got it.

> “…enable content type specific syntax highlighting mode. “

This is cool. Today I find GitLab  also can create new file and update file online (from UI) , but without syntax highlighting.

--

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---

You received this message because you are subscribed to a topic in the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/repo-discuss/20ge_59v3WI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to repo-discuss...@googlegroups.com.

[David Pursehouse]

Looks like there have been a few rebases and reworks on this series since December.

What's the status now?  Is it ready?

Even if it's not perfect I think we should merge the series (as long as there's nothing seriously wrong with it) and then add fixes as needed.  It would be really good to get this feature in 2.9.

BTW yesterday GitHub rolled out inline editing of pull requests [1].

[1] https://github.com/blog/1738-web-flow-editing-from-pull-requests

 

[David Ostrovsky]

Am Mittwoch, 22. Januar 2014 02:15:32 UTC+1 schrieb David Pursehouse:

On Friday, 20 December 2013 07:49:56 UTC+9, David Ostrovsky wrote:

Am Donnerstag, 19. Dezember 2013 07:13:54 UTC+1 schrieb David Pursehouse:

[...] 

[...] 

Looks like there have been a few rebases and reworks on this series since December.

What's the status now?  Is it ready?

It was suggested to introduce new collection RevisionEdit and separate the retrieval of edits from

normal and draft revisions. This solved the problem of stale change data. So now if eits canged

(created, replaced or deleted)  /changes/<id>/detail returns 304, and the own revision edit REST

call returns the edits.

That way it is not needed any more to always update change data after reviosion edit operation.

It is done and pending for review. 

 

Even if it's not perfect I think we should merge the series (as long as there's nothing seriously wrong with it) and then add fixes as needed.  It would be really good to get this feature in 2.9.

Well it is always a matter of feedback and review: check it out, try it, give your scores.

But because it is really a big series my suggestion would be to start small and try to merge

this one ground work change [1]. It is new code and depends only on two small extensions to

acceptance test framework.

[1] https://gerrit-review.googlesource.com/#/c/52890

[Björn Pedersen]

I just tested the series and it looks really nice.

There a a few nits I found (see also comments on the add file changeset):
 * The add-button is located a bit unfortunatly.
 * It is possible to start editing a merged change, you get the change-closed error only when you try to publish it.

Björn

[David Ostrovsky]

On Monday, February 24, 2014 1:34:58 PM UTC+1, Björn Pedersen wrote:

I just tested the series and it looks really nice.

Thanks!

To move forward with inline edit series and try to merge it, we should start with

review of this groundwork change:  [1], pure JGit code. Any chance someone can look into it?

There a a few nits I found (see also comments on the add file changeset):
 * The add-button is located a bit unfortunatly.

Will change it.

 

 * It is possible to start editing a merged change, you get the change-closed error only when you try to publish it.

We should add missing check here.

[1] https://gerrit-review.googlesource.com/52890

[Björn Pedersen]

Hi,

with the new changes it looks much better to me.

One think, were I am a bit unsure: The edit mode is not persistent (after doing an edit, you are back to
review mode). On one hand this is can be annoying, if you e.g want  touch many files, on the other hand it
has the advantage that it discourages too many (big) inline edit attempts. Larger changes should in my opinion
be done in a local editing environment were you can test your changes locally as well. But hat can definitly get
changed later, if desired.

Björn

[David Ostrovsky]

On Tuesday, February 25, 2014 9:29:53 AM UTC+1, Björn Pedersen wrote:

Hi,

with the new changes it looks much better to me.

Thanks for your feedback and help! You have VRFY permission now so don't hesitate to vote on changes,

that work for you as expected ;-) 

 

One think, were I am a bit unsure: The edit mode is not persistent (after doing an edit, you are back to
review mode).

True. David P. already mentioned the same problem in this thread. As you pointed out below, I am a bit

undecided if we should remember the edit state, or forget it (as currently implemented), or both and

allow user to choose the desired REMEMBER_REVISION_EDIT_STATE_ON_CS2 user preference

screen.

 

On one hand this is can be annoying, if you e.g want  touch many files, on the other hand it
has the advantage that it discourages too many (big) inline edit attempts. Larger changes should in my opinion
be done in a local editing environment were you can test your changes locally as well. But hat can definitly get
changed later, if desired.

One question: Do you think it is OK to go with plain text editor with the initial implementation of inline

edit feature, or would you expect that Codemirror integration with syntax highlighting should be already

implemented in the very first version?

[David Pursehouse]

IMHO the current implementation is good enough, and if we want to use
Codemirror that can be added in follow-up changes.

This series has been under review for ages now. I think it's time we
got it merged and then everyone can use it and submit patches to fix the
minor nits and glitches.

[David Ostrovsky]

Yeah, the first change to the predecessor inline-edit-1 series, that this series is based on,

was committed by Dave B. during London's Hackathon on May 8. 1013 [1], so ages ago ;-)

[1] https://gerrit-review.googlesource.com/45452

[Sven Selberg]

Yeah, the first change to the predecessor inline-edit-1 series, that this series is based on,

was committed by Dave B. during London's Hackathon on May 8. 1013 [1], so ages ago ;-)

[1] https://gerrit-review.googlesource.com/45452

After the battle of Hastings things were a bit chaotic, that might have been a contributing factor.

One must also remember that communications weren't that great in the 11th century, a simple ping would have taken hundreds of years! 

[Björn Pedersen]

One question: Do you think it is OK to go with plain text editor with the initial implementation of inline

edit feature, or would you expect that Codemirror integration with syntax highlighting should be already

implemented in the very first version?

I think the current version is fine for merging. CodeMirror support is a nice-to-have, already now you can many nice
last-minute tidy-ups (e.g. white space errors, simple typos) in web ui.

Björn

[David Ostrovsky]

Inline Edit series with 100% browser based workflow is feature complete now: [1].

* New changes can be initiated/populated directly in browser (from Project Inof screen)

* New follow-up changes can be created from change screen

* File table in CS2 was extended to support edit mode with seamless navigation to CM3 for editing

* SBS2 was extended to jump directly to CM3 in edit mode 

* Commit message can be changed in context of change edit ("Edit Message" button is still supported, but now it creates change edit that must be published)

* Files can be added, deleted, restored and modified directly in browser

* Content editing takes place in full screen Codemirror window with support for themes, syntax highlighting, different key maps (Emacs, Vim, Defaut) and usual CM3 setting, known from SBS2 screen

* User specific customizations dedicated to edit mode in CM3 can be saved/loaded in/from AllUsers repository (no database interaction involved)

Here are some screen shots: CM3 in edit mode with active Edit Preferences box [2].

[1] https://gerrit-review.googlesource.com/#/q/status:open+topic:inline-3

[2]

http://imgur.com/8wCGA8D

http://imgur.com/ISNreVU

[David Pursehouse]

I've rebased the series on the latest master branch and resolved conflict caused by the change that I submitted out-of-sequence earlier this week.

It looks like [1] is the latest change that is complete; the successor of that has TODO in the commit message.  I've done some quick smoke tests based on [1] and it's looking very good.

It would be great if we can get this finalised before making 2.11-rc0.

[1] https://gerrit-review.googlesource.com/#/c/61590/2

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---

You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Ostrovsky]

Am Donnerstag, 20. November 2014 10:11:40 UTC+1 schrieb David Pursehouse:

I've rebased the series on the latest master branch and resolved conflict caused by the change that I submitted out-of-sequence earlier this week.

Thanks!

 

It looks like [1] is the latest change that is complete; the successor of that has TODO in the commit message.  I've done some quick smoke tests based on [1] and it's looking very good.

The TODO you are referencing is missing REST API documentation.

Two other changes from the series allow to load/save user preferences

dedicated to edit mode from/to Git repository. So actually the last change

in the series is: [2]. With it in place, you could adjust CM3 settings, like

theme, key map, show/hide tabs, enable/disable line wrapping, etc. You

do this with Edit Preference dialog, like in SBS2, see screen shot [3].

It would be great if we can get this finalised before making 2.11-rc0.

+1

When the review of load/save preferences from/to Git repository takes

longer (last two changes in the series), we could try to merge it up to the

change you've referenced [1]. This would give us CM3 integration with syntax

highlighting in full screen window. This is much better, what we have now:

popup dialog with simple text area.

 

[1] https://gerrit-review.googlesource.com/#/c/61590/2

[2] https://gerrit-review.googlesource.com/61602

[3] http://imgur.com/8wCGA8D

[David Ostrovsky]

Am Donnerstag, 20. November 2014 10:11:40 UTC+1 schrieb David Pursehouse:

I've rebased the series on the latest master branch and resolved conflict caused by the change that I submitted out-of-sequence earlier this week.

It looks like [1] is the latest change that is complete; the successor of that has TODO in the commit message. 

Missing REST endpoint documentation was added in latest patch set. 

[David Ostrovsky]

I am pleased to announce, that the last major changes for inline edit feature were merged today.

Gerrit supports 100% browser based workflow now. This series was pending for almost 2 years,

has seen hundreds merged and abandoned changes and underwent 3 major rewrites:

* targeting old change screen

* targeting new change screen

* redesign to restrict to one edit per change with rebase support

Something like this is only possible with strong support from the community:

Special thank to main reviewers: Dave Borowitz and David Pursehouse.

Big thank to other reviewers and contributors: Shawn, Edwin, Martin, Dariusz and Björn Pedersen.

PS: You may be interested in my talk on upcoming Fosdem conference about inline edit feature in Gerrit: [1].

[1] https://fosdem.org/2015/

[Alex Blewitt]

Congratulations - this will be a great benefit to the Gerrit community. 

Alex

Sent from my iPhat 6

[Steffen Gebert]

Great!

Thanks for the incredible amount of work!
Looking forward to the release

Steffen

[Edwin Kempin]

Thanks a lot for driving this implementation with so much passion!

It's awesome that inline edit is now possible.

[Shawn Pearce]

I too am very excited about this. I am working on updating
gerrit-review with this series, and hope to have it online later
today.

[Luca Milanesio]

Same here :-) Loved the feature since David O. presented it at the last Gerrit User Summit :-)
In-line edit is available already at review.gerrithub.io but will update to the "latest and greatest" quite soon.

@David O: well done mate :-)

Luca.

[David Pursehouse]

On 12/18/2014 07:30 AM, 'Shawn Pearce' via Repo and Gerrit Discussion wrote:
> I too am very excited about this. I am working on updating
> gerrit-review with this series, and hope to have it online later
> today.
>

In case anyone hasn't noticed: it is online now on gerrit-review.

It works much better than the previous implementation. There are likely
still some things that need to be fixed and improved though, so I would
encourage people to try it out as much as possible.

I'm really happy to see this finally deployed and to be included in the
upcoming 2.11 release. Great work, David O.

[Luca Milanesio]

And this morning is live on gerrithub.io as well :-)
Thanks David O. well done!!!

Luca.