[Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 1:18 PM, Christopher Maynard christopher.mayn...@gtech.com wrote: If possible, add some information/basic steps on a few more topics as well? For example: 1) How do you undo a commit, or undo part of a commit? You can reset the head, but I really think going there requires reading the book. :) 2) How do you apply someone else's patch for testing before committing? Gerrit actually shows you what to do on the review web page - in each Patch Set it has a Download line, with something like this: git fetch https://code.wireshark.org/review/wireshark refs/changes/02/602/2 git checkout FETCH_HEAD You can copy that and paste it in your shell - though I usually create a local branch to do that in, rather than the detached head state done by that command. So I do this instead: git fetch https://code.wireshark.org/review/wireshark refs/changes/02/602/2 git checkout -b new-branch-name FETCH_HEAD 3) How to backport to other trunks? That's currently documented in: http://wiki.wireshark.org/Development/Backporting But that's written from the perspective of someone going through the submission process - not of a core developer doing the cherry-pick. 4) How do you know if someone has a fix or not? With subversion, they'd indicate they're running svn r51234, for example, and then you could tell them that they need to update to at least r52345. With git, how does this work with hashes? That would be good to know - because so far it seems people've been using the first ~6 characters of the commit hashes, but I'm not sure if that's right or not. -hadriel ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 6:47 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: 4) How do you know if someone has a fix or not? With subversion, they'd indicate they're running svn r51234, for example, and then you could tell them that they need to update to at least r52345. With git, how does this work with hashes? That would be good to know - because so far it seems people've been using the first ~6 characters of the commit hashes, but I'm not sure if that's right or not. That is in general the git method. Better to use the first 12, but the general idea stays the same. But I would rather suggest using the gerrit change-ids, as those are universal. Git commit ids differ between different people (each clone may create their one), but change-ids stay identical. - Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 7:01 PM, Roland Knall rkn...@gmail.com wrote: On Tue, Mar 11, 2014 at 6:47 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: 4) How do you know if someone has a fix or not? With subversion, they'd indicate they're running svn r51234, for example, and then you could tell them that they need to update to at least r52345. With git, how does this work with hashes? That would be good to know - because so far it seems people've been using the first ~6 characters of the commit hashes, but I'm not sure if that's right or not. That is in general the git method. Better to use the first 12, but the general idea stays the same. But I would rather suggest using the gerrit change-ids, as those are universal. Git commit ids differ between different people (each clone may create their one), but change-ids stay identical. For Wireshark build ( http://www.wireshark.org/download/automated ) The file contains the number of commit from start of new branch - Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 1:35 PM, Evan Huus eapa...@gmail.com wrote: Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. And if you use the Git Swiss Army Sledgehammer, a/k/a git rebase, you can get rid of the commit with SHA x or, at least, not have it clutter your logs (as well as getting rid of all those silly merges Git forces you to do in some cases). That's one reason why the git rebase in my git update script: git stash; git pull; git rebase; git stash pop is handy. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 4:47 PM, Guy Harris g...@alum.mit.edu wrote: On Mar 11, 2014, at 1:35 PM, Evan Huus eapa...@gmail.com wrote: Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. And if you use the Git Swiss Army Sledgehammer, a/k/a git rebase, you can get rid of the commit with SHA x or, at least, not have it clutter your logs (as well as getting rid of all those silly merges Git forces you to do in some cases). That's one reason why the git rebase in my git update script: git stash; git pull; git rebase; git stash pop is handy. Or if you do development in branches as is fairly common, you can just delete the old branch. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. SHAs aren't ordered like SVN revisions are (so given two arbitrary SHAs and nothing else I can't determine which came first) but they do still have an ordering in the repository. Regardless, we can say: fixed in commit SHA. They can pull, and if git show SHA shows the revision then they've got it. Otherwise they don't. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 1:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. That'd require a commit identifier where, on any given branch in the official repository, given the identifiers for two commits, it's easy to determine which commit is later. That's true of SVN revision numbers, as they're time-ordered, but it's not true of SHA hashes for Git commits. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. SHAs aren't ordered like SVN revisions are (so given two arbitrary SHAs and nothing else I can't determine which came first) but they do still have an ordering in the repository. Regardless, we can say: fixed in commit SHA. They can pull, and if git show SHA shows the revision then they've got it. Otherwise they don't. That doesn't help users who only install, not build as their copy of Wireshark doesn't have a list of SHA (or does it?). They only way I can think of resolving that is to refer to dates as they are time-ordered (I hope). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 4:55 PM, Guy Harris g...@alum.mit.edu wrote: On Mar 11, 2014, at 1:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. That'd require a commit identifier where, on any given branch in the official repository, given the identifiers for two commits, it's easy to determine which commit is later. That's true of SVN revision numbers, as they're time-ordered, but it's not true of SHA hashes for Git commits. Git will give you the answer (several options are given at [1]) but the SHAs themselves are not comparable. [1] https://stackoverflow.com/questions/18345157/how-can-i-tell-if-one-commit-is-an-ancestor-of-another-commit-or-vice-versa ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. SHAs aren't ordered like SVN revisions are (so given two arbitrary SHAs and nothing else I can't determine which came first) but they do still have an ordering in the repository. Regardless, we can say: fixed in commit SHA. They can pull, and if git show SHA shows the revision then they've got it. Otherwise they don't. That doesn't help users who only install, not build as their copy of Wireshark doesn't have a list of SHA (or does it?). They only way I can think of resolving that is to refer to dates as they are time-ordered (I hope). Time still works; if it was submitted to master at noon on Monday then presumably any automated build from after that point will include the relevant change. Alternatively, the automated build files have the name format: Wireshark-$Platform-$Tag-$CommitsSinceTag-g$SHA.exe (e.g. Wireshark-win32-1.11.3-1925-g0f73f79.exe) So if you know the change was in SHA x (and the current latest tag is y), you can run git rev-list y..x --count and it will give you the $CommitsSinceTag value which is strictly increasing like an SVN revision number. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On 11 March 2014 21:06, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. SHAs aren't ordered like SVN revisions are (so given two arbitrary SHAs and nothing else I can't determine which came first) but they do still have an ordering in the repository. Regardless, we can say: fixed in commit SHA. They can pull, and if git show SHA shows the revision then they've got it. Otherwise they don't. That doesn't help users who only install, not build as their copy of Wireshark doesn't have a list of SHA (or does it?). They only way I can think of resolving that is to refer to dates as they are time-ordered (I hope). Time still works; if it was submitted to master at noon on Monday then presumably any automated build from after that point will include the relevant change. Alternatively, the automated build files have the name format: Wireshark-$Platform-$Tag-$CommitsSinceTag-g$SHA.exe (e.g. Wireshark-win32-1.11.3-1925-g0f73f79.exe) So if you know the change was in SHA x (and the current latest tag is y), you can run git rev-list y..x --count and it will give you the $CommitsSinceTag value which is strictly increasing like an SVN revision number. I think you're still missing the point. Users who install don't have git, all they have is the About box. The information there should be enough to allow them to locate a bug on Bugzilla and determine if their version has been fixed. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 5:11 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 21:06, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:50, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 11 March 2014 20:35, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall rkn...@gmail.com wrote: Git commit ids differ between different people (each clone may create their one) Not technically true. If I make a commit with SHA x, push it, and it gets submitted, then it is true that the final SHA in master will be y != x. However, the next time I pull then I will get SHA y as well. They x and y technically reference different commits, since y contains additional information about who reviewed it, when it was submitted from Gerrit, etc. But aren't we talking about users, rather than devs? Users will either build from a clone from the main repo, or use an automated build, thus their reference point will be the Gerrit | master SHA whichever is the most appropriate name for it. In any case I don't think this fulfils the initial question. Previously we could say to users that an issue was fixed in svn r and they would know that any rev later than that was good. I don't understand how they can know that with a SHA of the latest master commit | merge. SHAs aren't ordered like SVN revisions are (so given two arbitrary SHAs and nothing else I can't determine which came first) but they do still have an ordering in the repository. Regardless, we can say: fixed in commit SHA. They can pull, and if git show SHA shows the revision then they've got it. Otherwise they don't. That doesn't help users who only install, not build as their copy of Wireshark doesn't have a list of SHA (or does it?). They only way I can think of resolving that is to refer to dates as they are time-ordered (I hope). Time still works; if it was submitted to master at noon on Monday then presumably any automated build from after that point will include the relevant change. Alternatively, the automated build files have the name format: Wireshark-$Platform-$Tag-$CommitsSinceTag-g$SHA.exe (e.g. Wireshark-win32-1.11.3-1925-g0f73f79.exe) So if you know the change was in SHA x (and the current latest tag is y), you can run git rev-list y..x --count and it will give you the $CommitsSinceTag value which is strictly increasing like an SVN revision number. I think you're still missing the point. Users who install don't have git, all they have is the About box. The information there should be enough to allow them to locate a bug on Bugzilla and determine if their version has been fixed. It's not. But if they ask, it's relatively easy for somebody with git to be able to find out. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 2:06 PM, Evan Huus eapa...@gmail.com wrote:
On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
graham.blo...@trihedral.com wrote:
That doesn't help users who only install, not build as their copy of
Wireshark doesn't have a list of SHA (or does it?).
They only way I can think of resolving that is to refer to dates as they are
time-ordered (I hope).
Time still works; if it was submitted to master at noon on Monday then
presumably any automated build from after that point will include the
relevant change.
Alternatively, the automated build files have the name format:
Wireshark-$Platform-$Tag-$CommitsSinceTag-g$SHA.exe (e.g.
Wireshark-win32-1.11.3-1925-g0f73f79.exe)
So if you know the change was in SHA x (and the current latest tag is
y), you can run git rev-list y..x --count and it will give you the
$CommitsSinceTag value which is strictly increasing like an SVN
revision number.
You presumably meaning the person who committed the change rather than the
user who downloaded the automated build, as the user who downloaded the
automated build not only might not have a Git repository for Wireshark, they
might not even have Git.
Perhaps we should have a page on some wireshark.org where a user can enter some
identifier for an automated build and an SHA hash for a commit and find out
whether that build has that commit, and perhaps also say take me to the latest
automated build for {pick your target for binary builds} that has this commit
(or fail if there's no such build yet).
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 2:13 PM, Evan Huus eapa...@gmail.com wrote: It's not. But if they ask, it's relatively easy for somebody with git to be able to find out. Somebody with Git and the repository. That's why I suggested that they be able to ask some*thing* with Git and the repository, instead, so they don't have to find somebody with Git and the repository to ask. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 5:15 PM, Guy Harris g...@alum.mit.edu wrote:
Perhaps we should have a page on some wireshark.org where a user can enter
some identifier for an automated build and an SHA hash for a commit and find
out whether that build has that commit, and perhaps also say take me to the
latest automated build for {pick your target for binary builds} that has this
commit (or fail if there's no such build yet).
Googling around a bit for this issue - because other apps must have this same
problem and their users - shows people either creating a ton of tags, or
scripting with the rev-list count to generate sequential numbers in their
commits to master.
How did SVN deal with a rev number in older branches, when you either
backported a change from a newer release or committed a change only to the
older release? Did it use the same rev number, or give it a new one? (ie, was
it the same/shared numberspace?)
-hadriel
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan
hadriel.kap...@oracle.com wrote:
On Mar 11, 2014, at 5:15 PM, Guy Harris g...@alum.mit.edu wrote:
Perhaps we should have a page on some wireshark.org where a user can enter
some identifier for an automated build and an SHA hash for a commit and find
out whether that build has that commit, and perhaps also say take me to the
latest automated build for {pick your target for binary builds} that has
this commit (or fail if there's no such build yet).
Googling around a bit for this issue - because other apps must have this same
problem and their users - shows people either creating a ton of tags, or
scripting with the rev-list count to generate sequential numbers in their
commits to master.
How did SVN deal with a rev number in older branches, when you either
backported a change from a newer release or committed a change only to the
older release? Did it use the same rev number, or give it a new one? (ie,
was it the same/shared numberspace?)
It gave it a new one (just like backported git revs get new SHAs) but
that's not really the problem. The problem is that the user only knows
their build was at some particular SHA; they don't know whether the
SHA they're interested in came before or after it.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GIT tutorials (was: Re: Fix bug in GSM MAP, have problems with GIT)
On Mar 11, 2014, at 5:38 PM, Evan Huus eapa...@gmail.com wrote: On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: Googling around a bit for this issue - because other apps must have this same problem and their users - shows people either creating a ton of tags, or scripting with the rev-list count to generate sequential numbers in their commits to master. How did SVN deal with a rev number in older branches, when you either backported a change from a newer release or committed a change only to the older release? Did it use the same rev number, or give it a new one? (ie, was it the same/shared numberspace?) It gave it a new one (just like backported git revs get new SHAs) but that's not really the problem. The problem is that the user only knows their build was at some particular SHA; they don't know whether the SHA they're interested in came before or after it. No, but I was already jumping ahead to a possible (crazy) solution. :) Since SVN used a single number space but gave each branch's commits new numbers, you can create a new revision string that looks like tag:number, where tag is the branch tag and number is the rev-list count of origin HEAD for each branch. The tag keeps them unique per branch, and also quickly tells the user which release branch that change is in. Is there a way to have a hook script that only takes effect when committing into the master branches? (ie, only when you guys cherry-pick and commit a change to the real master/master-x.x repositories?) If so, you could create a script which gets invoked during the cherry-pick commit into master/master-x.x, which inserts this tag:number string into the commit message.[1] For example adds a Revision: 1.11:12345 to the end of the commit message, similar to the commit-msg Change-ID line. That way backporting also appends additional revision info lines to the commit message, and each one is unique/identifiable by the tag portion. Copy that tag:number into the cherry-pick message you guys post on gerrit reviews (or is that scripted too?). And lastly, when the buildbots build a new nightly or tagged release, have them use the rev-list count for the given branch being built, for the binary file name and about-page info in the build. -hadriel [1] making it an atomic operation might be tricky though - dunno anything about how git does that. Might want to have the number be stored in a git-controlled file, in each repository? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
