Hi,
On Fri, 7 Dec 2007, Al Boldi wrote:
> Jakub Narebski wrote:
>
> > Version control system is all about WORKFLOW B, where programmer
> > controls when it is time to commit (and in private repository he/she
> > can then rewrite history to arrive at "Perfect patch series"[*1*]);
> > something
[EMAIL PROTECTED] wrote:
> On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> > It probably goes without saying, that gitfs should have some basic
> > configuration file to setup its transparent behaviour
>
> But then it's not *truly* transparent, is it?
Don't mistake transparency with some
[EMAIL PROTECTED] wrote:
On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
It probably goes without saying, that gitfs should have some basic
configuration file to setup its transparent behaviour
But then it's not *truly* transparent, is it?
Don't mistake transparency with some form of
Hi,
On Fri, 7 Dec 2007, Al Boldi wrote:
Jakub Narebski wrote:
Version control system is all about WORKFLOW B, where programmer
controls when it is time to commit (and in private repository he/she
can then rewrite history to arrive at Perfect patch series[*1*]);
something that for
On Dec 1, 2007 7:50 PM, Al Boldi <[EMAIL PROTECTED]> wrote:
> Not sure what you mean by operationally transparent? It would be transparent
> for the updating client, and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is
On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> It probably goes without saying, that gitfs should have some basic
> configuration file to setup its transparent behaviour
But then it's not *truly* transparent, is it?
And that leaves another question - if you make a config file that
[EMAIL PROTECTED] wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> > Because WORKFLOW C is transparent, it won't affect other workflows. So
> > you could still use your normal WORKFLOW B in addition to WORKFLOW C,
> > gaining an additional level of version control detail at no extra
On Dec 7, 2007, at 11:36 AM, [EMAIL PROTECTED] wrote:
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
Because WORKFLOW C is transparent, it won't affect other
workflows. So you
could still use your normal WORKFLOW B in addition to WORKFLOW C,
gaining an
additional level of version
On 2007.12.07 13:53:11 +0300, Al Boldi wrote:
> Andreas Ericsson wrote:
> > So, to get to the bottom of this, which of the following workflows is it
> > you want git to support?
> >
> > ### WORKFLOW A ###
> > edit, edit, edit
> > edit, edit, edit
> > edit, edit, edit
> > Oops I made a mistake and
On Fri, 7 Dec 2007, Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to "current - 12".
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> Because WORKFLOW C is transparent, it won't affect other workflows. So you
> could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an
> additional level of version control detail at no extra cost other than the
>
Jakub Narebski wrote:
> Al Boldi <[EMAIL PROTECTED]> writes:
> > For example:
> >
> > echo "// last comment on this file" >> /gitfs.mounted/file
> >
> > should do an implied checkpoint, and make these checkpoints immediately
> > visible under some checkpoint branch of the gitfs mounted dir.
> >
Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to "current - 12".
edit, edit, edit
edit,
Al Boldi <[EMAIL PROTECTED]> writes:
> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back
Andreas Ericsson wrote:
> So, to get to the bottom of this, which of the following workflows is it
> you want git to support?
>
> ### WORKFLOW A ###
> edit, edit, edit
> edit, edit, edit
> edit, edit, edit
> Oops I made a mistake and need to hop back to "current - 12".
> edit, edit, edit
> edit,
Al Boldi wrote:
Johannes Schindelin wrote:
Hi,
Hi
On Fri, 7 Dec 2007, Al Boldi wrote:
You need to re-read the thread.
I don't know why you write that, and then say thanks. Clearly, what you
wrote originally, and what Andreas pointed out, were quite obvious
indicators that git already
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to current - 12.
edit, edit, edit
edit, edit, edit
Al Boldi wrote:
Johannes Schindelin wrote:
Hi,
Hi
On Fri, 7 Dec 2007, Al Boldi wrote:
You need to re-read the thread.
I don't know why you write that, and then say thanks. Clearly, what you
wrote originally, and what Andreas pointed out, were quite obvious
indicators that git already
Al Boldi [EMAIL PROTECTED] writes:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to current - 12.
Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to current - 12.
edit, edit, edit
edit,
On Dec 1, 2007 7:50 PM, Al Boldi [EMAIL PROTECTED] wrote:
Not sure what you mean by operationally transparent? It would be transparent
for the updating client, and the rest of the git-users would need to wait
for the commit from the updating client; which is ok, as this transparency
is not
On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
It probably goes without saying, that gitfs should have some basic
configuration file to setup its transparent behaviour
But then it's not *truly* transparent, is it?
And that leaves another question - if you make a config file that excludes
[EMAIL PROTECTED] wrote:
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
Because WORKFLOW C is transparent, it won't affect other workflows. So
you could still use your normal WORKFLOW B in addition to WORKFLOW C,
gaining an additional level of version control detail at no extra cost
Jakub Narebski wrote:
Al Boldi [EMAIL PROTECTED] writes:
For example:
echo // last comment on this file /gitfs.mounted/file
should do an implied checkpoint, and make these checkpoints immediately
visible under some checkpoint branch of the gitfs mounted dir.
Note, this way the
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
Because WORKFLOW C is transparent, it won't affect other workflows. So you
could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an
additional level of version control detail at no extra cost other than the
git-engine
On Dec 7, 2007, at 11:36 AM, [EMAIL PROTECTED] wrote:
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
Because WORKFLOW C is transparent, it won't affect other
workflows. So you
could still use your normal WORKFLOW B in addition to WORKFLOW C,
gaining an
additional level of version
On Fri, 7 Dec 2007, Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to current - 12.
edit,
On 2007.12.07 13:53:11 +0300, Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back
Johannes Schindelin wrote:
> Hi,
Hi
> On Fri, 7 Dec 2007, Al Boldi wrote:
> > You need to re-read the thread.
>
> I don't know why you write that, and then say thanks. Clearly, what you
> wrote originally, and what Andreas pointed out, were quite obvious
> indicators that git already does what
Al Boldi wrote:
When you read server, don't read it as localized; a server can be
distributed. What distinguishes a server from an engine is that it has to
handle a multi-user use-case. How that is implemented, locally or remotely
or distributed, is another issue.
And again, git handles
Hi,
On Fri, 7 Dec 2007, Al Boldi wrote:
> Andreas Ericsson wrote:
> > Al Boldi wrote:
> >
> > > By pulling the sources into a git-client manager mounted on some
> > > dir, it should be possible to let the developer work
> > > naturally/transparently in a readable/writeable manner, and only
>
Al Boldi wrote:
Phillip Susi wrote:
Al Boldi wrote:
IOW, git currently only implements the server-side use-case, but fails
to deliver on the client-side. By introducing a git-client manager that
handles the transparency needs of a single user, it should be possible
to clearly isolate update
Andreas Ericsson wrote:
> Al Boldi wrote:
> > Phillip Susi wrote:
> >> Al Boldi wrote:
> >>> IOW, git currently only implements the server-side use-case, but fails
> >>> to deliver on the client-side. By introducing a git-client manager
> >>> that handles the transparency needs of a single user,
Phillip Susi wrote:
> Al Boldi wrote:
> > IOW, git currently only implements the server-side use-case, but fails
> > to deliver on the client-side. By introducing a git-client manager that
> > handles the transparency needs of a single user, it should be possible
> > to clearly isolate update
Phillip Susi wrote:
Al Boldi wrote:
IOW, git currently only implements the server-side use-case, but fails
to deliver on the client-side. By introducing a git-client manager that
handles the transparency needs of a single user, it should be possible
to clearly isolate update semantics
Andreas Ericsson wrote:
Al Boldi wrote:
Phillip Susi wrote:
Al Boldi wrote:
IOW, git currently only implements the server-side use-case, but fails
to deliver on the client-side. By introducing a git-client manager
that handles the transparency needs of a single user, it should be
Al Boldi wrote:
Phillip Susi wrote:
Al Boldi wrote:
IOW, git currently only implements the server-side use-case, but fails
to deliver on the client-side. By introducing a git-client manager that
handles the transparency needs of a single user, it should be possible
to clearly isolate update
Hi,
On Fri, 7 Dec 2007, Al Boldi wrote:
Andreas Ericsson wrote:
Al Boldi wrote:
By pulling the sources into a git-client manager mounted on some
dir, it should be possible to let the developer work
naturally/transparently in a readable/writeable manner, and only
require his
Al Boldi wrote:
When you read server, don't read it as localized; a server can be
distributed. What distinguishes a server from an engine is that it has to
handle a multi-user use-case. How that is implemented, locally or remotely
or distributed, is another issue.
And again, git handles
Johannes Schindelin wrote:
Hi,
Hi
On Fri, 7 Dec 2007, Al Boldi wrote:
You need to re-read the thread.
I don't know why you write that, and then say thanks. Clearly, what you
wrote originally, and what Andreas pointed out, were quite obvious
indicators that git already does what you
Al Boldi wrote:
Judging an idea, based on a flawed implementation, doesn't prove that the
idea itself is flawed.
It isn't the implementation that is flawed, it is the idea. The entire
point of a change control system is that you explicitly define change
sets and add comments to the set.
Al Boldi wrote:
Judging an idea, based on a flawed implementation, doesn't prove that the
idea itself is flawed.
It isn't the implementation that is flawed, it is the idea. The entire
point of a change control system is that you explicitly define change
sets and add comments to the set.
Jing Xue wrote:
> Quoting Al Boldi <[EMAIL PROTECTED]>:
> > Sure, browsing is the easy part, but Version Control starts when things
> > become writable.
>
> But how is that supposed to work? What happens when you make some
> changes to a file and save it? Do you want the "git file system" to
>
Jing Xue wrote:
Quoting Al Boldi [EMAIL PROTECTED]:
Sure, browsing is the easy part, but Version Control starts when things
become writable.
But how is that supposed to work? What happens when you make some
changes to a file and save it? Do you want the git file system to
commit it
On Thu, 29 Nov 2007, Jing Xue wrote:
>
> By the way, the only SCM I have worked with that tries to mount its
> repository (or a view on top of it) as a file system is ClearCase with
> its dynamic views. And, between the buggy file system implementation,
> the intrusion on workflow, and the lack
Quoting Al Boldi <[EMAIL PROTECTED]>:
Sure, browsing is the easy part, but Version Control starts when things
become writable.
But how is that supposed to work? What happens when you make some
changes to a file and save it? Do you want the "git file system" to
commit it right aways or wait
On Thu, 29 Nov 2007 13:45:44 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen schrieb:
> >
> > No, use "git rebase --interactive" ;-)
>
> What's that? I can't find it in "man git-rebase".
I think it was added very recently; most distributions probably don't
have a recent
On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
Jakub Narebski wrote:
Besides, you can always use "git show :". For
example gitweb (and I think other web interfaces) can show any
version of a file or a directory, accessing only repository.
Sure, browsing is the easy part, but Version Control
Arkadiusz Miskiewicz schrieb:
> You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's
> better
> 8-)
Thanks for that. It really cleared up a lot of things.
Now if I could get all that information in a less awkward form,
for example a nice text document I can read at leisure
Haavard Skinnemoen schrieb:
>
> No, use "git rebase --interactive" ;-)
What's that? I can't find it in "man git-rebase".
--
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis:
Haavard Skinnemoen schrieb:
No, use git rebase --interactive ;-)
What's that? I can't find it in man git-rebase.
--
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe
On Thu, 29 Nov 2007 13:45:44 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
Haavard Skinnemoen schrieb:
No, use git rebase --interactive ;-)
What's that? I can't find it in man git-rebase.
I think it was added very recently; most distributions probably don't
have a recent enough
On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
Jakub Narebski wrote:
Besides, you can always use git show revision:file. For
example gitweb (and I think other web interfaces) can show any
version of a file or a directory, accessing only repository.
Sure, browsing is the easy part, but
Arkadiusz Miskiewicz schrieb:
You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's
better
8-)
Thanks for that. It really cleared up a lot of things.
Now if I could get all that information in a less awkward form,
for example a nice text document I can read at leisure
Quoting Al Boldi [EMAIL PROTECTED]:
Sure, browsing is the easy part, but Version Control starts when things
become writable.
But how is that supposed to work? What happens when you make some
changes to a file and save it? Do you want the git file system to
commit it right aways or wait
On Thu, 29 Nov 2007, Jing Xue wrote:
By the way, the only SCM I have worked with that tries to mount its
repository (or a view on top of it) as a file system is ClearCase with
its dynamic views. And, between the buggy file system implementation,
the intrusion on workflow, and the lack of
Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent. Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking
On Wed, 28 Nov 2007 00:20:46 +0100 (CET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Nov 27 2007 23:33, Tilman Schmidt wrote:
> >
> >It didn't work too well. The first result was one of maximal
> >embarrassment: I produced a patch that didn't even compile when
> >applied to the official tree.
On Wed, Nov 28, 2007 at 02:38:02PM +0100, Tilman Schmidt wrote:
> Willy,
>
> thanks for your kind answer.
>
> Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
> > Tilman, there was a howto by Jeff Garzik I believe.
>
> Yes, I started from that and it's fine as far as it goes. The
>
Dave Quigley wrote:
On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
Dave Quigley schrieb:
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
On
On Wed, 2007-11-28 at 20:10 +0100, willem wrote:
> Dave Quigley wrote:
> > On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
> >
> >> Dave Quigley schrieb:
> >>
> >>> There is a project listed on the kernel.org git page called guilt. I
> >>> find it very useful. It is much more
Al Boldi wrote:
> Johannes Schindelin wrote:
>> By that definition, no SCM, not even CVS, is transparent. Nothing short
>> of unpacked directories of all versions (wasting a lot of disk space)
>> would.
>
> Who said anything about unpacking?
>
> I'm talking about GIT transparently serving a
Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent. Nothing short
> of unpacked directories of all versions (wasting a lot of disk space)
> would.
Who said anything about unpacking?
I'm talking about GIT transparently serving a Virtual Version Control dir to
Hi,
On Wed, 28 Nov 2007, Al Boldi wrote:
> [EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup.
Fair enough.
> Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > > Al Boldi wrote:
> > > > Willy Tarreau wrote:
> > > > > It should not turn into an endless
Johannes Schindelin wrote:
> Hi,
Hi!
[EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup.
> On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > Al Boldi wrote:
> > > Willy Tarreau wrote:
> > > > It should not turn into an endless thread led by people who want to
> > > > redefine GIT's
On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
> Dave Quigley schrieb:
> > There is a project listed on the kernel.org git page called guilt. I
> > find it very useful. It is much more responsive than stgit and it
> > actually has a git backend which quilt does not.
> >
> > On Wed,
Dave Quigley schrieb:
> There is a project listed on the kernel.org git page called guilt. I
> find it very useful. It is much more responsive than stgit and it
> actually has a git backend which quilt does not.
>
> On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
>> On Nov 27 2007 23:33,
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
There is a tutorial associated with
Al Boldi wrote:
Willy Tarreau wrote:
It should not turn into an endless thread led by people who want to
redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for
version control to start mutilating your
Willy,
thanks for your kind answer.
Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
> Tilman, there was a howto by Jeff Garzik I believe.
Yes, I started from that and it's fine as far as it goes. The
"Everyday GIT With 20 Commands Or So" document was quite helpful
too, especially the
Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for
version control to start mutilating your sources. Version
On Wed, 28 Nov 2007 12:23:48 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Kristoffer Ericson schrieb:
> > Google is your friend.
>
> Sigh.
>
> In case you didn't guess, I *have* of course searched Google,
> and not just that. I thought the wording of my request would
> have made that
Kristoffer Ericson schrieb:
> Google is your friend.
Sigh.
In case you didn't guess, I *have* of course searched Google,
and not just that. I thought the wording of my request would
have made that sufficiently clear. Do I really have to add the
phrase "Yes, I have searched Google!" to my sig?
On Tuesday 27 of November 2007, Tilman Schmidt wrote:
> So I've watched Linus' Google Tech Talk about git and let him convince
> me that I've been stupid to use CVS, that Subversion is even worse,
> and the only sensible approach is to use git. Went ahead and tried to
> convert my driver
On Tuesday 27 of November 2007, Tilman Schmidt wrote:
So I've watched Linus' Google Tech Talk about git and let him convince
me that I've been stupid to use CVS, that Subversion is even worse,
and the only sensible approach is to use git. Went ahead and tried to
convert my driver development
Kristoffer Ericson schrieb:
Google is your friend.
Sigh.
In case you didn't guess, I *have* of course searched Google,
and not just that. I thought the wording of my request would
have made that sufficiently clear. Do I really have to add the
phrase Yes, I have searched Google! to my sig?
--
On Wed, 28 Nov 2007 12:23:48 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
Kristoffer Ericson schrieb:
Google is your friend.
Sigh.
In case you didn't guess, I *have* of course searched Google,
and not just that. I thought the wording of my request would
have made that sufficiently
Willy Tarreau wrote:
It should not turn into an endless thread led by people who want to
redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for
version control to start mutilating your sources. Version
Willy,
thanks for your kind answer.
Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
Tilman, there was a howto by Jeff Garzik I believe.
Yes, I started from that and it's fine as far as it goes. The
Everyday GIT With 20 Commands Or So document was quite helpful
too, especially the
Al Boldi wrote:
Willy Tarreau wrote:
It should not turn into an endless thread led by people who want to
redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for
version control to start mutilating your
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
There is a tutorial associated with
Dave Quigley schrieb:
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
On Nov 27 2007 23:33, Tilman
On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
Dave Quigley schrieb:
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
On Wed, 2007-11-28 at
Johannes Schindelin wrote:
Hi,
Hi!
[EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup.
On Wed, 28 Nov 2007, Rogan Dawes wrote:
Al Boldi wrote:
Willy Tarreau wrote:
It should not turn into an endless thread led by people who want to
redefine GIT's roadmap, but
Hi,
On Wed, 28 Nov 2007, Al Boldi wrote:
[EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup.
Fair enough.
Johannes Schindelin wrote:
On Wed, 28 Nov 2007, Rogan Dawes wrote:
Al Boldi wrote:
Willy Tarreau wrote:
It should not turn into an endless thread led by
Johannes Schindelin wrote:
By that definition, no SCM, not even CVS, is transparent. Nothing short
of unpacked directories of all versions (wasting a lot of disk space)
would.
Who said anything about unpacking?
I'm talking about GIT transparently serving a Virtual Version Control dir to
be
Al Boldi wrote:
Johannes Schindelin wrote:
By that definition, no SCM, not even CVS, is transparent. Nothing short
of unpacked directories of all versions (wasting a lot of disk space)
would.
Who said anything about unpacking?
I'm talking about GIT transparently serving a Virtual
On Wed, 2007-11-28 at 20:10 +0100, willem wrote:
Dave Quigley wrote:
On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
Dave Quigley schrieb:
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit
Dave Quigley wrote:
On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
Dave Quigley schrieb:
There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.
On
On Wed, Nov 28, 2007 at 02:38:02PM +0100, Tilman Schmidt wrote:
Willy,
thanks for your kind answer.
Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
Tilman, there was a howto by Jeff Garzik I believe.
Yes, I started from that and it's fine as far as it goes. The
Everyday GIT
On Wed, 28 Nov 2007 00:20:46 +0100 (CET)
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Nov 27 2007 23:33, Tilman Schmidt wrote:
It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when
applied to the official tree. This
Jakub Narebski wrote:
Al Boldi wrote:
Johannes Schindelin wrote:
By that definition, no SCM, not even CVS, is transparent. Nothing
short of unpacked directories of all versions (wasting a lot of disk
space) would.
Who said anything about unpacking?
I'm talking about GIT
On Wed, 28 Nov 2007 00:52:38 +0100 Willy Tarreau wrote:
> Tilman, there was a howto by Jeff Garzik I believe. It helped me
> a lot when I didn't understand a damn command, even if it was in
> the very old ages (version 0.5 or something like this). The tutorials
> on the GIT site are quite good
On Wed, 28 Nov 2007 00:52:38 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> > Greetings,
> >
> > Google is your friend. If you're looking for irc channels you can always
> > try #git at irc.freenode.net
> > Git
On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> Greetings,
>
> Google is your friend. If you're looking for irc channels you can always try
> #git at irc.freenode.net
> Git howto/tutorial/... doesn't belong in the kernel mailinglist.
Well, I don't agree with you. His
On Nov 27 2007 23:33, Tilman Schmidt wrote:
>
>It didn't work too well. The first result was one of maximal
>embarrassment: I produced a patch that didn't even compile when
>applied to the official tree. This shouldn't happen with git, right?
>Well, it did. So now I'm back to keeping a virgin
Greetings,
Google is your friend. If you're looking for irc channels you can always try
#git at irc.freenode.net
Git howto/tutorial/... doesn't belong in the kernel mailinglist.
Best wishes
Kristoffer Ericson
On Tue, 27 Nov 2007 23:33:21 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> So
On Tue, Nov 27, 2007 at 11:33:21PM +0100, Tilman Schmidt wrote:
> Does somebody have a step by step tutorial for doing the standard
> "edit - test - modify - retest - submit - edit - resubmit" sequence
> with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
> post my silly questions
Greetings,
Google is your friend. If you're looking for irc channels you can always try
#git at irc.freenode.net
Git howto/tutorial/... doesn't belong in the kernel mailinglist.
Best wishes
Kristoffer Ericson
On Tue, 27 Nov 2007 23:33:21 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
So I've
On Tue, Nov 27, 2007 at 11:33:21PM +0100, Tilman Schmidt wrote:
Does somebody have a step by step tutorial for doing the standard
edit - test - modify - retest - submit - edit - resubmit sequence
with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
post my silly questions to
1 - 100 of 104 matches
Mail list logo
