Git-subrepo: Merge #142 with master

[ingydotnet]

Issue #142 basically does a merge commit on pull and master does a rebase. We
are going to make it so that pull has 3 strategies:

• --merge
• --rebase
• --reclone

and the user will need to specify one of these when they do a pull. If they
don't then they will get an informative message thelling them to do so. The
choice can be persisted in one of 2 ways:

• .git/config

[subrepo] strategy = merge

• subrepodir/.gitrepo

method = merge

When --update is used on pull, then the strategy will go into the .gitrepo
file.

Issue 142 actually has a lot of other things so we are going to merge this on
another branch and leave the issue/142 branch asis. Work will be done on branch
`issue/216'.

Things to think about:

• Make sure all tests are incorporated and passing
• Try to use original commits from 142 as possible
• A push should always error out if not currently pulled
• Make sure docs are all accurate
  
  
  
  • New options (--edit, etc) need to get into docs
  
  
• Add a --dryrun option for push

Release will (probably) be version 0.4.0.

[ingydotnet]

@grimmySwe, I tried to rebase this but had a few hiccups. I think I can do it
cleanly, but I need to sleep first. More tomorrow.

[grimmySwe]

@ingydotnet How is it going? Please let me know if I can help you out with anything.

[ingydotnet]

I'm still thinking on merge strategies :\

[grimmySwe]

@ingydotnet any progress :-) or are you stuck in the strategies, I have some spare time if you need assistance with something.

[ingydotnet]

@grimmySwe Thanks for the reminder. Let's meet again on IRC today at the usual time.

[grimmySwe]

@ingydotnet I have an early morning tomorrow, what about tomorrow?

torsdag 22 september 2016 skrev Ingy döt Net [email protected]:

@grimmySwe https://github.com/grimmySwe Thanks for the reminder. Let's
meet again on IRC today at the usual time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ingydotnet/git-subrepo/issues/216#issuecomment-248911878,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGLigtdOcRQwsHMfbP9Rl4j6EZ47nf6Qks5qsooXgaJpZM4Juz23
.

[ingydotnet]

@grimmySwe sure!

[ingydotnet]

Fixed the bug in my environment for test/push.t.

Pushed the 216_b branch plus my fix to issue/216 branch and deleted issue/216_b.

Also added url ref to issue 142 to all the 3 commit messages.

@grimmySwe, great work. Now it's my turn. I'm going to start by pulling back in
the deleted tests, see if they still make sense, and then getting them to pass.
Then add the ToDo stuff documented here:

https://gist.github.com/1169e0004f7050b5d08f74c0474be40a

If you have time, feel free to beat me to it :). Since we are in different
timezones, we can likely progress without conflict as long as we commit
regularly.

Cheers!

[grimmySwe]

@ingydotnet I have thought some on possible solutions for the rebase case, but I can't find anything better then the one where you probably have to solve conflicts twice, once when you pull and then another time at push. If you want you can use the squash when pushing to avoid this.

BUT... I would say that the rebase case is still good enough to have as a default strategy as it will work well in a low conflict scenario. So what do you think of the following statement:

Default method - rebase
Pro: Single history
Con: Multiple conflict resolutions in case of conflicts
Intended use case: Repositories with low concurrent progress or one person doing a lot of stuff

Alternative method - merge
Pro: When you solve the conflicts in the pull step, these will not return when pushing.
(Con): You will have merge commits in the history
Intended use case: Repositories with concurrent development

I will see if I can get some hours to try re-add the rebase method and make it default.

[grimmySwe]

I tried to implement a "rebase" method and it seems good so far :-) Currently there is a join_method variable that can be set to rebase to try it out.

There is a new commit on issue/216 branch with this.

@ingydotnet I feel that I have little experience with setting/getting configuration from different parts of git so I leave that to you.
I haven't started to update the test cases yet as I feel that we should decide the layout for the tests, should we duplicate tests and have one test file for each method when it's applicable? Rename all tests working with merge method to something like merge_*.t, keeping the regular rebase variants as *.t. Or should we try to have both methods in single files?

It would probably be a good idea to try and compact the tests a little, I feel that I have done a lot of cut and paste causing the test cases to be a little hard to maintain. I'll see if I can move in some code into the setup file to better share it.

[grimmySwe]

@ingydotnet We have started to use the git-subrepo (branch 216) in our production environment and it looks quite good. BUT... there are some cases that needs to be addressed.

The main issue is that the current algorithm will try to create a linear history when creating the local version of the branch it wants to attach to the subrepo. It does this by using the --first-parent option to rev-list. This can in some cases cause strange behavior in that it will cut the "wrong" parent. Ending result will be correct state but there will be missing commits.

In an attempt to fix this I tried to replace the --first-parent with --ancestor-path, but then there will be chances of a non-linear history.

I will look into this and see if I can find solutions to the problem.

One other note is that for our production environment it seems that we lean to using squash int the subrepo as well to keep the history short.

[ingydotnet]

I finally have time to merge the issue/216 branch to master.

I've just pushed a new branch called issue/216-B. THe head is dde65a5 and all
tests are passing (through no effort of my own). This branch has
origin/master in its history and so can become master when it is done.

I made the new branch by starting with master and then cherry-picking all the
new commits ( 1e79595 .. 169a0ed ) from issue/216.

@grimmySwe, Next I will diff master with issue/216-B and reconsider all the
changes you made, in accordance with our last meeting. I will not push anything
to issue/216 since you are using that. If you need to make work related
changes, push them to issue/216 and I will cherry-pick them in issue/216-B.

When feel that I am done, I'll notify you and you can review issue/216-B and
test it out in your environment. Upon approval it will become master and
there will be much rejoicing.

For those following along the basic plan is to keep the best parts of both
master and issue/142.

I'm going to keep working now. Wish me luck!

[ingydotnet]

@grimmySwe, I started by making the docs read the way I think it should work.
See a30cd54.

Fixed a few doc errors and inconsistencies. Please review.

[grimmySwe]

@ingydotnet So far it looks good! Please let me know if I can assist you in anything.

[grimmySwe]

@ingydotnet I saw that you released a 3.0.1 and said you had 0.4.0 in the pipe, anything you need help with?

[fingon]

Just as a data point, master failed pretty miserably in fairly basic (manual) rebased pull + subsequent push case. The issue/216 branch worked fine in the same case

[grimmySwe]

@fingon thanks for the information!

[grimmySwe]

@ingydotnet I am looking into the strategy options a little. From the original post you suggested two methods of persisting this.

1. .git/config
2. subdir/.gitrepo

The more I think about it I tend to prefer the second method, why?
Because then the information will be persistent in the repo, allowing everyone that uses the main repo to use the same setting.

Suggested changes:

• Add --strategy parameter to clone and init so you can set it when you create the subrepo.
• Add a git subrepo config command that works against the _subdir/.gitrepo_ file. So that we can say in the documentation: To set the join strategy for a subrepo use git subrepo config <subdir> strategy [merge/rebase]

[fingon]

I think the former strategy is downright dangerous (e.g. if .git/config strategy is different, you wind up a repository which looks like a Frankenstein's monster if multiple people deal with git subrepo), so I would say subdir/.gitrepo is the sensible choice.

[ingydotnet]

I think we called this --method and would us the method key in <subdir>/.gitrepo. (All keys are 6 chars).

I agree it should go into <subdir>/.gitrepo.

[grimmySwe]

@ingydotnet You are right, totally forgot that. I'll try it out then.

[ingydotnet]

@grimmySwe I have seen you try to contact me on IRC many times last week. Send
me an email to [email protected] suggesting an exact meeting time for next week
Tues-Fri.

Cheers!

[ingydotnet]

@grimmySwe where does this issue stand?

PS. I've removed all the upstream branches for closed issues. This issue has 3 branches.

[grimmySwe]

This issue is totally included in 0.4.0.