Re: pro coding style

[Per Steffensen <st...@designware.dk>]

Robert Muir wrote:
>
> Right, I'm positive this (pull requests) is github :)
Well, as I said, I dont KNOW exactly where the border between git and 
github is, but I have a very mature logical sence and a fair amount of 
knowledge about information theory. The rest of the content in the mail 
is based only on my logical sence. I would love to be proved wrong and 
told that my logical sence played a trick on me :-)

My thoughts are that SVN is not dumb (always thinks the best about 
others :-) ), it just hasnt got enough information to help merging in a 
better way than what we have all experienced with SVN. If SVN is not 
dumb, the only way you can be better is by having more information. And 
I would really be mistaken if this is not the reason that git is able to 
act in a smarter way when merging. It simply has more information than SVN!

So what kind of information does it have that SVN does not have? My 
guess is, that it knows where code came from and how it developed 
throughout the life of a hierarchy of branches/forks with a history 
going all the way back to the original common ancestor of the branches. 
If you have this kind of information I would imagine you can do smarter 
merging, and most important you can maintain the detailed information 
about where code came from and how it developed even on the target side 
of the merge, so that you can also be smarter when that branch/fork has 
to be merged somewhere else. So when I said in a prior mail "...else I 
couldnt imagine how you get the advantages you get. Remember that when 
using git you actually run a "repository" on every developers local 
machines. When you commit, you commit only to you local "repository". 
You need to "push" in order to have it "upstreamed" (as they call it)" 
it was acutally an attempt to make an argument that "all the smartness 
must be in git" - I understand it was a very unclear argument.

But the thing is that the local repository is NOT github - it is git. I 
dont have github on my local machine :-) And it is information about the 
commits I did to my local git repository that potentially can make the 
entire process smarter. Without information from my local git repository 
about how I changed the code, it is not possible (again only based on my 
mature logical sence) for the receiving git-repository (eventually 
github) to be smarter than SVN. Therefore, since the clever information 
tracking needs to go on on my local machine, where only git (not github) 
lives, I argue that the smart thing is in git and not in github. 
Actually I couldnt imagine that a "pull requests" isnt just a convenient 
alternative to sending a mail to the owners/committers of the target 
git-fork asking them to downstream this and that commit from my source 
git-fork. I know it is a lot to claim, based alone on logical sence, but 
I trust my logical sence very much :-)

Below some thought about what kind of information you will need to be 
smarter than SVN - again just completely on top of my own head (I really 
dont know anything about git :-) ):

Imagine a file in a repository - content of file:
*abcd
efgh
ijkl
mnop
*
Now we fork (branch) into three forks - fork1, fork2 and fork3
On fork1 the content of the file is changed into
*abcd
1234
efgh
ijkl
mnop
*A line between original line #1 and #2 was inserted - a line with the 
content "1234"

On fork2 the content of the file is changed into
*abcd
efxyz
ijkl
mnop
*The original line #2 was changed

Now you push the changes on fork1 into fork2. The net result on fork2 
obviously is
*abcd
1234
efxyz
ijkl
mnop

* In the meanwhile on fork3 the content of the file has changed into
*abcd
efgh
ij
mnop
*The original line #3 was changed

Now you want to push the changes on fork2 (where some of it came from 
fork1) into fork3
Basically you have the problem of merging the following two versions of 
the file:
*abcd
1234
efxyz
ijkl
mnop
*and
*abcd
efgh
ij
mnop
*In SVN you have no other information than the content of the two 
versions of the file about to be merged. With that amount of information 
it is impossible to make a solid decission about the net result --> 
merge conflict.
If you had information about the history of changes since the common 
original "a line between original line #1 and #2 was inserted", "the 
original line #2 was changed" and "the original line #3 was changed", 
there would be no doubt that the correct net result must be
*abcd
1234
efxyz
ij
mnop
*No merge conflict! I believe the thing about git is that is has this 
information and therefore that is can be smart.

So back to the my line of argument, that it has to be git and not github:
* The information needed to be smart in the final step has to be picked 
up in the early steps
* The early steps are (potentially) going on outside github
* Therefore github cannot be "the smart one"

A very important thing for this to work is that everything is a fork. In 
git a developer does not checkout a branch to do modifications on it. He 
forks the branch to make his changes, and afterwards he pushes  the 
changes to the branch he forked from (his "upstream"). Those pushes are 
explicit/built-in operations in git, and therefore git has a change to 
pick up and maintain the necessary information, and keep track of it 
transitively throughout a long chain of code-modifications. In SVN 
merging is not a SVN-thing - only the commit is. I SVN when you merge 
changes from branch1 into branch2, it just ends up in a commit on 
branch2 - no information is maintained about fact that the changes in 
this commit actually came from this and that change on branch1 (and that 
those changes originally came from this and that changes on branchX and 
branchY). For all of this to work everything needs to go on on separate 
branches (forks) and a change to a branch only happens by pushes 
(merges) from other branches (forks).

It is all about information - git has it, SVN doesnt. And my logical 
sence tells me that is has to be git and not github!

:-) Now tell me that I am stupid :-)

Re: pro coding style

[Toke Eskildsen <te...@statsbiblioteket.dk>]

On Sat, 2012-12-01 at 17:18 +0100, Per Steffensen wrote:
> With change/merge-tracking in both system, the important thing must be
> that you do not have to throw the tracked information away before in
> you attempt to get your changes into the main repository.

People write commit messages in many different ways and have different
working habits. Inserting all commit messages from a patch would
probably be quite messy for some patches, e.g. I have a tendency to make
many small commits, where a lot of those are just added TODO's, cosmetic
enhancements or spelling corrections.

Of course, git's rebase would mitigate this. As a non-committer and
newly converted git user, I'd much prefer to use git for working on
Lucene/Solr patches. Michael Sokolov's analysis is spot on.


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

Re: pro coding style

[Per Steffensen <st...@designware.dk>]

Michael Sokolov skrev:
> This kind of information (merge tracking) has been in svn since 1.5 
> (see 
> http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking).  
> I believe this perception of SVN dates from its early days, when 
> merging was indeed much more difficult: you had to keep track of all 
> the merges you had done, to avoid doing them again, and it was a huge 
> mess.  That has pretty much been sorted out now.
Ok, so the necessary tracking of data seems to be in both. One might be 
better that the other in some aspects and visa versa. I stand corrected.
>
> Now it seems to me that the main advantage about git/github is that it 
> doesn't create a strict boundary between committers and 
> non-committers.  As a committer, the two systems are basically the 
> same up to differences in UI, convenience of tools, etc. 
>
> But for a non-committer, with SVN the situation is irritating if you 
> submit patches that you continue to use, but are not accepted (or not 
> in a timely way) into the main repository.  In such a case, you either 
> have to abandon the use of source control (OUCH!), or you have to fork 
> the entire project and maintain your own repo, with no tools for 
> integrating with the main repo.
>
> My understanding is that with git, you can maintain your own repo, and 
> you have tools for taking changes from upstream repos, and also that 
> the "pull request" mechanism may be more convenient than submitting 
> patches.  So this sounds, on the whole, much more attractive for 
> outside contributors.  I have to admit I've only fiddled with this a 
> bit, so this is mostly based on what I've read and heard: please "tell 
> me that I am stupid"!
>
> -Mike

With change/merge-tracking in both system, the important thing must be 
that you do not have to throw the tracked information away before in you 
attempt to get your changes into the main repository. You certainly 
throw this information away when you create a dumb patch-file. Guess 
that we could make it work, if just "outsiders" where allowed to make 
branches in Apaches SVN - we are not :-) So I guess that is the main 
bennefit of git. It allows for forks from the main repository to live 
remote from the main repository - that is, I would be able to make a 
fork from the Apache git-repository (github or not), a fork that "lives" 
entirely on my system of servers. And when I want to forward changes 
into Apache it can go from my forked repository into the main repository 
(through upstreaming) without having to cross a border where the nice 
change/merge-tracking is lost. Still pretty sure that the stuff for this 
is all in git, but depeding on whether or not Apache would need access 
to my local repository (containing my fork) in order for the upstream 
from my repository to the Apache repository to be possible, when the 
actual action of accepting the upstream has to be on the Apache side, I 
dont know. With GitHub my repository would live the same place as 
Apaches and then certainly it would be possible. But why the discussion? 
Why not just GitHub?!

Regards, Per Steffensen

Re: pro coding style

[Michael Sokolov <so...@ifactory.com>]

On 12/1/2012 7:59 AM, Per Steffensen wrote:
>
> It is all about information - git has it, SVN doesnt. And my logical 
> sence tells me that is has to be git and not github!
>
> :-) Now tell me that I am stupid :-)
This kind of information (merge tracking) has been in svn since 1.5 (see 
http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking). I 
believe this perception of SVN dates from its early days, when merging 
was indeed much more difficult: you had to keep track of all the merges 
you had done, to avoid doing them again, and it was a huge mess.  That 
has pretty much been sorted out now.

Now it seems to me that the main advantage about git/github is that it 
doesn't create a strict boundary between committers and non-committers.  
As a committer, the two systems are basically the same up to differences 
in UI, convenience of tools, etc.

But for a non-committer, with SVN the situation is irritating if you 
submit patches that you continue to use, but are not accepted (or not in 
a timely way) into the main repository.  In such a case, you either have 
to abandon the use of source control (OUCH!), or you have to fork the 
entire project and maintain your own repo, with no tools for integrating 
with the main repo.

My understanding is that with git, you can maintain your own repo, and 
you have tools for taking changes from upstream repos, and also that the 
"pull request" mechanism may be more convenient than submitting 
patches.  So this sounds, on the whole, much more attractive for outside 
contributors.  I have to admit I've only fiddled with this a bit, so 
this is mostly based on what I've read and heard: please "tell me that I 
am stupid"!

-Mike