Juhani,

I am not sure why you pushed a bunch of merge commits to trunk. Trunk in general should be kept linear. We should not have merge commits on trunk - all commits should be done only after a rebase on the committer's side. I am going to check with Jukka if we can rollback trunk to a pre-merge commit state. Once that is done, can you push only the commits which you intended to push?

Thanks
Hari

--
Hari Shreedharan
On Wednesday, August 15, 2012 at 12:00 AM, [EMAIL PROTECTED] wrote:

> Merge branch 'trunk' of git://git.apache.org/flume (http://git.apache.org/flume) into new-trunk
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flume/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flume/commit/73e5364b
> Tree: http://git-wip-us.apache.org/repos/asf/flume/tree/73e5364b
> Diff: http://git-wip-us.apache.org/repos/asf/flume/diff/73e5364b
>
> Branch: refs/heads/trunk
> Commit: 73e5364b6683a5bbc4b1b93c5fab30be6ac66cc7
> Parents: 24f2d38 eaee422
> Author: Juhani Connolly <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])>
> Authored: Fri Aug 3 15:57:10 2012 +0900
> Committer: Juhani Connolly <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])>
> Committed: Fri Aug 3 15:57:10 2012 +0900
>
> ----------------------------------------------------------------------
> flume-ng-channels/flume-file-channel/pom.xml | 5 +
> .../org/apache/flume/conf/FlumeConfiguration.java | 14 +-
> .../org/apache/flume/channel/ChannelProcessor.java | 5 +
> .../flume/instrumentation/GangliaServer.java | 73 ++--
> .../flume/lifecycle/LifecycleSupervisor.java | 148 ++++----
> .../apache/flume/source/PollableSourceRunner.java | 2 +
> .../java/org/apache/flume/tools/VersionInfo.java | 15 +-
> flume-ng-doc/sphinx/FlumeUserGuide.rst | 26 +-
> .../file/AbstractFileConfigurationProvider.java | 3 +
> .../org/apache/flume/sink/hdfs/BucketWriter.java | 10 +-
> .../org/apache/flume/sink/hdfs/HDFSEventSink.java | 1 -
> .../apache/flume/sink/hdfs/HDFSSequenceFile.java | 2 +-
> .../apache/flume/sink/hbase/AsyncHBaseSink.java | 274 +++++++++------
> .../hbase/HBaseSinkConfigurationConstants.java | 3 +
> pom.xml | 6 +
> 15 files changed, 355 insertions(+), 232 deletions(-)
> ----------------------------------------------------------------------

Juhani,

I am going to try and force push the previous state of trunk back to apache git. If I can't do that, I will try to get Jukka's help in getting trunk to the previous state. Once that is done, you should create a new clone and apply the patch and push to trunk.
Hari

--
Hari Shreedharan
On Wednesday, August 15, 2012 at 12:08 AM, Hari Shreedharan wrote:

> Juhani,
>
> I am not sure why you pushed a bunch of merge commits to trunk. Trunk in general should be kept linear. We should not have merge commits on trunk - all commits should be done only after a rebase on the committer's side. I am going to check with Jukka if we can rollback trunk to a pre-merge commit state. Once that is done, can you push only the commits which you intended to push?
>
> Thanks
> Hari
>
> --
> Hari Shreedharan
>
>
> On Wednesday, August 15, 2012 at 12:00 AM, [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) wrote:
>
> > Merge branch 'trunk' of git://git.apache.org/flume (http://git.apache.org/flume) into new-trunk
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/flume/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/flume/commit/73e5364b
> > Tree: http://git-wip-us.apache.org/repos/asf/flume/tree/73e5364b
> > Diff: http://git-wip-us.apache.org/repos/asf/flume/diff/73e5364b
> >
> > Branch: refs/heads/trunk
> > Commit: 73e5364b6683a5bbc4b1b93c5fab30be6ac66cc7
> > Parents: 24f2d38 eaee422
> > Author: Juhani Connolly <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])>
> > Authored: Fri Aug 3 15:57:10 2012 +0900
> > Committer: Juhani Connolly <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])>
> > Committed: Fri Aug 3 15:57:10 2012 +0900
> >
> > ----------------------------------------------------------------------
> > flume-ng-channels/flume-file-channel/pom.xml | 5 +
> > .../org/apache/flume/conf/FlumeConfiguration.java | 14 +-
> > .../org/apache/flume/channel/ChannelProcessor.java | 5 +
> > .../flume/instrumentation/GangliaServer.java | 73 ++--
> > .../flume/lifecycle/LifecycleSupervisor.java | 148 ++++----
> > .../apache/flume/source/PollableSourceRunner.java | 2 +
> > .../java/org/apache/flume/tools/VersionInfo.java | 15 +-
> > flume-ng-doc/sphinx/FlumeUserGuide.rst | 26 +-
> > .../file/AbstractFileConfigurationProvider.java | 3 +
> > .../org/apache/flume/sink/hdfs/BucketWriter.java | 10 +-
> > .../org/apache/flume/sink/hdfs/HDFSEventSink.java | 1 -
> > .../apache/flume/sink/hdfs/HDFSSequenceFile.java | 2 +-
> > .../apache/flume/sink/hbase/AsyncHBaseSink.java | 274 +++++++++------
> > .../hbase/HBaseSinkConfigurationConstants.java | 3 +
> > pom.xml | 6 +
> > 15 files changed, 355 insertions(+), 232 deletions(-)
> > ----------------------------------------------------------------------
>

Yes, I will do that. Thanks for checking this out and my sincere
apologies for the hassle.

On 08/15/2012 04:12 PM, Hari Shreedharan wrote:
> Juhani,
>
> I am going to try and force push the previous state of trunk back to apache git. If I can't do that, I will try to get Jukka's help in getting trunk to the previous state. Once that is done, you should create a new clone and apply the patch and push to trunk.
>
>
> Hari
>

Don't worry about it. We don't seem to have lost any data, just that there are some local commits of yours which you probably didn't intend to push. I am hoping this will be fixed soon, so we can reopen trunk for commits.
Hari

--
Hari Shreedharan
On Wednesday, August 15, 2012 at 1:21 AM, Juhani Connolly wrote:

> Yes, I will do that. Thanks for checking this out and my sincere
> apologies for the hassle.
>
> On 08/15/2012 04:12 PM, Hari Shreedharan wrote:
> > Juhani,
> >
> > I am going to try and force push the previous state of trunk back to apache git. If I can't do that, I will try to get Jukka's help in getting trunk to the previous state. Once that is done, you should create a new clone and apply the patch and push to trunk.
> >
> >
> > Hari

The local commits of mine that were pushed were just me applying the
same patches that were applied to the trunk, just in a slightly
different order. I did do a diff against the trunk  before pushing, and
the only difference was the contents of the patch. The final state of
the trunk should  be consistent with what it was before + the changes
from 1382.I was under the false assumption I had grokked git from using
it internally but clearly missed some details. Seeing as this apparently
cannot easily be reversed I will take extra care in the future.

On 08/15/2012 05:25 PM, Hari Shreedharan wrote:
> Don't worry about it. We don't seem to have lost any data, just that there are some local commits of yours which you probably didn't intend to push. I am hoping this will be fixed soon, so we can reopen trunk for commits.
>
>
> Hari
>

Is it possible to get a general idea of the commands you ran push local
commits?  I am no git ninja so I want to be sure I don't push any local
commits.

As a side, I have what I hope is a very conservative development model
below.  If I am doing something dangerous, please let me know!

to work on a jira:

git checkout trunk
git checkout -b FLUME-XXXX
git commit -m "commit message"
git commit -m "commit message"
git commit -m "commit message"
git merge trunk
git diff --no-prefix trunk > /tmp/FLUME-XXXX.patch

and to commit something to trunk

git checkout trunk
patch -p0 --dry-run < /tmp/FLUME-XXXX.patch
patch -p0 < /tmp/FLUME-XXXX.patch
mvn test
git status
git diff
git commit -m "commit message"

Brock

On Thu, Aug 16, 2012 at 2:35 AM, Juhani Connolly <
[EMAIL PROTECTED]> wrote:

> The local commits of mine that were pushed were just me applying the same
> patches that were applied to the trunk, just in a slightly different order.
> I did do a diff against the trunk  before pushing, and the only difference
> was the contents of the patch. The final state of the trunk should  be
> consistent with what it was before + the changes from 1382.I was under the
> false assumption I had grokked git from using it internally but clearly
> missed some details. Seeing as this apparently cannot easily be reversed I
> will take extra care in the future.
>
>
> On 08/15/2012 05:25 PM, Hari Shreedharan wrote:
>
>> Don't worry about it. We don't seem to have lost any data, just that
>> there are some local commits of yours which you probably didn't intend to
>> push. I am hoping this will be fixed soon, so we can reopen trunk for
>> commits.
>>
>>
>> Hari
>>
>>
>
--
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Hey Brock,
I usually use "git status" to see where my local stands vs. the remote. To
get an up-to-date snapshot, you would have to do a "git fetch origin" first.

I just remembered about "git show" from reading the following thread (by
the end of the comments the author has a workable solution for seeing local
differences): http://drupal.org/node/1175950

So you could do something like:
git fetch origin
git status
git show -n5 # or however many commits you want to look back at
# any rebase/edit necessary, repeat above
git status
git push origin trunk

As far as working on other branches, there is more than one way to skin a
cat in git but I often work on a feature / JIRA-specific branch, then
switch to trunk and cherry-pick my changes from the branch. Then I run the
tests and create the diff using something like "git diff --no-prefix HEAD~1
HEAD > FLUME-xxxx.patch".

For applying patches, I do something like this:

git checkout trunk
git fetch origin
git status # ensure no changes
patch -p0 < FLUME-yyyy.patch
git status
git add ...
git commit
mvn clean install
mvn clean
git status # ensure only one commit (no merge commits)
git push origin trunk

Regards,
Mike
On Thu, Aug 16, 2012 at 1:32 AM, Brock Noland <[EMAIL PROTECTED]> wrote:

> Is it possible to get a general idea of the commands you ran push local
> commits?  I am no git ninja so I want to be sure I don't push any local
> commits.
>
> As a side, I have what I hope is a very conservative development model
> below.  If I am doing something dangerous, please let me know!
>
> to work on a jira:
>
> git checkout trunk
> git checkout -b FLUME-XXXX
> git commit -m "commit message"
> git commit -m "commit message"
> git commit -m "commit message"
> git merge trunk
> git diff --no-prefix trunk > /tmp/FLUME-XXXX.patch
>
> and to commit something to trunk
>
> git checkout trunk
> patch -p0 --dry-run < /tmp/FLUME-XXXX.patch
> patch -p0 < /tmp/FLUME-XXXX.patch
> mvn test
> git status
> git diff
> git commit -m "commit message"
>
> Brock
>
> On Thu, Aug 16, 2012 at 2:35 AM, Juhani Connolly <
> [EMAIL PROTECTED]> wrote:
>
> > The local commits of mine that were pushed were just me applying the same
> > patches that were applied to the trunk, just in a slightly different
> order.
> > I did do a diff against the trunk  before pushing, and the only
> difference
> > was the contents of the patch. The final state of the trunk should  be
> > consistent with what it was before + the changes from 1382.I was under
> the
> > false assumption I had grokked git from using it internally but clearly
> > missed some details. Seeing as this apparently cannot easily be reversed
> I
> > will take extra care in the future.
> >
> >
> > On 08/15/2012 05:25 PM, Hari Shreedharan wrote:
> >
> >> Don't worry about it. We don't seem to have lost any data, just that
> >> there are some local commits of yours which you probably didn't intend
> to
> >> push. I am hoping this will be fixed soon, so we can reopen trunk for
> >> commits.
> >>
> >>
> >> Hari
> >>
> >>
> >
>
>
> --
> Apache MRUnit - Unit testing MapReduce -
> http://incubator.apache.org/mrunit/
>

Before we moved to git, I would do my work on my git repository, then
when I was happy with it, I'd make a patch, apply that to a separate svn
checkout and commit it from svn after testing it. Before working on new
stuff in my git directory, I'd make a pull, merging what I had committed
from svn to the exact same work in git. This apparently resulted in
trivial merges rather than a clean fast forward.  Once I switched the
origin over and actually did a push from the git, those merges turned
up. I don't think the same scenario is likely in a normal working method
where we're only using git, and afaik your method looks fine.

On 08/16/2012 05:32 PM, Brock Noland wrote:
> Is it possible to get a general idea of the commands you ran push local
> commits?  I am no git ninja so I want to be sure I don't push any local
> commits.
>
> As a side, I have what I hope is a very conservative development model
> below.  If I am doing something dangerous, please let me know!
>
> to work on a jira:
>
> git checkout trunk
> git checkout -b FLUME-XXXX
> git commit -m "commit message"
> git commit -m "commit message"
> git commit -m "commit message"
> git merge trunk
> git diff --no-prefix trunk > /tmp/FLUME-XXXX.patch
>
> and to commit something to trunk
>
> git checkout trunk
> patch -p0 --dry-run < /tmp/FLUME-XXXX.patch
> patch -p0 < /tmp/FLUME-XXXX.patch
> mvn test
> git status
> git diff
> git commit -m "commit message"
>
> Brock
>
> On Thu, Aug 16, 2012 at 2:35 AM, Juhani Connolly <
> [EMAIL PROTECTED]> wrote:
>
>> The local commits of mine that were pushed were just me applying the same
>> patches that were applied to the trunk, just in a slightly different order.
>> I did do a diff against the trunk  before pushing, and the only difference
>> was the contents of the patch. The final state of the trunk should  be
>> consistent with what it was before + the changes from 1382.I was under the
>> false assumption I had grokked git from using it internally but clearly
>> missed some details. Seeing as this apparently cannot easily be reversed I
>> will take extra care in the future.
>>
>>
>> On 08/15/2012 05:25 PM, Hari Shreedharan wrote:
>>
>>> Don't worry about it. We don't seem to have lost any data, just that
>>> there are some local commits of yours which you probably didn't intend to
>>> push. I am hoping this will be fixed soon, so we can reopen trunk for
>>> commits.
>>>
>>>
>>> Hari
>>>
>>>
>