On 2012-Jun-25, Magnus Therning wrote:
On Mon, Jun 25, 2012 at 12:29:26PM -0400, gdweber@iue.edu 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: magnus@therning.org jabber: magnus@therning.org 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 arch-haskell@haskell.org 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 []