Menu
▾
▴
Re: Unreleased fixes in master
|
From: Ethan A M. <sf...@us...> - 2019-02-22 21:59:10
|
On Friday, February 22, 2019 12:52:24 PM PST Tait wrote: > > ... > > Back to my original question - why would I ever want to > > merge the stable and development branches? > > That was never the plan. > > ... > > > > > Let me add a couple "git work flow" history highlights for > > > further background. It all started with > > > https://nvie.com/posts/a-successful-git-branching-model/, and > > > this is called "Git Flow". > > > > I have just read that. > > I don't like it at all. > > > > > After much discussion, > > > https://www.endoflineblog.com/gitflow-considered-harmful > > > happened. > > > > That one is much closer to my way of thinking. > > Except that I do not see any reason to merge a release branch > > back into master (or development or whatever you want to call it). > > What would be gained by merging? > > That is a serious question - what is the rationale for even wanting > > to do a merge? > > The rationale is exactly the present example. Just as one would > rather make, then call a function from two places instead of > copy-and-paste the code in both places, it's preferable to make > a commit only once. The notion is that once created, the stable > branch contains mostly fixes and updates that should apply in > both places (stable and master) This has already diverged from my notion of "stable branch". For me, anything in "stable" either is already in the master or will never be there. In no case will something move from stable to master. [snip] > When merging, git looks at the tip of branch A, tip of branch B, > and history back to the common ancestor of A and B (called the > merge-base). It doesn't offer a way to indicate, > commit-by-commit, "merge this and this and not that and then > this..." That makes it difficult to work the way you want, where > all work happens on master and then different bits and pieces > filter back to other places. As you've found, it can be done > with cherry-pick, but then some of the other utilities, like git > log, become less useful. Exactly. This seems like a hint either that "git log" is the wrong tool or that it could be improved by tracking a bit more history. Can't the cherry-pick operation itself be recorded as a transaction? Then a hypothetical command option "git log --show-origin" would list entries as %%% [4] git status On branch branch-5-2-stable [5] git log --show-origin HEAD~1..HEAD commit d83adc16f5a572f5d004963ead8326591498dd41 Author: Ethan A Merritt <merritt@u.washington.edu> Date: Tue Feb 19 23:10:08 2019 -0800 Origin: cherry-pick from master/83a349a07b3f30d3f0c11ff80152f3cb96ff3c77 <body of commit message text> %%% Compared to everything else being tracked already, that seems like it would be a trivial change with nice benefits. [snip] > Anticipating the "why is git this way?" question, remember one > of git's design imperatives was to have a single small token be > enough to ensure all of history was intact and unaltered > (including by a possibly malicious actor). Other systems don't > deliver that guarantee, and as a result they can be more free > with their history. I assumed this was the case. But the thing is, security measures only make sense in the context of a particular threat model. I am far less concerned about the possibility of authorized but malicious contributors corrupting the history than I am about the presence of typos, errors, and outdated or mistaken information in the history that cannot be corrected. To me the benefit from being able to edit the commit messages outways the risk of deliberate corruption. The edit history itself could be tracked, reviewed, and undone if necessary in the case of corruption. > > > If there's just one take-away from this, it's try to avoid using > > > cherry-pick. > > > > All I can say at this point is that "git cherry-pick" is the thing > > that made git usable for me. If I can't use that then I think > > I'd rather go back to CVS. > > Anything but CVS. The biggest issue with CVS is versioning each > file separately, rather than having commits and a uniform state > across the whole repository. I have to concede that point. Consistent synchronization at the level of the entire project definitely beats timestamps on individual files. Ethan |
