Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Let's also not forget that Git was originally invented by Linus Torvalds to manage the Linux kernel with thousands of contributors, commits, and branches being done every day. Although my projects are slightly below that complexity, Git does manage (barely) This is the fault of tools like SourceTree. Here is an example of Git moving away from a detached head: Again, they provide you with the necessary command template to prevent you from loosing track of your changes. I cannot stress enough how much better the command line interface is compared to any of the tools (at least the ones I have tried).
  3. Today
  4. I found gitExtensions to be very good too. http://gitextensions.github.io/. If you coming from HG, this maybe a good choice to try.
  5. That is expected. As I wrote previously, Git and Hg are very similar to each other in scope/functionality (but not in workflow details!). 5 years ago, people were saying that we should just pick one or the other and stick with it; we gained nothing from using both. Today, there is a benefit to learning Git: It gives us easier access to the plethora of code bases around the world, and it helps us move forward from incidents like Bitbucket's bombshell. You have just described Git (and SVN, according to @shoneill). The exact steps differ but the concepts are the same. Agreed. My analogy with an unsaved VI was a poor one, I realized. Unlike a power cut which is quite plausible, it is actually quite difficult to accidentally lose commits unless we ignore prompts/hints/warnings like the ones @LogMAN posted. Yes, Git could be made safer by automatically preserving "detached" branches and requiring the user to manually discard them, rather than automatically hiding them when the user moves away. I guess I've never encountered this issue in my 9 years of regular Git use because I habitually create a branch before making any new commits at an old point. This highlights the importance of running UX tests on people who aren't familiar with a product!
  6. Yesterday
  7. Correct me if I'm wrong, but you can also do all of that with SVN....
  8. Not really tried sourcetree enough to make an educated comparison. I really like the look and feel of GitKraken and am now invested in learning how to use it properly. Also, at the time I was super annoyed with Atlassian for the way they handled the sunsetting of Mercurial and was fed up with dealing with their snail-slow Bitbucket servers all the time so I just picked up my toys, set aside a week or so to move 30 repositories over and now am a happy Github koolaid drinker.
  9. THIS. Absolutely this. Misery loves company: please use GIT!
  10. GIT is that awful, in my opinion. I've screwed up many things years. I try not to use it as much as possible. The reason that GIT has taken over the SCC world is not because of its ease of comprehension or elegance of interface. It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.
  11. Thank you Rolf and Tim. This crash has seemed to happen exactly one time but maybe with enough logging I'll figure it out. My other option is to just convince people get rid of ZMQ completely for this application and use UDP or TCP connection. The application is just sending data to one server anyways so ZMQ is not really adding much functionality anyways
  12. Assuming you've tried both, what are some of the features you found useful over Sourcetree? At least at a glance they look pretty similar. GitKraken has the ability to add issues to the sidebar, which is nice. Unfortunately, it only seems to be available for Jira and their own Boards product, and I'm not really planning to use either... probably.
  13. This actually sums it up quite nicely ๐Ÿ˜‹
  14. Atlassian has comprehensive (and visual appealing) documentation on Git. https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet Unfortunately Git has a lot of commands, most of which you'll probably never use. I suggest you play around with it to get used to the workflow and be prepared for your daily job. Just don't do stuff like "git push -f" and you should be fine. You might find this worth reading: https://sqlite.org/whynotgit.html There you have it, your problem is not Git, it's the tools. Have you ever tried the command line? In my experience, there are many tools that work well with some aspects, but fail miserably at others. They only get you so far before you need some command line Voodoo to fix the "unfixable". Eventually you'll get used to the command line ๐Ÿคทโ€โ™‚๏ธ (I lost this battle a long time ago) This is the same reason why I abandoned SourceTree a few years back. Tools like that only give you access to a subset of instructions and they don't even provide ways to undo bad decisions. To be fair, you do actually get a big warning message (which nobody seems to read, including me): The command line version of this is much more helpful in my opinion, as it even teaches you some new commands. There is also no way to mistake it with the normal output.
  15. Sorry about that @LogMAN. It should be publicly visible now. Please try again and let me know: VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up
  16. Ah, "Reflog". Another tool to fix the problems caused by the other tools.
  17. @jksh thanks for the explanation. In every other VCS I have used I can pretty much arbitrarily move around the changesets without fear. All I did was roll back to check out some earlier code and my recent changes just "disappeared" from the client. That is very unexpected behaviour. Sure, I was able to get them back by looking up the commits using the reflog because they were not truly missing, but it is really strange behaviour to me. Not wanting to sidetrack the discussions, I now using Plastic SCM at work where I do Unity and C# dev and its really quite nice to use. Apparently it is based on git but made more for game devs.
  18. Doubtful. You went from Git from SVN, I'm coming from Hg. In Hg, if you want to go to an earlier commit, you just go to that commit. If you want to make changes, then you make a new branch coming off at that point. If you like those changes, you might merge that offshoot branch with the main one. I have yet to find anything in Git over Hg that is actually useful. I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.
  19. I switched from Subversion to Git many years ago and encountered quite a steep learning curve but it was well worth it in the end -- Not having to be connected to the server all the time was a great boon. I haven't used Mercurial much, but from what I read Hg and Git were supposed to be similar to each other (at least when compared to SVN or Perforce) Yes, your choice of client has a huge impact on your experience. I find GitHub Desktop far too limiting; I like the power of SourceTree but I wouldn't recommend it to newcomers of Git -- too much power and too many options can overwhelm. Having said that, SourceTree supports Mercurial too. Perhaps @drjdpowell can use SourceTree to create and manage a Mercurial project, and then repeat the same steps for a Git project? This might help you to see the parallels between the 2 technologies and learn Git faster. Every single commit in the Git history can be checked out. If you ask git to check out Branch X, your HEAD now points to the latest commit on Branch X. If you ask git to check out Commit Y, your HEAD now points to Commit Y and is now considered "detached" (because it is not attached to a specific branch). To avoid "detached HEAD state", all you have to do is specify a branch when you check out. I have a use-case for entering detached HEAD state: Suppose I've made many commits recently and then discover a bug in my code. I want to go back to an earlier snapshot of my code, so I check out a commit that I think is good. Voila, I'm now in detached HEAD state and I can run my old code for debugging. When my HEAD is detached, I think of it as working on an anonymous/unnamed branch (a bit like how I can edit and run an unsaved VI, but if my PC loses power the VI is gone) Don't let the terminology discourage you; your journey will be worth it. Happy coding!
  20. Try GitKraken, it is not free if you want to access private repos on GitHub (which I do) but I really like the interface and does everything I need apart from showing the reflog which I believe Fork does show.
  21. The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist. Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?
  22. The problems I've had have mostly been using SourceTree. I've started to just us TortoiseGit, but it is lacking compared with TortoiseHg that I used to use.
  23. I have recently embarked on this same journey and also found things to be way less intuitive than Hg. Which client are you using? I found GitHub desktop awful and am now using GitKraken which I really like. Just a few days ago I "lost" some work by rolling back to the "wrong" commit. I was able to get back my commit by reverting to the commit using the hash which can be found by running: git reflog I seem to get into a Detached head state quite often. No idea what I am doing wrong but have sort of figured out how to recover from it. Was not able to see the commits from another user for love or money. Turns out somehow the "upstream" on the remote (whatever this is) was not set correctly Anyway, stick with it my friend. The war is over and git has won...
  24. I've switched to Git from Mercurial recently, and my opinion of it gets worse and worse. The number of times I've gotten stuck trying to figure out how Git got screwed up and how to fix things is way too high. Mercurial had similar issues when I first learned it, but it was an order of magnitude less than Git. Git seems to make the simple unnecessarily complicated and non-intuitive, with any step wrong leaving you in a position of not being able to fix things. with horrible gobbledygook error messages and blank stares on my part. So I must be doing something wrong. What should I read up on to make Git less crap?
  25. Does anyone use Cyth SQLite Logger? In particular, does anyone use it with Actor Framework or DQMH or similar frameworks. This logger was written by me years ago and I use it often, but in Messenger-Library based applications. I would like to know if it works properly in those frameworks. It should, I think, as they use similar Async-Called VIs as Messenger Library (Cyth SQLite Logger identifies the Async-running "actor" that makes a log entry and records it).
  26. I've seen that with clients I have been working for on LabVIEW related projects. A new software development manager came in with a clear dislike for LabVIEW as it is only a play toy. The project was canceled and completely rebuild based on a "real" PLC instead of a NI realtime controller. The result was a system that had a lot less possibilities and a rather big delay in shipping the product. Obviously I didn't work on that "new" project and don't quite know if it was ever installed at the customer site. That said, we as company are reevaluating our use of LabVIEW currently. We have no plans to abandon it anytime soon, but other options are certainly not excluded from being used whenever it makes sense and there have been more and more cases that would have been solved in the past in LabVIEW without even thinking twice, but are currently seriously looked at to be done in other development platforms. And I know that this trend has been even stronger at many other companies in the last 5 years or so. My personal feeling is that the amount of questions in general has dropped. The decline is less visible on the NI fora, but all the other alternative fora including LAVA, have seen a rather steep decline in activity. Much of the activity on the NI fora tends to be pretty basic beginner problems or installation pericles and pretty little advanced topics. It could be because all the important questions for more advanced topics already have been tackled but more likely it is because the people who traditionally use LabVIEW for advanced usage are very busy in their work and the others are dabbling their feet in it, come with their beginner problems to the NI fora and then move on to something else rather than developing to the intermediate and advanced level of LabVIEW use. Also with exception of a few notable people, participation of NI employees in the fora seems nowadays almost non-existent and except the aforementioned notable exceptions, many times if an NI empoyee eventually reacts after a thread has stayed unanswered from other fora members for several days, doesn't go very much beyond the standard questions of "What LabVIEW version are you using? Have you made sure the power plug is attached?" and other such pretty unhelpful things. This is especially painful when the post in question clearly states a problem that is not specific to a certain version and pretty well known to anyone who would even bother to start up just about any LabVIEW version and try the thing mentioned! It sometimes makes me want to tell that blue eagle (รคah is that a greenie now?) to just shut up.
  1. Load more activity
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.