Hi Philip, Very well put, thanks for the quality read (especially "bringing up" the Titanic... so to say :))
It is exactly because of the mentioned "separation of concerns" that I wanted to point out that flow (graphs) (*3*)-(*4*)-(*5*) from my previous e-mail <https://groups.google.com/d/msg/git-users/YfgaEuXJdvk/T09bHZpwAwAJ>[1] may be more appropriate in comparison to (*1*)-(*2*), in the given situation where additional changes are needed upon the file that has not yet been merged inside the "master", and where an idea to checkout/create a file alone inside an unrelated branch for further modification was brought up / discussed. For the sake of this topic, I think it shouldn`t be that much about "is Git able to do the **right thing**" as it should be about "what the right thing **is**" in the first place -- being able to communicate your intent to Git in a clear way, so it can _just do it_. Back to the given example -- while you certainly _can_ checkout/create a file from a different branch into a branch where it doesn`t exist yet in order to modify it, it is arguable if that`s something that you _should_ do. In the light of "separation of concerns" between the topic branches, once the merging to "master" time comes, from the Git`s perspective, both of the topic branches will want to "add a new file", where it is in fact the very same file (but with more or less different content) -- thus concerns between two topic branches are not well separated (they shouldn`t both try to do the same thing). Even worse, because of some well established automatic resolution possibilities, which the user might not be aware of, the end result of merging these two topic branches (concerns), where they both want to "add new file A", may be unexpected. If your branch "topic2" wants to modify contents of the file added inside "topic1", then that`s what should happen -- "topic2" should only be concerned with "modify file A", where "topic1" keeps its concern of "add new file A" (graph (*3*) from my previous e-mail). In this case, checking out new file A from "topic1" to "topic2" (where it doesn`t exist, graph (*2*), commits 1, 2 and 3), just in order to be able to modify it before it actually gets merged to "master" seems wrong[2]. Having a need to do so might be a clue that our approach needs to be revised, taking a different one instead. To sum it up -- as wisely advised, if you can, merge as often as possible, but if you can`t (for whatever reason), then at least make sure that your further actions communicate your intention as clearly as possible, so you`re not lying to Git about what you actually want to accomplish, giving it a more fair chance to later do what you consider *the right thing* :) Regards, Buga [1] https://groups.google.com/d/msg/git-users/YfgaEuXJdvk/T09bHZpwAwAJ [2] Unless you then rewrite "topic1" to change its concern, too, or you`re at least aware of the implications, but let`s not blow the discussion out of proportions. On Friday, March 3, 2017 at 11:52:00 PM UTC+1, Philip Oakley wrote: > > Igor, > > The approaches you suggest are perfectly valid approaches to the _worry_ > that the merges might not go right and that other factors may have > intervened. > > However, we have two disparate scenarios: first we have separate discrete > small changes, which can be merged simply. Any merge conflicts would happen > anyway and would be resolved simply when the relevant merge happens. > Or second, we have overlapping intertwined large changes (but done > separately and for a long time) and merging is hell. Even if merging is > done fairly often the division of labour and taskings means they are still > a problem, and then people just avoid merges until its far too late and > they can always blame the other team. Often this delay and obfuscation is > management driven (desire for control) > > The benefit of git is not all the usual stuff, but that control has been > removed from the misinformed management (who often don't let coder's commit > because of 'rules') and the control has been distributed to the coders. > This allows coders to have smaller commits, with more rapid interactions, > and git strongly supports that DAG tree model [It is why I knew it was the > solution when I first read about it!]. > > With Git it becomes easy to see if there is churn between teams (as long > as the cross merging is performed / evaluate), and if seen then the teams > will generally get together (assuming open management) and refine the tasks > into those of the first type, and at least solve the common problems in a > common way. > > Once the activities on the feature branches has achieve the 'separation of > concerns' level then each can progress independently without _worry_. > Obviously (?) this is best supported by some test platform that helps > ensure that important test scenarios aren't broken (even if the Git test > suite takes hours on GfW....) > > > It should be remembered that most peoples views of 'configuration > management' is based on ideas that predate the Titanic, where the 'master > drawing' were worth more than the old masters (Mona Lisa etc) because if > they were damaged you could not build the ship etc. That unique master had > to be protected at all costs, and procedure and process reinforced that > protection. > > Now we have perfect replication (and verification hashes) in milliseconds > for master files, so all the old _worries_ are GONE, and all the old > processes and procedures concerning protection of the master need to also > go. What must be retained is the authorisation step that identifies the > particular revision (and its identical copies) that have a sufficvient > quality level to release for 'production'. > > Most folk do not have a scoobies about this 'titanic' shift that computer > based DVCS provides. <Climb's off horse> > > Merge often, merge early, allways test ! > > Philip > > ----- Original Message ----- > *From:* Igor Djordjevic <javascript:> > *To:* Git for human beings <javascript:> > *Cc:* philip...@iee.org <javascript:> > *Sent:* Wednesday, March 01, 2017 2:22 AM > *Subject:* Re: [git-users] What's the best course of action when you need > a file from another branch that is not yet merged with master? > > On Tuesday, February 28, 2017 at 9:52:11 PM UTC+1, Philip Oakley wrote: > >> On Tuesday, February 28, 2017 at 5:28:14 AM UTC+1, AD S wrote: >> >>> The statement that git will have problems is untrue, as long as it is >>> the same file/filename in the same place/path. >> >> > > Your changes to it will (should) merge in just fine. > > I've been told it is not a good idea to create the same file again as Git >> will see them as 2 different files with the same name and won't necessarily >> merge them together. > > > Philip, am I correct to assume that the future merge "correctness" would > actually also depend on where in the history graph we are at the moment of > doing the proposed checkout of the file from a different branch...? I > quoted the "correctness" because once the merge happens, the result would > certainly be correct technically, but possibly unexpected (thus perceived > as "incorrect", actually just something that was not wanted). > > For example: > > (*1*) ---A---B---C master > \ > X---Y---Z topic1 > > In this case, if we`re currently on "master" branch and we do 'git > checkout topic1 -- file.txt', where "file.txt" doesn`t yet exist in > "master", depending on what we do with the file, once "topic1" gets merged > to "master" the result may be surprising (both branches adding the same > file, but with a bit different content) -- if we just add contents to the > file, it should all be fine, but if any of the branches remove anything > from the file before they get merged, the removal might be reverted and > removed content could reappear in the merge commit, which might be both > unwanted and unexpected (example (2) below, commits 1, 2 and 3 are changes > to the new file we checked-out from "topic1"). > > (*2*) ---A---B---C---1---2---3---M master > \ / > X---Y---Z-----------/ topic1 > > > Thus, could it be better to follow "natural flow" of the history instead, > and incorporate changes in place where they feel most "natural" -- checking > out a non-existent file from a different branch in order to modify it and > commit the changes separately from the branch the file was created in might > not be the best idea, especially if you`re new to Git...? > > So, would it be a good suggestion to follow the history and apply the > changes where they (arguably) "belong" -- on the branch containing the file > we want to modify: > > (*3*) ---A---B---C master > \ > X---Y---Z topic1 > \ > 1---2---3 topic2 > > Now, there is no more problem of a non-existent file -- we`re on branch > "topic1" and we create/checkout a new branch "topic2" there, modifying the > existing file as needed (commits 1, 2 and 3 again). > > Once "topic1" gets merged into "master", we can merge "topic2" as well, > but this time we can rest assured that no matter the changes we did in > those commits 1 to 3 (adding, changing or removing content), the upcoming > merge will yield expected results (file state from commit 3 coming out as a > "winner", being expected as it is the latest file state). We would finally > have a situation like this: > > (*4*) ---A---B---C---M1 master > \ / > X---Y---Z topic1 > \ > 1---2---3 topic2 > > (*5*) ---A---B---C---M1---------M2 master > \ / / > X---Y---Z topic1 / > \ / > 1---2---3 topic2 > > What do you think? > > > Of course, in a scenario like this, we could skip merging branch "topic1" > (we could delete it altogether as well) and just merge "topic2", but due to > a specific workflow that may not be desirable (like a pending review / pull > request for a specific task/issue we were working on in "topic1", being > separate from "topic2", where we would like to keep the two logically > separated and shown inside the history as such). > > And as a side note, if we`re fine with rebasing, once we have the case > shown in (4), instead of doing merge (5), we may rebase "topic2" onto > "master" (M1) to get even cleaner history before issuing a pull request, if > that`s what we prefer. With a merge commit M2 in the end it may look > something like this ("topic1" text omitted to spare some space, but it`s > still at commit Z as in previous examples): > > (*6*) ---A---B---C---M1------------M2 master > \ / \ / > X---Y---Z 1'---2'---3' topic2 > > > ... but this may be now pretty much falling out of the scope of the > initial question, though just saying, all the possibilities :) > > Regards, > Buga > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
