That wasn't what happened to me. Here are the steps I took and the outcome:
1. Git pull to update my local copy.
2. Make changes to 4 files.
3. Stash push.
4. Pull to get latest repo changes.
5. Stash pop.
6. Commit - 4 files changed.
7. Push - dozens of files changed.
!!!???
8. Check commit log - 4 files changed.
Why did my push change dozens of files I didn't touch? Basically,
several days of other people's work were reverted by my push.
My local copy says I changed only 4 files, but a diff of the repo before
and after my push shows that many more files were changed. Even the Git
gurus couldn't figure that out. Meanwhile, the unintended changes had to
be fixed by hand.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 1:12 AM, Adam Heath wrote:
I used to be in the same boat; in the early days, I would blame git for
losing my work. "Damn you frigging piece of software!"
However, I also realized that the linux-kernel was using it to do much
more complex things than I was, so I toiled on. It took me a long time,
but I was finally able to figure out how to make use of git's features.
The main thing that keeps you from losing work, is to commit
*everything* to git. If you leave *anything* in your $working_tree, not
committed, then yes, sometimes things get confused. But once you have
everything committed to git, there are certain things that git helps you
with, with regard to keeping copies of stuff around.
==
# git config --global rerere.enabled true
# (echo adfadsfasdf; date) > new-file
# git branch before-new-file
# git add new-file
# git commit -m "This is my cool new file, yipee!"
# git log
# git checkout before-new-file
# git branch -f master before-new-file
# git checkout master
# ls new-file # hmm, where did it go?
# git reflog # hmm, seems to show the commit from above
# git log trunk # commit is gone
# git log trunk@{1} # this shows the commit, and the file
==
This is just one of the powerful features that git has. I have rerere
enabled locally, but don't use it often. I enabled it long ago, because
I saw that it keeps copies of all my rebasing and branching, so that I
can feel safer about having this safety net.
Also, I when back in time, and found an older copy of the previous ofbiz
svn tree, and "underlayed" it into the current git-svn checkout, so I
have git history going all the way back to 2003.
On 04/20/2015 02:53 AM, Adrian Crum wrote:
I don't agree that "all major contributors are using git."
Personally, I find Git to be an overly complicated solution to a
simple problem. It frequently does bizarre things that no one
understands, and you are left with things being mysteriously reverted
for unknown reasons.
This isn't a -1 vote though. I'm just making it clear that I will be
dragged kicking and screaming into using it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 5:38 AM, Hans Bakker wrote:
As discussed at apachecon in Austin, i propose to switch from svn to git
for the ofbiz repository. The main reason being that all major
contributors are using git and contributions are cumbersome, further,
git allows for better branching and merging.
Regards,
Hans
