Beautiful explanation! Thank you! The dot clicking functionality is really very cool, that actually makes everything way easy to deal with, as far as code review…especially with the background color stuff in there. The Webgui is starting to make more sense to me as I look at these examples.
I am definitely of the opinion also that in situations like that the feature branch should DEFINITELY not squash the commits and throw them away…so I’m with you guys on that one! I guess its just a matter of making it easy for the code reviewer to review the change prior to the merge. But the color coding and graph tree you guys have put on this web page make that very easy enough! And actually pretty easy to make a lot of various different diffs quickly and easily to grok the change before allowing the merge. One question about the example you gave me… Did joe explicitly create a branch called “warnings” to do his fix and merge it back to the main trunk or is that implicitly showing his work on his own repo? I’m assuming the first explanation to be the case but please correct me if I’m wrong. I’m presuming that by having a different branch, he can call commit numerous times.. (which implicitly calls pull before and push after right?), but since he has his own feature branch its no problem, its just pushing that branch to the server repo ( as long as he doesn’t have any other forgotten about changes on his local main trunk). That is probably the general work flow method i would like to standardize on. brings me to another question though…is there any way for me to block people from being able to push their local trunk to the another repo trunk? In essence forcing them to use Joe’s approach. Looks like push is always for the whole repo, so when they call push or commit, then the whole repo is going to get pushed to the server repo…including perhaps things they forgot they were working directly on the main trunk in their local repo. wrapper scripts can hopefully guide them towards always working on a branch, but I have to think that through. Another question, what exactly is the different between pull and update? On Apr 22, 2016, at 7:31 PM, Richard Hipp <d...@sqlite.org> wrote: > On 4/22/16, Steve Schow <st...@bstage.com> wrote: >> >> Im not sure if you’re saying a merge here would >> merge multiple commits from one branch into a single commit on the dest >> branch? You said it preserves the history, but that would infer that the >> merge would not squash the commits in the process. >> > > Here is an simple example: > > https://www.sqlite.org/src/timeline?c=2016-04-13&nd > > Ignore the tempfiles-25 and tempfiles-lazy-open branches - those are > concurrent activities that do not play into this discussion. I'm > looking at the "warning" branch with three check-ins by Joe (userid: > mistachkin) starting on 2016-04-12 20:05. > > Joe did three check-ins to fix compiler warnings. [ab69527c], > [7faec9ea], and [929fa4c3]. He then asked me (userid: drh) to look > them over and merge them if he thought they were appropriate, which I > did at [68142dc5]. Do you see the branch I'm talking about? > > Notice that after Joe made his changes, but before they were merged, I > checked in another unrelated change directly to trunk at [83cfe82c]. > > You can see a "squash" of Joe's three commits in several ways: > > (1) Click on the circular graph node for the baseline of Joe's > changes, which is [bedb88a4]. You'll notice that the center of the > circle turns red. Then click on the circle for the last of Joe's > check-ins [929fa4c3]. You will then see a diff which is the aggregate > of Joe's three check-ins. It is showing you an aggregate diff from > the baseline (the circle with the red dot in the middle) to the second > node you clicked on, which is same thing as the "squashed" check-in. > > Hint: Click on the circle with the red dot again to turn the red dot off. > > (2) Click on the "[68142dc5]" hyperlink to the merge check-in and look > at its diff. That check-in merged all changes in the "warnings" > branch into trunk, so it should show mostly the same diff as (1). > (Any variance is because (1) is using [bedb88a4] as its baseline where > as (2) is using [83cfe82c]. In this case, as in the vast majority of > cases, the changes from [bedb88] to [83cfe8] are be well separated > from the changes in the "warnings" branch and hence the diffs will be > identical.) > > (3) You can also do this from the command-line by typing: "fossil > diff --from bedb88 --to 929fa4 --tk" or something similar. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
