![]() As complicated as this revision history is, this does help anyone navigate the line of commits to see how compatible any change is versus any others in the master-branch line. ![]() These now mark all the points on the trunk/master line of commits. last same-commit-used between master and many branches). these last-shared-commits marked with these tags. So I've put the tags up as I mentioned a while ago. This message was imported via the External PhorumMail Module > just delete the whole branch if things go wobbly). > Easier to just make up a new branch name and experiment there (and even always possible but we've seen that Git doesn't like them as much as a smooth fast-forward line of commits. > with the right number of resets and rebases, but in my early stages with git, I > That situation can always be sorted after the fact (as can most things in git) Maybe that can be the basis of naming a new branch with a "merge mixin". In theory any build should be identified by its peak commit and this merge should make a distinct but repeatable commit name. If we have other configuration-changes we may do that. Ideally a build-with-merge-mixin-options is a bit of a silly option for the long term. I was thinking I may add a tool in for that. > community_3_5_1 that has extra stuff on it, and can no longer be sync'd with > That way, I don't end up with a branch in my repo called > community_3_5_1), and then do the merge there. > a branch with a new name (initially pointing to the same point in history as > If I were doing that in my own repo, I would add a middle step where I create Being one of the main CM-and-old-old-C-debugging guys at BETSOL has kept me in demand! This was, I should note, merely put in until we may consider the pull-requests. > git checkout origin/tags/community_3_5_1 git merge > If you merge with it in your own repo (" > On 4/5/19 8:20 PM, Chris Hassell wrote: because those are passed on to "git log". I go big and do "gitk -branches -tags -all". > where, what was merged when, and so on. > will give you a nice display of the history showing what branches point I have made several and, as well, don't want to make them ambiguous or confusing against real releases. > won't automatically confuse it with a release. > a new descriptive name for the point in history that it points to. If you add no new commits to the new 'branch', it can also function as > It's also possible to create a branch at any time, starting at any historical Having just one (recent) point that shows up in git, labelling a branch in its history, would be all we need. > messages themselves will give that information. > commits between one release and the next, one hopes the commit > For the day-to-day details of what was going on in the many individual ![]() I don't want to clutter the namespace but we do need exact names to keep track, for history and for the future. I hope to name them something clear-enough like "tag-3.1-trunk" or somesuch. As well these fork-points are ambiguous with the tag-branches we have now so they must be named differently anyway. No need to clutter with thousands of others. My intention is to simply name that fork-point for *only* the tags that we have present from SVN. Many of these 'tag-forks' are simply the last-modification-before-a-release and the release itself is a branch where the "tag" was applied and the ChangeLog file was altered to show this. The ties to SVN make it so that there are not merely *zero* tags present anywhere, but that every 'branch-head' which SVN used as a tag has a fork-point (a commit parent of two child commits) that is wholly unnamed. In this case the situation is more complex. > interesting moments in development that weren't actual releases.Īgreed. > For exactly that reason, it might be confusing to add a lot of tags for, hm, > commits that have tags, or at least maybe tags of a certain form.) > example, github will automagically populate its "Releases" page from > releases? That's a very common approach and definitely useful. > Are you planning to tag just the commits that correspond to numbered > (using "git describe") for every possible point in the repository. > (symbolic names for commits) so that we can get descriptive names > As we move from SVN to Git I'm hoping to add real git "Tags" ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |