Re: [Wireshark-dev] GIT tutorials
On Mar 11, 2014, at 8:08 PM, Evan Huus wrote: > On Tue, Mar 11, 2014 at 7:12 PM, Hadriel Kaplan > wrote: >> >> Any way we could have the "v1.11.0-rc1-1917" portion automatically put into >> the gerrit review once it's been cherry-picked into master/master-x.x? >> >> Like if a script is currently generating the "Change has been successfully >> cherry-picked as ..." message, then have it append the 'git describe' output >> to that message? > > I don't understand how that would help end-users? They don't get the > full commit message, just the SHA... I'm assuming we would copy from that into the bugzilla comment when we close a ticket, similar to how "fixed in r2345" was done before. Basically it's a way to let me (a developer fixing a bug) know what to copy into the bugzilla ticket when I close it. Putting it in the commit means we can always find it later too, and I assume we'd get it in the gitweb views/logs and gerrit code review page too for that matter. I'm also assuming the main downloads page would indicate the full string for its releases, or at least that "1917" number, as the automated builds download page does today. (or in release notes/whatever) Of course to be useful, we need to change the version info shown by Wireshark/tshark to say "1917" where it currently says an unknown SVN rev number. So let's say a user finds a bug, they go look on bugzilla and find it's already fixed, and the resolved-fixed comment would say "Fixed in v1.10.5-rc1-1234-g3ddb100". They go check their local version, which is "1.10.6" so bigger than "v1.10.5" so they're good. Or else they have v1.10.5 in which case they check if their revision number is >= 1234. Or they have a different release altogether, in which case the "revision" number is just as meaningful as it was in SVN (which is to say, not much apparently). If the bug says "Fixed in v1.11.3-rc1-1234-g345f00b" they know they either need to get a wireshark 1.11.4, or a 1.11.3 of rc > 1, or a v1.11.3-rc1 of > 1234. If all else fails, they can ask on ask.wireshark.org, and someone looks up the g345f00b on code review, where it will (hopefully) have not only that "v1.11.3-rc1-1234-g345f00b" string, but also other versions if it was backported to. -hadriel ___ Sent via:Wireshark-dev mailing list 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
On Mar 11, 2014, at 6:42 PM, Gerald Combs wrote: > Would `git describe` suit your needs? > > $ git describe > v1.11.3-rc1-1917-gd3b8084 > > The current tag is v1.11.3-rc1. There are 1917 commits between > v1.11.3-rc1 and gd3b8084. > > $ git describe --match v1.11.0-rc1 > v1.11.0-rc1-5874-gd3b8084 > > There have been 5874 commits since v1.11.0-rc1 was tagged. Yup. Any way we could have the "v1.11.0-rc1-1917" portion automatically put into the gerrit review once it's been cherry-picked into master/master-x.x? Like if a script is currently generating the "Change has been successfully cherry-picked as ..." message, then have it append the 'git describe' output to that message? -hadriel ___ Sent via:Wireshark-dev mailing list 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
On Tue, Mar 11, 2014 at 7:12 PM, Hadriel Kaplan wrote: > > On Mar 11, 2014, at 6:42 PM, Gerald Combs wrote: > >> Would `git describe` suit your needs? >> >> $ git describe >> v1.11.3-rc1-1917-gd3b8084 >> >> The current tag is v1.11.3-rc1. There are 1917 commits between >> v1.11.3-rc1 and gd3b8084. >> >> $ git describe --match v1.11.0-rc1 >> v1.11.0-rc1-5874-gd3b8084 >> >> There have been 5874 commits since v1.11.0-rc1 was tagged. > > Yup. > > Any way we could have the "v1.11.0-rc1-1917" portion automatically put into > the gerrit review once it's been cherry-picked into master/master-x.x? > > Like if a script is currently generating the "Change has been successfully > cherry-picked as ..." message, then have it append the 'git describe' output > to that message? > > -hadriel I don't understand how that would help end-users? They don't get the full commit message, just the SHA... ___ Sent via:Wireshark-dev mailing list 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
On 3/11/14 3:32 PM, Hadriel Kaplan wrote: > > On Mar 11, 2014, at 5:38 PM, Evan Huus wrote: > >> On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan >> 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 > ":", where is the branch tag and is the rev-list > count of origin HEAD for each branch. The keeps them unique per > branch, and also quickly tells the user which release branch that change is > in. Would `git describe` suit your needs? $ git describe v1.11.3-rc1-1917-gd3b8084 The current tag is v1.11.3-rc1. There are 1917 commits between v1.11.3-rc1 and gd3b8084. $ git describe --match v1.11.0-rc1 v1.11.0-rc1-5874-gd3b8084 There have been 5874 commits since v1.11.0-rc1 was tagged. ___ Sent via:Wireshark-dev mailing list 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 wrote: > On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan > 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 ":", where is the branch tag and is the rev-list count of origin HEAD for each branch. The 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 ":" 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 portion. Copy that ":" 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 be stored in a git-controlled file, in each repository? ___ Sent via:Wireshark-dev mailing list 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
wrote:
>
> On Mar 11, 2014, at 5:15 PM, Guy Harris 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
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 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
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 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 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 wrote:
> On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice
> 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
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 wrote: > On 11 March 2014 21:06, Evan Huus wrote: >> >> On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice >> wrote: >> > On 11 March 2014 20:50, Evan Huus wrote: >> >> >> >> On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice >> >> wrote: >> >> > On 11 March 2014 20:35, Evan Huus wrote: >> >> >> >> >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall >> >> >> 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 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 wrote: > On Tue, Mar 11, 2014 at 4:58 PM, Graham Bloice > wrote: > > On 11 March 2014 20:50, Evan Huus wrote: > >> > >> On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice > >> wrote: > >> > On 11 March 2014 20:35, Evan Huus wrote: > >> >> > >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall > 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 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 wrote: > On 11 March 2014 20:50, Evan Huus wrote: >> >> On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice >> wrote: >> > On 11 March 2014 20:35, Evan Huus wrote: >> >> >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall 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 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 wrote: > > On Mar 11, 2014, at 1:42 PM, Graham Bloice > 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 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 wrote: > On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice > wrote: > > On 11 March 2014 20:35, Evan Huus wrote: > >> > >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall 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 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 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 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 wrote: > On 11 March 2014 20:35, Evan Huus wrote: >> >> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall 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 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 wrote: > > On Mar 11, 2014, at 1:35 PM, Evan Huus 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 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 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 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 wrote: > On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall 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 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 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 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 wrote: > On Tue, Mar 11, 2014 at 6:47 PM, Hadriel Kaplan > 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 > 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 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
On 3/11/2014 1:47 PM, Hadriel Kaplan wrote: On Mar 11, 2014, at 1:18 PM, Christopher Maynard 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. :) If you want to undo a (non-pushed) commit other than at HEAD, you'll need to search the web for a solution. (I don't believe Pro Git covers that case). What I found; http://sethrobertson.github.io/GitFixUm/fixup.html ___ Sent via:Wireshark-dev mailing list 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 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 Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[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 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 Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
