Chani wrote:
>> I'd say there's no need for pull or rebase.
>>
>> You should do this:
>> git fetch $REPOSITORY
>
>any reason for fetch instead of pull?
Yes: pull is fetch + merge. Since two steps down we'll do a reset, we'll
discard our merge here. So there's no point in wasting cycles.
>> git c
2009/5/26 Chusslove Illich :
>> [: Ian Monroe :]
>> I agree that there's no reason translators and programmers should use the
>> same system. However I don't think letting individual projects in KDE pick
>> their own VCS is a good idea. Amarok is probably going to switch before
>> the rest, but thi
>
> I'd say there's no need for pull or rebase.
>
> You should do this:
> git fetch $REPOSITORY
any reason for fetch instead of pull?
> git clean -x -d -f
> git reset --hard $REPOSITORY/$BRANCH
> [ apply changes ]
> git commit -m "Scripty changes" -a
> git push $REPOSITORY $BRANCH
>
> If the pus
> [: Ian Monroe :]
> I agree that there's no reason translators and programmers should use the
> same system. However I don't think letting individual projects in KDE pick
> their own VCS is a good idea. Amarok is probably going to switch before
> the rest, but this is purely transitional. Keeping
Em Terça-feira 26 Maio 2009, às 17:56:52, Chani escreveu:
> On May 26, 2009 08:45:52 Thomas Zander wrote:
> > On Tuesday 26. May 2009 09.18.43 Chani wrote:
> > > -I'm not sure if I should rebase when I pull, just in case strange
> > > things have happened to the git repo. maybe only if the first pu
On May 26, 2009 08:45:52 Thomas Zander wrote:
> On Tuesday 26. May 2009 09.18.43 Chani wrote:
> > -I'm not sure if I should rebase when I pull, just in case strange things
> > have happened to the git repo. maybe only if the first pull fails?
>
> The only commits you ever will create in this repo a
On Tuesday 26. May 2009 09.18.43 Chani wrote:
> -I'm not sure if I should rebase when I pull, just in case strange things
> have happened to the git repo. maybe only if the first pull fails?
The only commits you ever will create in this repo are the translation
update right?
In that case --rebase
Ian Monroe wrote:
>> [amarok]
>> section = extragear
>> subsection = multimedia
>> vcs = git
>> repo-base = git://foo.bar.kde/amarok
>> ui-stable = s...@branch_2_0
>> ui-trunk = s...@master
>> doc-stable = d...@branch_2_0
>> doc-trunk = d...@master
>
> Outside of the "vcs = git" line (sin
On Tuesday 26. May 2009 09.18.43 Chani wrote:
> -if git checkout fails (which I'm not sure would ever happ
reasons it might fail;
* you are out of diskspace
* there is a file present (like Makefile) on filesystem that is actually known
to git in the branch. Git then will say it can't checkout sin
2009/5/26 Chusslove Illich :
> First of all, "moving to Git" is under quotes because it's, in my view, a
> misnomer for what should really be done to properly reorganize the things,
> such that we do not set ourselves up for a similar trouble in the
> foreseeable future, and provide even more flexi
First of all, "moving to Git" is under quotes because it's, in my view, a
misnomer for what should really be done to properly reorganize the things,
such that we do not set ourselves up for a similar trouble in the
foreseeable future, and provide even more flexibility right after its up and
running
here's a first draft of adding git support to scripty. I've tried to keep all
the svn code the same; the only nonessential change here was doing a cd $mod
once instead of multiple times (this should only change behaviour if a module
is a directory but cannot be entered, which seems very unlikely
12 matches
Mail list logo
