[JBoss JIRA] (FORGE-486) Scaffolding an entity with an enum fails
by Pete Muir (JIRA)
Pete Muir created FORGE-486:
-------------------------------
Summary: Scaffolding an entity with an enum fails
Key: FORGE-486
URL: https://issues.jboss.org/browse/FORGE-486
Project: Forge
Issue Type: Bug
Reporter: Pete Muir
for
{code}
{code}
{code}
{code}
I get
{code}
[ticket-monster] ticket-monster-1 $ scaffold from-entity org.jboss.jdf.example.ticketmonster.model.MediaItem;
Wrote /Users/pmuir/workspace/ticket-monster-1/src/main/java/org/jboss/jdf/examples/view/MediaItemBean.java
***ERROR*** [scaffold from-entity] Error generating default scaffolding: java.lang.ClassCastException: org.jboss.forge.parser.java.impl.JavaEnumImpl cannot be cast to org.jboss.forge.parser.java.MethodHolder
org.jboss.forge.shell.exceptions.CommandExecutionException: Error generating default scaffolding: java.lang.ClassCastException: org.jboss.forge.parser.java.impl.JavaEnumImpl cannot be cast to org.jboss.forge.parser.java.MethodHolder
at org.jboss.forge.shell.command.Execution.perform(Execution.java:153)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:125)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:63)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:829)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:852)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:642)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:120)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:149)
... 31 more
Caused by: java.lang.RuntimeException: Error generating default scaffolding: java.lang.ClassCastException: org.jboss.forge.parser.java.impl.JavaEnumImpl cannot be cast to org.jboss.forge.parser.java.MethodHolder
at org.jboss.forge.scaffold.faces.FacesScaffold.generateFromEntity(FacesScaffold.java:339)
at org.jboss.forge.scaffold.plugins.ScaffoldPlugin.generateFromEntity(ScaffoldPlugin.java:174)
... 35 more
Caused by: org.metawidget.inspector.iface.InspectorException: java.lang.ClassCastException: org.jboss.forge.parser.java.impl.JavaEnumImpl cannot be cast to org.jboss.forge.parser.java.MethodHolder
at org.metawidget.inspector.iface.InspectorException.newException(InspectorException.java:51)
at org.jboss.forge.scaffold.faces.metawidget.inspector.propertystyle.ForgePropertyStyle.inspectProperties(ForgePropertyStyle.java:159)
at org.metawidget.inspector.impl.propertystyle.BasePropertyStyle.getUncachedTraits(BasePropertyStyle.java:172)
at org.metawidget.inspector.impl.BaseTraitStyle.getTraits(BaseTraitStyle.java:126)
at org.metawidget.inspector.impl.propertystyle.BasePropertyStyle.getProperties(BasePropertyStyle.java:54)
at org.metawidget.inspector.impl.BaseObjectInspector.getProperties(BaseObjectInspector.java:499)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectTraits(BaseObjectInspector.java:341)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:243)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:69)
at org.metawidget.inspector.composite.CompositeInspector.runInspector(CompositeInspector.java:241)
at org.metawidget.inspector.composite.CompositeInspector.runInspectors(CompositeInspector.java:220)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:167)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:151)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:53)
at org.metawidget.pipeline.base.BasePipeline.inspectAsDom(BasePipeline.java:344)
at org.metawidget.statically.StaticMetawidget.inspect(StaticMetawidget.java:301)
at org.metawidget.statically.StaticMetawidget.write(StaticMetawidget.java:247)
at org.metawidget.statically.StaticMetawidget.write(StaticMetawidget.java:233)
at org.metawidget.statically.BaseStaticWidget.write(BaseStaticWidget.java:126)
at org.metawidget.statically.BaseStaticXmlWidget.write(BaseStaticXmlWidget.java:168)
at org.metawidget.statically.BaseStaticWidget.write(BaseStaticWidget.java:126)
at org.metawidget.statically.StaticMetawidget.write(StaticMetawidget.java:255)
at org.jboss.forge.scaffold.faces.FacesScaffold.writeEntityMetawidget(FacesScaffold.java:777)
at org.jboss.forge.scaffold.faces.FacesScaffold.generateFromEntity(FacesScaffold.java:292)
... 36 more
Caused by: java.lang.ClassCastException: org.jboss.forge.parser.java.impl.JavaEnumImpl cannot be cast to org.jboss.forge.parser.java.MethodHolder
at org.jboss.forge.scaffold.faces.metawidget.inspector.propertystyle.ForgePropertyStyle.inspectProperties(ForgePropertyStyle.java:152)
... 58 more
[ticket-monster] ticket-monster-1 $
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (FORGE-490) Cannot access configuration outside of an active Project context
by Lincoln Baxter III (JIRA)
Lincoln Baxter III created FORGE-490:
----------------------------------------
Summary: Cannot access configuration outside of an active Project context
Key: FORGE-490
URL: https://issues.jboss.org/browse/FORGE-490
Project: Forge
Issue Type: Bug
Components: Plugin API, Shell
Affects Versions: 1.0.0.Final
Reporter: Lincoln Baxter III
Fix For: 1.0.1.CR1, 1.0.1.Final
{code}
[no project] forge-distribution-1.0.0.Final $ set VERBOSE true
set VERBOSE true
[no project] forge-distribution-1.0.0.Final $
[no project] forge-distribution-1.0.0.Final $ forge git-plugin git://github.com/forge/scaffold-aerogear.git
***ERROR*** [forge git-plugin] null
org.jboss.forge.shell.exceptions.CommandExecutionException
at org.jboss.forge.shell.command.Execution.perform(Execution.java:153)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:125)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:63)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:829)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:852)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:642)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:120)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:149)
... 31 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.solder.unwraps.UnwrapsInvocationHandler.invoke(UnwrapsInvocationHandler.java:82)
at org.javassist.tmp.java.lang.Object_$$_javassist_0.getScopedConfiguration(Object_$$_javassist_0.java)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.getProxySettings(ForgePlugin.java:190)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.prepareProxyForJGit(ForgePlugin.java:472)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromGit(ForgePlugin.java:405)
... 36 more
Caused by: java.lang.IllegalStateException
at org.jboss.forge.shell.env.ScopedConfigurationAdapter.getScopedConfiguration(ScopedConfigurationAdapter.java:74)
at org.jboss.forge.shell.env.ConfigurationAdapter.getScopedConfiguration(ConfigurationAdapter.java:59)
... 45 more
[no project] forge-distribution-1.0.0.Final $
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (FORGE-320) Git-powered "Undo" functionality in Forge
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-320?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III updated FORGE-320:
-------------------------------------
Description:
Forge should support undo/redo of changes on the file system. Use of git would rock here, particularly cases where Forge is introduced to an existing project, and determining what actually changed during a plugin execution could be nasty.
Care should be taken to integrate with projects that are already using git as a version control mechanism.
For example:
{code}I see you are already using git, what branch should Forge use when modifying files?
1 - org.jboss.forge.history
2 - define your own?*{code}
After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
{code}***ERROR*** Could not complete action [blah]...
? Undo changes from previous command? [Y/n] {code}
Scenarios:
* Master/current branch is ahead of history branch
* Master/current branch is behind history branch
* How to handle running in detached state?
* How to handle rebasing of a branch to avoid merge commits?
was:
Forge should support undo/redo of changes on the file system. Use of git would rock here.
Particularly cases where forge is introduced to an existing project could be nasty.
Care should be taken to integrate with projects that are already using git as a version control mechanism.
For example:
{code}I see you are already using git, what branch should Forge use when modifying files?
1 - org.jboss.forge.history
2 - define your own?*{code}
After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
Scenarios:
* Master/current branch is ahead of history branch
* Master/current branch is behind history branch
* How to handle running in detached state?
* How to handle rebasing of a branch to avoid merge commits?
> Git-powered "Undo" functionality in Forge
> -----------------------------------------
>
> Key: FORGE-320
> URL: https://issues.jboss.org/browse/FORGE-320
> Project: Forge
> Issue Type: Feature Request
> Components: Brainstorming
> Environment: All
> Reporter: Ian Hands
> Priority: Minor
>
> Forge should support undo/redo of changes on the file system. Use of git would rock here, particularly cases where Forge is introduced to an existing project, and determining what actually changed during a plugin execution could be nasty.
> Care should be taken to integrate with projects that are already using git as a version control mechanism.
> For example:
> {code}I see you are already using git, what branch should Forge use when modifying files?
> 1 - org.jboss.forge.history
> 2 - define your own?*{code}
> After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
> {code}***ERROR*** Could not complete action [blah]...
> ? Undo changes from previous command? [Y/n] {code}
> Scenarios:
> * Master/current branch is ahead of history branch
> * Master/current branch is behind history branch
> * How to handle running in detached state?
> * How to handle rebasing of a branch to avoid merge commits?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (FORGE-320) Git-powered "Undo" functionality in Forge
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-320?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III updated FORGE-320:
-------------------------------------
Description:
Forge should support undo/redo of changes on the file system. Use of git would rock here.
Particularly cases where forge is introduced to an existing project could be nasty.
Care should be taken to integrate with projects that are already using git as a version control mechanism.
For example:
{code}I see you are already using git, what branch should Forge use when modifying files?
1 - org.jboss.forge.history
2 - define your own?*{code}
After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
Scenarios:
* Master/current branch is ahead of history branch
* Master/current branch is behind history branch
* How to handle running in detached state?
* How to handle rebasing of a branch to avoid merge commits?
was:
Forge should support undo/redo of changes on the file system. Use of git would rock here.
Particularly cases where forge is introduced to an existing project could be nasty.
Care should be taken to integrate with projects that are already using git as a version control mechanism.
ex:
I see you are already using git, what branch should Forge use when modifying files?
1 - org.jboss.forge.history
* - define your own?
After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
Scenarios:
* Master/current branch is ahead of history branch
* Master/current branch is behind history branch
* How to handle running in detached state?
* How to handle rebasing of a branch to avoid merge commits?
> Git-powered "Undo" functionality in Forge
> -----------------------------------------
>
> Key: FORGE-320
> URL: https://issues.jboss.org/browse/FORGE-320
> Project: Forge
> Issue Type: Feature Request
> Components: Brainstorming
> Environment: All
> Reporter: Ian Hands
> Priority: Minor
>
> Forge should support undo/redo of changes on the file system. Use of git would rock here.
> Particularly cases where forge is introduced to an existing project could be nasty.
> Care should be taken to integrate with projects that are already using git as a version control mechanism.
> For example:
> {code}I see you are already using git, what branch should Forge use when modifying files?
> 1 - org.jboss.forge.history
> 2 - define your own?*{code}
> After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
> Scenarios:
> * Master/current branch is ahead of history branch
> * Master/current branch is behind history branch
> * How to handle running in detached state?
> * How to handle rebasing of a branch to avoid merge commits?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (FORGE-320) Git-powered "Undo" functionality in Forge
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-320?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III updated FORGE-320:
-------------------------------------
Summary: Git-powered "Undo" functionality in Forge (was: Undo features in Seam Forge)
Affects Version/s: (was: 1.0.0.Alpha4)
Description:
Forge should support undo/redo of changes on the file system. Use of git would rock here.
Particularly cases where forge is introduced to an existing project could be nasty.
Care should be taken to integrate with projects that are already using git as a version control mechanism.
ex:
I see you are already using git, what branch should Forge use when modifying files?
1 - org.jboss.forge.history
* - define your own?
After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
Scenarios:
* Master/current branch is ahead of history branch
* Master/current branch is behind history branch
* How to handle running in detached state?
* How to handle rebasing of a branch to avoid merge commits?
was:
Forge should support undo/redo of changes on the file system. Use of git would rock here.
Particularly cases where forge is introduced to an existing project could be nasty.
If git is used care could be taken to integrate with projects that are already using git as a version control mechanism.
ex:
I see you are already using git, what branch should Forge use when modifying files?
1 - SeamForgeScratch
* - define your own
Commit changes to the tmp branch and then optionally merge with master.
> Git-powered "Undo" functionality in Forge
> -----------------------------------------
>
> Key: FORGE-320
> URL: https://issues.jboss.org/browse/FORGE-320
> Project: Forge
> Issue Type: Feature Request
> Components: Brainstorming
> Environment: All
> Reporter: Ian Hands
> Priority: Minor
>
> Forge should support undo/redo of changes on the file system. Use of git would rock here.
> Particularly cases where forge is introduced to an existing project could be nasty.
> Care should be taken to integrate with projects that are already using git as a version control mechanism.
> ex:
> I see you are already using git, what branch should Forge use when modifying files?
> 1 - org.jboss.forge.history
> * - define your own?
> After every successful command execution, changes should be committed to the history branch. If an undo is requested, users could be presented with a list of revisions, or simply pop the latest revision off the stack. If a command exits in failure state, the user should be prompted to either "Undo" or "Abort," in which case, if "Undo" is selected, changes made during the failed command execution should be reverted to the previous state - "Abort" simply does nothing.
> Scenarios:
> * Master/current branch is ahead of history branch
> * Master/current branch is behind history branch
> * How to handle running in detached state?
> * How to handle rebasing of a branch to avoid merge commits?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months