Git driving me crazy...
-
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
-
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
Albert Holguin wrote:
Don't get me started with hash values being used as commit identifiers.
1CFD67F65A3CBB0AC352229058BE3DB3E988E1D13511FD14A2A804A3625BEE33 ?
Jeremy Falcon
-
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
I completely agree. I may (very likely) be a dinosaur, but the particular use of git at one customer has me thinking of leaving.
TTFN - Kent
-
I completely agree. I may (very likely) be a dinosaur, but the particular use of git at one customer has me thinking of leaving.
TTFN - Kent
I believe the git developers have been quoted as saying their approach was, "if in doubt, do the opposite of what was done in SVN"... it seems like an absolutely idiotic approach to something. Instead of learning from the mistakes in the past, you're bound to invent new mistakes... that's what I see in git, completely new mistakes (innovative mistakes in design? ;P ).
-
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
Albert Holguin wrote:
Don't get me started with hash values being used as commit identifiers
First they tried to use commit comments, but then they saw yours :rolleyes: Ain't it weird? It was hacked together by a crazy egomaniac in an I'll-show-you all-nighter, so get in contact with the crazy egomanic I'll-show-you side of yours, and you'll be fine. Here's the (at this point practically required) "Don't do that, then" - advise:
git fetchto update your local repo without making any other changes, thengit mergeorgit rebaseto integrate your changes. If the merge/rebase goes bonkers, you can always go back to "before limbo". Srsly: Find a workflow that works. I found it pretty awkward that virtually every operation requires at least two commands, but you get used to it, then yo uget hooked on it. -
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
I totally agree. I hate Git. I'll take SVN over Git any day! X|
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time -
We've been using git at work and after a few months of using it... it still drives me a bit mad. For example: git pull origin branch Should in theory be a specialized version of: git pull ...yet you end up in a weird limbo (now thinks your local is ahead of origin/branch) because the tracking pointer somehow doesn't get updated when you specify the branch (it does with the generic "git pull"). Anyone deal with git regularly? I keep finding some of these little inconsistencies that are driving me mad. I may just be partial to SVN since I used that for years but it seems like everything is overly complex for no good reason in git. Don't get me started with hash values being used as commit identifiers. :mad:
What drives me mad about git is that you can't get a previous version of a single file pulled down into a separate directory to be able to look at the old code and the new code at the same time(or I haven't found the way at least). Comparing versions of files is sometimes very helpful in figuring out the bug. Much rather prefer source control systems that work on files not directory structures like SubVersion or heaven forbid old school, file locking PVCS. With file locking I know no one can mess with my work and I know who I need to talk to in case the file I want is locked. source code CONTROL system.
-
What drives me mad about git is that you can't get a previous version of a single file pulled down into a separate directory to be able to look at the old code and the new code at the same time(or I haven't found the way at least). Comparing versions of files is sometimes very helpful in figuring out the bug. Much rather prefer source control systems that work on files not directory structures like SubVersion or heaven forbid old school, file locking PVCS. With file locking I know no one can mess with my work and I know who I need to talk to in case the file I want is locked. source code CONTROL system.
MarkTJohnson wrote:
What drives me mad about git is that you can't get a previous version of a single file pulled down into a separate directory to be able to look at the old code and the new code at the same time(
We use ToroiseGit and it's trivial to Show Log, click the commit, right click the file that was changed and compare with the current. (However this only gives you a quick shortcut to viewing files changed in a given commit, so some hunting will be required, but there is a search feature in the TortoiseGit Log window)
cheers Chris Maunder
-
Albert Holguin wrote:
Don't get me started with hash values being used as commit identifiers
First they tried to use commit comments, but then they saw yours :rolleyes: Ain't it weird? It was hacked together by a crazy egomaniac in an I'll-show-you all-nighter, so get in contact with the crazy egomanic I'll-show-you side of yours, and you'll be fine. Here's the (at this point practically required) "Don't do that, then" - advise:
git fetchto update your local repo without making any other changes, thengit mergeorgit rebaseto integrate your changes. If the merge/rebase goes bonkers, you can always go back to "before limbo". Srsly: Find a workflow that works. I found it pretty awkward that virtually every operation requires at least two commands, but you get used to it, then yo uget hooked on it.peterchen wrote:
I found it pretty awkward that virtually every operation requires at least two commands
That's where the git pull is supposed to come in... but when
git pull <origin> <branch>gives you a different result thangit pull.... it's just another hardly documented "feature". By the way, I was doing the pull instead of the fetch/merge because it was for a repo that I hadn't changed locally, so I was just trying to sync with the origin.