591–600 of 821 posts
Earlier quoted context omitted.
Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?
git fetch && git rebase origin/master, which is equivalent to git pull --rebase origin master, requires your worktree to be clean, so you must either commit or stash if you have any local changes.
git config rebase.autoStash trueThe underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
This is why I use Git Kraken. It abstracts away all the nonsense and gives me a lovely interface to work with my repos in a user-friendly way.
Earlier quoted context omitted.
That's just for compression. Commits aren't diffs, and when you checkout stuff, git doesn't do diffs to give you the working directory at that point. See https://stackoverflow.com/a/25028688/8272371 for detailed explanation.
> See https://stackoverflow.com/a/25028688/8272371 for detailed explanation. There is a disconnect somewhere. The linked answer says: > Now, git is different. Git stores references to complete blobs and this means that with git, only one commit is sufficient to recreate the codebase at that point in time . Git does not need to look up information from past revisions to create a snapshot. > So if that is the case, the…
Initially I had thought one page would be enough. But as I started, it went on and on. Still there is much more. At a point I had to stop.
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
I disagree on GitHub Desktop. The whole point of the UI is so that your workflow is simplified without having to understand the exact inner workings of it all. GHDesktop’s simplicity means that most of time I don’t have to call 4 commands to just check out a new repository or PR because one click runs all those 4 commands and more. As simple as it is, lately I rarely have to use the CLI (which however I still use bec…
This sounds ominious.
“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217
While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…
Well why didn't you just say so!
Also—I'm a language guy. Picking up languages, reading in other languages, just "clicks" for me. But math? Pffft. Forget it. I barely scraped myself out of college with my CS degree intact.
I learned Russian and Spanish just for fun!
My theory is that git is learned like a language and retained like a language. Tools like "GitKraken" are just "Duolingo" for your brain. They don't replace immersion learning when the stakes are high. (Not claiming this is the "best" way to learn, but boy is it effective)
Anyway.. I've never really struggled with git, nor with it's advanced notations. But algorithms? Hard, math-related thinking? That's an every day struggle. Perhaps the author's opinion is geared from the perspective of more functionally-paradigmed thinking?
Earlier quoted context omitted.
Based on my experience - most teams will get by with ivanhoe's list. You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps. There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.
As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…
Earlier quoted context omitted.
SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. In your list of shout commands I don't see anything that could be used for merging? I guess the "language" of git could be tweaked to make it more consistent, but otherwise the problems it…
> It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. select ... as of timestamp; > In your list of shout commands I don't see anything that could be used for merging? I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better…
Based on how SQL and C/C++ faired in these kinds of processes we could have a standard abstraction layer in perhaps 10-15 years ...
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
> Resisting GUI's is not a good idea. Explain why. Within our lifetimes, an interaction most users have with a computer could be just thinking about something to cause an action. I don't want to have to see a GUI in my brain to do that. Similarly, not everyone likes having to use what is traditionally called a GUI. For git, I prefer the CLI, though I use some helpers for completion, I have some scripts I wrote to sho…
Thats why, not everyone prefer CLI, if you are the one who learn better with GUI then resisting GUI's is not a good idea