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 form
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 exclude
[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 c
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 contro
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 n
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 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-engi
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, ed
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, ed
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 does
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 y
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 bot
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 se
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, i
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 sema
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. The
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
> co
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 e
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 in
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: (s
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. T
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
> "Ever
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 respo
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 Vir
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
b
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 th
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 roa
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
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 guil
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 sou
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 se
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 C
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 suffic
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 developmen
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 too
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 howto/tutoria
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 questi
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 kern
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'v
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 t
52 matches
Mail list logo
