On 2012-Jun-25, Magnus Therning wrote: > On Mon, Jun 25, 2012 at 12:29:26PM -0400, [email protected] wrote: > > Thanks for this advice and also Magnus's. > > > > I've made some progress, and have made a pull request to > > archhaskell/habs -- my first contribution to the project! > > > > But since then I've pulled from archhaskell/habs and have conflicts > > in cblrepo.db. What is the best thing to do here -- should I try to > > resolve the conflicts on my end (and make another pull request?) or > > will Magnus resolve the conflicts (assuming he accepts my pull > > request) and I fetch them later? > > It's always best to make sure your changes are rebased onto > habs/master, that makes it trivial to pull them.
Always, or usually? I think I understand how this would usually be helpful, but not always, and not in the current case. My understanding of "rebase" is not as clear as I would like, but it seems to me that the two main uses are (1) to collapse a series of commits into a single commit, and (2) to convert a series of committed snapshots, beginning at A and culminating in C, into a series of patches (differences), move backward (or maybe forward) to some other commit B in the history, and "replay" or apply the patches from there, resulting in a new snapshot C' which can then be easily merged in to succeed B. (1) does not apply in this case, because I made only a single commit. (2) could have been helpful if commits were made in habs/master (meaning, I think, archhaskell/habs master) between the time of my fork and the time of my pull request, but if I read the network graph correctly, the commits in archhaskell/habs were made after my pull request. Consequently, if I had done a rebase at the time, C' would have been identical with C. Do I understand this correctly? > > > Also, I've noticed that most pull requests are from master to > > master. Is this the best way, or is it preferred to make a branch > > for any set of packages that we want to contribute? > > Personally I think this stems from peoples' inexperience with git. > It's definitely preferred to make a separate branch for your changes > and create a pull request from it. Then use the master branch only to > track habs/master. Yes, I also began to think this as I continued reading about git in the meantime. Coming from darcs to git, it was a surprise to learn that my repo, forked and cloned from archhaskell/habs, was not already a "separate branch". I will follow the practice of making a topic branch in the future. In fact, I think I'll just start over and do it right. I'll lose some work, but not much. > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: [email protected] jabber: [email protected] > twitter: magthe http://therning.org/magnus > > Most software today is very much like an Egyptian pyramid with > millions of bricks piled on top of each other, with no structural > integrity, but just done by brute force and thousands of slaves. > -- Alan Kay > _______________________________________________ > arch-haskell mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/arch-haskell -- Gregory D. Weber, Ph. D. : Associate Professor of Informatics / \ Indiana University East 0 : Tel. (765) 973-8420; FAX (765) 973-8550 / \ http://mypage.iu.edu/~gdweber/ 1 [] _______________________________________________ arch-haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/arch-haskell
