Dear Thomas,
thank you very much for your reply!
I know it was a long post, and I very much appreciate your having worked
through it.
Am 2012-10-07 23:42, schrieb Thomas Ferris Nicolaisen:
It is indeed a large post and hard to read out the question(s) in there. In the
middle
part, you
Hi all,
as pointed out by Thomas, my original description of our problem and question was too verbose
and cluttered, so here is another attempt that is shorter and more to the point:
We have a Subversion repository with this layout:
cafu/
trunk/
branches/
tags/
Hi Thomas,
Am 09.10.2012 09:35, schrieb Thomas Ferris Nicolaisen:
So, if you want to make an upgrade of for example lua, you first download and
unzip it into
/vendor/ExtLibs/lua/, make some adaptions, and then merge it into trunk and any
other branch
where you want to perform the upgrade.
Hi Thomas,
Am 2012-10-09 12:35, schrieb Thomas Ferris Nicolaisen:
A branch in Git is uusally a branch of *what is the main contents of the
repository*,
not some arbitrary content. As I said above, submodules were invented for this
purpose,
to avoid filling up your own repositories with
Am 2012-10-10 08:02, schrieb Thomas Ferris Nicolaisen:
One repo should have one versioning scheme. Think about tagging. You want to
identify
versions of lua 1.0, 1.1, and so on. If you keep a lot of products in one
vendor
repo, it will be filled with tags of different versioning schemes like
Hi Damien,
Am 2012-10-10 01:10, schrieb Damien Robert:
if I have understood your problem correctly, it looks like the git subtree
script could help you a lot.
[...]
Unfortunately, the above proposition will only help you track vendor
branches after you have done the conversion, but not in the
Hi all,
thanks to the great help of Thomas and Damien, I've been able to complete our conversion
from Subversion to Git successfully.
For possible future readers (including myself, in case I cannot remember the next time
;-) ), I've written down all the steps and considerations that
Hi all,
we have a repository with essentially this commit graph:
o---o---o---...---o---o---D -- develop
/ / /
o---o---o---o---...---M -- master
As shown, we occasionally merge master into develop, but never vice-versa. (We
create our releases off
Hi Philip,
Am 2013-01-06 18:21, schrieb Philip Oakley:
Your issue [my mistake] is that the (gits's) merge process is a three way
merge, so you
have the two commits F and N to merge, but git will also locate the merge-base
at M
(which has the old directory structure), and compares the diffs
Hi Philip,
Am 2013-01-08 00:02, schrieb Philip Oakley:
That is, do I understand correctly that if I had used the default merge
strategy, and
somehow solved all the conflicts (so that none of the files had been changed
from F),
the result would have technically been exactly the same?
to the
problem, it seems to me that Subversion works better in such cases, and thus I posted
here. ;-)
Best regards,
Carsten
On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs
carsten.fuchs-sdyparl0...@public.gmane.org wrote:
Hi all,
in my repo, I'm doing this:
$ git status
# On branch master
# Your
Hi again,
Am 11.01.2013 11:38, schrieb Carsten Fuchs:
[...]
So my real question is, why does Git not do something analogous?
(Afaics, update the HEAD, update the Index, but leave the working-copy edition
alone?)
I searched for this beforehand, and most advice involves either stashing
with this problem.
Best regards,
Carsten
--
Dipl.-Inf. Carsten Fuchs
Carsten Fuchs Software
Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany
Internet: http://www.cafu.de | E-Mail: i...@cafu.de
Cafu - the open-source game and graphics engine for multiplayer 3D action
--
You received
=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
user.name=Carsten Fuchs
Am 2013-04-10 21:11, schrieb Carsten Fuchs:
The problem described in my original message seems to stem from the fact that
the line
endings are not written as CRLF in the working directory.
Please consider these simple steps to see the problem:
[...]
Can someone help me?
Can someone
Hi Rupert,
Am 2013-04-14 13:37, schrieb rupert THURNER:
we have a unix - linux - windows 7 environment, and we never needed
.gitattributes. but,
i used to get the error message regularly when the text files contain crlf line
endings
and use core.autocrlf = input.
Thanks for your reply!
I
Hi Kai,
Am 2016-01-08 um 05:18 schrieb Kai Hendry:
Thanks what {aws s3,s3cmd} sync does but it has a problem of trumping data.
Maybe http://www.boarvcs.org/ is an option for you?
Best regards,
Carsten
--
You received this message because you are subscribed to the Google Groups "Git
and their suggestion was to set a couple of
memory constraints and to run `git gc`. This seemed to work well – but
`git status` still fails:
(uiserver):p7715773:~/cafu$ cat ~/.gitconfig
[color]
ui = auto
[user]
name = Carsten Fuchs
email = carsten.fu...@cafu.de
[core]
editor = nano
18 matches
Mail list logo
