Re: Hmm Git mistake I believe

[Thomas Matthijs]

You can always use git pull --rebase, (make it the default) to not
pollute the history with useless merge commits.
This will fetch the changes from the server and rebase your commits on
top of them (like svn does).

On Tue, Jan 26, 2016 at 4:58 PM, Joel Bernstein  wrote:
>
> https://github.com/apache/lucene-solr/commit/bc815b5207638c676810699bae592fc8f3d93abd
>
> Is this something that I need to fix?
>
> These were my commands:
>
> defaultildsMBP5:lucene-solr joelbernstein$ git pull origin master
>
> remote: Counting objects: 507, done.
>
> remote: Compressing objects: 100% (66/66), done.
>
> remote: Total 95 (delta 41), reused 0 (delta 0)
>
> Unpacking objects: 100% (95/95), done.
>
> From https://git-wip-us.apache.org/repos/asf/lucene-solr
>
>  * branchmaster -> FETCH_HEAD
>
>0ff8d11..85ae198  master -> origin/master
>
> Merge made by the 'recursive' strategy.
>
>  lucene/CHANGES.txt
> |   5 +
>
>  lucene/core/src/java/org/apache/lucene/index/PrefixCodedTerms.java
> |  21 ---
>
>  lucene/memory/src/java/org/apache/lucene/index/memory/MemoryIndex.java
> | 107
> +++---
>
>  lucene/memory/src/test/org/apache/lucene/index/memory/TestMemoryIndex.java
> |  27 
>
>  lucene/queries/src/java/org/apache/lucene/queries/TermsQuery.java
> |  52 +-
>
>  lucene/queries/src/test/org/apache/lucene/queries/CommonTermsQueryTest.java
> |   2 +-
>
>  lucene/sandbox/src/test/org/apache/lucene/search/TestGeoPointQuery.java
> |  35 +++
>
>
> lucene/sandbox/src/test/org/apache/lucene/search/TestLatLonPointQueries.java
> |  25 ++
>
>  lucene/sandbox/src/test/org/apache/lucene/util/BaseGeoPointTestCase.java
> |   1 -
>
>  solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
> |   2 +-
>
>  solr/core/src/java/org/apache/solr/search/facet/FacetRequest.java
> |  10 ++---
>
>  solr/core/src/test/org/apache/solr/search/facet/TestJsonFacets.java
> |  22 +++-
>
>  12 files changed, 240 insertions(+), 69 deletions(-)
>
> defaultildsMBP5:lucene-solr joelbernstein$ git status
>
> On branch master
>
> Your branch is ahead of 'origin/master' by 2 commits.
>
>   (use "git push" to publish your local commits)
>
>
> nothing to commit, working directory clean
>
> defaultildsMBP5:lucene-solr joelbernstein$ git push origin master
>
> Counting objects: 81, done.
>
> Delta compression using up to 8 threads.
>
> Compressing objects: 100% (21/21), done.
>
> Writing objects: 100% (28/28), 3.34 KiB | 0 bytes/s, done.
>
> Total 28 (delta 12), reused 0 (delta 0)
>
> To https://git-wip-us.apache.org/repos/asf/lucene-solr.git
>
>85ae198..bc815b5  master -> master

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Hmm Git mistake I believe

[Michael McCandless]

Why is this a problem?

It records the fact that you had pull'd and had to merge your changes
with what "came in" from master from other devs.

Such historical accuracy, while looking "dirty" to some devs, is
nevertheless accurate to what actually transpired, and can therefore
be useful to future devs digging through the history.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Jan 26, 2016 at 11:18 AM, david.w.smi...@gmail.com
 wrote:
> Yup.  And when you pulled, you didn't do it via rebase.  I'll assume you're
> in the camp of not wanting these merge commits and non-liinear history (and
> thus loops) -- granted I don't think you explicitly stated your opinion.
> So, even if you followed Yoniks' advice (and not mine) and thus set the
> branch.autosetuprebase option, that AFAIK only affects repos created *after*
> you set that option.  I recommend you remove that setting if you have and
> instead set this:
> git config --global pull.rebase true
> (or at your discretion remove the --global and thus only set this on this
> project).
>
> Cheers,
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Hmm Git mistake I believe

[Joel Bernstein]

Yep, it makes sense to me now. It's just a lot more information than I'm
used to seeing with a commit.

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, Jan 26, 2016 at 11:36 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Why is this a problem?
>
> It records the fact that you had pull'd and had to merge your changes
> with what "came in" from master from other devs.
>
> Such historical accuracy, while looking "dirty" to some devs, is
> nevertheless accurate to what actually transpired, and can therefore
> be useful to future devs digging through the history.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Jan 26, 2016 at 11:18 AM, david.w.smi...@gmail.com
>  wrote:
> > Yup.  And when you pulled, you didn't do it via rebase.  I'll assume
> you're
> > in the camp of not wanting these merge commits and non-liinear history
> (and
> > thus loops) -- granted I don't think you explicitly stated your opinion.
> > So, even if you followed Yoniks' advice (and not mine) and thus set the
> > branch.autosetuprebase option, that AFAIK only affects repos created
> *after*
> > you set that option.  I recommend you remove that setting if you have and
> > instead set this:
> > git config --global pull.rebase true
> > (or at your discretion remove the --global and thus only set this on this
> > project).
> >
> > Cheers,
> > ~ David
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Hmm Git mistake I believe

[Yonik Seeley]

On Tue, Jan 26, 2016 at 11:36 AM, Michael McCandless
 wrote:
> Why is this a problem?
>
> It records the fact that you had pull'd and had to merge your changes
> with what "came in" from master from other devs.

The branch just reflects when Joel last pulled changes before making
his own changes (local to him). That is normally going to be
irrelevant.

The majority of our changes are of the form "I want this change on
both 5x and trunk" and cherry-pick is normally the cleanest way to
represent that.

-Yonik

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Hmm Git mistake I believe

[Mark Miller]

On Tue, Jan 26, 2016 at 11:37 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> and can therefore
> be useful to future devs digging through the history.
>
>
Some like to say that, but no one has given any concrete examples how this
is useful to future devs. No duh someone that is working locally has to
make their changes work with the latest remote code. Kind of goes without
saying. Putting a lot of no duh into our history is just as easily arguable
to hurt the ability of future devs to understand what actually matters in
the history.

- Mark
-- 
- Mark
about.me/markrmiller

Re: Hmm Git mistake I believe

[david.w.smi...@gmail.com]

I understand it is "accurate" in the sense that it is more detailed as to
what transpired -- at a cost of making the commit log more confusing should
everyone do this.  But I think this extra information is moot in simple
cases like this -- i.e. "simple" in the sense that what he's working on
didn't warrant a feature branch -- the vast majority of cases.  Lets say he
rebases.  And lets say, he had to address some merge conflicts, and that
some error was made -- perhaps too much beer :-).  We determine there's a
bug introduced at his commit but was absent at the commit prior.  Clearly
this commit introduced the bug and then we can go looking to see why.  This
is just like our current dev practice that we've done with subversion, and
note we didn't desire to change our dev practices (yet), even if git
enables new options.   You know -- one step at a time?  Also, sometimes
wether there's a merge commit or not winds up being arbitrary.  For
example, if Joel had developed, tested, *then* pulled (and resolved any
conflicts as necessary & tested again), *then* committed, there would be no
merge commit bubble.  Thus the presence of the merge bubble is arbitrary;
sometimes it'll be there in our logs; sometimes not, even if none of us do
rebase pulls.  So that defeats the meaningfulness of those merge commits.

~ David

On Tue, Jan 26, 2016 at 11:37 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Why is this a problem?
>
> It records the fact that you had pull'd and had to merge your changes
> with what "came in" from master from other devs.
>
> Such historical accuracy, while looking "dirty" to some devs, is
> nevertheless accurate to what actually transpired, and can therefore
> be useful to future devs digging through the history.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Jan 26, 2016 at 11:18 AM, david.w.smi...@gmail.com
>  wrote:
> > Yup.  And when you pulled, you didn't do it via rebase.  I'll assume
> you're
> > in the camp of not wanting these merge commits and non-liinear history
> (and
> > thus loops) -- granted I don't think you explicitly stated your opinion.
> > So, even if you followed Yoniks' advice (and not mine) and thus set the
> > branch.autosetuprebase option, that AFAIK only affects repos created
> *after*
> > you set that option.  I recommend you remove that setting if you have and
> > instead set this:
> > git config --global pull.rebase true
> > (or at your discretion remove the --global and thus only set this on this
> > project).
> >
> > Cheers,
> > ~ David
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com