Return-Path: X-Original-To: apmail-allura-dev-archive@www.apache.org Delivered-To: apmail-allura-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1328F17214 for ; Fri, 6 Mar 2015 12:42:03 +0000 (UTC) Received: (qmail 59634 invoked by uid 500); 6 Mar 2015 12:42:03 -0000 Delivered-To: apmail-allura-dev-archive@allura.apache.org Received: (qmail 59610 invoked by uid 500); 6 Mar 2015 12:42:02 -0000 Mailing-List: contact dev-help@allura.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@allura.apache.org Delivered-To: mailing list dev@allura.apache.org Received: (qmail 59595 invoked by uid 99); 6 Mar 2015 12:42:02 -0000 Received: from allura-vm.apache.org (HELO allura-vm) (140.211.11.147) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Mar 2015 12:42:02 +0000 Received: from allura-vm.apache.org (localhost [127.0.0.1]) by allura-vm (Postfix) with ESMTP id EDC0628018A for ; Fri, 6 Mar 2015 12:42:01 +0000 (UTC) Content-Type: multipart/related; boundary="===============8437354709417777136==" MIME-Version: 1.0 To: dev@allura.apache.org From: "Igor Bondarenko" Reply-To: "[allura:tickets] " <7830@tickets.allura.p.forge-allura.apache.org> Subject: [allura:tickets] #7830 One-click merge Message-ID:

Sender: tickets@allura.p.forge-allura.apache.org In-Reply-To: <54d8dda06d19cd561c9ac78c.tickets@allura.p.forge-allura.apache.org> References: <54d8dda06d19cd561c9ac78c.tickets@allura.p.forge-allura.apache.org> Date: Fri, 6 Mar 2015 12:42:01 +0000 (UTC) --===============8437354709417777136== Content-Type: multipart/alternative; boundary="===============7392428563688555163==" MIME-Version: 1.0 --===============7392428563688555163== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit With current approach we can't detect those git conflicts you mentioned above. Maybe we can do smarter parsing of output of `merge-tree`, but it seems pretty complicated and error-prone. We can't use 'removed in' as indicator of conflict, since different files can be removed in upstream and downstream and in this case there's no conflict. See output examples [here](https://forge-allura.apache.org/p/allura/pastebin/54f99ff56d19cd73d3cf6c7b). I think most reliable approach is to try run merge in temporary repository clone and see if it fails (as hg does). As I mentioned earlier it would require background task + ajax monitoring on user page. What do you think? I've fixed other issues you mentioned. Also take a look at my comment on [#7836]. It can affect this ticket too. Updated `allura:ib/7830` (force-push). No new merge request for ForgeHg yet. I found some issues with it, so work in progress. --- ** [tickets:#7830] One-click merge** **Status:** in-progress **Milestone:** unreleased **Labels:** sf-current sf-4 42cc **Created:** Mon Feb 09, 2015 04:17 PM UTC by Dave Brondsema **Last Updated:** Thu Mar 05, 2015 11:03 PM UTC **Owner:** Igor Bondarenko Add a button to merge requests to merge the branch on the server-side. Of course, don't do it if there are conflicts. Also need to consider server-side filesystem permissions and make sure install docs are updated if needed, etc. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. --===============7392428563688555163== MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

With current approach we can't detect those git conflicts you mentioned above. Maybe we can do smarter parsing of output of merge-tree, but it seems pretty complicated and error-prone.

We can't use 'removed in' as indicator of conflict, since different files can be removed in upstream and downstream and in this case there's no conflict. See output examples here.

I think most reliable approach is to try run merge in temporary repository clone and see if it fails (as hg does). As I mentioned earlier it would require background task + ajax monitoring on user page. What do you think?

I've fixed other issues you mentioned.

Also take a look at my comment on [#7836]. It can affect this ticket too.

Updated allura:ib/7830 (force-push).

No new merge request for ForgeHg yet. I found some issues with it, so work in progress.

[tickets:#7830] One-click merge

Status: in-progress
Milestone: unreleased
Labels: sf-current sf-4 42cc
Created: Mon Feb 09, 2015 04:17 PM UTC by Dave Brondsema
Last Updated: Thu Mar 05, 2015 11:03 PM UTC
Owner: Igor Bondarenko

Add a button to merge requests to merge the branch on the server-side. Of course, don't do it if there are conflicts. Also need to consider server-side filesystem permissions and make sure install docs are updated if needed, etc.

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

--===============7392428563688555163==-- --===============8437354709417777136==--