5 ms·

To be fair, with git, specifically, it's a good idea to at least clone for backup before things like major merges. There are lots of horror stories from people

by yosefk 3y ago

To be fair, with git, specifically, it's a good idea to at least clone for backup before things like major merges. There are lots of horror stories from people losing work to git workflow issues and I'd rather be ridiculed as an idiot who is afraid of "his tools" (as if I have anything like a choice when using git) and won't learn them properly than lose work thanks to a belief that this thing behaves in a way which can actually be learned and followed safely. A special case of this is git rebase after which you "can" access the original history in some obscure way until it's garbage-collected; or you could clone the repo before the merge and then you can access the original history straightforwardly and you decide when to garbage-collect it by deleting that repo.

theptip 3y ago
Git is a lot less scary when you understand the reflog; commit or stash your local changes and then you can rebase without fear of losing anything. (As a bonus tip, place “mybranch.bak” branches as pointers to your pre-rebase commit sha to avoid having to dig around in the reflog at all.) I would never ridicule anyone for your approach, just gently encourage them to spend a few mins to grok the ‘git reflog’ command.
- ansgri 3y ago
  Then submodules enter the picture. I’m comfortable with reflog, but haven’t fully grokked submodules yet, easier to reclone.
deleted 3y ago
[deleted]
jonathanlydall 3y ago
If you’re not super comfortable with Git, before rebasing, simply: - Commit any pending changes. - Make a git tag at your current head (any name is fine, even gibberish). If anything “goes wrong” you can rollback by simply doing reset hard to the tagged commit. Once done, delete the tag. Making a complete “backup clone” is a complete waste of time and disk space.
- ekimehtor 3y ago
  Isn't the whole purpose of GIT Version Control? In other words to prevent work loss occurring from mergers and/or updates? Maybe I'm confusing GitHub with GIT? PS I want to set up a server for a couple of domain names I recently acquired, it has been many years so I'm not exactly sure if this is even practical anymore. Way back when I used to distribution based off of CENT OS called SME server, is it still common place to use a all in one distribution like that? Or is it better to just install my preferred flavour of Linux and each package separately?
  - jonathanlydall 3y ago
    Git does source code management. The two primary source code management activities developers use are versioning of source code (tracking changes which happened over time) and the other being synchronisation of code with other developers. One of Git’s differentiating strengths is it being decentralised, allowing you to do many operations in isolation locally without a central server being involved. You can then synchronise your local repository with an arbitrary number of other copies of it which may be remote, but you may need to rebase or merge in order to integrate your changes with those of other developers. Git is more like a local database (it even allows multiple local checkouts against a single common “database”) and it only occasionally “deletes” old “garbage”. Anything you do locally in Git is atomic and can always be rolled back (provided garbage collection hasn’t yet been performed). Although I’m comfortable enough with using the reflog to rollback changes (I’m also skilled enough in git I haven’t needed to in many years), it’s not very user friendly, it’s essentially like sifting through trash, you’ll eventually be able to find what you lost (provided it wasn’t lost too long ago), but you may have to dig around a bit. Hence my suggestion of tagging first, makes it easy to find it again if needed. I have very limited Linux experience and have no recommendations on your other question.
    - ekimehtor 3y ago
      Thank you for the well detailed response to my question. I'm currently working on returning to the CS Field due to a devastating and career ending injury. The specific Field I'm interested in his programming the interface between hardware such as robotics and user interfaces. So much has changed over the past decade I feel like I'm having to start all over and relearn everything to do with programming! And on top of that I have to also relearn how to live as a quadriplegic! Thank goodness for the Internet and it's incredible amount of free knowledge available these days!

by yosefk 3y ago

theptip 3y ago

Git is a lot less scary when you understand the reflog; commit or stash your local changes and then you can rebase without fear of losing anything. (As a bonus tip, place “mybranch.bak” branches as pointers to your pre-rebase commit sha to avoid having to dig around in the reflog at all.) I would never ridicule anyone for your approach, just gently encourage them to spend a few mins to grok the ‘git reflog’ command.

ansgri 3y ago
Then submodules enter the picture. I’m comfortable with reflog, but haven’t fully grokked submodules yet, easier to reclone.

deleted 3y ago

[deleted]

jonathanlydall 3y ago

If you’re not super comfortable with Git, before rebasing, simply: - Commit any pending changes. - Make a git tag at your current head (any name is fine, even gibberish). If anything “goes wrong” you can rollback by simply doing reset hard to the tagged commit. Once done, delete the tag. Making a complete “backup clone” is a complete waste of time and disk space.

ekimehtor 3y ago
Isn't the whole purpose of GIT Version Control? In other words to prevent work loss occurring from mergers and/or updates? Maybe I'm confusing GitHub with GIT? PS I want to set up a server for a couple of domain names I recently acquired, it has been many years so I'm not exactly sure if this is even practical anymore. Way back when I used to distribution based off of CENT OS called SME server, is it still common place to use a all in one distribution like that? Or is it better to just install my preferred flavour of Linux and each package separately?
- jonathanlydall 3y ago
  Git does source code management. The two primary source code management activities developers use are versioning of source code (tracking changes which happened over time) and the other being synchronisation of code with other developers. One of Git’s differentiating strengths is it being decentralised, allowing you to do many operations in isolation locally without a central server being involved. You can then synchronise your local repository with an arbitrary number of other copies of it which may be remote, but you may need to rebase or merge in order to integrate your changes with those of other developers. Git is more like a local database (it even allows multiple local checkouts against a single common “database”) and it only occasionally “deletes” old “garbage”. Anything you do locally in Git is atomic and can always be rolled back (provided garbage collection hasn’t yet been performed). Although I’m comfortable enough with using the reflog to rollback changes (I’m also skilled enough in git I haven’t needed to in many years), it’s not very user friendly, it’s essentially like sifting through trash, you’ll eventually be able to find what you lost (provided it wasn’t lost too long ago), but you may have to dig around a bit. Hence my suggestion of tagging first, makes it easy to find it again if needed. I have very limited Linux experience and have no recommendations on your other question.
  - ekimehtor 3y ago
    Thank you for the well detailed response to my question. I'm currently working on returning to the CS Field due to a devastating and career ending injury. The specific Field I'm interested in his programming the interface between hardware such as robotics and user interfaces. So much has changed over the past decade I feel like I'm having to start all over and relearn everything to do with programming! And on top of that I have to also relearn how to live as a quadriplegic! Thank goodness for the Internet and it's incredible amount of free knowledge available these days!