Unfortunately I don't have time for a full reply right now, but essentially everything I said about actually implementing auto-merging applies to implementing auto-cherry-picking. (Cherry-picking means taking a commit from one place, and applying the same patch somewhere else and re-committing it with the same commit info). This includes the fact that you have to check out the "child branch" in order to do the cherry-pick, since you have to have files there to apply the patch to.
Just remember that there's a reason for merges. They make it straightforward to bring things back together later. Only do the cherry-picking if you have no intent of ever merging the child branches back into a parent - hopefully this is your situation. If it is, like I said, you can do the scripted checkout+cherry-pick loop/ tree traversal like I described. If it's prohibitively expensive to check out each branch, but you really do need it done every time, you might end up wanting to have multiple repositories - your script/hook can go to the others, have them do a fetch/remote update to get the new stuff, then cherry-pick it in their own work trees. (And if your repo is huge enough that duplicate .git directories are a problem, you could use the git-new- workdir script found in the contrib/ directory of the git tarball to set up multiple workdirs. It puts symlinks back to the original .git directory in their .git directories. Just make sure not to commit in one to a branch that another has checked out!) Jeffrey On Mar 3, 6:57 am, will <william.full.m...@gmail.com> wrote: > Yes! -- Thanks for clearing this up. > > I think it is fair to save folk time, I did preface my query with > "tried and true" processes for versioning different development > threads that share a common code base. I'm aware git works in a 'git > way'. I like the tool as it is, just want to fit with others and > myself find productive ... > > j>> You said one thing that really doesn't make sense in context of > git: > j>> "inheriting files". A branch is a pointer to a particular > commit, and > j>> a commit is a snapshot of the entire work tree at that point > (along > > You pretty much understood my intention. I want the 'generations' to > cascade changes from the earlier version, unless otherwise changed. > It's not complicated. What surprises me is that git kind of codes > against it. How does one support multiple releases or development > threads off a common base with a Git system? > > For my understanding then I ought to be able to ... > > 1. Make a change in the baseline (A-0, to keep things canonical). > 2. Commit A-0 > 3. Checkout A-1 > 4. Merge A-0 into A-1 .... A-1 now has A-0 changes NOT change in > A-1 > 5. Commit A-1 > 6. Checkout A-1 > 7. Merge A-1 into A-2 .... A-2 cascades A-0 changes NOT changed in > A-1 and A-2, and then > A-1 > changes NOT changed in A-2 > 8. Commit A-2 > > Beaver away on A-2 or A-1, confident to know that daughters get all > the fixes for previous versions, except those that needed separate > attention (these being merge conflicts in the cascade). > > j>> tree. Besides, you don't really want a merge on A1 and A2 for > every > j>> commit in A. This is pretty much the worst way to clutter your > j>> history! > > On (some) alternative systems, there's no clutter because you set-up > the daughter branches (my A-1 and A-2 in the example) as 'copy from' > the parent. The clutter seems to be an artefact from the Git way. No > problem here, every system has pros and cons. Git may not be the > right tool for this. Or, there may be a 'git-way' solution that > you're not aware of. > > Since my 'bag' is mostly systems and business analysis, it's my job > for systems to work FOR the humans, not talk humans into working for > the system/appliance. There was a line in the AT&T C++ manual that > advised the reader, to "reread the section above until you understand > it." That has to be almost 24 years ago, it seems that times haven't > changed. > > j>> circumstances. And if somehow you really think you want to call > this > j>> every single time you update A, you could trigger it from the > post- > > I dunno why I'd need to do that, just need to cascade behind me when I > checkout A-2, a script hook could merge A-0 to A-1, and merge A-1 with > A-2, This would achieve the correct balance. > > Normally it is incumbent on the person doing the ancestor commit to > verify that the same fix is applied in the descendant daughter > development threads (A-x ... branch family). > > j>> Please have a look at this post from Junio Hamano's blog (he's the > j>>http://gitster.livejournal.com/42247.html > > jh>> As the consequence of the latter point, when you merge a topic > branch 'add-frotz' to > jh>> your 'master' branch, > > This looks fine to me, because someone is describing a specific style > of how the software development workflow 'should' go for them, it is > almost a 'philosophy' except there's rules/principles rather than a > cause-and-effect structure. > > If the Git-way only offers a "branch"-es to do diverging development > -- Branch and merge is what I have to work with, until something > better comes along. I came to the "Git for humans" list to ask for > alternatives to do what I need to do -- That indeed is why I came on > and combed through past posts on the list. > > The effect of the development workflow I asked about. It saves time, > saves money and saves boredom. It also allows some development > leverage on well structured source architectures. > > j>> branches, with A1 and A2 representing configuration differences > that > j>> will never be merged into A? > > Yes and no. On the macro level A-0, A-1, A-2 might never meet. On > the small scale, sometimes folk working in (say) A-3 might re-merge > back the A-3 feature to A-2. > > Btw, I don't _want_ to merge anything. That's the answer you've > provided to my query. > > I want the stuff from A-0 that is untouched in daughter branched to be > checked-out when I've committed them back in A-0. A-1 for example > (ought to be) should only be small increment in the A-0 image. > > Ideally: A-1 = A-0.current_state - A-1.deletions + A-1.additions + > A-1.changes > > That's what would happen for me. i admit there's some limitations in > the Git design, cause now the SHA1 can't be immutable since A-1 is > dependent on the A-0 state, etc. That's not a challenge so much as > "an extra phone call"... When a parent is changed the daughters need > new SHA1-s (say). Since one can only working on one branch at a time, > that should be OK. > > If I've got cloned banks to do independent work that's probably OK too > -- When I update things get 're-balanced'. > > I don't need to change Git, just want to find a way to support what I > need done. If I can't do or it is too much I can rethink my > specifications. The good thing about being process based, is that you > can go start-to-finish. So limits in a tool are just something to be > analysed and corrected (as you say a small script, perhaps?) or we > find alternatives. > > Thanks for that. Definitely helped me with my thought processes. > > Cheers, > Will > > On Mar 2, 12:04 pm, Jeffrey <jefr...@gmail.com> wrote: > > > You said one thing that really doesn't make sense in context of git: > > "inheriting files". A branch is a pointer to a particular commit, and > > a commit is a snapshot of the entire work tree at that point (along > > .. .. .. > > Please have a look at this post from Junio Hamano's blog (he's the > > current maintainer of git) before you get too crazy with your merge > > philosophy. It's a very, very good description of a good way to handle > > branches and merging: > > >http://gitster.livejournal.com/42247.html > > .. .. .. > > branches, with A1 and A2 representing configuration differences that > > will never be merged into A? > > .. .. .. > > So if you still want to do this, all you really need is a script which > > loops through the branches, checking them out and merging the > > appropriate "parent". How you implement this is kind of up to you - > > > Note: your diagrams show cherry-picking, not merging, but I really > > think you probably want to merge. There's nothing gained by having > > duplicate commits on every single branch. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
