Re: Merge vs Rebase

[Mark Miller]

On Tue, Jan 26, 2016 at 12:18 PM Erick Erickson 
wrote:

>
> Well, I'm not advocating at all using all their practices,
>

If Hadoop is too janky a project to look at, perhaps we look at
ElasticSearch, which also rebases and squashes commits to manage sanity:
https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md

- Mark
-- 
- Mark
about.me/markrmiller

Re: Merge vs Rebase

[Erick Erickson]

Robert:

Well, I'm not advocating at all using all their practices, just the
guide for how we want to use Git as a place to start our own process.
Or, more accurately, how newbie to Git can use it without "surprises".
David's right, I'm really looking at just the commit patches part.

> The thing I want to model most is the form. It's a clear set of steps I can 
> use to get my feet wet and refine if necessary later. _What_ those steps are 
> open to change.

> I'm getting a little numbed by this endless debate about how to use the shiny 
> new Git thing. Unless we (well, Git pros) want to coach every one of us 
> new-to-Git folks individually, a "how to" guide is indicated. So I'm trying 
> to get something concrete we can then change to suit. As usual, of course, 
> people are more than generous with their time/advice, but why make more work 
> for them?

> Git is just a tool. Right now, the learning curve is just obstructing my 
> getting any "real work" done. We can debate how sparse my code contributions 
> have been recently some other time ;)

> There's nothing coercive about this proposal. If people have a favorite way 
> of making Git stand up and do tricks, I'm not about to ask anyone to change 
> it.

> I have no objections to there being multiple processes outlined in whatever 
> doc we create, just as long as there's a consistent set of steps outlined 
> that I can follow for each workflow without parsing endless "if you want 
> this, then do that" branches.

> The very fact that this conversation has lasted so long is all the proof I 
> need that Git has enough different ways of being used that a "how to" guide 
> is a good thing.

Best,
Erick



On Tue, Jan 26, 2016 at 8:54 AM, Mark Miller  wrote:
> They say the same thing about our horrid build system and so won't learn
> from our other good practices. What a stupid way to think on both sides.
>
> - Mark
>
> On Tue, Jan 26, 2016 at 11:30 AM, Michael McCandless
>  wrote:
>>
>> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smi...@gmail.com
>>  wrote:
>> > Rob,
>> > I'll trust your assessment of the technical deficiencies of the Hadoop
>> > codebase as I have no experience to say one way or the other.
>>
>> I will trust Rob's assessment too.
>>
>> > But I'm
>> > confused why this is relevant to wether they have a decent process &
>> > docs on
>> > how to use git?
>>
>> Actually I think the relationship is clear?
>>
>> If XYZ entity creates something scary looking to me, then it's
>> appropriate for me to question XYZ's dev practices/processes.  I.e. I
>> would not want to look for inspiration on dev practices from such an
>> XYZ project.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
>
> --
> - Mark
>
> http://about.me/markrmiller

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

Re: Merge vs Rebase

[Mark Miller]

They say the same thing about our horrid build system and so won't learn
from our other good practices. What a stupid way to think on both sides.

- Mark

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

> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smi...@gmail.com
>  wrote:
> > Rob,
> > I'll trust your assessment of the technical deficiencies of the Hadoop
> > codebase as I have no experience to say one way or the other.
>
> I will trust Rob's assessment too.
>
> > But I'm
> > confused why this is relevant to wether they have a decent process &
> docs on
> > how to use git?
>
> Actually I think the relationship is clear?
>
> If XYZ entity creates something scary looking to me, then it's
> appropriate for me to question XYZ's dev practices/processes.  I.e. I
> would not want to look for inspiration on dev practices from such an
> XYZ project.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
- Mark

http://about.me/markrmiller

Re: Merge vs Rebase

[Yonik Seeley]

On Tue, Jan 26, 2016 at 11:22 AM, Yonik Seeley  wrote:
> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smi...@gmail.com
>  wrote:
>> My only critique of it is that I sense the git branch.autosetuprebase option
>> (what Yonik is using) might be obsoleted by the pull.rebase option;

Ah, OK... I see from the other thread you meant this:

git config --global pull.rebase true

Didn't know about that.  Looks good to me!

-Yonik

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

Re: Merge vs Rebase

[Michael McCandless]

On Tue, Jan 26, 2016 at 10:54 AM, david.w.smi...@gmail.com
 wrote:
> Rob,
> I'll trust your assessment of the technical deficiencies of the Hadoop
> codebase as I have no experience to say one way or the other.

I will trust Rob's assessment too.

> But I'm
> confused why this is relevant to wether they have a decent process & docs on
> how to use git?

Actually I think the relationship is clear?

If XYZ entity creates something scary looking to me, then it's
appropriate for me to question XYZ's dev practices/processes.  I.e. I
would not want to look for inspiration on dev practices from such an
XYZ project.

Mike McCandless

http://blog.mikemccandless.com

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

Re: Merge vs Rebase

[Yonik Seeley]

On Tue, Jan 26, 2016 at 10:54 AM, david.w.smi...@gmail.com
 wrote:
> My only critique of it is that I sense the git branch.autosetuprebase option
> (what Yonik is using) might be obsoleted by the pull.rebase option;

Maybe I don't understand what you're saying, but
"git config branch.autosetuprebase always"
just changes the default for new branches.
I think we should recommend this for new git users, since someone will
forget to type the rebase part of "git pull --rebase" and accidentally
get merge commits when they didn't mean to (and it's already happened
;-)

-Yonik

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

Re: Merge vs Rebase

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

Rob,
I'll trust your assessment of the technical deficiencies of the Hadoop
codebase as I have no experience to say one way or the other.  But I'm
confused why this is relevant to wether they have a decent process & docs
on how to use git?

For reference I think Erick is referring to this:
https://wiki.apache.org/hadoop/HowToCommit
and perhaps just the "Commit individual patches" section.

FWIW I like the documentation there.  Relatively succinct and represents
almost exactly how I plan to work with Lucene/Solr going forward, albeit
through IntelliJ and not at the command-line.

My only critique of it is that I sense the git branch.autosetuprebase
option (what Yonik is using) might be obsoleted by the pull.rebase option;
I like the latter (newer option) better; and it makes no sense to use
both.  This is a nitpick though; the result is rebasing on pull.

~ David

On Tue, Jan 26, 2016 at 9:06 AM Robert Muir  wrote:

> I am entirely serious, but we all know the code quality problems with
> hadoop. Many are the same ones Uwe has already fought here and you can
> already find issues/discussions on them:
>
> * any hadoop maven artifact is "jar hell in a box"
> * hadoop classes do crazy shit, like execute operating system
> processes when classes load.
> * at the same time, hadoop is not really portable (e.g. hdfs just
> fails on windows without native libraries).
>
> furthermore, I have seen a push for a lot of apache projects to follow
> a "typical" hadoop-like development style. You can recognize certain
> features of it like trying to enforce code reviews,
> review-then-commit, etc. It recently caused a big thread on the
> incubator lists. personally, I agree with some of the comments there,
> that making it too hard to get commits in discourages code cleanups
> and things like that (which appear to be desperately needed if you
> actually look at the code)
>
> I also think their approach to backwards compatibility and JVM version
> support plays a big role. If they stopped pretending they could run on
> ancient java versions and just adopted java 7, they would actually be
> *more* portable (e.g. work on windows) and not less. Also use of NIO.2
> instead of trying to execute processes like 'ln -s' for handling files
> is way cleaner.
>
> On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher 
> wrote:
> > Robert - not sure if you're serious or not but I'd love to see an
> example of the (lack of?) code quality especially in how the dev practices
> there contributed to it. Pointers?
> >
> >Erik
> >
> >> On Jan 26, 2016, at 06:16, Robert Muir  wrote:
> >>
> >> I don't think we should follow the hadoop dev practices, just look at
> >> the quality of the code they produce...
> >>
> >>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <
> erickerick...@gmail.com> wrote:
> >>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> >>> start and we can refine as necessary.
> >>>
> >>> I'll put big banners about "PRELIMINARY" in it, and add bits about
> >>> this being recommended not required.
> >>>
> >>> Thoughts?
> >>>
>  On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler 
> wrote:
>  Hi,
> 
> > Another chore we do is on adding new files is
> > svn propset svn:eol-style native 
> >
> > do we have an equivalent for that in git?
> 
>  Per-file properties like eol-style or MIME-type don't exist. Git has
> some set of internal file extensions it treats as text files and does the
> newlines automagically. If we want to configure that, we can commit a
> ".gitconfig" file in root directory of repository:
> https://help.github.com/articles/dealing-with-line-endings/
> 
>  I would like to add such a .gitconfig file in any case to do some
> sane defaults.
> 
>  The ANT checker in "precommit" now also checks your GIT working copy
> and fails like before, although it no longer looks at mime types or
> eol-style.
> 
>  Uwe
> 
> 
>  -
>  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
> >>
> >> -
> >> 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --

Re: Merge vs Rebase

[Robert Muir]

I am entirely serious, but we all know the code quality problems with
hadoop. Many are the same ones Uwe has already fought here and you can
already find issues/discussions on them:

* any hadoop maven artifact is "jar hell in a box"
* hadoop classes do crazy shit, like execute operating system
processes when classes load.
* at the same time, hadoop is not really portable (e.g. hdfs just
fails on windows without native libraries).

furthermore, I have seen a push for a lot of apache projects to follow
a "typical" hadoop-like development style. You can recognize certain
features of it like trying to enforce code reviews,
review-then-commit, etc. It recently caused a big thread on the
incubator lists. personally, I agree with some of the comments there,
that making it too hard to get commits in discourages code cleanups
and things like that (which appear to be desperately needed if you
actually look at the code)

I also think their approach to backwards compatibility and JVM version
support plays a big role. If they stopped pretending they could run on
ancient java versions and just adopted java 7, they would actually be
*more* portable (e.g. work on windows) and not less. Also use of NIO.2
instead of trying to execute processes like 'ln -s' for handling files
is way cleaner.

On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher  wrote:
> Robert - not sure if you're serious or not but I'd love to see an example of 
> the (lack of?) code quality especially in how the dev practices there 
> contributed to it. Pointers?
>
>Erik
>
>> On Jan 26, 2016, at 06:16, Robert Muir  wrote:
>>
>> I don't think we should follow the hadoop dev practices, just look at
>> the quality of the code they produce...
>>
>>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson  
>>> wrote:
>>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
>>> start and we can refine as necessary.
>>>
>>> I'll put big banners about "PRELIMINARY" in it, and add bits about
>>> this being recommended not required.
>>>
>>> Thoughts?
>>>
 On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
 Hi,

> Another chore we do is on adding new files is
> svn propset svn:eol-style native 
>
> do we have an equivalent for that in git?

 Per-file properties like eol-style or MIME-type don't exist. Git has some 
 set of internal file extensions it treats as text files and does the 
 newlines automagically. If we want to configure that, we can commit a 
 ".gitconfig" file in root directory of repository: 
 https://help.github.com/articles/dealing-with-line-endings/

 I would like to add such a .gitconfig file in any case to do some sane 
 defaults.

 The ANT checker in "precommit" now also checks your GIT working copy and 
 fails like before, although it no longer looks at mime types or eol-style.

 Uwe


 -
 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
>>
>> -
>> 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
>

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

Re: Merge vs Rebase

[Erik Hatcher]

Robert - not sure if you're serious or not but I'd love to see an example of 
the (lack of?) code quality especially in how the dev practices there 
contributed to it. Pointers?

   Erik

> On Jan 26, 2016, at 06:16, Robert Muir  wrote:
> 
> I don't think we should follow the hadoop dev practices, just look at
> the quality of the code they produce...
> 
>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson  
>> wrote:
>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
>> start and we can refine as necessary.
>> 
>> I'll put big banners about "PRELIMINARY" in it, and add bits about
>> this being recommended not required.
>> 
>> Thoughts?
>> 
>>> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
>>> Hi,
>>> 
 Another chore we do is on adding new files is
 svn propset svn:eol-style native 
 
 do we have an equivalent for that in git?
>>> 
>>> Per-file properties like eol-style or MIME-type don't exist. Git has some 
>>> set of internal file extensions it treats as text files and does the 
>>> newlines automagically. If we want to configure that, we can commit a 
>>> ".gitconfig" file in root directory of repository: 
>>> https://help.github.com/articles/dealing-with-line-endings/
>>> 
>>> I would like to add such a .gitconfig file in any case to do some sane 
>>> defaults.
>>> 
>>> The ANT checker in "precommit" now also checks your GIT working copy and 
>>> fails like before, although it no longer looks at mime types or eol-style.
>>> 
>>> Uwe
>>> 
>>> 
>>> -
>>> 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
> 
> -
> 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: Merge vs Rebase

[Robert Muir]

I don't think we should follow the hadoop dev practices, just look at
the quality of the code they produce...

On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson  wrote:
> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> start and we can refine as necessary.
>
> I'll put big banners about "PRELIMINARY" in it, and add bits about
> this being recommended not required.
>
> Thoughts?
>
> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
>> Hi,
>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native 
>>>
>>> do we have an equivalent for that in git?
>>
>> Per-file properties like eol-style or MIME-type don't exist. Git has some 
>> set of internal file extensions it treats as text files and does the 
>> newlines automagically. If we want to configure that, we can commit a 
>> ".gitconfig" file in root directory of repository: 
>> https://help.github.com/articles/dealing-with-line-endings/
>>
>> I would like to add such a .gitconfig file in any case to do some sane 
>> defaults.
>>
>> The ANT checker in "precommit" now also checks your GIT working copy and 
>> fails like before, although it no longer looks at mime types or eol-style.
>>
>> Uwe
>>
>>
>> -
>> 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
>

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

Re: Merge vs Rebase

[Dennis Gove]

+1 for stealing the Hadoop guide wrt commit guidelines. I find their
approach straight forward and I am a fan of attempting to keep a linear
history, as we did in svn.

- Dennis



On Mon, Jan 25, 2016 at 7:50 PM, Erick Erickson 
wrote:

> P.S. with attribution re: the hadoop committer guide.
>
> On Mon, Jan 25, 2016 at 4:49 PM, Erick Erickson 
> wrote:
> > OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> > start and we can refine as necessary.
> >
> > I'll put big banners about "PRELIMINARY" in it, and add bits about
> > this being recommended not required.
> >
> > Thoughts?
> >
> > On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
> >> Hi,
> >>
> >>> Another chore we do is on adding new files is
> >>> svn propset svn:eol-style native 
> >>>
> >>> do we have an equivalent for that in git?
> >>
> >> Per-file properties like eol-style or MIME-type don't exist. Git has
> some set of internal file extensions it treats as text files and does the
> newlines automagically. If we want to configure that, we can commit a
> ".gitconfig" file in root directory of repository:
> https://help.github.com/articles/dealing-with-line-endings/
> >>
> >> I would like to add such a .gitconfig file in any case to do some sane
> defaults.
> >>
> >> The ANT checker in "precommit" now also checks your GIT working copy
> and fails like before, although it no longer looks at mime types or
> eol-style.
> >>
> >> Uwe
> >>
> >>
> >> -
> >> 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: Merge vs Rebase

[Erick Erickson]

P.S. with attribution re: the hadoop committer guide.

On Mon, Jan 25, 2016 at 4:49 PM, Erick Erickson  wrote:
> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> start and we can refine as necessary.
>
> I'll put big banners about "PRELIMINARY" in it, and add bits about
> this being recommended not required.
>
> Thoughts?
>
> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
>> Hi,
>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native 
>>>
>>> do we have an equivalent for that in git?
>>
>> Per-file properties like eol-style or MIME-type don't exist. Git has some 
>> set of internal file extensions it treats as text files and does the 
>> newlines automagically. If we want to configure that, we can commit a 
>> ".gitconfig" file in root directory of repository: 
>> https://help.github.com/articles/dealing-with-line-endings/
>>
>> I would like to add such a .gitconfig file in any case to do some sane 
>> defaults.
>>
>> The ANT checker in "precommit" now also checks your GIT working copy and 
>> fails like before, although it no longer looks at mime types or eol-style.
>>
>> Uwe
>>
>>
>> -
>> 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: Merge vs Rebase

[Erick Erickson]

OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
start and we can refine as necessary.

I'll put big banners about "PRELIMINARY" in it, and add bits about
this being recommended not required.

Thoughts?

On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler  wrote:
> Hi,
>
>> Another chore we do is on adding new files is
>> svn propset svn:eol-style native 
>>
>> do we have an equivalent for that in git?
>
> Per-file properties like eol-style or MIME-type don't exist. Git has some set 
> of internal file extensions it treats as text files and does the newlines 
> automagically. If we want to configure that, we can commit a ".gitconfig" 
> file in root directory of repository: 
> https://help.github.com/articles/dealing-with-line-endings/
>
> I would like to add such a .gitconfig file in any case to do some sane 
> defaults.
>
> The ANT checker in "precommit" now also checks your GIT working copy and 
> fails like before, although it no longer looks at mime types or eol-style.
>
> Uwe
>
>
> -
> 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: Merge vs Rebase

[Uwe Schindler]

Hi,

> Another chore we do is on adding new files is
> svn propset svn:eol-style native 
> 
> do we have an equivalent for that in git?

Per-file properties like eol-style or MIME-type don't exist. Git has some set 
of internal file extensions it treats as text files and does the newlines 
automagically. If we want to configure that, we can commit a ".gitconfig" file 
in root directory of repository: 
https://help.github.com/articles/dealing-with-line-endings/

I would like to add such a .gitconfig file in any case to do some sane defaults.

The ANT checker in "precommit" now also checks your GIT working copy and fails 
like before, although it no longer looks at mime types or eol-style.

Uwe


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

RE: Merge vs Rebase

[Uwe Schindler]

Hi,

> > The example of the conflict between my commit and Mike’s is just a
> “normal usecase”.

It was meant as a conflict in workflow (two people committing at almost same 
time). And that happens quite often.

Uwe


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

Re: Merge vs Rebase

[Shai Erera]

Thanks Dawid. I'll try for sport to not amend commits for a while, see how
that works out for me :). I'll admit that I already ran into needing to
revert a local change cause it didn't work, but I didn't have the "history"
to revert to ...

I don't mind typing 'git push origin HEAD:master'. I prefer commands that
are explicit. Anyway, I usually do Ctrl+R (in bash) and type the command,
which is quickly found in the history. Since it's always the same, I don't
really type it all the time.

Shai

On Mon, Jan 25, 2016 at 11:07 PM Dawid Weiss  wrote:

> > I'll admit Dawid that I obviously still have a lot to learn about working
> > with Git, but what I wrote above reflects my workflow on another project,
> > where we also use Gerrit for doing the code reviews.
>
> I'm not a git expert too, but I've grown to like it for its,
> surprisingly, simplicity. If you grasp the idea of a commit being a
> "patch with a parent" then everything becomes really logical. Looking
> up options and switches to commands in git can be frustrating, but
> this is "implementation layer" not "understanding of what's happening"
> layer.
>
> > I was referring to our current review style -- I'll upload a patch to
> JIRA
> > and get reviews. Yes, for my own history I could commit as many as I want
> > locally, then squash what I want, drop the ones that I don't etc. At the
> > moment I'm used to amending the commit, but I know of a coworker of mine
> who
> > works like you propose -- many commits and squashing in the end.
>
> Your workflow is up to you, Shai. I think amending the same commit
> over and over is in contrast to what you use a version tracking system
> for -- you do *want* those changes layered one on top of another. If
> not for anything else, then for just the possibility that you may want
> to browse through them and see what you've changed when (I do this a
> lot).
>
> > I thought that if I'm in branch 'feature', I cannot do 'git push' since
> > there's no remote tracking branch called 'feature'.
>
> This is where git does not excel. A "git push" for one person may be
> different than for another person -- this depends... on the
> configuration.
>
> The push by default tries to send all the "matching" branches -- the
> ones you have locally that are tracking something on the remote end
> with the same name. They have been fiddling with the defaults though,
> so I'm not sure if this is still the case. Grep for "push.default"
> here:
>
> https://git-scm.com/docs/git-config
>
> > So just so I'm clear, the sequence of commands you're proposing is:
> >
> > git checkout master
> > git merge --squash feature
> # review patch here
> > git push (update origin/master)
> >
> > git checkout branch_5x
> > git cherry-pick master (or the commit hash)
> > git push (update origin/branch_5x)
>
> Yes, that's one of my favorites. It consolidates all the "working"
> state of a feature into one final diff (patch) which you can review
> (see above) before pushing. I have pushes set to  "matching" so for me
> it's one final push after I'm done with all the branches.
>
> > Can you make it even shorter? :)
>
> Yes, you can use what Yonik suggested -- just work on the master
> branch directly and rebase before you commit. For tiny things this
> works just fine.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Merge vs Rebase

[Dawid Weiss]

> I'll admit Dawid that I obviously still have a lot to learn about working
> with Git, but what I wrote above reflects my workflow on another project,
> where we also use Gerrit for doing the code reviews.

I'm not a git expert too, but I've grown to like it for its,
surprisingly, simplicity. If you grasp the idea of a commit being a
"patch with a parent" then everything becomes really logical. Looking
up options and switches to commands in git can be frustrating, but
this is "implementation layer" not "understanding of what's happening"
layer.

> I was referring to our current review style -- I'll upload a patch to JIRA
> and get reviews. Yes, for my own history I could commit as many as I want
> locally, then squash what I want, drop the ones that I don't etc. At the
> moment I'm used to amending the commit, but I know of a coworker of mine who
> works like you propose -- many commits and squashing in the end.

Your workflow is up to you, Shai. I think amending the same commit
over and over is in contrast to what you use a version tracking system
for -- you do *want* those changes layered one on top of another. If
not for anything else, then for just the possibility that you may want
to browse through them and see what you've changed when (I do this a
lot).

> I thought that if I'm in branch 'feature', I cannot do 'git push' since
> there's no remote tracking branch called 'feature'.

This is where git does not excel. A "git push" for one person may be
different than for another person -- this depends... on the
configuration.

The push by default tries to send all the "matching" branches -- the
ones you have locally that are tracking something on the remote end
with the same name. They have been fiddling with the defaults though,
so I'm not sure if this is still the case. Grep for "push.default"
here:

https://git-scm.com/docs/git-config

> So just so I'm clear, the sequence of commands you're proposing is:
>
> git checkout master
> git merge --squash feature
# review patch here
> git push (update origin/master)
>
> git checkout branch_5x
> git cherry-pick master (or the commit hash)
> git push (update origin/branch_5x)

Yes, that's one of my favorites. It consolidates all the "working"
state of a feature into one final diff (patch) which you can review
(see above) before pushing. I have pushes set to  "matching" so for me
it's one final push after I'm done with all the branches.

> Can you make it even shorter? :)

Yes, you can use what Yonik suggested -- just work on the master
branch directly and rebase before you commit. For tiny things this
works just fine.

Dawid

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

Re: Merge vs Rebase

[Yonik Seeley]

On Mon, Jan 25, 2016 at 2:47 PM, Shai Erera  wrote:
> The 'merged' commit, in this case, seems redundant to me as it doesn't add
> any useful information about them. I believe this case isn't an example one
> for a merge. Just my thoughts...

+1

For back-porting the majority of issues from trunk to 5x, cherry-pick
should definitely be the default we point to.
"merge" is about merging *all* changes from a branch, so it won't even
work unless one has a separate feature branch for the change being
back-ported.

-Yonik

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

Re: Merge vs Rebase

[Mark Miller]

On Mon, Jan 25, 2016 at 3:11 PM Dawid Weiss  wrote:

> > commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> > Merge: 5319ca6 6df206a
> >
> > The 'merged' commit, in this case, seems redundant to me as it doesn't
> add
> > any useful information about them.
>
> It tells you exactly which two parent commits this merge actually
> joins. In terms of patches -- this tells you which two different
> "lines" of patches this commit consolidates. This isn't unimportant
> information.
>
>
Depends on the change, who you are, and what you care about.

It's a discussion that's already been had 10 times on the internet. We
won't break any new ground here.

Most of the other Apache projects go for linear history and rebase (eg see
the Hadoop projects https://wiki.apache.org/hadoop/HowToCommit). Other
projects don't. It's simply a religious decision.

- Mark
-- 
- Mark
about.me/markrmiller

Re: Merge vs Rebase

[Shai Erera]

As a person looking at the history, I don't care what this particular
commit merged. I only care about the two commits before it. They're the
ones with content, they're the ones I'll want to 'git show' ... most likely.

Anyway, we don't have to agree on this, but I do suggest that we come up w/
a standard. Otherwise, we'll see a mess. I personally prefer rebase, but if
the project decided to do merge, I'll adopt that and apply it. I'm not
going to argue much because aside from aesthetics and cleanup of 'git log',
I don't feel knowledgeable enough to argue against one or the other.

Shai

On Mon, Jan 25, 2016 at 10:11 PM Dawid Weiss  wrote:

> > commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> > Merge: 5319ca6 6df206a
> >
> > The 'merged' commit, in this case, seems redundant to me as it doesn't
> add
> > any useful information about them.
>
> It tells you exactly which two parent commits this merge actually
> joins. In terms of patches -- this tells you which two different
> "lines" of patches this commit consolidates. This isn't unimportant
> information.
>
> Think of Solr and Lucene, for example -- the merge commit that glues
> the two projects together looks exactly like the one above: it
> connects two different lines of (thousands) of patches that in the
> result form Lucene-Solr.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Merge vs Rebase

[Dawid Weiss]

> commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> Merge: 5319ca6 6df206a
>
> The 'merged' commit, in this case, seems redundant to me as it doesn't add
> any useful information about them.

It tells you exactly which two parent commits this merge actually
joins. In terms of patches -- this tells you which two different
"lines" of patches this commit consolidates. This isn't unimportant
information.

Think of Solr and Lucene, for example -- the merge commit that glues
the two projects together looks exactly like the one above: it
connects two different lines of (thousands) of patches that in the
result form Lucene-Solr.

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

Re: Merge vs Rebase

[Shai Erera]

f I had gone and spontaneously developed that patch suddenly?
>>
>> I think it's odd to insist on "beauty" for our source control history
>> when in fact the reality is quite messy.  This is like people who
>> insist on decorating the inside of their home as if they live in a
>> museum when in reality they have four crazy kids running around.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Mon, Jan 25, 2016 at 3:34 AM, Uwe Schindler  wrote:
>> > Hi,
>> >
>> >
>> >
>> > I am fine with both. The example of the conflict between my commit and
>> > Mike’s is just a “normal usecase”. To me it looks correct how it is
>> shown in
>> > history. At least it shows reality: 2 people were about to commit the
>> same.
>> > This happened with SVN many times, too, but you are right it was solved
>> by
>> > SVN through additional update (a rebase) and then try commit again. I am
>> > fine with both variants. But if we decide to only do one variant, I’d
>> prefer
>> > to have some “howto chart” what you need to do to setup your working
>> copy
>> > correctly (all commands for configuring @apache.org username, pull
>> > settings,…) that are local to the repository. Maybe add a
>> shell/windows.cmd
>> > script to devtools! I don’t want to change those settings globaly, so
>> please
>> > don’t use the magic –global setting in the example.If we have a script,
>> we
>> > can do that per WC:
>> >
>> > -  Fetch repo from git-wip-us
>> >
>> > -  Run script
>> >
>> >
>> >
>> > About merge: When we get pull requests from 3rd parties, we should
>> > definitely not rebase With merging that in (in the same way how
>> Githiub
>> > is doing it), we preserve attribution to the original commiter. We
>> should
>> > really keep that! That is to me the only good reason to use Git!
>> >
>> >
>> >
>> > I am fine with rebasing our own stuff and make it a slight as possible,
>> but
>> > for stuff from 3rd party people, we should really preserve what they
>> did! So
>> > I will always use the command in the github pull request mail and apply
>> that
>> > to my working copy and push.
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >
>> > From: Shai Erera [mailto:ser...@gmail.com]
>> > Sent: Monday, January 25, 2016 8:50 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Merge vs Rebase
>> >
>> >
>> >
>> > I agree David. I'm sure there are valid use cases for merging commits,
>> but I
>> > always prefer rebasing. This has been our way with Apache SVN anyway,
>> so why
>> > change it? I fell like merging only adds unnecessary lines to 'git log',
>> > where you see "Merge commits (1, 7)" but this doesn't add much
>> information
>> > to whoever looks at it.
>> >
>> > What does it matter if this merge commit is from previous master and
>> > feature-commit? Why do we need one additional commit per change?
>> >
>> > I'm not a Git expert, but I know (think...) that if you merge C1 and
>> C2, and
>> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably
>> can
>> > confirm that.
>> >
>> > FWIW, I plan to continue working the 'SVN' way by doing the following:
>> >
>> > git checkout master
>> >
>> > git pull --rebase (update to latest commit/rev)
>> >
>> > git checkout -b feature
>> >
>> > git commit -a -m "feature message"
>> >
>> > git commit --amend (applying review feedback)
>> >
>> > git fetch origin master:master (a'la 'svn up' we used to do)
>> > git rebase master (now my feature commit is right on top of master's
>> latest
>> > commit / rev)
>> >
>> > git push origin HEAD:master
>> >
>> > This will preserve the history linear and flat, which is what we
>> currently
>> > have w/ SVN.
>> >
>> >
>> >
>> > As for mergi

Re: Merge vs Rebase

[Mark Miller]

Yup, it's committers like you and Joel that I'm most worried about simple
guidelines for. Those that are deep into Git on this project are likely to
do whatever they want anyway. I'm not looking to waste my time fighting
them. But for those that don't want to walk those waters, that don't have a
religious bent about having the history of every patch in SVN and hundreds
of one off branches, let's set up a simple work flow for them that helps
keep things sane.

Mark

On Mon, Jan 25, 2016 at 2:42 PM Erick Erickson 
wrote:

> Gotta echo Joel, I just want to get through my first commit here.
> Yonik's outline is along the lines of what I'm looking for. For
> newcomers (including newcomers to Git like me), this discussion is a
> little analogous to someone asking "how do I write to a file in Java"
> and having the discussion dive into the pros and cons of the zillion
> different things you can do with writing data to some disk somewhere;
> options for binary, text, character set, buffered, flushed, fsync'd,
> and on and on. Each and every one of the options discussed has a very
> good use case, but is hard to absorb all at once.
>
> The "How to Contribute" page needs to be updated; I'll be happy to
> volunteer to create/edit a "Git commit process". I can bring the
> newbie's ignorant perspective to bear on it, doing all the dumb things
> that newbies do. Trust me on this, I can misinterpret even the
> simplest of instructions.
>
> And do note that it's perfectly OK IMO to have multiple ways of doing
> things, so this more along the lines of recommendations than
> requirements. I'm not interested in "the one true way". I _am_
> interested in "how do I keep from messing this up completely".
>
> I'm envisioning a few sections here.
> >Your first Git commit
> >> steps for method 1
> >>> backporting to 5x
> >> steps for method 2
> >>> backporting to 5x
>
> > Advanced issues
> >> advanced issue 1
> >> advanced issue 2
>
> Of course we have to reach some consensus on what acceptable  "method
> for newbies" are, which is much of what this discussion is about.
>
> Erick
>
> On Mon, Jan 25, 2016 at 10:07 AM, Shai Erera  wrote:
> > I used cherry-pick, as to me it's the most similar thing to the svn merge
> > workflow we had. But as Mark said, there are other ways too, and IMO we
> > should get to an agreed upon way as a project, and not individuals.
> >
> > For instance, IIRC, branch_5x now has 2 commits: the first is the one
> from
> > master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
> > doesn't contribute to a better understanding of the history.
> >
> > Shai
> >
> >
> > On Mon, Jan 25, 2016, 19:56 Mark Miller  wrote:
> >>
> >> Although, again, before someone gets angry, some groups choose to merge
> in
> >> this case as well instead. There are lots of legit choices. Projects
> tend to
> >> come to consensus on how they operate with these things. There is no
> >> 'correct' choice, just opinions and what the project coalesces around.
> >>
> >>
> >> - Mark
> >>
> >> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller 
> >> wrote:
> >>>
> >>> >> The next step is merging to branch_5x
> >>> >> How do you recommend I do it?
> >>>
> >>> Generally, people use 'cherry-pick' for this.
> >>>
> >>> - Mark
> >>>
> >>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul 
> wrote:
> 
>  The most common usecase is
>  Do development on trunk(master)
> 
>  git commit to master
>  git push
> 
> 
>  The next step is merging to branch_5x
>  How do you recommend I do it?
> 
>  Another chore we do is on adding new files is
>  svn propset svn:eol-style native 
> 
>  do we have an equivalent for that in git?
> 
> 
>  On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley 
>  wrote:
>  >>  git push origin HEAD:master (this is the equivalent of svn commit)
>  >>  (b) Is there a less verbose way to do it,
>  >
>  > I'm no git expert either, but it seems like the simplest example of
>  > applying and committing a patch could be much simpler by having good
>  > defaults and not using a separate branch.
>  >
>  > 1) update your repo (note my .gitconfig makes this use rebasing)
>  > $ git pull
>  >
>  > 2) apply patch / changes, run tests, etc
>  >
>  > 3) commit locally
>  > $ git add  # add the changed files.. use "git add -u" for adding all
>  > modified files
>  > $ git commit -m "my commit message"
>  >
>  > 4) push to remote
>  > $ git push
>  >
>  > -Yonik
>  >
>  >  my .gitconfig --
>  > [user]
>  >   name = yonik
>  >   email = yo...@apache.org
>  >
>  > [color]
>  >   diff = auto
>  >   status = auto
>  >   branch = auto
>  >
>  > [alias]
>  >   br = branch
>  >   co = checkout
>  >   l = log --pretty=oneline
>  >   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>  > --date=short
>  

Re: Merge vs Rebase

[Shai Erera]

I don't think anyone here says "no merges at all", but rather I feel the
direction is "rebase whenever possible, merge when you must or it makes
sense". I realize that the last part is fuzzy and open, and maybe that's
why Dawid (I think?) suggested that we don't change much yet, but rather
let this new Git roll in, let everyone feel it and experience it, and then
perhaps a month-two from now we can discuss how we want to have commits
done in the project.

About history, when I look at 'git log' in branch_5x, it looks like that:

-
commit 51396b8cf63fd7c77d005d10803ae953acfe659f
Merge: *5319ca6*
*6df206a *Author: Michael McCandless 
Date: Sun Jan 24 16:51:39 2016 -0500
  merged

commit *5319ca6*11a7dabc07d23a63555ff2df39596d00e
Author: Michael McCandless 
Date: Sun Jan 24 16:48:51 2016 -0500
   revert this est change until we can fix geo API border cases
(LUCENE-6956)

commit *6df206a*51dee447e9f4625d864ffd80778bdf8ff
Author: Uwe Schindler 
Date: Sun Jan 24 22:05:38 2016 +0100
   LUCENE-6938: Add WC checks back, now based on JGit
--

The 'merged' commit, in this case, seems redundant to me as it doesn't add
any useful information about them. I believe this case isn't an example one
for a merge. Just my thoughts...

Shai


On Mon, Jan 25, 2016 at 9:30 PM Michael McCandless <
luc...@mikemccandless.com> wrote:

> I am very much a git newbie, but:
>
> > The example of the conflict between my commit and Mike’s is just a
> “normal usecase”.
>
> It did not happen in this case, but what if there were tricky
> conflicts to resolve?  And I went and did that and then committed the
> resulting merge?  I would want this information ("Mike did a hairy
> conflict ridden merge using Emacs while drinking too much beer") to be
> preserved because it is in fact meaningful, e.g. to retroactively
> understand how bugs were introduced, as one example.
>
> If I understand it right, a git pull --rebase would also introduce
> conflicts, which I would have (secretly) resolved and then committed
> as if I had gone and spontaneously developed that patch suddenly?
>
> I think it's odd to insist on "beauty" for our source control history
> when in fact the reality is quite messy.  This is like people who
> insist on decorating the inside of their home as if they live in a
> museum when in reality they have four crazy kids running around.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Jan 25, 2016 at 3:34 AM, Uwe Schindler  wrote:
> > Hi,
> >
> >
> >
> > I am fine with both. The example of the conflict between my commit and
> > Mike’s is just a “normal usecase”. To me it looks correct how it is
> shown in
> > history. At least it shows reality: 2 people were about to commit the
> same.
> > This happened with SVN many times, too, but you are right it was solved
> by
> > SVN through additional update (a rebase) and then try commit again. I am
> > fine with both variants. But if we decide to only do one variant, I’d
> prefer
> > to have some “howto chart” what you need to do to setup your working copy
> > correctly (all commands for configuring @apache.org username, pull
> > settings,…) that are local to the repository. Maybe add a
> shell/windows.cmd
> > script to devtools! I don’t want to change those settings globaly, so
> please
> > don’t use the magic –global setting in the example.If we have a script,
> we
> > can do that per WC:
> >
> > -  Fetch repo from git-wip-us
> >
> > -  Run script
> >
> >
> >
> > About merge: When we get pull requests from 3rd parties, we should
> > definitely not rebase With merging that in (in the same way how
> Githiub
> > is doing it), we preserve attribution to the original commiter. We should
> > really keep that! That is to me the only good reason to use Git!
> >
> >
> >
> > I am fine with rebasing our own stuff and make it a slight as possible,
> but
> > for stuff from 3rd party people, we should really preserve what they
> did! So
> > I will always use the command in the github pull request mail and apply
> that
> > to my working copy and push.
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Shai Erera [mailto:ser...@gmail.com]
> > Sent: Monday, January 25, 2016 8:50 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Merge vs Rebase
> 

Re: Merge vs Rebase

[Erick Erickson]

Gotta echo Joel, I just want to get through my first commit here.
Yonik's outline is along the lines of what I'm looking for. For
newcomers (including newcomers to Git like me), this discussion is a
little analogous to someone asking "how do I write to a file in Java"
and having the discussion dive into the pros and cons of the zillion
different things you can do with writing data to some disk somewhere;
options for binary, text, character set, buffered, flushed, fsync'd,
and on and on. Each and every one of the options discussed has a very
good use case, but is hard to absorb all at once.

The "How to Contribute" page needs to be updated; I'll be happy to
volunteer to create/edit a "Git commit process". I can bring the
newbie's ignorant perspective to bear on it, doing all the dumb things
that newbies do. Trust me on this, I can misinterpret even the
simplest of instructions.

And do note that it's perfectly OK IMO to have multiple ways of doing
things, so this more along the lines of recommendations than
requirements. I'm not interested in "the one true way". I _am_
interested in "how do I keep from messing this up completely".

I'm envisioning a few sections here.
>Your first Git commit
>> steps for method 1
>>> backporting to 5x
>> steps for method 2
>>> backporting to 5x

> Advanced issues
>> advanced issue 1
>> advanced issue 2

Of course we have to reach some consensus on what acceptable  "method
for newbies" are, which is much of what this discussion is about.

Erick

On Mon, Jan 25, 2016 at 10:07 AM, Shai Erera  wrote:
> I used cherry-pick, as to me it's the most similar thing to the svn merge
> workflow we had. But as Mark said, there are other ways too, and IMO we
> should get to an agreed upon way as a project, and not individuals.
>
> For instance, IIRC, branch_5x now has 2 commits: the first is the one from
> master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
> doesn't contribute to a better understanding of the history.
>
> Shai
>
>
> On Mon, Jan 25, 2016, 19:56 Mark Miller  wrote:
>>
>> Although, again, before someone gets angry, some groups choose to merge in
>> this case as well instead. There are lots of legit choices. Projects tend to
>> come to consensus on how they operate with these things. There is no
>> 'correct' choice, just opinions and what the project coalesces around.
>>
>>
>> - Mark
>>
>> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller 
>> wrote:
>>>
>>> >> The next step is merging to branch_5x
>>> >> How do you recommend I do it?
>>>
>>> Generally, people use 'cherry-pick' for this.
>>>
>>> - Mark
>>>
>>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul  wrote:

 The most common usecase is
 Do development on trunk(master)

 git commit to master
 git push


 The next step is merging to branch_5x
 How do you recommend I do it?

 Another chore we do is on adding new files is
 svn propset svn:eol-style native 

 do we have an equivalent for that in git?


 On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley 
 wrote:
 >>  git push origin HEAD:master (this is the equivalent of svn commit)
 >>  (b) Is there a less verbose way to do it,
 >
 > I'm no git expert either, but it seems like the simplest example of
 > applying and committing a patch could be much simpler by having good
 > defaults and not using a separate branch.
 >
 > 1) update your repo (note my .gitconfig makes this use rebasing)
 > $ git pull
 >
 > 2) apply patch / changes, run tests, etc
 >
 > 3) commit locally
 > $ git add  # add the changed files.. use "git add -u" for adding all
 > modified files
 > $ git commit -m "my commit message"
 >
 > 4) push to remote
 > $ git push
 >
 > -Yonik
 >
 >  my .gitconfig --
 > [user]
 >   name = yonik
 >   email = yo...@apache.org
 >
 > [color]
 >   diff = auto
 >   status = auto
 >   branch = auto
 >
 > [alias]
 >   br = branch
 >   co = checkout
 >   l = log --pretty=oneline
 >   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
 > --date=short
 >
 > [branch]
 > autosetuprebase = always
 >
 > [push]
 > default = tracking
 >
 > -
 > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 > For additional commands, e-mail: dev-h...@lucene.apache.org
 >



 --
 -
 Noble Paul

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

>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller

-

Re: Merge vs Rebase

[Dawid Weiss]

> git checkout -b feature-branch
> git commit -a -m "message"
> (Get reviews)
> git commit --amend (addressing review comments)

How do you get reviews? Did you push feature-branch to origin or did
you just create a patch from it? If you did push then it doesn't make
sense to amend. If you didn't push then I still don't see any point in
amending -- you'd just  apply any reviews you see fit and squash for
the merge with the mainline. Why bother amending commits that never
make it to the mainline? I see only downsides -- you lose the history
of what you fixed in response to those reviews, for example.

> I do not intend to stack additional commits on top of the initial commit,
> and then in the end squash them or whatever. I treat it all as one piece of
> work and commit, and I don't think our history should reflect every comment
> someone makes on an issue.

Why not? I admit I don't understand. A merge squash at the end of your
work is essentially combining all the intermediate commits into a
single patch -- what's the difference to having one commit amended
multiple times?

> In analogy, today in JIRA we always update a full
> .patch file, and eventually commit it, irrespective of the number of
> iterations that issue has gone through.

Issues very often have a history of patches, not just the most recent one.

> Again, I think we're sync, but wanted to clarify what I meant.

I don't think we are, but at the same time I don't think it matters.
It's what I said -- how you work on your own branches is your thing.

> git checkout master && git pull --rebase (this is nearly identical to the

You don't have to rebase anything. This pull will always succeed and
will fast-forward to the current origin/master, unless you work
directly on your local master branch (which you don't, concluding from
your log of commands).

> git push origin HEAD:master (this is the equivalent of svn commit)

git push will push all remote tracking branches (or current branch),
so you could simply do git push. Shorter.

> (a) Is this (one of) the correct way to do it?

Yes.

> (b) Is there a less verbose way to do it, aside from rebasing feature on
> origin/branch_5x?

You're committing multiple commits on top of master (by rebasing).
Like I mentioned before, this is just one way to do it (in my opinion
it's inferior to no-fast-forward merge in that it obcures which
commits formed a single "feature").

A less verbose way to do it would be to merge --squash your feature
into master and then cherry pick a single commit from master to
branch_5x.

D.

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

Re: Merge vs Rebase

[Michael McCandless]

On Mon, Jan 25, 2016 at 2:49 AM, Shai Erera  wrote:

This has been our way with Apache SVN anyway, so why change it?
>

I don't consider this a valid argument ;)  Git is a new tool, it opens up
new features.  We shouldn't "lock ourselves into the SVN" way just because
"that is what we have always done".

Do you still restrict yourself to what "vi" was able to do while using
Eclipse ;)

Mike McCandless

http://blog.mikemccandless.com

Re: Merge vs Rebase

[Michael McCandless]

I am very much a git newbie, but:

> The example of the conflict between my commit and Mike’s is just a “normal 
> usecase”.

It did not happen in this case, but what if there were tricky
conflicts to resolve?  And I went and did that and then committed the
resulting merge?  I would want this information ("Mike did a hairy
conflict ridden merge using Emacs while drinking too much beer") to be
preserved because it is in fact meaningful, e.g. to retroactively
understand how bugs were introduced, as one example.

If I understand it right, a git pull --rebase would also introduce
conflicts, which I would have (secretly) resolved and then committed
as if I had gone and spontaneously developed that patch suddenly?

I think it's odd to insist on "beauty" for our source control history
when in fact the reality is quite messy.  This is like people who
insist on decorating the inside of their home as if they live in a
museum when in reality they have four crazy kids running around.

Mike McCandless

http://blog.mikemccandless.com

On Mon, Jan 25, 2016 at 3:34 AM, Uwe Schindler  wrote:
> Hi,
>
>
>
> I am fine with both. The example of the conflict between my commit and
> Mike’s is just a “normal usecase”. To me it looks correct how it is shown in
> history. At least it shows reality: 2 people were about to commit the same.
> This happened with SVN many times, too, but you are right it was solved by
> SVN through additional update (a rebase) and then try commit again. I am
> fine with both variants. But if we decide to only do one variant, I’d prefer
> to have some “howto chart” what you need to do to setup your working copy
> correctly (all commands for configuring @apache.org username, pull
> settings,…) that are local to the repository. Maybe add a shell/windows.cmd
> script to devtools! I don’t want to change those settings globaly, so please
> don’t use the magic –global setting in the example.If we have a script, we
> can do that per WC:
>
> -  Fetch repo from git-wip-us
>
> -  Run script
>
>
>
> About merge: When we get pull requests from 3rd parties, we should
> definitely not rebase With merging that in (in the same way how Githiub
> is doing it), we preserve attribution to the original commiter. We should
> really keep that! That is to me the only good reason to use Git!
>
>
>
> I am fine with rebasing our own stuff and make it a slight as possible, but
> for stuff from 3rd party people, we should really preserve what they did! So
> I will always use the command in the github pull request mail and apply that
> to my working copy and push.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Shai Erera [mailto:ser...@gmail.com]
> Sent: Monday, January 25, 2016 8:50 AM
> To: dev@lucene.apache.org
> Subject: Re: Merge vs Rebase
>
>
>
> I agree David. I'm sure there are valid use cases for merging commits, but I
> always prefer rebasing. This has been our way with Apache SVN anyway, so why
> change it? I fell like merging only adds unnecessary lines to 'git log',
> where you see "Merge commits (1, 7)" but this doesn't add much information
> to whoever looks at it.
>
> What does it matter if this merge commit is from previous master and
> feature-commit? Why do we need one additional commit per change?
>
> I'm not a Git expert, but I know (think...) that if you merge C1 and C2, and
> C2 is a parent of C1, Git doesn't do a merge commit. Someone probably can
> confirm that.
>
> FWIW, I plan to continue working the 'SVN' way by doing the following:
>
> git checkout master
>
> git pull --rebase (update to latest commit/rev)
>
> git checkout -b feature
>
> git commit -a -m "feature message"
>
> git commit --amend (applying review feedback)
>
> git fetch origin master:master (a'la 'svn up' we used to do)
> git rebase master (now my feature commit is right on top of master's latest
> commit / rev)
>
> git push origin HEAD:master
>
> This will preserve the history linear and flat, which is what we currently
> have w/ SVN.
>
>
>
> As for merging this commit now to branch_5x. I'll admit I don't have
> experience working with Git w/ multiple active (feature) branches, so I'm
> not sure if rebasing branch_5x on my commit is what we want (cause it will
> drag with it all of trunk's history, as far as I understand). I might try to
> cheerrypick that commit only and apply to branch_5x, which is, again - AFAIU
> - what we used to do in SVN.
>
> However, as I said, I'm 

Re: Merge vs Rebase

[Shai Erera]

I used cherry-pick, as to me it's the most similar thing to the svn merge
workflow we had. But as Mark said, there are other ways too, and IMO we
should get to an agreed upon way as a project, and not individuals.

For instance, IIRC, branch_5x now has 2 commits: the first is the one from
master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
doesn't contribute to a better understanding of the history.

Shai

On Mon, Jan 25, 2016, 19:56 Mark Miller  wrote:

> Although, again, before someone gets angry, some groups choose to merge in
> this case as well instead. There are lots of legit choices. Projects tend
> to come to consensus on how they operate with these things. There is no
> 'correct' choice, just opinions and what the project coalesces around.
>
>
> - Mark
>
> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller 
> wrote:
>
>> >> The next step is merging to branch_5x
>> >> How do you recommend I do it?
>>
>> Generally, people use 'cherry-pick' for this.
>>
>> - Mark
>>
>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul  wrote:
>>
>>> The most common usecase is
>>> Do development on trunk(master)
>>>
>>> git commit to master
>>> git push
>>>
>>>
>>> The next step is merging to branch_5x
>>> How do you recommend I do it?
>>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native 
>>>
>>> do we have an equivalent for that in git?
>>>
>>>
>>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley 
>>> wrote:
>>> >>  git push origin HEAD:master (this is the equivalent of svn commit)
>>> >>  (b) Is there a less verbose way to do it,
>>> >
>>> > I'm no git expert either, but it seems like the simplest example of
>>> > applying and committing a patch could be much simpler by having good
>>> > defaults and not using a separate branch.
>>> >
>>> > 1) update your repo (note my .gitconfig makes this use rebasing)
>>> > $ git pull
>>> >
>>> > 2) apply patch / changes, run tests, etc
>>> >
>>> > 3) commit locally
>>> > $ git add  # add the changed files.. use "git add -u" for adding all
>>> > modified files
>>> > $ git commit -m "my commit message"
>>> >
>>> > 4) push to remote
>>> > $ git push
>>> >
>>> > -Yonik
>>> >
>>> >  my .gitconfig --
>>> > [user]
>>> >   name = yonik
>>> >   email = yo...@apache.org
>>> >
>>> > [color]
>>> >   diff = auto
>>> >   status = auto
>>> >   branch = auto
>>> >
>>> > [alias]
>>> >   br = branch
>>> >   co = checkout
>>> >   l = log --pretty=oneline
>>> >   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>>> --date=short
>>> >
>>> > [branch]
>>> > autosetuprebase = always
>>> >
>>> > [push]
>>> > default = tracking
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> -
>>> Noble Paul
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> - Mark
> about.me/markrmiller
>

Re: Merge vs Rebase

[Mark Miller]

Although, again, before someone gets angry, some groups choose to merge in
this case as well instead. There are lots of legit choices. Projects tend
to come to consensus on how they operate with these things. There is no
'correct' choice, just opinions and what the project coalesces around.


- Mark

On Mon, Jan 25, 2016 at 12:45 PM Mark Miller  wrote:

> >> The next step is merging to branch_5x
> >> How do you recommend I do it?
>
> Generally, people use 'cherry-pick' for this.
>
> - Mark
>
> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul  wrote:
>
>> The most common usecase is
>> Do development on trunk(master)
>>
>> git commit to master
>> git push
>>
>>
>> The next step is merging to branch_5x
>> How do you recommend I do it?
>>
>> Another chore we do is on adding new files is
>> svn propset svn:eol-style native 
>>
>> do we have an equivalent for that in git?
>>
>>
>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley  wrote:
>> >>  git push origin HEAD:master (this is the equivalent of svn commit)
>> >>  (b) Is there a less verbose way to do it,
>> >
>> > I'm no git expert either, but it seems like the simplest example of
>> > applying and committing a patch could be much simpler by having good
>> > defaults and not using a separate branch.
>> >
>> > 1) update your repo (note my .gitconfig makes this use rebasing)
>> > $ git pull
>> >
>> > 2) apply patch / changes, run tests, etc
>> >
>> > 3) commit locally
>> > $ git add  # add the changed files.. use "git add -u" for adding all
>> > modified files
>> > $ git commit -m "my commit message"
>> >
>> > 4) push to remote
>> > $ git push
>> >
>> > -Yonik
>> >
>> >  my .gitconfig --
>> > [user]
>> >   name = yonik
>> >   email = yo...@apache.org
>> >
>> > [color]
>> >   diff = auto
>> >   status = auto
>> >   branch = auto
>> >
>> > [alias]
>> >   br = branch
>> >   co = checkout
>> >   l = log --pretty=oneline
>> >   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>> --date=short
>> >
>> > [branch]
>> > autosetuprebase = always
>> >
>> > [push]
>> > default = tracking
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

Re: Merge vs Rebase

[Mark Miller]

>> The next step is merging to branch_5x
>> How do you recommend I do it?

Generally, people use 'cherry-pick' for this.

- Mark

On Mon, Jan 25, 2016 at 12:39 PM Noble Paul  wrote:

> The most common usecase is
> Do development on trunk(master)
>
> git commit to master
> git push
>
>
> The next step is merging to branch_5x
> How do you recommend I do it?
>
> Another chore we do is on adding new files is
> svn propset svn:eol-style native 
>
> do we have an equivalent for that in git?
>
>
> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley  wrote:
> >>  git push origin HEAD:master (this is the equivalent of svn commit)
> >>  (b) Is there a less verbose way to do it,
> >
> > I'm no git expert either, but it seems like the simplest example of
> > applying and committing a patch could be much simpler by having good
> > defaults and not using a separate branch.
> >
> > 1) update your repo (note my .gitconfig makes this use rebasing)
> > $ git pull
> >
> > 2) apply patch / changes, run tests, etc
> >
> > 3) commit locally
> > $ git add  # add the changed files.. use "git add -u" for adding all
> > modified files
> > $ git commit -m "my commit message"
> >
> > 4) push to remote
> > $ git push
> >
> > -Yonik
> >
> >  my .gitconfig --
> > [user]
> >   name = yonik
> >   email = yo...@apache.org
> >
> > [color]
> >   diff = auto
> >   status = auto
> >   branch = auto
> >
> > [alias]
> >   br = branch
> >   co = checkout
> >   l = log --pretty=oneline
> >   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
> >
> > [branch]
> > autosetuprebase = always
> >
> > [push]
> > default = tracking
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Merge vs Rebase

[Noble Paul]

The most common usecase is
Do development on trunk(master)

git commit to master
git push


The next step is merging to branch_5x
How do you recommend I do it?

Another chore we do is on adding new files is
svn propset svn:eol-style native 

do we have an equivalent for that in git?


On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley  wrote:
>>  git push origin HEAD:master (this is the equivalent of svn commit)
>>  (b) Is there a less verbose way to do it,
>
> I'm no git expert either, but it seems like the simplest example of
> applying and committing a patch could be much simpler by having good
> defaults and not using a separate branch.
>
> 1) update your repo (note my .gitconfig makes this use rebasing)
> $ git pull
>
> 2) apply patch / changes, run tests, etc
>
> 3) commit locally
> $ git add  # add the changed files.. use "git add -u" for adding all
> modified files
> $ git commit -m "my commit message"
>
> 4) push to remote
> $ git push
>
> -Yonik
>
>  my .gitconfig --
> [user]
>   name = yonik
>   email = yo...@apache.org
>
> [color]
>   diff = auto
>   status = auto
>   branch = auto
>
> [alias]
>   br = branch
>   co = checkout
>   l = log --pretty=oneline
>   hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
>
> [branch]
> autosetuprebase = always
>
> [push]
> default = tracking
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
-
Noble Paul

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

Re: Merge vs Rebase

[Yonik Seeley]

>  git push origin HEAD:master (this is the equivalent of svn commit)
>  (b) Is there a less verbose way to do it,

I'm no git expert either, but it seems like the simplest example of
applying and committing a patch could be much simpler by having good
defaults and not using a separate branch.

1) update your repo (note my .gitconfig makes this use rebasing)
$ git pull

2) apply patch / changes, run tests, etc

3) commit locally
$ git add  # add the changed files.. use "git add -u" for adding all
modified files
$ git commit -m "my commit message"

4) push to remote
$ git push

-Yonik

 my .gitconfig --
[user]
  name = yonik
  email = yo...@apache.org

[color]
  diff = auto
  status = auto
  branch = auto

[alias]
  br = branch
  co = checkout
  l = log --pretty=oneline
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

[branch]
autosetuprebase = always

[push]
default = tracking

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

Re: Merge vs Rebase

[Joel Bernstein]

I'm a non git expert and I would prefer to have guidelines to follow.
Understanding the complexities here is not something I have any interest
in. I just want to merge and commit in some agreed apon standard way.

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

On Mon, Jan 25, 2016 at 10:37 AM, Shai Erera  wrote:

> Hi Dawid,
>
> Yes, I know what --amend does. I never amend the parent commit, only my
> initial commit. I think we're talking about the same thing, but just to
> clarify, this is what I mean:
>
> git checkout -b feature-branch
> git commit -a -m "message"
> (Get reviews)
> git commit --amend (addressing review comments)
>
> I do not intend to stack additional commits on top of the initial commit,
> and then in the end squash them or whatever. I treat it all as one piece of
> work and commit, and I don't think our history should reflect every comment
> someone makes on an issue. In analogy, today in JIRA we always update a
> full .patch file, and eventually commit it, irrespective of the number of
> iterations that issue has gone through.
>
> Again, I think we're sync, but wanted to clarify what I meant.
>
> About the guidelines, I'd prefer that we use rebase, but that's not what I
> was after with the guide. Today I've made my first commit to Git (in
> Lucene!), and the way I handled trunk and branch_5x is as follows:
>
> git checkout -b feature master (i.e. trunk)
> (work, commit locally, publish ...)
> (time to push, i.e. SVN commit)
> git fetch origin
> git checkout master && git pull --rebase (this is nearly identical to the
> previous 'svn up')
> git checkout feature && git rebase master
> git push origin HEAD:master (this is the equivalent of svn commit)
>
> ('merge' to branch_5x)
> git checkout branch_5x
> git pull --rebase (pulls from origin/branch_5x)
> git checkout -b feature_5x branch_5x
> git cherry-pick feature (this is partly 'svn merge')
> git push origin HEAD:branch_5x
>
> (a) Is this (one of) the correct way to do it?
> (b) Is there a less verbose way to do it, aside from rebasing feature on
> origin/branch_5x?
>
> So, if we can have such sequence of operations written somewhere, even if
> only as a proposed way to handle it, I think it will make it easy on the
> Git newcomers among committers, since they're going to need to do this a
> lot. And certainly if there's a quicker way to do it!
>
> Shai
>
> On Mon, Jan 25, 2016 at 5:15 PM Dawid Weiss  wrote:
>
>> Hi Shai,
>>
>> > I usually do 'git commit --amend',
>>
>> When do you do this? Note that what the above command does is:
>>
>> 1) it takes the last commit on the current local branch,
>> 2) it takes its parent commit,
>> 3) it applies the diff from the last commit to the parent, permits you
>> to modify the message and commits this new stuff on top of the parent,
>> *resetting* the branch's HEAD reference to this new commit.
>>
>> If you already pushed your unamended commit to the remote then it's
>> too late -- you'd end up with diverged local branch. Again, the
>> simplest way to "see" this would be gitk. I'm sorry if I'm explaining
>> something obvious.
>>
>> > is beneficial. But if I upload a patch, get reviews and intend to
>> upload an
>> > updated patch, I will --amend my commit.
>>
>> I don't see any relation with commits and --amend here. As long as
>> you're working on a branch, this really doesn't matter -- you can just
>> commit your changed stuff after a review and push it to a remote
>> feature branch for others to see (or keep it local if you work on it
>> alone). Amending commit is meant merely to fix a typo in a commit
>> message. Yes, you can play with commits in a serious way (skipping
>> commits, merging them together, changing commit  contents, etc.), but
>> this is really beyond the scope of a new git user (for those who are
>> interested -- see what an interactive rebase is -- rebase -i).
>>
>> > I also agree w/ Uwe, I think it will really help if we have a
>> > guidelines/cheatsheet that document how do we expect dev to happen in
>> the
>> > Git world.
>>
>> Even if it seems right I don't think this is realistic, given that
>> people have their own preferences and (strong) opinions. For example I
>> disagree with Mark that multiple merges and then final merge are a bad
>> thing in general. They are fairly straightforward in the commit graph
>> and they very clearly signify that somebody was working on their own
>> stuff and periodically synced up with changes on the master (or any
>> other branch). Finally, when the feature is ready, a merge to the
>> mainline happens. It's no different to what we used in SVN, actually.
>> This is a classic example of flying fish strategy -- it's been with
>> versioning systems for ages. What I think Mark is worried about is
>> merges across multiple branches, which indeed can quickly become
>> mind-boggling. That's why I suggested that, at first, everyone should
>> stick to simple cherry picks and squashed merges -- not that they're
>> "the best" way to work with git,

Re: Merge vs Rebase

[Shai Erera]

Hi Dawid,

Yes, I know what --amend does. I never amend the parent commit, only my
initial commit. I think we're talking about the same thing, but just to
clarify, this is what I mean:

git checkout -b feature-branch
git commit -a -m "message"
(Get reviews)
git commit --amend (addressing review comments)

I do not intend to stack additional commits on top of the initial commit,
and then in the end squash them or whatever. I treat it all as one piece of
work and commit, and I don't think our history should reflect every comment
someone makes on an issue. In analogy, today in JIRA we always update a
full .patch file, and eventually commit it, irrespective of the number of
iterations that issue has gone through.

Again, I think we're sync, but wanted to clarify what I meant.

About the guidelines, I'd prefer that we use rebase, but that's not what I
was after with the guide. Today I've made my first commit to Git (in
Lucene!), and the way I handled trunk and branch_5x is as follows:

git checkout -b feature master (i.e. trunk)
(work, commit locally, publish ...)
(time to push, i.e. SVN commit)
git fetch origin
git checkout master && git pull --rebase (this is nearly identical to the
previous 'svn up')
git checkout feature && git rebase master
git push origin HEAD:master (this is the equivalent of svn commit)

('merge' to branch_5x)
git checkout branch_5x
git pull --rebase (pulls from origin/branch_5x)
git checkout -b feature_5x branch_5x
git cherry-pick feature (this is partly 'svn merge')
git push origin HEAD:branch_5x

(a) Is this (one of) the correct way to do it?
(b) Is there a less verbose way to do it, aside from rebasing feature on
origin/branch_5x?

So, if we can have such sequence of operations written somewhere, even if
only as a proposed way to handle it, I think it will make it easy on the
Git newcomers among committers, since they're going to need to do this a
lot. And certainly if there's a quicker way to do it!

Shai

On Mon, Jan 25, 2016 at 5:15 PM Dawid Weiss  wrote:

> Hi Shai,
>
> > I usually do 'git commit --amend',
>
> When do you do this? Note that what the above command does is:
>
> 1) it takes the last commit on the current local branch,
> 2) it takes its parent commit,
> 3) it applies the diff from the last commit to the parent, permits you
> to modify the message and commits this new stuff on top of the parent,
> *resetting* the branch's HEAD reference to this new commit.
>
> If you already pushed your unamended commit to the remote then it's
> too late -- you'd end up with diverged local branch. Again, the
> simplest way to "see" this would be gitk. I'm sorry if I'm explaining
> something obvious.
>
> > is beneficial. But if I upload a patch, get reviews and intend to upload
> an
> > updated patch, I will --amend my commit.
>
> I don't see any relation with commits and --amend here. As long as
> you're working on a branch, this really doesn't matter -- you can just
> commit your changed stuff after a review and push it to a remote
> feature branch for others to see (or keep it local if you work on it
> alone). Amending commit is meant merely to fix a typo in a commit
> message. Yes, you can play with commits in a serious way (skipping
> commits, merging them together, changing commit  contents, etc.), but
> this is really beyond the scope of a new git user (for those who are
> interested -- see what an interactive rebase is -- rebase -i).
>
> > I also agree w/ Uwe, I think it will really help if we have a
> > guidelines/cheatsheet that document how do we expect dev to happen in the
> > Git world.
>
> Even if it seems right I don't think this is realistic, given that
> people have their own preferences and (strong) opinions. For example I
> disagree with Mark that multiple merges and then final merge are a bad
> thing in general. They are fairly straightforward in the commit graph
> and they very clearly signify that somebody was working on their own
> stuff and periodically synced up with changes on the master (or any
> other branch). Finally, when the feature is ready, a merge to the
> mainline happens. It's no different to what we used in SVN, actually.
> This is a classic example of flying fish strategy -- it's been with
> versioning systems for ages. What I think Mark is worried about is
> merges across multiple branches, which indeed can quickly become
> mind-boggling. That's why I suggested that, at first, everyone should
> stick to simple cherry picks and squashed merges -- not that they're
> "the best" way to work with git, it's just that they're conceptually
> simpler to understand for those who start their adventure with
> distributed revision control systems. I personally use a lot of
> partial merges and I have no problem with them at all.
>
> > What you (Dawid) put on Github is great for Git newcomers, but as
> > a community I think that having rough standards and guidelines will help,
>
> I didn't have enough time and I'm on vacation with my family this
> week. But I a

Re: Merge vs Rebase

[Mark Miller]

On Mon, Jan 25, 2016 at 10:15 AM Dawid Weiss  wrote:

>  For example I
> disagree with Mark that multiple merges and then final merge are a bad
> thing in general. They are fairly straightforward in the commit graph
> and they very clearly signify that somebody was working on their own
> stuff and periodically synced up with changes on the master (or any
> other branch).
>

It sounds like you are talking about something else. If you are
legitimately working on a large feature, what you would an svn branch for,
merge commits can make sense. That's not the general case at all. Like I
said, it's about determining when the merge commit adds value and when it
just creates complexity with no extra value.

Other than that, you guys are just too obsessed with 'forbidden'.

We talk about getting on the same page and guidelines, and you guys talk
about 'forbidden' and 'bans'. You are just talking past us.

Do some googling. Pretty much every project faces this and either decides
to create an insane amount of merge commits or not. Both choices are taken,
but the path that is almost never taken is, everyone just does whatever the
hell they want without discussing first.


- Mark
-- 
- Mark
about.me/markrmiller

Re: Merge vs Rebase

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

y own changes on master
>>> git merge --squash myfeature
>>> git commit -m "myfeature"
>>>
>>> By the way -- having those "bubbles" in history can be perceived as
>>> beneficial if you merge features that have multiple commits because
>>> then you "see" all the intermediate commits and you can revert the
>>> entire feature in one step (as opposed to multiple fast-forward
>>> commits).
>>>
>>> Dawid
>>>
>>>
>>>
>>> Dawid
>>>
>>>
>>> On Mon, Jan 25, 2016 at 9:34 AM, Uwe Schindler  wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > I am fine with both. The example of the conflict between my commit and
>>> > Mike’s is just a “normal usecase”. To me it looks correct how it is
>>> shown in
>>> > history. At least it shows reality: 2 people were about to commit the
>>> same.
>>> > This happened with SVN many times, too, but you are right it was
>>> solved by
>>> > SVN through additional update (a rebase) and then try commit again. I
>>> am
>>> > fine with both variants. But if we decide to only do one variant, I’d
>>> prefer
>>> > to have some “howto chart” what you need to do to setup your working
>>> copy
>>> > correctly (all commands for configuring @apache.org username, pull
>>> > settings,…) that are local to the repository. Maybe add a
>>> shell/windows.cmd
>>> > script to devtools! I don’t want to change those settings globaly, so
>>> please
>>> > don’t use the magic –global setting in the example.If we have a
>>> script, we
>>> > can do that per WC:
>>> >
>>> > -  Fetch repo from git-wip-us
>>> >
>>> > -  Run script
>>> >
>>> >
>>> >
>>> > About merge: When we get pull requests from 3rd parties, we should
>>> > definitely not rebase With merging that in (in the same way how
>>> Githiub
>>> > is doing it), we preserve attribution to the original commiter. We
>>> should
>>> > really keep that! That is to me the only good reason to use Git!
>>> >
>>> >
>>> >
>>> > I am fine with rebasing our own stuff and make it a slight as
>>> possible, but
>>> > for stuff from 3rd party people, we should really preserve what they
>>> did! So
>>> > I will always use the command in the github pull request mail and
>>> apply that
>>> > to my working copy and push.
>>> >
>>> >
>>> >
>>> > Uwe
>>> >
>>> >
>>> >
>>> > -
>>> >
>>> > Uwe Schindler
>>> >
>>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>>> >
>>> > http://www.thetaphi.de
>>> >
>>> > eMail: u...@thetaphi.de
>>> >
>>> >
>>> >
>>> > From: Shai Erera [mailto:ser...@gmail.com]
>>> > Sent: Monday, January 25, 2016 8:50 AM
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: Merge vs Rebase
>>> >
>>> >
>>> >
>>> > I agree David. I'm sure there are valid use cases for merging commits,
>>> but I
>>> > always prefer rebasing. This has been our way with Apache SVN anyway,
>>> so why
>>> > change it? I fell like merging only adds unnecessary lines to 'git
>>> log',
>>> > where you see "Merge commits (1, 7)" but this doesn't add much
>>> information
>>> > to whoever looks at it.
>>> >
>>> > What does it matter if this merge commit is from previous master and
>>> > feature-commit? Why do we need one additional commit per change?
>>> >
>>> > I'm not a Git expert, but I know (think...) that if you merge C1 and
>>> C2, and
>>> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably
>>> can
>>> > confirm that.
>>> >
>>> > FWIW, I plan to continue working the 'SVN' way by doing the following:
>>> >
>>> > git checkout master
>>> >
>>> > git pull --rebase (update to latest commit/rev)
>>> >
>>> > git checkout -b feature
>>> >
>>> > git commit -a -m "feature message"
>>> >
>&g

Re: Merge vs Rebase

[Mark Miller]

tools! I don’t want to change those settings globaly, so
>> please
>> > don’t use the magic –global setting in the example.If we have a script,
>> we
>> > can do that per WC:
>> >
>> > -  Fetch repo from git-wip-us
>> >
>> > -  Run script
>> >
>> >
>> >
>> > About merge: When we get pull requests from 3rd parties, we should
>> > definitely not rebase With merging that in (in the same way how
>> Githiub
>> > is doing it), we preserve attribution to the original commiter. We
>> should
>> > really keep that! That is to me the only good reason to use Git!
>> >
>> >
>> >
>> > I am fine with rebasing our own stuff and make it a slight as possible,
>> but
>> > for stuff from 3rd party people, we should really preserve what they
>> did! So
>> > I will always use the command in the github pull request mail and apply
>> that
>> > to my working copy and push.
>> >
>> >
>> >
>> > Uwe
>> >
>> >
>> >
>> > -
>> >
>> > Uwe Schindler
>> >
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> >
>> > http://www.thetaphi.de
>> >
>> > eMail: u...@thetaphi.de
>> >
>> >
>> >
>> > From: Shai Erera [mailto:ser...@gmail.com]
>> > Sent: Monday, January 25, 2016 8:50 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Merge vs Rebase
>> >
>> >
>> >
>> > I agree David. I'm sure there are valid use cases for merging commits,
>> but I
>> > always prefer rebasing. This has been our way with Apache SVN anyway,
>> so why
>> > change it? I fell like merging only adds unnecessary lines to 'git log',
>> > where you see "Merge commits (1, 7)" but this doesn't add much
>> information
>> > to whoever looks at it.
>> >
>> > What does it matter if this merge commit is from previous master and
>> > feature-commit? Why do we need one additional commit per change?
>> >
>> > I'm not a Git expert, but I know (think...) that if you merge C1 and
>> C2, and
>> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably
>> can
>> > confirm that.
>> >
>> > FWIW, I plan to continue working the 'SVN' way by doing the following:
>> >
>> > git checkout master
>> >
>> > git pull --rebase (update to latest commit/rev)
>> >
>> > git checkout -b feature
>> >
>> > git commit -a -m "feature message"
>> >
>> > git commit --amend (applying review feedback)
>> >
>> > git fetch origin master:master (a'la 'svn up' we used to do)
>> > git rebase master (now my feature commit is right on top of master's
>> latest
>> > commit / rev)
>> >
>> > git push origin HEAD:master
>> >
>> > This will preserve the history linear and flat, which is what we
>> currently
>> > have w/ SVN.
>> >
>> >
>> >
>> > As for merging this commit now to branch_5x. I'll admit I don't have
>> > experience working with Git w/ multiple active (feature) branches, so
>> I'm
>> > not sure if rebasing branch_5x on my commit is what we want (cause it
>> will
>> > drag with it all of trunk's history, as far as I understand). I might
>> try to
>> > cheerrypick that commit only and apply to branch_5x, which is, again -
>> AFAIU
>> > - what we used to do in SVN.
>> >
>> > However, as I said, I'm not a Git expert, so if anyone thinks I should
>> adopt
>> > a different workflow, especially for the branch_5x changes, I'd be
>> happy to
>> > learn.
>> >
>> > Shai
>> >
>> >
>> >
>> > On Mon, Jan 25, 2016 at 8:13 AM David Smiley 
>> > wrote:
>> >
>> > I suspect my picture didn’t make it so I’m trying again:
>> >
>> >
>> >
>> > Or if that didn’t work, I put it on dropbox:
>> >
>> >
>> https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0
>> >
>> >
>> >
>> > ~ David
>> >
>> >
>> >
>> > On Jan 25, 2016, at 1:07 AM, david.w.smi...@gmail.com wrote:
>> >
>> >
>> >
>> >
>> >
>> > Just to put a little picture to this, I noticed the following:  (see
>> > attached pic)
>> >
>> > I suspect it was the bi-product of using a merge based pull (I think the
>> > default?) instead of a rebase one, and as a result we have this little
>> loop
>> > in the log.  No doubt there is a place for merge commits (e.g. merging
>> one
>> > feature branch and another); but is there an advocate willing to tell
>> us the
>> > virtues that in this instance (not all instances but this one), it's a
>> good
>> > thing?  i.e. is there some insight this loop shows that that I should
>> value
>> > more than a direct simple lineage?
>> >
>> >
>> >
>> > FWIW I prefer to rebase my commits to prevent these little merge
>> bubbles.
>> > It happens automatically with this setting:
>> >
>> >git config --global pull.rebase true
>> >
>> > Alternatively it could be done without the --global flag.  I would most
>> > appreciate it if other committers used this same setting, and I think
>> we'd
>> > all mutually appreciate it as well with cleaner git histories.
>> >
>> >
>> > ~ 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
>>
>> --
- Mark
about.me/markrmiller

Re: Merge vs Rebase

[Shai Erera]

I usually do 'git commit --amend', but I agree Dawid, especially in those
JIRA issues which are logically sub-divided into multiple sub-tasks, with
ISSUE-1.patch, ISSUE-2.patch.. that keeping all the commits in the history
is beneficial. But if I upload a patch, get reviews and intend to upload an
updated patch, I will --amend my commit.

I also agree w/ Uwe, I think it will really help if we have a
guidelines/cheatsheet that document how do we expect dev to happen in the
Git world. What you (Dawid) put on Github is great for Git newcomers, but
as a community I think that having rough standards and guidelines will
help, especially the newcomers who may make work one way just because they
read about it somewhere. The merge/rebase and especially between master and
branch_5x are a good starting point to alleviate confusion and setting
expectations / proposing a workflow.

> git merge origin/master   # merge any changes from remote master,

I would do a rebase here. Is there a reason you pick merge in the example -
i.e. do u think it's the preferred way, or was it just an example? (asking
for educational reasons)

Shai

On Mon, Jan 25, 2016 at 10:48 AM Dawid Weiss  wrote:

> > [...] merge C1 and C2, and C2 is a parent of C1, Git doesn't do a merge
> commit. Someone probably can confirm that.
>
> No, there is freedom in how you do it. You can do a fast-forward merge
> or a regular merge, which will show even a single commit which would
> otherwise be linear as a diversion from history.
>
> There is no way to "script rebase" since rebases can cause conflicts
> and these need to be resolved. If you wish to avoid these "bubbles"
> then I'd suggest to:
>
> 1) *never* work on any remote-tracking branch directly, branch your
> feature branch and work on that, merging from remote branch until
> you're ready to commit.
>
> git fetch origin
> git checkout master -b myfeature
> while (!done) {
>   ... work on myfeature, committing to myfeature
>   git fetch origin
>   git merge origin/master   # merge any changes from remote master,
> resolving conflicts
> }
>
> # when done, either rebase myfeature on top of origin/master and do a
> fast-forward commit (preserves history of all intermediate commits) or
> squash the entire feature into a single commit.
>
> git checkout master
> git pull   # this will never conflict or rebase anything since you
> never had any own changes on master
> git merge --squash myfeature
> git commit -m "myfeature"
>
> By the way -- having those "bubbles" in history can be perceived as
> beneficial if you merge features that have multiple commits because
> then you "see" all the intermediate commits and you can revert the
> entire feature in one step (as opposed to multiple fast-forward
> commits).
>
> Dawid
>
>
>
> Dawid
>
>
> On Mon, Jan 25, 2016 at 9:34 AM, Uwe Schindler  wrote:
> > Hi,
> >
> >
> >
> > I am fine with both. The example of the conflict between my commit and
> > Mike’s is just a “normal usecase”. To me it looks correct how it is
> shown in
> > history. At least it shows reality: 2 people were about to commit the
> same.
> > This happened with SVN many times, too, but you are right it was solved
> by
> > SVN through additional update (a rebase) and then try commit again. I am
> > fine with both variants. But if we decide to only do one variant, I’d
> prefer
> > to have some “howto chart” what you need to do to setup your working copy
> > correctly (all commands for configuring @apache.org username, pull
> > settings,…) that are local to the repository. Maybe add a
> shell/windows.cmd
> > script to devtools! I don’t want to change those settings globaly, so
> please
> > don’t use the magic –global setting in the example.If we have a script,
> we
> > can do that per WC:
> >
> > -  Fetch repo from git-wip-us
> >
> > -  Run script
> >
> >
> >
> > About merge: When we get pull requests from 3rd parties, we should
> > definitely not rebase With merging that in (in the same way how
> Githiub
> > is doing it), we preserve attribution to the original commiter. We should
> > really keep that! That is to me the only good reason to use Git!
> >
> >
> >
> > I am fine with rebasing our own stuff and make it a slight as possible,
> but
> > for stuff from 3rd party people, we should really preserve what they
> did! So
> > I will always use the command in the github pull request mail and apply
> that
> > to my working copy and push.
> >
> >
> >
> > Uwe
> >
> >
> >
> > ---

Re: Merge vs Rebase

[Dawid Weiss]

> [...] merge C1 and C2, and C2 is a parent of C1, Git doesn't do a merge 
> commit. Someone probably can confirm that.

No, there is freedom in how you do it. You can do a fast-forward merge
or a regular merge, which will show even a single commit which would
otherwise be linear as a diversion from history.

There is no way to "script rebase" since rebases can cause conflicts
and these need to be resolved. If you wish to avoid these "bubbles"
then I'd suggest to:

1) *never* work on any remote-tracking branch directly, branch your
feature branch and work on that, merging from remote branch until
you're ready to commit.

git fetch origin
git checkout master -b myfeature
while (!done) {
  ... work on myfeature, committing to myfeature
  git fetch origin
  git merge origin/master   # merge any changes from remote master,
resolving conflicts
}

# when done, either rebase myfeature on top of origin/master and do a
fast-forward commit (preserves history of all intermediate commits) or
squash the entire feature into a single commit.

git checkout master
git pull   # this will never conflict or rebase anything since you
never had any own changes on master
git merge --squash myfeature
git commit -m "myfeature"

By the way -- having those "bubbles" in history can be perceived as
beneficial if you merge features that have multiple commits because
then you "see" all the intermediate commits and you can revert the
entire feature in one step (as opposed to multiple fast-forward
commits).

Dawid



Dawid


On Mon, Jan 25, 2016 at 9:34 AM, Uwe Schindler  wrote:
> Hi,
>
>
>
> I am fine with both. The example of the conflict between my commit and
> Mike’s is just a “normal usecase”. To me it looks correct how it is shown in
> history. At least it shows reality: 2 people were about to commit the same.
> This happened with SVN many times, too, but you are right it was solved by
> SVN through additional update (a rebase) and then try commit again. I am
> fine with both variants. But if we decide to only do one variant, I’d prefer
> to have some “howto chart” what you need to do to setup your working copy
> correctly (all commands for configuring @apache.org username, pull
> settings,…) that are local to the repository. Maybe add a shell/windows.cmd
> script to devtools! I don’t want to change those settings globaly, so please
> don’t use the magic –global setting in the example.If we have a script, we
> can do that per WC:
>
> -  Fetch repo from git-wip-us
>
> -  Run script
>
>
>
> About merge: When we get pull requests from 3rd parties, we should
> definitely not rebase With merging that in (in the same way how Githiub
> is doing it), we preserve attribution to the original commiter. We should
> really keep that! That is to me the only good reason to use Git!
>
>
>
> I am fine with rebasing our own stuff and make it a slight as possible, but
> for stuff from 3rd party people, we should really preserve what they did! So
> I will always use the command in the github pull request mail and apply that
> to my working copy and push.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Shai Erera [mailto:ser...@gmail.com]
> Sent: Monday, January 25, 2016 8:50 AM
> To: dev@lucene.apache.org
> Subject: Re: Merge vs Rebase
>
>
>
> I agree David. I'm sure there are valid use cases for merging commits, but I
> always prefer rebasing. This has been our way with Apache SVN anyway, so why
> change it? I fell like merging only adds unnecessary lines to 'git log',
> where you see "Merge commits (1, 7)" but this doesn't add much information
> to whoever looks at it.
>
> What does it matter if this merge commit is from previous master and
> feature-commit? Why do we need one additional commit per change?
>
> I'm not a Git expert, but I know (think...) that if you merge C1 and C2, and
> C2 is a parent of C1, Git doesn't do a merge commit. Someone probably can
> confirm that.
>
> FWIW, I plan to continue working the 'SVN' way by doing the following:
>
> git checkout master
>
> git pull --rebase (update to latest commit/rev)
>
> git checkout -b feature
>
> git commit -a -m "feature message"
>
> git commit --amend (applying review feedback)
>
> git fetch origin master:master (a'la 'svn up' we used to do)
> git rebase master (now my feature commit is right on top of master's latest
> commit / rev)
>
> git push origin HEAD:master
>
> This will preserve the history linear and flat, which is what we currently
&

RE: Merge vs Rebase

[Uwe Schindler]

Hi,

 

I am fine with both. The example of the conflict between my commit and Mike’s 
is just a “normal usecase”. To me it looks correct how it is shown in history. 
At least it shows reality: 2 people were about to commit the same. This 
happened with SVN many times, too, but you are right it was solved by SVN 
through additional update (a rebase) and then try commit again. I am fine with 
both variants. But if we decide to only do one variant, I’d prefer to have some 
“howto chart” what you need to do to setup your working copy correctly (all 
commands for configuring @apache.org username, pull settings,…) that are local 
to the repository. Maybe add a shell/windows.cmd script to devtools! I don’t 
want to change those settings globaly, so please don’t use the magic –global 
setting in the example.If we have a script, we can do that per WC:

-  Fetch repo from git-wip-us

-  Run script

 

About merge: When we get pull requests from 3rd parties, we should definitely 
not rebase With merging that in (in the same way how Githiub is doing it), 
we preserve attribution to the original commiter. We should really keep that! 
That is to me the only good reason to use Git!

 

I am fine with rebasing our own stuff and make it a slight as possible, but for 
stuff from 3rd party people, we should really preserve what they did! So I will 
always use the command in the github pull request mail and apply that to my 
working copy and push.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Shai Erera [mailto:ser...@gmail.com] 
Sent: Monday, January 25, 2016 8:50 AM
To: dev@lucene.apache.org
Subject: Re: Merge vs Rebase

 

I agree David. I'm sure there are valid use cases for merging commits, but I 
always prefer rebasing. This has been our way with Apache SVN anyway, so why 
change it? I fell like merging only adds unnecessary lines to 'git log', where 
you see "Merge commits (1, 7)" but this doesn't add much information to whoever 
looks at it.

What does it matter if this merge commit is from previous master and 
feature-commit? Why do we need one additional commit per change?

I'm not a Git expert, but I know (think...) that if you merge C1 and C2, and C2 
is a parent of C1, Git doesn't do a merge commit. Someone probably can confirm 
that.

FWIW, I plan to continue working the 'SVN' way by doing the following:

git checkout master

git pull --rebase (update to latest commit/rev)

git checkout -b feature

git commit -a -m "feature message"

git commit --amend (applying review feedback)

git fetch origin master:master (a'la 'svn up' we used to do)
git rebase master (now my feature commit is right on top of master's latest 
commit / rev)

git push origin HEAD:master

This will preserve the history linear and flat, which is what we currently have 
w/ SVN.

 

As for merging this commit now to branch_5x. I'll admit I don't have experience 
working with Git w/ multiple active (feature) branches, so I'm not sure if 
rebasing branch_5x on my commit is what we want (cause it will drag with it all 
of trunk's history, as far as I understand). I might try to cheerrypick that 
commit only and apply to branch_5x, which is, again - AFAIU - what we used to 
do in SVN.

However, as I said, I'm not a Git expert, so if anyone thinks I should adopt a 
different workflow, especially for the branch_5x changes, I'd be happy to learn.

Shai

 

On Mon, Jan 25, 2016 at 8:13 AM David Smiley mailto:david.w.smi...@gmail.com> > wrote:

I suspect my picture didn’t make it so I’m trying again:



 

Or if that didn’t work, I put it on dropbox:

https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0

 

~ David

 

On Jan 25, 2016, at 1:07 AM, david.w.smi...@gmail.com 
<mailto:david.w.smi...@gmail.com>  wrote:

 



 

Just to put a little picture to this, I noticed the following:  (see attached 
pic)

I suspect it was the bi-product of using a merge based pull (I think the 
default?) instead of a rebase one, and as a result we have this little loop in 
the log.  No doubt there is a place for merge commits (e.g. merging one feature 
branch and another); but is there an advocate willing to tell us the virtues 
that in this instance (not all instances but this one), it's a good thing?  
i.e. is there some insight this loop shows that that I should value more than a 
direct simple lineage?

 

FWIW I prefer to rebase my commits to prevent these little merge bubbles.  It 
happens automatically with this setting:

   git config --global pull.rebase true

Alternatively it could be done without the --global flag.  I would most 
appreciate it if other committers used this same setting, and I think we'd all 
mutually appreciate it as well with cleaner git histories.

Re: Merge vs Rebase

[David Smiley]

I suspect my picture didn’t make it so I’m trying again:


Or if that didn’t work, I put it on dropbox:
https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0

~ David

> On Jan 25, 2016, at 1:07 AM, david.w.smi...@gmail.com wrote:
> 
> 
> 
> Just to put a little picture to this, I noticed the following:  (see attached 
> pic)
> I suspect it was the bi-product of using a merge based pull (I think the 
> default?) instead of a rebase one, and as a result we have this little loop 
> in the log.  No doubt there is a place for merge commits (e.g. merging one 
> feature branch and another); but is there an advocate willing to tell us the 
> virtues that in this instance (not all instances but this one), it's a good 
> thing?  i.e. is there some insight this loop shows that that I should value 
> more than a direct simple lineage?
> 
> FWIW I prefer to rebase my commits to prevent these little merge bubbles.  It 
> happens automatically with this setting:
>git config --global pull.rebase true
> Alternatively it could be done without the --global flag.  I would most 
> appreciate it if other committers used this same setting, and I think we'd 
> all mutually appreciate it as well with cleaner git histories.
> 
> ~ David
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
>