Re: How can I automatically create a GIT branch that represents a sequence of tags?
On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson iv...@iveqy.com wrote: I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further? For better or worse, the current state includes a lot of noisy fixing tests type commits which I would like to automatically skip over when hunting bugs. This is not great and is being addressed, but I am trying to make the most of the historical data we have today - which does contain tags for all builds that passed automated testing etc but does not have only good commits on the related branch. My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag. I can see how this would work, but only for future builds. I would need something like it but loop over all existing tags as this is a problem with historical data. Could you please be more specific as to the steps required to automatically form a commit that represents the change between two commits (i.e. tags)? Thanks, Kristian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How can I automatically create a GIT branch that represents a sequence of tags?
In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc. To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is. Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighbouring tags? Thanks, Kristian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What is the best way to perform a complex refactoring spanning multiple repositories?
Hi, I need to re-organize a project using git. This project currently has 3 separate (central) repositories and I will need to move a large number of files back and forth between them. While doing this, there is development going on on each branch, and the restructuring will take some time. I have been continuously rebasing my refactor branches from master in each respective repository. Is there an established way of doing this sort of complex cross repository refactoring in a way that preserves the history across repositories and takes advantage of git's rename merge logic across repositories, by say moving all repos into a third one, do the merge and move back? Effectively, I have three repositories, A, B, and C. I want to move files from B to A and C and preserve history. This is not a simple move of one directory, but a large number of individual files being moved to new locations, renamed, updated etc. I have been working across A, B, and C, moving and updating files, but this will obviously not keep the history of the files being moved across repositories. I imagine that it would be possible to create a new repository D, import A, B, and C into sub directories, rebase to merge the individual commits on A, B, and C into one new big commit on D that will make git understand that files have been moved across, not just removed in one place and deleted from another, then apply the changes back to each individual repository? Thanks, Kristian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
