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.
