On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
> Georg Baum wrote:
> > commit yet)? I guess it would look like
> >
> > git checkout -b fixfileformat
> > git commit
> > git checkout master
> > git merge fixfileformat
> > git commit
> > git branch -d fixfileformat
>
> The simplistic S
Georg Baum wrote:
> commit yet)? I guess it would look like
>
> git checkout -b fixfileformat
> git commit
> git checkout master
> git merge fixfileformat
> git commit
> git branch -d fixfileformat
The simplistic SVN-like scenario is just:
git pull (update from public repo)
git commit (just loca
On 03/20/2012 04:14 PM, Georg Baum wrote:
I have to admit that I am confused. There have been lots of discussions and
proposals, but to me it is neither clear whether a long term workflow has
been agreed on, nor how the current workflow is supposed to look like. For
example, what am I supposed to
I have to admit that I am confused. There have been lots of discussions and
proposals, but to me it is neither clear whether a long term workflow has
been agreed on, nor how the current workflow is supposed to look like. For
example, what am I supposed to do if I want to fix the latest file form
Vincent van Ravesteijn wrote:
>> So your plan is to play with stage history (eg merge commits) and from time
>> to time push such repaired history into official? From that time no changes
>> will be done to those commits in stage as well?
>
> Yes, the staging repo will always be based on the stable
On 14/03/2012 02:05, Julien Rioux wrote:
I want it simple, and I want it centralized. It's nice to allow
private new repos to developers, thank you for that, but it seems
overkill to require their use. I honestly cannot be bothered at the
moment to setup remote repositories to fetch someone els
Op 15-3-2012 10:57, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Fine. If I understand correctly the shift "stage"->"devel" stable can help
you to rewrite history (e.g. by merging fix of fix commits). So then we
would have 2 incompatible histories in two repos.
No, the staging repo has no
Vincent van Ravesteijn wrote:
>> Fine. If I understand correctly the shift "stage"->"devel" stable can help
>> you to rewrite history (e.g. by merging fix of fix commits). So then we
>> would have 2 incompatible histories in two repos.
>
> No, the staging repo has no own fixed history.
So if I
On 14/03/2012 7:14 PM, Lars Gullik Bjønnes wrote:
Julien Rioux writes:
| On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
But why?
This is the perfect case for a separate repo.
[...]
| Assuming that the pristinity of the lyx repo as a whole is so
| important that we cannot allow trusted de
Julien Rioux writes:
| On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
>> But why?
>>
>> This is the perfect case for a separate repo.
>>
>> [...]
>>
>> | Assuming that the pristinity of the lyx repo as a whole is so
>> | important that we cannot allow trusted developers to create branches,
>>
André Pönitz writes:
| On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote:
>>
>> >>>Yes, that's where we disagree. I don't see these additional commits as
>> >>>good enough reason to drown people in branching mania. Unless someone
>> >>>develops new nifty feature or particula
Le 14/03/12 23:17, Tommaso Cucinotta a écrit :
+1
+\inf
You win!
JMarc
Il 14/03/2012 21:14, Uwe Stöhr ha scritto:
Am 13.03.2012 16:47, schrieb Richard Heck:
I don't disagree with any of what is below, but I guess I'd prefer to
see us move more slowly. Many
people are going to have to get used to using git locally, on their
own machine, and making too many
changes
On 14/03/2012 4:37 PM, André Pönitz wrote:
On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote:
On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
But why?
This is the perfect case for a separate repo.
[...]
| Assuming that the pristinity of the lyx repo as a whole is so
| important
Am 13.03.2012 16:47, schrieb Richard Heck:
I don't disagree with any of what is below, but I guess I'd prefer to see us
move more slowly. Many
people are going to have to get used to using git locally, on their own
machine, and making too many
changes to the workflow now, while people are just
Am 13.03.2012 16:47, schrieb Richard Heck:
I don't disagree with any of what is below, but I guess I'd prefer to see us
move more slowly. Many
people are going to have to get used to using git locally, on their own
machine, and making too many
changes to the workflow now, while people are just
On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote:
>
> >>>Yes, that's where we disagree. I don't see these additional commits as
> >>>good enough reason to drown people in branching mania. Unless someone
> >>>develops new nifty feature or particularly tough bug, he shouldn't
>
Yes, that's where we disagree. I don't see these additional commits as
good enough reason to drown people in branching mania. Unless someone
develops new nifty feature or particularly tough bug, he shouldn't
recognize there is some difference between svn and git.
You seem to have an aversion to
On Wed, Mar 14, 2012 at 08:33:05PM +0100, Vincent van Ravesteijn wrote:
> Op 14-3-2012 14:11, Pavel Sanda schreef:
> >Vincent van Ravesteijn wrote:
> >>>I see that in some cases of 2. additional commit are applied but we
> >>>shouldn't value clean commit history at such high rates.
> >>These additi
On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote:
> On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
> >But why?
> >
> >This is the perfect case for a separate repo.
> >
> > [...]
> >
> >| Assuming that the pristinity of the lyx repo as a whole is so
> >| important that we cannot allow
On 03/13/2012 09:05 PM, Julien Rioux wrote:
I want it simple, and I want it centralized. It's nice to allow
private new repos to developers, thank you for that, but it seems
overkill to require their use. I honestly cannot be bothered at the
moment to setup remote repositories to fetch someon
Op 14-3-2012 14:11, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
I see that in some cases of 2. additional commit are applied but we
shouldn't value clean commit history at such high rates.
These additional commits are the number 1 reason for me to propose what I
proposed. To my liking, t
Vincent van Ravesteijn wrote:
>> I see that in some cases of 2. additional commit are applied but we
>> shouldn't value clean commit history at such high rates.
>
> These additional commits are the number 1 reason for me to propose what I
> proposed. To my liking, there are way too many commits t
On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote:
But why?
This is the perfect case for a separate repo.
> [...]
>
| Assuming that the pristinity of the lyx repo as a whole is so
| important that we cannot allow trusted developers to create branches,
| then maybe such branches can be allowed
Julien Rioux writes:
| On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote:
>> Julien Rioux writes:
>>
>> | it should be allowed to have feature branches
>> | directly in the main repo.
>>
>> This is the part that I really disagree with. Plainly: no, you should
>> not be allow to create what ever b
On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote:
Julien Rioux writes:
| it should be allowed to have feature branches
| directly in the main repo.
This is the part that I really disagree with. Plainly: no, you should
not be allow to create what ever branch you want in the main repo.
Please
Pavel Sanda writes:
| Pavel
| BTW Lars, can we get wiki and web working again? Christian stop to
| respond altogether..
I was really hoping that I should not have to look at this, this is
something that I really have not playing with before.
I'll handle apache config, deamons, distributions, git
Julien Rioux writes:
| it should be allowed to have feature branches
| directly in the main repo.
This is the part that I really disagree with. Plainly: no, you should
not be allow to create what ever branch you want in the main repo.
This is the repo with the higher goals and that everyone els
Pavel Sanda wrote:
> From what I see there are roughly 3 kinds of things committed into trunk
> as far as time and testing is concerned
>
> 1. Short-time one shots, e.g. fixing small glitches, doc changes,
> translations.
>Sometimes can take few minutes to produce and once committed there is
On 13/03/2012 11:39 AM, Pavel Sanda wrote:
Lars Gullik Bj?nnes wrote:
You, the lyx developers, have to agree on process, but the git repo
has been open for writing since sunday evening.
From what I see there are roughly 3 kinds of things committed into trunk
as far as time and testing is conc
On 03/13/2012 12:12 PM, Vincent van Ravesteijn wrote:
Op 13-3-2012 16:47, Richard Heck schreef:
On 03/13/2012 08:40 AM, Vincent van Ravesteijn wrote:
You, the lyx developers, have to agree on process, but the git
repo has been open for writing since sunday evening.
I propose the following:
Op 13-3-2012 16:47, Richard Heck schreef:
On 03/13/2012 08:40 AM, Vincent van Ravesteijn wrote:
You, the lyx developers, have to agree on process, but the git repo
has been open for writing since sunday evening.
I propose the following:
I don't disagree with any of what is below, but I guess
I see that in some cases of 2. additional commit are applied but we shouldn't
value clean commit history at such high rates.
These additional commits are the number 1 reason for me to propose what
I proposed. To my liking, there are way too many commits that fix a
typo, fix a warning on a diff
On 03/13/2012 08:40 AM, Vincent van Ravesteijn wrote:
You, the lyx developers, have to agree on process, but the git repo
has been open for writing since sunday evening.
I propose the following:
I don't disagree with any of what is below, but I guess I'd prefer to
see us move more slowly. Ma
Lars Gullik Bj?nnes wrote:
> You, the lyx developers, have to agree on process, but the git repo
> has been open for writing since sunday evening.
>From what I see there are roughly 3 kinds of things committed into trunk
as far as time and testing is concerned
1. Short-time one shots, e.g. fixing
You, the lyx developers, have to agree on process, but the git repo
has been open for writing since sunday evening.
I propose the following:
Goal:
Do not merge any new features into lyx.git until
- they are truly finished,
- well commented and understandable by others,
- have good commit mess
On 09/13/2011 05:25 PM, Vincent van Ravesteijn wrote:
> Op 13-9-2011 23:10, Julien Rioux schreef:
>> How can git help me porting patches to the stable branch?
>>
>> Previously with svn I just had two directories, one pointing to trunk
>> one to branch. I made a patch file from trunk by svn diff -r
Op 13-9-2011 23:10, Julien Rioux schreef:
How can git help me porting patches to the stable branch?
Previously with svn I just had two directories, one pointing to trunk
one to branch. I made a patch file from trunk by svn diff -r then
applied the patch to branch, manually copying the log mess
How can git help me porting patches to the stable branch?
Previously with svn I just had two directories, one pointing to trunk
one to branch. I made a patch file from trunk by svn diff -r then
applied the patch to branch, manually copying the log message. Does git
make it any easier?
Thanks
39 matches
Mail list logo
