• GIT

    From Alterego@VERT/ALTERANT to Digital Man on Monday, September 02, 2019 12:42:15
    Hey DM,

    Have you considered switching to git? I'm just curious.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
    ...*

    ... A day for firm decisions!!!!! Or is it?

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From The Millionaire@VERT to Alterego on Sunday, September 01, 2019 20:36:56
    Hey DM,

    Have you considered switching to git? I'm just curious.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.
    ...*

    ... A day for firm decisions!!!!! Or is it?

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!

    A lot of source is going git lately I hear. It's supposed to be the new sourceforge.

    $ The Millionaire $

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Alterego on Sunday, September 01, 2019 21:22:02
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm

    Hey DM,

    Have you considered switching to git? I'm just curious.

    Yup.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.

    There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
    https://github.com/W8BSD/SBBSUnstable

    The reason I haven't switched the main development repo to git is the lack of a revision number in git. With CVS, I can ask you to read the $Id tag of a file or send the relevant log message and I can know *exactly* what revision of that file you have/are-running (and how old it is). With git, that's way more complicated.

    And with the high percentage of sysops that have/are-running some arbitrary snapshot from CVS, it's critical that I can easily find out what revision of what file(s) they're using.

    digital man

    This Is Spinal Tap quote #5:
    Nigel Tufnel: Authorities said... best leave it... unsolved.
    Norco, CA WX: 73.3F, 75.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Alterego@VERT/ALTERANT to Digital Man on Monday, September 02, 2019 15:30:14
    Re: GIT
    By: Digital Man to Alterego on Sun Sep 01 2019 09:22 pm

    There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:

    Hmm... a bit :)

    The reason I haven't switched the main development repo to git is the lack of a revision number in git. With CVS, I can ask you to read the $Id tag of a file or send the relevant log message and I can know
    *exactly* what revision of that file you have/are-running (and how old it is). With git, that's way more complicated.

    Shame, have you considered that the build could add the hash of the checkout?

    IE: sbbs -h could say "SBBS v3.17c abcd1234", where abcd1234 is the hash of the checkout used during the build? That way its quite easy to see what version everything is at, and what has changed since. (And to branch at the hash to reproduce the issue, fix, and merge it back into master).

    It wouldnt be "normal" that somebody just checks out a part of SBBS and uses it (even to compile) right? Ideally, if you updated a component (lets say binkit), you ideally should update everything else, especially if binkit is dependant on changes in other files as well?

    Git handles sub modules well as well, so you could be working on a sub module and committing changes, then updating master (to use the updated submodule) when its ready...

    Sorry, just thinking aloud - but I think it would be good to see git being used, only because my brain cells that remembered cvs have long gone - and I'd love to explore your code for some ideas I have... ;)
    ...*

    ... Old fishermen never die, they just smell that way.

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Alterego on Monday, September 02, 2019 01:11:21
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 03:30 pm

    Re: GIT
    By: Digital Man to Alterego on Sun Sep 01 2019 09:22 pm

    There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:

    Hmm... a bit :)

    The reason I haven't switched the main development repo to git is the lack of a revision number in git. With CVS, I can ask you to read the $Id tag of a file or send the relevant log message and I can know *exactly* what revision of that file you have/are-running (and how old it is). With git, that's way more complicated.

    Shame, have you considered that the build could add the hash of the checkout?

    Yup, done that with other projects.

    IE: sbbs -h could say "SBBS v3.17c abcd1234", where abcd1234 is the hash of the checkout used during the build?

    Uh huh.

    That way its quite easy to see what
    version everything is at, and what has changed since. (And to branch at the hash to reproduce the issue, fix, and merge it back into master).

    Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the revision you have of that file is newer than the revision which includes the fix for the problem being discussed.

    It wouldnt be "normal" that somebody just checks out a part of SBBS and uses it (even to compile) right?

    Quite frequent, yes.

    Ideally, if you updated a component (lets say
    binkit), you ideally should update everything else, especially if binkit is dependant on changes in other files as well?

    Ideally, but that rarely happens. And, the updated JS and .src files usually do not require the absolete latest executables built from the C/C++ code. It's quite frequent that sysop only update some of their files. Or even if they've updated their source files, maybe they forgot to rebuild them or they ran differnet binaries than the ones they last built. All kinds of scenarios.

    Git handles sub modules well as well, so you could be working on a sub module and committing changes, then updating master (to use the updated submodule) when its ready...

    I don't see how that's relevant to the revision number issue. Sub modules bring their sets of problems anyway.

    Sorry, just thinking aloud - but I think it would be good to see git being used, only because my brain cells that remembered cvs have long gone - and I'd love to explore your code for some ideas I have... ;)

    I'm not sure how git changes how you (or anyone else) can explore the code. The files are on your disk. If you want a web inteface to the source files, goto cvs.synchro.net.

    digital man

    Synchronet "Real Fact" #102:
    Synchronet added PETSCII (e.g. C64/C128) terminal support in October of 2018. Norco, CA WX: 73.5F, 74.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Alterego@VERT/ALTERANT to Digital Man on Monday, September 02, 2019 20:03:54
    Re: GIT
    By: Digital Man to Alterego on Mon Sep 02 2019 01:11 am

    Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the
    revision you have of that file is newer than the revision which includes the fix for the problem being discussed.

    I guess I dont understand your thinking. I've certainly used CVS before and currently use git, and I find supporting downstream users far easier with a git environment (and that use case is well used). IE: By knowing what hash or tag they've checked out, I know what their source enviroment looks (or should) look like.

    Ideally, but that rarely happens. And, the updated JS and .src files usually do not require the absolete latest executables built from the C/C++ code.
    It's quite frequent that sysop only update some of their files. Or even if they've updated their source files, maybe they forgot to rebuild them or they
    ran differnet binaries than the ones they last built. All kinds of scenarios.

    Fair enough, its certainly not what I do, nor encourage end users to do.

    Git handles sub modules well as well, so you could be working on a sub module and committing changes, then updating master (to use the updated
    submodule) when its ready...

    I don't see how that's relevant to the revision number issue. Sub modules bring their sets of problems anyway.

    Your right it isnt. And I wasnt trying to use it as a way to address it. But I do see that there are autonomous componets to SBBS (doors for example, cryptlib as another example), that could well develop on its own path and have dependancies on a past view of SBBS. I like how sub modules are referenced to
    a hash, so that when you do want to upgrade a submodule, its easy to view what has changed in it, that may require changes in the parent code base.

    I'm not sure how git changes how you (or anyone else) can explore the code. The files are on your disk. If you want a web inteface to the source files,
    goto cvs.synchro.net.

    I find it far easier (and quicker) to clone an enviroment, break off at a point in time, try stuff, commit, merge and completely abandon what I'm doing without impacting the work that another developer is doing. I also find it far easier to compare what they've done, to what I'm trying to do. (and no, I dont use a web based interface for any of it).

    As I said, I've forgotten most of my CVS commands and I would need to refer back to docs to try any of that, and it would be familiar to me if you ever switched to using git.

    Anyway, sounds like you are not likely to change to using git. No big deal, was just curious...
    ...*

    ... The House of Lords has a value.it is good evidence of life after death.

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Alterego on Monday, September 02, 2019 03:41:10
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 08:03 pm

    Re: GIT
    By: Digital Man to Alterego on Mon Sep 02 2019 01:11 am

    Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the revision you have of that file is newer than the revision which includes the fix for the problem being discussed.

    I guess I dont understand your thinking. I've certainly used CVS before and currently use git, and I find supporting downstream users far easier with a git environment (and that use case is well used). IE: By knowing what hash or tag they've checked out, I know what their source enviroment looks (or should) look like.

    I've done both too and in this case, I disagree. We use CVS as a distribution system. Many sysops just get updated .js files without updating their source. Or maybe they update their source, but they don't rebuild it right away. Or maybe they rebuild it, but they don't actually *run* the code they rebuild.

    I just want to know the revision of a specific module (e.g. newslink.js). And I can tell quickly and easily from that number whether it is newer or older (or the same) as another specific revision (e.g. one that includes some important change). I can't do that with a hash value.

    digital man

    This Is Spinal Tap quote #3:
    How much more black could this be? and the answer is none. None more black. Norco, CA WX: 75.3F, 66.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rampage@VERT/SESTAR to The Millionaire on Monday, September 02, 2019 07:43:09
    Re: GIT
    By: The Millionaire to Alterego on Sun Sep 01 2019 20:36:56


    Have you considered switching to git? I'm just curious.
    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.

    A lot of source is going git lately I hear. It's supposed to be the new sourceforge.

    sourceforge /uses/ git as do numerous other project hosting sites...


    )\/(ark

    ---
    Synchronet The SouthEast Star Mail HUB - SESTAR
  • From Rampage@VERT/SESTAR to Alterego on Monday, September 02, 2019 08:01:58
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 20:03:54


    Not really. It doesn't tell me what revision of exec/load/sbbsdefs.js you have (as a random example). And it doesn't tell me (or anyone else) if the
    revision you have of that file is newer than the revision which includes the fix for the problem being discussed.

    I guess I dont understand your thinking. I've certainly used CVS before and currently use git, and I find supporting downstream users far easier with a git environment (and that use case is well used). IE: By knowing what
    hash or tag they've checked out, I know what their source enviroment looks (or should) look like.

    you're thinking of the snapshot hash of the entire source tree... so what happens if i go in and manually grab the source to (eg) binkit by copying the source from the view window (copy'n'pasta) instead of using git to grab it? i've now got the/some source for binkit that is behind or beyond the current hash my system carries... if i have problems and you ask for the hash, i give it to you but my binkit sources do not match with the binkit sources in that hash... if there was an automated method to assign and increment a version number inside each file, you would know immediately where the problem resides... can you see the problem now?

    it may be possible to do this internal revision number for each file by scripting something in the hooks available in git when files/changes are uploaded to git... one of the projects i work with does similar but not for revision numbers... they check other things and either accept or reject the update/upload... i'd have to ask their git guru if assigning/updating internal revision numbers is possible via this method... that's why i started this paragraph with "may be" ;)


    )\/(ark

    ---
    Synchronet The SouthEast Star Mail HUB - SESTAR
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Monday, September 02, 2019 09:47:09
    El 2/9/19 a las 01:22, Digital Man escribi:
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm

    Hey DM,

    Have you considered switching to git? I'm just curious.

    Yup.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc.

    There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
    https://github.com/W8BSD/SBBSUnstable


    This repo from Deuce are update , but two weeks ago, lost sync.

    https://github.com/RealDeuce

    ---
    Synchronet Dock Sud BBS TLD 24 HS - http://bbs.docksud.com.ar - telnet://bbs.docksud.com.ar
  • From Alterego@VERT/ALTERANT to Rampage on Monday, September 02, 2019 23:34:24
    Re: GIT
    By: Rampage to Alterego on Mon Sep 02 2019 08:01 am

    you're thinking of the snapshot hash of the entire source tree... so what happens if i go in and manually grab the source to (eg) binkit by copying the
    source from the view window (copy'n'pasta) instead of using git to grab it? i've now got the/some source for binkit that is behind or beyond the current
    hash my system carries... if i have problems and you ask for the hash, i give it to you but my binkit sources do not match with the binkit sources in
    that hash... if there was an automated method to assign and increment a version number inside each file, you would know immediately where the problem
    resides... can you see the problem now?

    Actually, no not really.

    I understand what you are doing - you are cherry-picking individual files to use. I dont understand why you would only cherry pick individual files. (And therefore DM wants to know what version of a cherry-picked file you have got.)

    Is it to save rebuilding time? If nothing else changed, then there wouldnt be any rebuild (or it would be minimal). But if other things changed needing a rebuild, wouldnt you want to get those updates as well?

    If something is truely independant of the core code base - that is being developed (and consumed) at a different rate then the core, then it could be a submodule. Although, I'm not saying every individual cherrypickable file should be a sub module (I know that doesnt work for may reasons).

    Anyway, I think I get whats going on - and I know everybody does things a differently, for their different reasons - I respect that ...
    ...*

    ... Degeneration and evolution are not the same thing.

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From mark lewis@VERT to Alterego on Monday, September 02, 2019 10:57:38
    On 2019 Sep 02 23:34:24, you wrote to Rampage:

    you're thinking of the snapshot hash of the entire source tree... so
    what happens if i go in and manually grab the source to (eg) binkit
    by copying the source from the view window (copy'n'pasta) instead of
    using git to grab it? i've now got the/some source for binkit that is
    behind or beyond the current hash my system carries... if i have
    problems and you ask for the hash, i give it to you but my binkit
    sources do not match with the binkit sources in that hash... if there
    was an automated method to assign and increment a version number
    inside each file, you would know immediately where the problem
    resides... can you see the problem now?

    Actually, no not really.

    I understand what you are doing - you are cherry-picking individual files

    nope... not cherry picking like cherry picking commits...

    to use. I dont understand why you would only cherry pick individual
    files.

    because that's the only file believed needing updating...

    (And therefore DM wants to know what version of a cherry-picked file
    you have got.)

    exactly... this is quite common with sbbs... it happened recently with a system
    where all they needed to fix their FTN connectivity problem was to update their
    binkit and one or two other files... nothing else was needing to be updated...

    Is it to save rebuilding time? If nothing else changed, then there
    wouldnt be any rebuild (or it would be minimal). But if other things changed needing a rebuild, wouldnt you want to get those updates as
    well?

    js files aren't rebuilt... they are raw source used directly as they are...

    If something is truely independant of the core code base - that is
    being developed (and consumed) at a different rate then the core, then
    it could be a submodule. Although, I'm not saying every individual cherrypickable file should be a sub module (I know that doesnt work
    for may reasons).

    submodules are not the panacea they purport to be...

    Anyway, I think I get whats going on - and I know everybody does
    things a differently, for their different reasons - I respect that

    :)

    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set
    them free. But that only permitted other men with machines to enslave them.
    ... Please do not write in the space below this line; it is reserved for me. ---
    * Origin: (1:3634/12.73)
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Nightfox@VERT/DIGDIST to Alterego on Monday, September 02, 2019 11:37:02
    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm

    Have you considered switching to git? I'm just curious.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc. ...*

    My team at work just started using Git a couple years ago (we were using SVN before that). In some ways, I still feel like I'm getting used to git. My biggest frustration is still when I want to push up one of my commits and there are merge conflicts with other changes. From what I understand, I think the best way to deal with that is to do a 'git fetch' and a 'git rebase' and fix any merge conflicts with the rebase, and then amend any commits I currently have. But sometimes it seems like there are still problems. Sometimes when I do a 'git fetch' or 'git pull', it merges in another branch.. I'm sometimes unsure of the state of my local copy after that, so sometimes I've resorted to pulling a fresh copy of the repo/branch.

    Nightfox

    ---
    Synchronet Digital Distortion: digitaldistortionbbs.com
  • From Nightfox@VERT/DIGDIST to The Millionaire on Monday, September 02, 2019 11:38:00
    Re: GIT
    By: The Millionaire to Alterego on Sun Sep 01 2019 08:36 pm

    A lot of source is going git lately I hear. It's supposed to be the new sourceforge.

    Git itself is just a repository for files/source, rather than a central online service like Sourceforge. Maybe you're thinking of GitHub?

    Nightfox

    ---
    Synchronet Digital Distortion: digitaldistortionbbs.com
  • From Alterego@VERT/ALTERANT to Nightfox on Tuesday, September 03, 2019 08:29:36
    Re: GIT
    By: Nightfox to Alterego on Mon Sep 02 2019 11:37 am

    My team at work just started using Git a couple years ago (we were using SVN before that). In some ways, I still feel like I'm getting used to git. My biggest frustration is still when I want to push up
    one of my commits and there are merge conflicts with other changes. From what I understand, I think the best way to deal with that is to do a 'git fetch' and a 'git rebase' and fix any merge conflicts with
    the rebase, and then amend any commits I currently have. But sometimes it seems like there are still problems. Sometimes when I do a 'git fetch' or 'git pull', it merges in another branch.. I'm sometimes
    unsure of the state of my local copy after that, so sometimes I've resorted to pulling a fresh copy of the repo/branch.

    Do you work on your contributions in your own branch locally?

    IE: When I'm working on something, I break off from master (typically at the latest), and work away on what I'm doing. In fact, I may have a couple of branches on the go (starting at different branches of master), and I use stash a lot as well... I never push "my" branches upstream (unless somebody wants to see what I'm working on and potentially help).

    Then, when my contribution is complete, and I want to bring it back to master (to push upstream). I fetch the updated master, compare my branch to it, make any necessary adjustments, commit it, and then push it upstream. In the rare chance somebody pushed to master before I did, then obviously my push would fail - but I can refetch the current master, still compare it to my branch, and if necessariy, make adjustments, commit and push.

    Once I've commited to master and pushed it, my branch is ideally finished with and could be deleted...

    I dont think I have my head fully around all of git yet either (and I've been using it for a long time), but to independantly work on something and compare it to somebody else (or even a completly different project that shares a common source), without loosing the ability to keep the "remote" branches up to date, its works well for me.
    ...*

    ... Nothing matters very much, and very few things matter at all.

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Ragnarok on Monday, September 02, 2019 18:59:39
    Re: Re: GIT
    By: Ragnarok to Digital Man on Mon Sep 02 2019 09:47 am

    There's a Synchronet repo on github, but it seems to be out-of-sync with CVS now:
    https://github.com/W8BSD/SBBSUnstable


    This repo from Deuce are update , but two weeks ago, lost sync.

    https://github.com/RealDeuce

    Thanks for the correction!

    digital man

    Synchronet "Real Fact" #32:
    The second most prolific contributor to Synchronet is Stephen Hurd (Deuce). Norco, CA WX: 83.5F, 44.0% humidity, 15 mph ENE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Alterego on Monday, September 02, 2019 19:30:06
    Re: GIT
    By: Alterego to Rampage on Mon Sep 02 2019 11:34 pm

    Re: GIT
    By: Rampage to Alterego on Mon Sep 02 2019 08:01 am

    you're thinking of the snapshot hash of the entire source tree... so what happens if i go in and manually grab the source to (eg) binkit by copying the
    source from the view window (copy'n'pasta) instead of using git to grab it? i've now got the/some source for binkit that is behind or beyond the current
    hash my system carries... if i have problems and you ask for the hash, i give it to you but my binkit sources do not match with the binkit sources in
    that hash... if there was an automated method to assign and increment a version number inside each file, you would know immediately where the problem
    resides... can you see the problem now?

    Actually, no not really.

    I understand what you are doing - you are cherry-picking individual files to use. I dont understand why you would only cherry pick individual files. (And therefore DM wants to know what version of a cherry-picked file you have got.)

    Is it to save rebuilding time? If nothing else changed, then there wouldnt be any rebuild (or it would be minimal). But if other things changed needing a rebuild, wouldnt you want to get those updates as well?

    The majority of Synchronet sysops run the Windows versions which they do not rebuild themselves, so they really don't even need to bother updating the C/C++ source files (but they often do want the latest revision of others files). But I can (with CVS) ask them or even check for myself what revision of webservr.c or mailsrvr.c that they're running and know very easily if that revision includes some change of note (or not). With a hash, I don't get that. I'd have to find that hash in a git log and then compare its date against the date of hash of interest.

    With incrementing revision numbers, I can just say, hey you need rev 1.287 or later for that fix and it's obvious to everyone what that means. If I said you need rev EA9BC2F or later, that's not very helpful. Perhaps they *already* have a revision later than EA9BC2F, but how would they know? They wouldn't, again, without carefully examining a git log.

    digital man

    Synchronet "Real Fact" #54:
    The Synchronet source code consists of over 500,000 lines of C and C++.
    Norco, CA WX: 81.5F, 48.0% humidity, 9 mph E wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to Nightfox on Monday, September 02, 2019 19:45:07
    Re: GIT
    By: Nightfox to Alterego on Mon Sep 02 2019 11:37 am

    Re: GIT
    By: Alterego to Digital Man on Mon Sep 02 2019 12:42 pm

    Have you considered switching to git? I'm just curious.

    I'm a huge fan of git (used to use cvs a long time ago) and kinda like its flexibilty and its collabouration - especially when using it with things like github/gitlab, etc. ...*

    My team at work just started using Git a couple years ago (we were using SVN before that). In some ways, I still feel like I'm getting used to git. My biggest frustration is still when I want to push up one of my commits and there are merge conflicts with other changes. From what I understand, I think the best way to deal with that is to do a 'git fetch' and a 'git rebase' and fix any merge conflicts with the rebase, and then amend any commits I currently have. But sometimes it seems like there are still problems. Sometimes when I do a 'git fetch' or 'git pull', it merges in another branch.. I'm sometimes unsure of the state of my local copy after that, so sometimes I've resorted to pulling a fresh copy of the repo/branch.

    I feel ya. Even when think I have a good grasp of git, I sometimes get into states where I'm like: how'd that happen?

    And many times when trying to help junior co-workers, I'd be befuddled about how they got their local repo into the state its in.

    Here's some tips that've helped me with using git:

    1. "pull" before making any changes. Forgetting this step can lead to pain later.

    2. remember that the current branch is always the *target* of any operation (e.g. merge) and that your local git-tree can and usually does contain multiple branches. 'git branch -v' is your friend.

    3. "git stash [pop]" is incredibly useful when you forgot tip 1.

    4. When out-of-tree builds aren't possible, make sure your .gitignore file is excluding any/all output files or be judicious about your "git add"s.

    5. *Always* perform "git diff" before your adds/commits. Or use "git difftool" if you have one configured (e.g. a visual diff).

    6. Use "git commit -a" with caution (or don't use it at all).

    7. You can have multiple identities with git (e.g. your personal and work identies). These can be managed and quickly switched-between with the 'git-identity' plugin. Committing code while using the wrong identity can be an embarassment that is hard or impossible to wipe from the history books.

    8. Write your git commit messages like you would an email: the first line is subject (less than 80 chars), followed by a blank line, followed by a detailed description of the change(s). Although commit messages where the second line is not blank still work, much of git's command-line tools work better when it's a blank line.

    digital man

    Synchronet/BBS Terminology Definition #24:
    DTE = Data Terminal Equipment
    Norco, CA WX: 80.8F, 50.0% humidity, 9 mph ESE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Nightfox@VERT/DIGDIST to Alterego on Monday, September 02, 2019 19:23:40
    Re: GIT
    By: Alterego to Nightfox on Tue Sep 03 2019 08:29 am

    Do you work on your contributions in your own branch locally?

    No, not usually. Our team at work usually has a branch that everyone works from and contributes their patches to. But sometimes developers make their own branch for experimental stuff.

    Nightfox

    ---
    Synchronet Digital Distortion: digitaldistortionbbs.com
  • From Alterego@VERT/ALTERANT to Digital Man on Tuesday, September 03, 2019 13:26:38
    Re: GIT
    By: Digital Man to Alterego on Mon Sep 02 2019 07:30 pm

    The majority of Synchronet sysops run the Windows versions which they do not rebuild themselves, so they really don't even need to bother updating the C/C++ source files (but they often do want the latest
    revision of others files). But I can (with CVS) ask them or even check for myself what revision of webservr.c or mailsrvr.c that they're running and know very easily if that revision includes some change of
    note (or not). With a hash, I don't get that. I'd have to find that hash in a git log and then compare its date against the date of hash of interest.

    Do you mean, something like this:
    * What is the output of sbbs.exe -h => Answer: ec2e28
    * Rob thinks I did some stuff in 156166a that addressed a problem like you are reporting:

    https://github.com/RealDeuce/cvs-synchronet-src/compare/ec2e28...156166a

    Or, hmm, whats changed since then?

    https://github.com/RealDeuce/cvs-synchronet-src/compare/ec2e28...HEAD

    With incrementing revision numbers, I can just say, hey you need rev 1.287 or later for that fix and it's obvious to everyone what that means. If I said you need rev EA9BC2F or later, that's not very

    "Grab revision 156166a of websrvr.c, it addresses your problem."

    https://github.com/RealDeuce/cvs-synchronet-src/blob/156166/sbbs3/websrvr.c and press "Raw", or
    wget https://raw.githubusercontent.com/RealDeuce/cvs-synchronet-src/156166/sbbs3/websrvr.c, or
    git checkout 156166 sbbs3/websrvr.c

    helpful. Perhaps they *already* have a revision later than EA9BC2F, but how would they know? They wouldn't, again, without carefully examining a git log.

    I get that this is probably not that easy, but I would achieve it a couple of ways:

    * If the build said this is reversion ec2e28 - and I downloaded the prebuilt binaries, and output of "sbbs -?" could show SBBS v3.17c ec2e28
    * If I checked out the code myself, and built it myself, "git branch -v" tells me what my environment is.
    * If you told me to get revision 156166, thats recorded in a message somewhere

    Not trying to the poke the bear - I just think you can still answer your questions that you need answers to (even if users need to cherrypick individual files now and again).

    I'm sure there would be an answer to your questions using git, as well as you probably dont have any compelling reason to change from CVS. If it aint broke dont fix it right?
    ...*

    ... Psychologists only do it if they feel good about it

    ---
    Synchronet Alterant | an SBBS in Docker on Pi!
  • From Digital Man@VERT to Alterego on Monday, September 02, 2019 20:51:24
    Re: GIT
    By: Alterego to Digital Man on Tue Sep 03 2019 01:26 pm

    I'm sure there would be an answer to your questions using git, as well as you probably dont have any compelling reason to change from CVS. If it aint broke dont fix it right?

    Right. And there's a git repo you can use if you prefer: https://github.com/RealDeuce/cvs-synchronet-src

    digital man

    This Is Spinal Tap quote #34:
    We'd love to stand around and chat, but we've gotta sit down in the lobby Norco, CA WX: 77.7F, 61.0% humidity, 3 mph E wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Nightfox@VERT/DIGDIST to Digital Man on Tuesday, September 03, 2019 09:45:12
    Re: GIT
    By: Digital Man to Nightfox on Mon Sep 02 2019 07:45 pm

    I feel ya. Even when think I have a good grasp of git, I sometimes get into states where I'm like: how'd that happen?

    And many times when trying to help junior co-workers, I'd be befuddled about how they got their local repo into the state its in.

    Here's some tips that've helped me with using git:

    Thanks for the tips.

    Nightfox

    ---
    Synchronet Digital Distortion: digitaldistortionbbs.com