You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by sc...@apache.org on 2017/01/16 02:17:25 UTC
[1/2] maven git commit: [MNG-5629] ClosedChannelException from
DefaultUpdateCheckManager.read
Repository: maven
Updated Branches:
refs/heads/master a83296d79 -> c6c5192d4
[MNG-5629] ClosedChannelException from DefaultUpdateCheckManager.read
o Updated to stop producing 'ClosedChannelException's when reading tracking files.
o Updated to use 'Long.MAX_VALUE' as the size of any locked regions to prevent writing beyond locked regions.
o Updated to support shrinking of tracking files.
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/ca1179ce
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/ca1179ce
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/ca1179ce
Branch: refs/heads/master
Commit: ca1179ce6ab6ed78fe755e2b97f7e0c01ea91361
Parents: e51fc87
Author: Christian Schulte <sc...@apache.org>
Authored: Fri Dec 11 21:42:09 2015 +0100
Committer: Christian Schulte <sc...@apache.org>
Committed: Mon Jan 9 16:07:28 2017 +0100
----------------------------------------------------------------------
.../legacy/DefaultUpdateCheckManager.java | 61 ++++++++------------
1 file changed, 24 insertions(+), 37 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/maven/blob/ca1179ce/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
----------------------------------------------------------------------
diff --git a/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java b/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
index dfc463b..4839d68 100644
--- a/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
+++ b/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java
@@ -28,15 +28,12 @@ import org.apache.maven.repository.Proxy;
import org.codehaus.plexus.component.annotations.Component;
import org.codehaus.plexus.logging.AbstractLogEnabled;
import org.codehaus.plexus.logging.Logger;
-import org.codehaus.plexus.util.IOUtil;
-import java.io.ByteArrayInputStream;
-import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.RandomAccessFile;
-import java.nio.ByteBuffer;
+import java.nio.channels.Channels;
import java.nio.channels.FileChannel;
import java.nio.channels.FileLock;
import java.util.Date;
@@ -242,18 +239,12 @@ public class DefaultUpdateCheckManager
Properties props = new Properties();
channel = new RandomAccessFile( touchfile, "rw" ).getChannel();
- lock = channel.lock( 0, channel.size(), false );
+ lock = channel.lock();
if ( touchfile.canRead() )
{
getLogger().debug( "Reading resolution-state from: " + touchfile );
- ByteBuffer buffer = ByteBuffer.allocate( (int) channel.size() );
-
- channel.read( buffer );
- buffer.flip();
-
- ByteArrayInputStream stream = new ByteArrayInputStream( buffer.array() );
- props.load( stream );
+ props.load( Channels.newInputStream( channel ) );
}
props.setProperty( key, Long.toString( System.currentTimeMillis() ) );
@@ -267,18 +258,15 @@ public class DefaultUpdateCheckManager
props.remove( key + ERROR_KEY_SUFFIX );
}
- ByteArrayOutputStream stream = new ByteArrayOutputStream();
-
getLogger().debug( "Writing resolution-state to: " + touchfile );
- props.store( stream, "Last modified on: " + new Date() );
+ channel.truncate( 0 );
+ props.store( Channels.newOutputStream( channel ), "Last modified on: " + new Date() );
- byte[] data = stream.toByteArray();
- ByteBuffer buffer = ByteBuffer.allocate( data.length );
- buffer.put( data );
- buffer.flip();
+ lock.release();
+ lock = null;
- channel.position( 0 );
- channel.write( buffer );
+ channel.close();
+ channel = null;
}
catch ( IOException e )
{
@@ -359,27 +347,26 @@ public class DefaultUpdateCheckManager
synchronized ( touchfile.getAbsolutePath().intern() )
{
+ FileInputStream in = null;
FileLock lock = null;
- FileChannel channel = null;
+
try
{
Properties props = new Properties();
- FileInputStream stream = new FileInputStream( touchfile );
- try
- {
- channel = stream.getChannel();
- lock = channel.lock( 0, channel.size(), true );
+ in = new FileInputStream( touchfile );
+ lock = in.getChannel().lock( 0, Long.MAX_VALUE, true );
- getLogger().debug( "Reading resolution-state from: " + touchfile );
- props.load( stream );
+ getLogger().debug( "Reading resolution-state from: " + touchfile );
+ props.load( in );
- return props;
- }
- finally
- {
- IOUtil.close( stream );
- }
+ lock.release();
+ lock = null;
+
+ in.close();
+ in = null;
+
+ return props;
}
catch ( IOException e )
{
@@ -402,11 +389,11 @@ public class DefaultUpdateCheckManager
}
}
- if ( channel != null )
+ if ( in != null )
{
try
{
- channel.close();
+ in.close();
}
catch ( IOException e )
{
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
I have no strong opinion.
There is the magical 'git log --first-parent' and 'git blame
--first-parent' if you just want to see each change on master (or whatever
branch you are on)
That can be nicer if you have lots of PRs which have not been
squashed/rebased
Given the way git works as the ASF, committers need to do stuff to merge
PRs, so we can pick our process.
For PRs the advantage of the merge commit is that the hashes of the commits
match those on the PR originally, which might be useful for clarifying that
the author intended to submit the code under ALv2... on the other hand the
patches in JIRA style doesn't have that issue, so perhaps we say rebase and
fast-forward merges onto master only.
Squashing only works where the changes have a single author.
As a release manager, I like either Squashed commits OR explicit Merge
commits.
As a developer, I dislike squashed commits. I got the git developers to fix
--first-parent so that merge commits could be nice for me.
But these are my opinions. Really this needs to be a community decision.
On Mon 16 Jan 2017 at 07:24, Hervé BOUTEMY <he...@free.fr> wrote:
> do we want to keep such merge commits?
>
>
>
> I would have expected that when merging, we rebase then have no such merge
>
> commit: that branch work is just a temporary situation that completely
>
> disappears once merged (and we must not forget to delete merged branch)
>
>
>
> what do others think?
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
> Le lundi 16 janvier 2017, 02:17:26 CET schulte@apache.org a écrit :
>
> > Merge branch 'MNG-5629'
>
> >
>
> >
>
> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>
> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/c6c5192d
>
> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/c6c5192d
>
> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/c6c5192d
>
> >
>
> > Branch: refs/heads/master
>
> > Commit: c6c5192d4bcb50c1aab6fade53dfb9c2f3d9b7e7
>
> > Parents: a83296d ca1179c
>
> > Author: Christian Schulte <sc...@apache.org>
>
> > Authored: Mon Jan 16 03:16:49 2017 +0100
>
> > Committer: Christian Schulte <sc...@apache.org>
>
> > Committed: Mon Jan 16 03:16:49 2017 +0100
>
> >
>
> > ----------------------------------------------------------------------
>
> > .../legacy/DefaultUpdateCheckManager.java | 61
> ++++++++------------
>
> > 1 file changed, 24 insertions(+), 37 deletions(-)
>
> > ----------------------------------------------------------------------
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
We've already reviewed the branch and done a CI build with the full
integration tests before we get to the merging point.
On 16 January 2017 at 09:18, Fred Cooke <fr...@gmail.com> wrote:
> Perfect, if reviews aren't part of the deal. <3
>
> On Mon, Jan 16, 2017 at 10:11 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > I do not thing we want an overly heavy process.
> >
> > For the 3.5.0 release I suggest we try the following. Rebase so that it
> is
> > a fast-forward merge
> >
> > git checkout BRANCH
> > git fetch origin
> > git rebase origin/master
> > git push origin BRANCH:master
> >
> > if that git push fails,
> >
> > fetch
> > rebase
> > push
> >
> > once your push has succeeded
> >
> > git push origin :BRANCH
> >
> >
> > On 16 January 2017 at 08:51, Christian Schulte <cs...@schulte.it> wrote:
> >
> > > Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > > > No, not correct in my books.
> > > >
> > > > git checkout BRANCH # Assuming it's local already
> > > > git fetch upstream # risk free, unlike pull!
> > > > git rebase upstream/master # diff difftool merge mergetool settings
> are
> > > > useful, prompt = false and specify your diff tool in advance
> > > > git push --force upstream BRANCH # After verifying no one has pushed
> to
> > > it
> > > > # create pull request/email someone/communicate your intention to
> have
> > it
> > > > merged
> > > >
> > > > ^ correct in my books, others may differ.
> > >
> > > I merged pull requests from others in the past as well. Create pull
> > > requests for master even if I am a committer? Really? That would mean I
> > > would create a pull request I will pull in myself afterwards? Leave the
> > > merge commit so that the merges can be tracked back to the PR?
> > >
> > > Regards,
> > > --
> > > Christian
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Fred Cooke <fr...@gmail.com>.
Perfect, if reviews aren't part of the deal. <3
On Mon, Jan 16, 2017 at 10:11 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I do not thing we want an overly heavy process.
>
> For the 3.5.0 release I suggest we try the following. Rebase so that it is
> a fast-forward merge
>
> git checkout BRANCH
> git fetch origin
> git rebase origin/master
> git push origin BRANCH:master
>
> if that git push fails,
>
> fetch
> rebase
> push
>
> once your push has succeeded
>
> git push origin :BRANCH
>
>
> On 16 January 2017 at 08:51, Christian Schulte <cs...@schulte.it> wrote:
>
> > Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > > No, not correct in my books.
> > >
> > > git checkout BRANCH # Assuming it's local already
> > > git fetch upstream # risk free, unlike pull!
> > > git rebase upstream/master # diff difftool merge mergetool settings are
> > > useful, prompt = false and specify your diff tool in advance
> > > git push --force upstream BRANCH # After verifying no one has pushed to
> > it
> > > # create pull request/email someone/communicate your intention to have
> it
> > > merged
> > >
> > > ^ correct in my books, others may differ.
> >
> > I merged pull requests from others in the past as well. Create pull
> > requests for master even if I am a committer? Really? That would mean I
> > would create a pull request I will pull in myself afterwards? Leave the
> > merge commit so that the merges can be tracked back to the PR?
> >
> > Regards,
> > --
> > Christian
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Fred Cooke <fr...@gmail.com>.
My preference matches yours for the exact same reason. You're trying to
rebase or merge something you don't understand, otherwise. Blind. 10/10 :-)
On Mon, Jan 16, 2017 at 10:21 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> or if you want less commands
>
> git checkout BRANCH
> git pull --rebase origin master
> git push origin BRANCH:master
> git push origin :BRANCH
>
> but personally I prefer to separate the fetch from the rebase as you have
> at least more of a feeling of control (e.g. you can check the git log
> origin/master locally first before doing the rebase
>
> On 16 January 2017 at 09:11, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > I do not thing we want an overly heavy process.
> >
> > For the 3.5.0 release I suggest we try the following. Rebase so that it
> is
> > a fast-forward merge
> >
> > git checkout BRANCH
> > git fetch origin
> > git rebase origin/master
> > git push origin BRANCH:master
> >
> > if that git push fails,
> >
> > fetch
> > rebase
> > push
> >
> > once your push has succeeded
> >
> > git push origin :BRANCH
> >
> >
> > On 16 January 2017 at 08:51, Christian Schulte <cs...@schulte.it> wrote:
> >
> >> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> >> > No, not correct in my books.
> >> >
> >> > git checkout BRANCH # Assuming it's local already
> >> > git fetch upstream # risk free, unlike pull!
> >> > git rebase upstream/master # diff difftool merge mergetool settings
> are
> >> > useful, prompt = false and specify your diff tool in advance
> >> > git push --force upstream BRANCH # After verifying no one has pushed
> to
> >> it
> >> > # create pull request/email someone/communicate your intention to have
> >> it
> >> > merged
> >> >
> >> > ^ correct in my books, others may differ.
> >>
> >> I merged pull requests from others in the past as well. Create pull
> >> requests for master even if I am a committer? Really? That would mean I
> >> would create a pull request I will pull in myself afterwards? Leave the
> >> merge commit so that the merges can be tracked back to the PR?
> >>
> >> Regards,
> >> --
> >> Christian
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
if we do merge commits then
git log --first-parent
will give you the same simple history *and* let you look at the development
history...
of course then we have to do merge commits... (which is a different story)
And squashing only works if the commits you want to merge are from a single
author... if there are multiple authors we need to respect the authorship
On 16 January 2017 at 15:29, Benson Margulies <bi...@gmail.com> wrote:
> there is always merge --squash. Makes the master history dead simple
> on the theory that no one cares about the dev history of a feature
> branch.
>
> On Mon, Jan 16, 2017 at 1:24 AM, Christian Schulte <cs...@schulte.it> wrote:
> > Am 16.01.2017 um 10:21 schrieb Stephen Connolly:
> >> or if you want less commands
> >>
> >> git checkout BRANCH
> >> git pull --rebase origin master
> >> git push origin BRANCH:master
> >> git push origin :BRANCH
> >>
> >> but personally I prefer to separate the fetch from the rebase as you
> have
> >> at least more of a feeling of control (e.g. you can check the git log
> >> origin/master locally first before doing the rebase
> >
> > Ok. Thanks.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Benson Margulies <bi...@gmail.com>.
there is always merge --squash. Makes the master history dead simple
on the theory that no one cares about the dev history of a feature
branch.
On Mon, Jan 16, 2017 at 1:24 AM, Christian Schulte <cs...@schulte.it> wrote:
> Am 16.01.2017 um 10:21 schrieb Stephen Connolly:
>> or if you want less commands
>>
>> git checkout BRANCH
>> git pull --rebase origin master
>> git push origin BRANCH:master
>> git push origin :BRANCH
>>
>> but personally I prefer to separate the fetch from the rebase as you have
>> at least more of a feeling of control (e.g. you can check the git log
>> origin/master locally first before doing the rebase
>
> Ok. Thanks.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Christian Schulte <cs...@schulte.it>.
Am 16.01.2017 um 10:21 schrieb Stephen Connolly:
> or if you want less commands
>
> git checkout BRANCH
> git pull --rebase origin master
> git push origin BRANCH:master
> git push origin :BRANCH
>
> but personally I prefer to separate the fetch from the rebase as you have
> at least more of a feeling of control (e.g. you can check the git log
> origin/master locally first before doing the rebase
Ok. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
or if you want less commands
git checkout BRANCH
git pull --rebase origin master
git push origin BRANCH:master
git push origin :BRANCH
but personally I prefer to separate the fetch from the rebase as you have
at least more of a feeling of control (e.g. you can check the git log
origin/master locally first before doing the rebase
On 16 January 2017 at 09:11, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I do not thing we want an overly heavy process.
>
> For the 3.5.0 release I suggest we try the following. Rebase so that it is
> a fast-forward merge
>
> git checkout BRANCH
> git fetch origin
> git rebase origin/master
> git push origin BRANCH:master
>
> if that git push fails,
>
> fetch
> rebase
> push
>
> once your push has succeeded
>
> git push origin :BRANCH
>
>
> On 16 January 2017 at 08:51, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
>> > No, not correct in my books.
>> >
>> > git checkout BRANCH # Assuming it's local already
>> > git fetch upstream # risk free, unlike pull!
>> > git rebase upstream/master # diff difftool merge mergetool settings are
>> > useful, prompt = false and specify your diff tool in advance
>> > git push --force upstream BRANCH # After verifying no one has pushed to
>> it
>> > # create pull request/email someone/communicate your intention to have
>> it
>> > merged
>> >
>> > ^ correct in my books, others may differ.
>>
>> I merged pull requests from others in the past as well. Create pull
>> requests for master even if I am a committer? Really? That would mean I
>> would create a pull request I will pull in myself afterwards? Leave the
>> merge commit so that the merges can be tracked back to the PR?
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
I do not thing we want an overly heavy process.
For the 3.5.0 release I suggest we try the following. Rebase so that it is
a fast-forward merge
git checkout BRANCH
git fetch origin
git rebase origin/master
git push origin BRANCH:master
if that git push fails,
fetch
rebase
push
once your push has succeeded
git push origin :BRANCH
On 16 January 2017 at 08:51, Christian Schulte <cs...@schulte.it> wrote:
> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > No, not correct in my books.
> >
> > git checkout BRANCH # Assuming it's local already
> > git fetch upstream # risk free, unlike pull!
> > git rebase upstream/master # diff difftool merge mergetool settings are
> > useful, prompt = false and specify your diff tool in advance
> > git push --force upstream BRANCH # After verifying no one has pushed to
> it
> > # create pull request/email someone/communicate your intention to have it
> > merged
> >
> > ^ correct in my books, others may differ.
>
> I merged pull requests from others in the past as well. Create pull
> requests for master even if I am a committer? Really? That would mean I
> would create a pull request I will pull in myself afterwards? Leave the
> merge commit so that the merges can be tracked back to the PR?
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Fred Cooke <fr...@gmail.com>.
Squashing is for commits that were not done properly in the first place,
either by choice WIP style, or by incompetence. I'd be heart broken if you
squashed my carefully crafted atomic and standalone commits. :-p
With-lease is new to me, but it's what I manually do anyway. If I see the
from hash is not what I thought, then I back it out again. Though that's
yet to happen, so I'll save the key strokes and use my alias "git force".
On Mon, Jan 16, 2017 at 9:51 PM, Christian Schulte <cs...@schulte.it> wrote:
> Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> > No, not correct in my books.
> >
> > git checkout BRANCH # Assuming it's local already
> > git fetch upstream # risk free, unlike pull!
> > git rebase upstream/master # diff difftool merge mergetool settings are
> > useful, prompt = false and specify your diff tool in advance
> > git push --force upstream BRANCH # After verifying no one has pushed to
> it
> > # create pull request/email someone/communicate your intention to have it
> > merged
> >
> > ^ correct in my books, others may differ.
>
> I merged pull requests from others in the past as well. Create pull
> requests for master even if I am a committer? Really? That would mean I
> would create a pull request I will pull in myself afterwards? Leave the
> merge commit so that the merges can be tracked back to the PR?
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Christian Schulte <cs...@schulte.it>.
Am 16.01.2017 um 09:00 schrieb Fred Cooke:
> No, not correct in my books.
>
> git checkout BRANCH # Assuming it's local already
> git fetch upstream # risk free, unlike pull!
> git rebase upstream/master # diff difftool merge mergetool settings are
> useful, prompt = false and specify your diff tool in advance
> git push --force upstream BRANCH # After verifying no one has pushed to it
> # create pull request/email someone/communicate your intention to have it
> merged
>
> ^ correct in my books, others may differ.
I merged pull requests from others in the past as well. Create pull
requests for master even if I am a committer? Really? That would mean I
would create a pull request I will pull in myself afterwards? Leave the
merge commit so that the merges can be tracked back to the PR?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Stephen Connolly <st...@gmail.com>.
Well:
1. one should never 'git push --force' rather 'git push --force-with-lease'
(which is not perfect, but just better)
2. Its all moot as 'master' is protected and will refuse an actual force
push
On Mon 16 Jan 2017 at 08:00, Fred Cooke <fr...@gmail.com> wrote:
> No, not correct in my books.
>
>
>
> git checkout BRANCH # Assuming it's local already
>
> git fetch upstream # risk free, unlike pull!
>
> git rebase upstream/master # diff difftool merge mergetool settings are
>
> useful, prompt = false and specify your diff tool in advance
>
> git push --force upstream BRANCH # After verifying no one has pushed to it
>
> # create pull request/email someone/communicate your intention to have it
>
> merged
>
>
>
> ^ correct in my books, others may differ.
>
>
>
>
>
> On Mon, Jan 16, 2017 at 8:52 PM, Christian Schulte <cs...@schulte.it> wrote:
>
>
>
> > Am 16.01.2017 um 08:27 schrieb Fred Cooke:
>
> > > Rebase is the only clean way forward for small projects in which people
>
> > > step on each others toes.
>
> > >
>
> > > Merge commits are difficult to comprehend for some developers, leading
> to
>
> > > errors. Avoiding them is beneficial.
>
> > >
>
> > > On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY <he...@free.fr>
>
> > > wrote:
>
> > >
>
> > >> do we want to keep such merge commits?
>
> >
>
> > Just to clarify. I should have done the following:
>
> >
>
> > cmd> git checkout master
>
> > cmd> git merge BRANCH
>
> > cmd> git rebase (possible -i to do some housekeeping)
>
> > cmd> git push
>
> >
>
> > Correct? I did this but then decided to keep that merge commit so that
>
> > it's obvious that there had been a branch carrying the commit(s).
>
> >
>
> > Regards,
>
> > --
>
> > Christian
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> >
>
> >
>
> --
Sent from my phone
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Fred Cooke <fr...@gmail.com>.
No, not correct in my books.
git checkout BRANCH # Assuming it's local already
git fetch upstream # risk free, unlike pull!
git rebase upstream/master # diff difftool merge mergetool settings are
useful, prompt = false and specify your diff tool in advance
git push --force upstream BRANCH # After verifying no one has pushed to it
# create pull request/email someone/communicate your intention to have it
merged
^ correct in my books, others may differ.
On Mon, Jan 16, 2017 at 8:52 PM, Christian Schulte <cs...@schulte.it> wrote:
> Am 16.01.2017 um 08:27 schrieb Fred Cooke:
> > Rebase is the only clean way forward for small projects in which people
> > step on each others toes.
> >
> > Merge commits are difficult to comprehend for some developers, leading to
> > errors. Avoiding them is beneficial.
> >
> > On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY <he...@free.fr>
> > wrote:
> >
> >> do we want to keep such merge commits?
>
> Just to clarify. I should have done the following:
>
> cmd> git checkout master
> cmd> git merge BRANCH
> cmd> git rebase (possible -i to do some housekeeping)
> cmd> git push
>
> Correct? I did this but then decided to keep that merge commit so that
> it's obvious that there had been a branch carrying the commit(s).
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Christian Schulte <cs...@schulte.it>.
Am 16.01.2017 um 08:27 schrieb Fred Cooke:
> Rebase is the only clean way forward for small projects in which people
> step on each others toes.
>
> Merge commits are difficult to comprehend for some developers, leading to
> errors. Avoiding them is beneficial.
>
> On Mon, Jan 16, 2017 at 8:23 PM, Herv� BOUTEMY <he...@free.fr>
> wrote:
>
>> do we want to keep such merge commits?
Just to clarify. I should have done the following:
cmd> git checkout master
cmd> git merge BRANCH
cmd> git rebase (possible -i to do some housekeeping)
cmd> git push
Correct? I did this but then decided to keep that merge commit so that
it's obvious that there had been a branch carrying the commit(s).
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Fred Cooke <fr...@gmail.com>.
Rebase is the only clean way forward for small projects in which people
step on each others toes.
Merge commits are difficult to comprehend for some developers, leading to
errors. Avoiding them is beneficial.
On Mon, Jan 16, 2017 at 8:23 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> do we want to keep such merge commits?
>
> I would have expected that when merging, we rebase then have no such merge
> commit: that branch work is just a temporary situation that completely
> disappears once merged (and we must not forget to delete merged branch)
>
> what do others think?
>
> Regards,
>
> Hervé
>
> Le lundi 16 janvier 2017, 02:17:26 CET schulte@apache.org a écrit :
> > Merge branch 'MNG-5629'
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/c6c5192d
> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/c6c5192d
> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/c6c5192d
> >
> > Branch: refs/heads/master
> > Commit: c6c5192d4bcb50c1aab6fade53dfb9c2f3d9b7e7
> > Parents: a83296d ca1179c
> > Author: Christian Schulte <sc...@apache.org>
> > Authored: Mon Jan 16 03:16:49 2017 +0100
> > Committer: Christian Schulte <sc...@apache.org>
> > Committed: Mon Jan 16 03:16:49 2017 +0100
> >
> > ----------------------------------------------------------------------
> > .../legacy/DefaultUpdateCheckManager.java | 61
> ++++++++------------
> > 1 file changed, 24 insertions(+), 37 deletions(-)
> > ----------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [2/2] maven git commit: Merge branch 'MNG-5629'
Posted by Hervé BOUTEMY <he...@free.fr>.
do we want to keep such merge commits?
I would have expected that when merging, we rebase then have no such merge
commit: that branch work is just a temporary situation that completely
disappears once merged (and we must not forget to delete merged branch)
what do others think?
Regards,
Hervé
Le lundi 16 janvier 2017, 02:17:26 CET schulte@apache.org a écrit :
> Merge branch 'MNG-5629'
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/c6c5192d
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/c6c5192d
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/c6c5192d
>
> Branch: refs/heads/master
> Commit: c6c5192d4bcb50c1aab6fade53dfb9c2f3d9b7e7
> Parents: a83296d ca1179c
> Author: Christian Schulte <sc...@apache.org>
> Authored: Mon Jan 16 03:16:49 2017 +0100
> Committer: Christian Schulte <sc...@apache.org>
> Committed: Mon Jan 16 03:16:49 2017 +0100
>
> ----------------------------------------------------------------------
> .../legacy/DefaultUpdateCheckManager.java | 61 ++++++++------------
> 1 file changed, 24 insertions(+), 37 deletions(-)
> ----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[2/2] maven git commit: Merge branch 'MNG-5629'
Posted by sc...@apache.org.
Merge branch 'MNG-5629'
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/c6c5192d
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/c6c5192d
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/c6c5192d
Branch: refs/heads/master
Commit: c6c5192d4bcb50c1aab6fade53dfb9c2f3d9b7e7
Parents: a83296d ca1179c
Author: Christian Schulte <sc...@apache.org>
Authored: Mon Jan 16 03:16:49 2017 +0100
Committer: Christian Schulte <sc...@apache.org>
Committed: Mon Jan 16 03:16:49 2017 +0100
----------------------------------------------------------------------
.../legacy/DefaultUpdateCheckManager.java | 61 ++++++++------------
1 file changed, 24 insertions(+), 37 deletions(-)
----------------------------------------------------------------------