git tag --contains for cherry-picks
Dear List, We have several release branches as well as a master branch where the active development happens. Old releases are maintained with important bug fixes or even new features in our case. It sometimes means that we need to cherry-pick commits across branches, like from master to a specific release branch. Cherry-picking changes the hash of the commit, therefore, this may no longer work for cherry-picks: git tag --contains I am thinking of having something like: git tag --contains-follow which would follow cherry-picks. I am not sure how easily and/or efficiently this can be implemented, but my gut feeling is that in the vast majority of the cases, the content check would bail out already at the "subject line". Again, just to recap: I would like to be able to list of releases (i.e. tags) in which a commit occurs even if it is cherry-picked because what matters for us in the end of the day is whether the feature or bugfix goes into a release. Best Regards, Laszlo Papp -- 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
Re: git log --follow for directories
Junio C Hamano gitster at pobox.com writes: Laszlo Papp lpapp at kde.org writes: Is there any benefit about having it like it is today or is it just the usual no one has implemented it yet? It actually is even more sketchy than that. A single file following was done merely as a checkbox item that works majority of the time, and any mergy history that renames the file on one side of the side branch but not on the other may not truly follow it. Well, in worst case, why not have something like --follow-dirs, then? The case at hand is that we unfortunately named a directory based on the codename of some software for the time. Now, we have improved that software and the codename is different accordingly. Now, instead of pastcodename, I would change the directory name to src to be future proof, but here, I face these difficulties: 1) The directory name is stuck with some ancient codename and it therefore will be confusing for the rest of the life cycle for this project. 2) We get unfollowable directories. At best, we could use some scripts to work this around, but why not address this directly in git? I think renaming a directory without losing the history would be really cool to have, one way or another. If that requires a separate option, I am happy with that, but what I would really like to avoid is not being able to rename directories without losing the history. Note that I am speaking from user point of view. I do not know the nitty-gritty technical details, but that is just implementation details as far as I am concerned, anyway. -- 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
git log --follow for directories
Hi, I have just realized that this would not work on directories triggering directory renames somewhat pointless for those who want to keep track of a group of files in directories. It is unfortunate when you have a directory with many files and more often than not, you would like to look at the history of all rather than individually. Is there any benefit about having it like it is today or is it just the usual no one has implemented it yet? Cheers, L. PS.: I will not stand up for implement this though, but of course I will be very grateful if someone else decides to do so. -- 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
Option for git bisect run to automatically clean up
Hi everybody, I have just run into a problem when I had to issue an explicit cleanup for tracked files after a configure run in the Qt5 project. I have tried to suggest to the people to bring up this idea on the mailing list in order to get this further on. Unfortunately I did not have time to do so, especially for the follow-up. I have also been told it is not a good way of asking on IRC which surprised me a bit, but I am now bringing this up, and I try to also make the follow-up. Hope it is ok. Unfortunately my time is limited so I cannot contribute with that patch myself, but I think it would be a cool convenience feature. Help is appreciated. Thank you in advance! Laszlo -- 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
