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'
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 workin
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 (l
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 h
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 d
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/apac
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),
