|
I don't have any issues with it.
This book[^] may be of use to you. You can download it for free from there.
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
Brisingr Aerowing wrote: What do you get when you cross a joke with a rhetorical question?
An angry joke, rhetorically speaking of course?
|
|
|
|
|
Nagy Vilmos wrote: Oh Jeez, how do I hate thee? Let me count the ways.
I completely agree.
"git branch" will show all your local repo branches, the starred one is your current one.
Find someone that's an expert (or use your google fu, which is what I end up doing.) "git reset --hard" quickly became my most common command after fubar'ing my local branches more than I can tell you.
Are you using a GUI? There's a couple good ones out there, but even they lack. Just yesterday I had to create a new branch from a specific SHA point on an existing branch. My GUI does not support that action so I had to do it from the command line (after looking up how.) 
I'm beginning to see the "power" of it, creating local branches and doing your work locally (and disconnected even) and having it track my changes. The problem is, merging of branches sucks. Git will often report a merge conflict when there is none (other than perhaps whitespaces replaced with tabs or some such foolery) and often enough screwing up the merge, which you discover later.
And I absolutely LOATHE the <<<< ==== >>>>> markup - I never understand which is mine and which is theirs, and the word "HEAD" or "MASTER" doesn't help, I have no idea who the master head is. Well, at least with regards to Git! 
Marc
|
|
|
|
|
We have kind of abandoned branching because it looks and feels like stuff vanishes.
Programmers work with files not directory structures, Linus.
|
|
|
|
|
We have the same problem but unfortunately haven't taken any action yet. We have at least one solid example of an entire commit's code that has disappeared... 
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
|
|
|
|
|
MarkTJohnson wrote: We have kind of abandoned branching because it looks and feels like stuff vanishes.
 Branching is the cornerstone of Git (and actually any VCS.) If you don't understand the minimum of how to create, switch, pull and push branches in Git, you shouldn't be using Git. Even with SVN, it's standard to create "dev, test, and prod" branches at a minimum.
I'd strongly suggest that your team takes a step back and figures out at least that much of the basics of Git.
Marc
|
|
|
|
|
Trust me, if I didn't have to use it I wouldn't.
PVCS was wonderful. I could lock the file I was working on and know my changes would go in. If someone had a file I needed locked then I knew I could work on some other item in my queue but we wouldn't be stepping on each other's code.
|
|
|
|
|
MarkTJohnson wrote: I could lock the file I was working on and know my changes would go in. If someone had a file I needed locked
Ew. I hated locking files. I thought it was a huge improvement to work with something like SVN that didn't require file locking, and was one of the reasons I never adopted TFS because in its early days, it required file locking. Inevitably, someone would leave a file locked at the end of the day and was nowhere to be found.
Marc
|
|
|
|
|
Not to mention locking a whole bunch of files, and then leaving the company!
I really disliked PVCS... almost as much as CMS on the VAX.
Cheers,
Mike Fidler
|
|
|
|
|
"someone would leave a file locked at the end of the day and was nowhere to be found"
Same happened in my org, someone left entire directory (containing a big project) locked (reserved checked-out) in ClearCase on his last working day and we had to copy the dir with dir_new 
I really hate ClearCase, when it take 5 seconds just to show the diff. Git is fast.
|
|
|
|
|
MarkTJohnson wrote: I could lock the file I was working on and know my changes would go in. If someone had a file I needed locked then I knew I could work on some other item in my queue but we wouldn't be stepping on each other's code.
If you have that problem except very rarely then it isn't a problem with the source control system. It is a problem with the design, implementation and/or the way tasks are allocated.
|
|
|
|
|
Branching is evil and should be avoided. It's a sign of a flawed process.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Branching is evil and should be avoided. It's a sign of a flawed process.
Why? I'm on the fence (having seen the usefulness of it in Git), but want to know your reasons.
Marc
|
|
|
|
|
Marc Clifton wrote: but want to know your reasons.
Best I can remember he claims that every production delivery is perfect so he never needs to make an emergency fix into a production release.
|
|
|
|
|
PIEBALDconsult wrote: Branching is evil and should be avoided. It's a sign of a flawed process.
The fact that you don't like it and that you claim that you deliver perfect code into production doesn't mean that the rest of the world doesn't need it nor that they shouldn't have it.
|
|
|
|
|
Well, they want back to the first feature of source control : backup !
I definitely need to write that article about it...
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
Not sure what you are stating but just to be clear - source control is not a back up system.
|
|
|
|
|
Hear hear!
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Preach it brother and all the rest who have posted!
I've had something happen with "that thing" that none of the "experts"/acolytes where I work could explain why it happened.
In our repository there are many directories. I was working on some files in directory A(name changed for its protection and simplicity). One of my coworkers was working on files in directory H. For the record, I didn't even know about directory H. Our files were completely disjoint. I go to commit my files by creating the commit, marking which files I want to commit, entering the commit label, etc. While doing this I see I am behind by one commit so I dutifully do the Pull. The coworker's files come down to directory H. Git then creates, on its own mind you, a second Push commit for me to merge the files I just pulled, the ones from directory H which I knew nothing about until the pull, back into the repository.
I saw this one other time but the behavior seems to be random. Yes, I have contacted GitHub and they are looking at it.
|
|
|
|
|
I never got into Git because the name is so stupid.
I'm tired of stupid names for technology.
I'm relieved that it sucks - now I can allow my curiosity die and think of it no more.
|
|
|
|
|
MehGerbil wrote: I never got into Git because the name is so stupid.
... says MehGerbil... 
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
*moves Rage over to the 'not nice' column*
|
|
|
|
|
Never tried it. No plans to try it. Using TFS at work and at least it's a step up from Subversion.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Er, no.
Regards,
Rob Philpott.
|
|
|
|
|
I cannot agree with that. I've been using TFS for the past 6 mths, and while I found it to be great Application Development Lifecycle tool, when it comes to the source control, SVN is far superior IMHO.
Initially I thought it is just a matter of getting used to the tool and I should give it a chance. After months of experience, I still reckon that common things like branching, merging, blaming, comparing revisions (changesets) or even committing is simpler and more intuitive in SVN.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
