If someone wants to re-tag Android to get rid of the merge commit, fine. I
don't care. Seriously, committing to this project is really becoming a pain
in the ass with all the git acrobatics that keep getting introduced.
On Jun 25, 2013 9:36 PM, "Michal Mocny" <[email protected]> wrote:
> Yeah, rebase private (local) commits liberally, never rebase public
> commits.
>
> Also, merge commits do come with a cost. Aside from the extra commits
> adding noise, it becomes more difficult to track branch history for
> anything complicated.
>
> ** Aside ** RE: git rebase origin/master after an accidental merge: thats a
> very simple solution, and I just ran into this problem today. Instead, I
> had git reset --hard to my previous local parent (and had to deal with
> figuring out which commit that was, as git log shows mangled history
> post-merge, though I've now learned that git reset --hard HEAD@{1} may do
> that), followed by a normal rebase. Stack Overflow didn't help with that
> one, so go answer
> http://stackoverflow.com/questions/2389361/undo-a-git-merge ;)
>
> -Michal
>
>
> On Tue, Jun 25, 2013 at 8:47 PM, Andrew Grieve <[email protected]>
> wrote:
>
> > A personal preference perhaps, but an Apache no-no? Are you sure? This
> > isn't re-writing upstream history, and would go along the same lines as
> > saying that you should never squash your work-in-progress commits, which
> > we've been advocating that you do on all of our wiki pages. We also tell
> > contributors to rebase when they update pull requests instead of making
> > commit after commit.
> >
> >
> > On Tue, Jun 25, 2013 at 7:47 PM, Joe Bowser <[email protected]> wrote:
> >
> > > Honestly, I would rather have merge commits in the repo than start
> > > screwing with the history of the repo with a rebase. Re-writing
> > > history is a big Apache no-no.
> > >
> > > On Tue, Jun 25, 2013 at 4:39 PM, Andrew Grieve <[email protected]>
> > > wrote:
> > > > A couple git tips that I learned recently:
> > > >
> > > > git pull --rebase will eliminate merge commits that are due to
> pulling
> > > when
> > > > a local commit has been made.
> > > >
> > > > If you failed to --rebase and have a merge commit:
> > > >
> > > > git rebase origin/master (assuming you're on master) will reorder
> your
> > > > commits to make your local ones come after remote ones, and also
> > > eliminate
> > > > the merge commit.
> > > >
> > > >
> > > > On Tue, Jun 25, 2013 at 7:13 PM, Joe Bowser <[email protected]>
> wrote:
> > > >
> > > >> I pushed to the 2.9.0 branch, but someone snuck a commit in on run.
> I
> > > >> then decided to re-tag it, since this is a script change, and not
> > > >> anything that required re-testing.
> > > >>
> > > >> On Tue, Jun 25, 2013 at 4:04 PM, Andrew Grieve <
> [email protected]>
> > > >> wrote:
> > > >> > Hey Joe - not sure what happened, but would love to know what
> errors
> > > >> you're
> > > >> > now seeing.
> > > >> >
> > > >> > Looks like the tagging of Android didn't go quite right:
> > > >> >
> > > >>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=log;h=df1536ea77e97b7d362a19582f8beddd168c5ec3
> > > >> >
> > > >> > There shouldn't be a merge commit (I don't think anyways), and the
> > tag
> > > >> > points past the branch head. Did you forget to push the 2.9.x
> > branch?
> > > >> >
> > > >> >
> > > >> > On Tue, Jun 25, 2013 at 6:41 PM, Steven Gill <
> > [email protected]>
> > > >> wrote:
> > > >> >
> > > >> >> Hey All,
> > > >> >>
> > > >> >> I would really appreciate if we could get the tags rolling. I am
> > > heading
> > > >> >> out for nodeconf on Thursday and want to get the release out
> > tomorrow
> > > >> >> before I leave. Are there any issues holding people back from
> > > tagging?
> > > >> >> Android is the only platform tagged so far.
> > > >> >>
> > > >> >> https://issues.apache.org/jira/browse/CB-3981
> > > >> >>
> > > >> >> Cheers,
> > > >> >> -Steve
> > > >> >>
> > > >> >>
> > > >> >> On Tue, Jun 25, 2013 at 1:50 PM, Joe Bowser <[email protected]>
> > > wrote:
> > > >> >>
> > > >> >> > I'm now getting even worse errors with coho. I've fully
> > abandoned
> > > >> >> > using that tool for this release and I'm tagging everything the
> > old
> > > >> >> > fashioned way. We should create tickets for each of the
> platform
> > > >> >> > maintainers to tag their releases so we can get this rolling.
> > > >> >> >
> > > >> >> > On Tue, Jun 25, 2013 at 12:25 PM, Andrew Grieve <
> > > [email protected]
> > > >> >
> > > >> >> > wrote:
> > > >> >> > > The tool logs most of the commands that it executes, it
> prints
> > > out
> > > >> >> stack
> > > >> >> > > traces when it fails, and you can step through the code using
> > > >> >> > > node_inspector. Do you have any suggestions on how to make it
> > > >> easier to
> > > >> >> > > debug?
> > > >> >> > >
> > > >> >> > > If you don't have a --short, then that would certainly be the
> > > >> problem.
> > > >> >> > > Perhaps your git version is older than mine and that flag
> was a
> > > new
> > > >> >> > > addition? I just pushed a change to not use --short.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > On Tue, Jun 25, 2013 at 2:52 PM, Joe Bowser <
> [email protected]
> > >
> > > >> wrote:
> > > >> >> > >
> > > >> >> > >> I don't have a --short for symbolic-ref, and I already
> posted
> > > the
> > > >> >> stack
> > > >> >> > >> trace:
> > > >> >> > >>
> > > >> >> > >> Here's what I get when I'm on the 2.9.x branch. Am I
> supposed
> > > to
> > > >> be
> > > >> >> > >> on something else? Shouldn't coho be smart enough to deal?
> > Can
> > > we
> > > >> >> > >> make it easier to debug when things go off the rails?
> > > >> >> > >>
> > > >> >> > >> jbowser-MacBookPro:cordova-js jbowser$ git symbolic-ref HEAD
> > > >> >> > >> refs/heads/2.9.x
> > > >> >> > >>
> > > >> >> > >>
> > > >> >> > >>
> > > >> >> > >> On Tue, Jun 25, 2013 at 9:49 AM, Andrew Grieve <
> > > >> [email protected]>
> > > >> >> > >> wrote:
> > > >> >> > >> > Ahh, okay, I see what you mean about the change. The jira
> > bug
> > > >> says
> > > >> >> to
> > > >> >> > tag
> > > >> >> > >> > them all in one command, which doesn't fit in with the
> > using a
> > > >> tag
> > > >> >> as
> > > >> >> > a
> > > >> >> > >> > vote idea. I'll update the JIRA issue to not use -r
> > > >> active-platform
> > > >> >> > flag.
> > > >> >> > >> >
> > > >> >> > >> > Joe - I just pushed a change that adds a --pretend flag to
> > the
> > > >> >> > >> tag-release
> > > >> >> > >> > command. Probably should have had this from the start to
> > > ensure
> > > >> it's
> > > >> >> > >> doing
> > > >> >> > >> > the right thing.
> > > >> >> > >> >
> > > >> >> > >> > Can you post your log, and also tell me the output of
> > running
> > > >> "git
> > > >> >> > >> > symbolic-ref --short HEAD" from cordova-js?
> > > >> >> > >> >
> > > >> >> > >> >
> > > >> >> > >> > On Tue, Jun 25, 2013 at 12:23 PM, Joe Bowser <
> > > [email protected]>
> > > >> >> > wrote:
> > > >> >> > >> >
> > > >> >> > >> >> Coho does introduce a change in the process, because
> > instead
> > > of
> > > >> all
> > > >> >> > >> >> the platform maintainers tagging their code, we have one
> > > person
> > > >> >> > >> >> tagging everything. If a tag is the vote, this is
> stuffing
> > > the
> > > >> >> > ballot
> > > >> >> > >> >> box. It's bad enough that we can vote twice.
> > > >> >> > >> >>
> > > >> >> > >> >> Now, I'm personally OK with us decoupling automation from
> > the
> > > >> rest
> > > >> >> of
> > > >> >> > >> >> the process, but right now I'm not OK with tagging this
> > > release.
> > > >> >> > >> >> Also, I'm having some issues with tagging the existing
> > > >> cordova-js,
> > > >> >> > >> >> whenever I try and use the cordova tool, I keep getting
> an
> > > error
> > > >> >> > about
> > > >> >> > >> >> it not being on a named branch:
> > > >> >> > >> >>
> > > >> >> > >> >> /Users/jbowser/cordova-coho/coho:488
> > > >> >> > >> >> throw new Error('Aborted due to repo ' +
> shjs.pwd()
> > > + '
> > > >> not
> > > >> >> > >> being
> > > >> >> > >> >> on a
> > > >> >> > >> >> ^
> > > >> >> > >> >> Error: Aborted due to repo /Users/jbowser/cordova-js not
> > > being
> > > >> on a
> > > >> >> > >> named
> > > >> >> > >> >> branch
> > > >> >> > >> >> at retrieveCurrentBranchName
> > > >> >> > >> (/Users/jbowser/cordova-coho/coho:488:15)
> > > >> >> > >> >> at /Users/jbowser/cordova-coho/coho:778:9
> > > >> >> > >> >> at /Users/jbowser/cordova-coho/coho:290:9
> > > >> >> > >> >> at Array.forEach (native)
> > > >> >> > >> >> at forEachRepo
> > (/Users/jbowser/cordova-coho/coho:281:11)
> > > >> >> > >> >> at updateRepos
> (/Users/jbowser/cordova-coho/coho:776:5)
> > > >> >> > >> >> at Object.prepareReleaseBranchCommand [as entryPoint]
> > > >> >> > >> >> (/Users/jbowser/cordova-coho/coho:898:5)
> > > >> >> > >> >> at main (/Users/jbowser/cordova-coho/coho:1118:25)
> > > >> >> > >> >> at Object.<anonymous>
> > > >> (/Users/jbowser/cordova-coho/coho:1120:1)
> > > >> >> > >> >> at Module._compile (module.js:456:26)
> > > >> >> > >> >>
> > > >> >> > >> >> Are there additional steps that we need to do to get this
> > to
> > > >> work?
> > > >> >> > >> >>
> > > >> >> > >> >> Finally, can we not change how we do things until after
> the
> > > 3.0
> > > >> >> > >> >> release is out? I'm really not liking all these proposed
> > > >> changes to
> > > >> >> > >> >> both our process and APIs at the 11th hour. There's some
> > > good
> > > >> >> ideas
> > > >> >> > >> >> here, but this is slowing things down considerably.
> > > >> >> > >> >>
> > > >> >> > >> >> Joe
> > > >> >> > >> >>
> > > >> >> > >> >> On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve <
> > > >> >> [email protected]
> > > >> >> > >
> > > >> >> > >> >> wrote:
> > > >> >> > >> >> > Coho introduces no change in process, but it does
> > automate
> > > >> some
> > > >> >> > steps
> > > >> >> > >> of
> > > >> >> > >> >> > the existing process.
> > > >> >> > >> >> >
> > > >> >> > >> >> >
> > > >> >> > >> >> > On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux <
> > [email protected]>
> > > >> >> wrote:
> > > >> >> > >> >> >
> > > >> >> > >> >> >> Yes. The idea would be, as it always has been, the
> > > platform
> > > >> >> > >> >> >> maintainers tag as their "vote". That tag says, 'hey
> > this
> > > >> part
> > > >> >> is
> > > >> >> > >> >> >> tested, stable, and works'.
> > > >> >> > >> >> >>
> > > >> >> > >> >> >>
> > > >> >> > >> >> >> On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser <
> > > >> [email protected]>
> > > >> >> > >> wrote:
> > > >> >> > >> >> >> > So, we're using coho for tagging everything now?
> That
> > > >> seems
> > > >> >> > like a
> > > >> >> > >> >> >> > major process change.
> > > >> >> > >> >> >> >
> > > >> >> > >> >> >> > On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve <
> > > >> >> > >> [email protected]>
> > > >> >> > >> >> >> wrote:
> > > >> >> > >> >> >> >> Created Release bug:
> > > >> >> > >> https://issues.apache.org/jira/browse/CB-3981
> > > >> >> > >> >> >> >>
> > > >> >> > >> >> >> >> Please update the subtasks if I've missed any
> steps.
> > > >> >> > >> >> >> >>
> > > >> >> > >> >> >> >>
> > > >> >> > >> >> >> >> On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj <
> > > >> [email protected]>
> > > >> >> > >> wrote:
> > > >> >> > >> >> >> >>
> > > >> >> > >> >> >> >>> Sgtm!
> > > >> >> > >> >> >> >>>
> > > >> >> > >> >> >> >>> On 6/21/13 6:27 PM, "Steven Gill" <
> > > >> [email protected]>
> > > >> >> > >> wrote:
> > > >> >> > >> >> >> >>>
> > > >> >> > >> >> >> >>> >I say we begin the tagging process for 2.9.0
> final
> > on
> > > >> >> Monday.
> > > >> >> > >> That
> > > >> >> > >> >> >> gives
> > > >> >> > >> >> >> >>> >us
> > > >> >> > >> >> >> >>> >a couple of days to get everything tested, tagged
> > and
> > > >> >> > released
> > > >> >> > >> >> before
> > > >> >> > >> >> >> the
> > > >> >> > >> >> >> >>> >end of the month. We can also merge in 3.0.0
> > branches
> > > >> after
> > > >> >> > the
> > > >> >> > >> 2.9
> > > >> >> > >> >> >> >>> >release.
> > > >> >> > >> >> >> >>>
> > > >> >> > >> >> >> >>>
> > > >> >> > >> >> >>
> > > >> >> > >> >>
> > > >> >> > >>
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
