On Sun, 7 Jun 2009, Peter Eisentraut wrote:
On Wednesday 03 June 2009 01:55:48 Andrew Dunstan wrote:
Running recursive grep on a subversion working copy is quite nasty.
I suggest
export GREP_OPTIONS='-d skip -I --exclude=*.svn-base --exclude=tags
--exclude=*~ --exclude-dir=CVS
On Wednesday 03 June 2009 01:55:48 Andrew Dunstan wrote:
Running recursive grep on a subversion working copy is quite nasty.
I suggest
export GREP_OPTIONS='-d skip -I --exclude=*.svn-base --exclude=tags
--exclude=*~ --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.svn
--exclude=TAGS'
--
Hi,
Quoting Alvaro Herrera alvhe...@commandprompt.com:
The only rant I have about the outcome is that Linus did not copy more
of it.
He he.. nice way of looking at it ;-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
Quoting Tom Lane t...@sss.pgh.pa.us:
I can't escape the feeling that we're missing something basic here.
Perhaps the power (and importance) of merging is still a bit
underestimated, but otherwise I don't think there's much to miss.
But rebuilding the Linux kernel is hardly a
On Wed, Jun 3, 2009 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of
Hi,
Quoting David E. Wheeler da...@kineticode.com:
Monotone?
..one of the sources of inspiration for Linus to write git. He was not
satisfied with its speed and he didn't like C++ and SQL. Plus the main
contributors weren't around at the time Linus was on the mailing list.
So he turned
* Tom Lane:
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
repository and status information about the current checkout, so
that's not gonna work.
git clone --reference stores just a reference and does not
On 06/03/2009 01:48 PM, Florian Weimer wrote:
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
repository and status information about the current checkout, so
that's not gonna work.
git clone --reference stores
Robert Haas wrote:
The problem with making each release a separate directory is that,
just like using separate repositories, it will defeat one of the main
strengths of git, which is the ability to move around commits easily.
git-new-workdir is the only solution to the problem of having
Robert Haas escribió:
On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think these are the two usable options. They will probably end up
...wait a minute. I just went and Googled this git-new-workdir thing
and it looks like it's almost exactly what we
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which doesn't bother me
personally but may
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which
On Wed, 2009-06-03 at 12:01 -0400, Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
available, as long as you're using
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on Windows which doesn't bother
On Wed, Jun 3, 2009 at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the
On Wed, Jun 3, 2009 at 5:14 PM, Dave Page dp...@pgadmin.org wrote:
It's a simple perl script that uses symlinks:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/workdir/git-new-workdir
Err, shell script even.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
available, as long as you're
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It
Andres Freund wrote:
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on Windows,
and is that fixable? Without having looked, I'm guessing the issue
is that it depends on hardlinks or symlinks --- and we know those are
On 06/03/2009 06:38 PM, Andrew Dunstan wrote:
Andres Freund wrote:
On 06/03/2009 06:17 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I think the appropriate question is why doesn't it work on
Windows, and is that fixable? Without having looked, I'm
guessing the issue is that it depends on
Andrew Dunstan and...@dunslane.net writes:
You have carefully left out the first sentence of my reply. Neither of
the committers who actually do much work on Windows (namely Magnus and
me) commit direct from *any* version of Windows.
Nonetheless, that might not be true in future. I'd be a
Markus Wanner wrote:
Hi,
Quoting David E. Wheeler da...@kineticode.com:
Monotone?
..one of the sources of inspiration for Linus to write git. He was not
satisfied with its speed and he didn't like C++ and SQL. Plus the main
contributors weren't around at the time Linus was on the
Andrew Dunstan wrote:
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
unsupported. It doesn't work on
Andres Freund wrote:
The git for windows installation includes a functional unix-alike shell
(mingw, not cygwin or such). Some core part of git are still written in
shell, so it would not work without that anyway.
Ah. Ok. Good to know. Does it contain a builtin ln command? And does
that
Hi,
On 06/03/2009 07:26 PM, Andrew Dunstan wrote:
Andres Freund wrote:
The git for windows installation includes a functional unix-alike shell
(mingw, not cygwin or such). Some core part of git are still written in
shell, so it would not work without that anyway.
Ah. Ok. Good to know. Does it
Magnus Hagander wrote:
Andrew Dunstan wrote:
Dave Page wrote:
On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Well, it sounds about perfect for my use case too (which is
approximately the same as Tom's), but the description makes it sound
My last post on the git issue... If any one wants to ask specific
questions, feel free to e-mail me directly... But this thread has
digressed to way too much hand-waving...
If any of your are not familiar with git and want to get an overview of
it, this might be a good place to start:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The only reason Tom sees a single line history is because he uses an
addon tool for CVS called cvs2cl: see http://www.red-bean.com/cvs2cl/.
It's not part of CVS, and I'm not sure how many others use it. I sure
don't.
FWIW, I
[ it's way past time for a new subject thread ]
Marko Kreen mark...@gmail.com writes:
They cannot be same commits in GIT as the resulting tree is different.
This brings up something that I've been wondering about: my limited
exposure to git hasn't shown me any sane way to work with multiple
On Jun 2, 2009, at 8:43 AM, Tom Lane wrote:
Each of these is configured (using --prefix) to install into a
separate
installation tree. So I can switch my attention to one branch or
another by cd'ing to the right place and adjusting a few environment
variables such as PATH and PGDATA.
Yeah,
David E. Wheeler da...@kineticode.com writes:
Yeah, with git, rather than cd'ing to another directory, you'd just do
`git checkout rel8_3` and work from the same directory.
That's what I'd gathered, and frankly it is not an acceptable answer.
Sure, the checkout operation is remarkably fast,
On Jun 2, 2009, at 9:03 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
That's what I'd gathered, and frankly it is not an acceptable answer.
David E. Wheeler wrote:
Well, you can have as many clones of a repository as you like. You can
keep one with master checked out, another with rel8_3, another with
rel8_2, etc. You'd just have to write a script to keep them in sync
(shouldn't be too difficult, each just as all the others
Yeah I was annoyed by the issue with having to reconfigure as well.
There are various tricks you can do though with separate repositories.
You could have the older branch repositories be clones of HEAD branch
repository so when you push from them the changes just go to that
repository then
On Jun 2, 2009, at 9:16 AM, Alvaro Herrera wrote:
Well, you can have as many clones of a repository as you like. You
can
keep one with master checked out, another with rel8_3, another with
rel8_2, etc. You'd just have to write a script to keep them in sync
(shouldn't be too difficult, each
On Tue, Jun 2, 2009 at 5:16 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
David E. Wheeler wrote:
Well, you can have as many clones of a repository as you like. You can
keep one with master checked out, another with rel8_3, another with
rel8_2, etc. You'd just have to write a script to
* David E. Wheeler da...@kineticode.com [090602 11:56]:
On Jun 2, 2009, at 8:43 AM, Tom Lane wrote:
Each of these is configured (using --prefix) to install into a
separate
installation tree. So I can switch my attention to one branch or
another by cd'ing to the right place and adjusting a
On 6/2/09, Tom Lane t...@sss.pgh.pa.us wrote:
[ it's way past time for a new subject thread ]
Marko Kreen mark...@gmail.com writes:
They cannot be same commits in GIT as the resulting tree is different.
This brings up something that I've been wondering about: my limited
exposure to git
On 06/02/2009 05:43 PM, Tom Lane wrote:
Marko Kreenmark...@gmail.com writes:
They cannot be same commits in GIT as the resulting tree is different.
I don't see any even-approximately-sane way to handle similar cases
in git. From what I've learned so far, you can have one checkout
at a time
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, but is there a way to create those clones from a single local
database?
(I like the monotone model much better. This mixing of working copies
and databases as if they were a single thing is silly and uncomfortable
to use.)
I agree,
On 06/02/2009 06:33 PM, Tom Lane wrote:
At the same time, I don't really buy the theory that relating commits on
different branches via merges will work. In my experience it is very
seldom the case that a patch applies to each back branch with no manual
effort whatever, which is what I gather
On 6/2/09, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, but is there a way to create those clones from a single local
database?
(I like the monotone model much better. This mixing of working copies
and databases as if they were a single
On Jun 2, 2009, at 9:23 AM, Aidan Van Dyk wrote:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
But that looses his configured and compiled state...
But git isn't forcing him to change his workflow at all...
Tom Lane wrote:
Marko Kreen mark...@gmail.com writes:
They cannot be same commits in GIT as the resulting tree is different.
The way I prepare a patch that has to be back-patched is first to make
and test the fix in HEAD. Then apply it (using diff/patch and perhaps
manual adjustments) to the
* Tom Lane t...@sss.pgh.pa.us [090602 12:35]:
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, but is there a way to create those clones from a single local
database?
(I like the monotone model much better. This mixing of working copies
and databases as if they were a single
Tom Lane wrote:
I agree, .git as a subdirectory of the working directory doesn't make
much sense to me.
I wondered for a second about symlinking .git from several checkout
directories to a common master, but AFAICT .git stores both the
repository and status information about the current
Mark Mielke wrote:
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in the
top-level directory, whereas CVS and SVN like to pollute
On 6/2/09, Alvaro Herrera alvhe...@commandprompt.com wrote:
Mark Mielke wrote:
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in
Andres Freund wrote:
On 06/02/2009 06:33 PM, Tom Lane wrote:
At the same time, I don't really buy the theory that relating commits on
different branches via merges will work. In my experience it is very
seldom the case that a patch applies to each back branch with no manual
effort whatever,
* Alvaro Herrera alvhe...@commandprompt.com [090602 13:25]:
That's not the problem. The problem is that it is kept in the same
directory as the checked out copy. It would be a lot more usable if it
was possible to store it elsewhere.
Yes, the .svn directories are a PITA.
You can export
Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Yeah, with git, rather than cd'ing to another directory, you'd just do
`git checkout rel8_3` and work from the same directory.
That's what I'd gathered, and frankly it is not an acceptable answer.
Sure, the checkout
Andrew Dunstan and...@dunslane.net writes:
Hmm. I confess that I never switch between CVS branches. Instead I keep
a separate tree for each maintained branch.
Right, exactly, and that's the workflow I want to maintain with git.
Having to rebuild the derived files every time I look at a
Alvaro Herrera wrote:
Mark Mielke wrote:
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in the
top-level directory, whereas CVS
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git directory bug you now? I'm
genuinely interested as I don't get it. :-)
It doesn't. What bugs me is that the database (the pulled tree if you
will) is stored in
Alvaro Herrera wrote:
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git directory bug you now? I'm
genuinely interested as I don't get it. :-)
It doesn't. What bugs me is that the database (the pulled
On 06/02/2009 09:38 PM, Alvaro Herrera wrote:
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git directory bug you now? I'm
genuinely interested as I don't get it. :-)
It doesn't. What bugs me is that the database
Tom Lane wrote:
Once I have all the versions
tested, I prepare a commit message and commit all the branches. This
results in one commit message per branch in the pgsql-committers
archives, and just one commit in the cvs2cl representation of the
history --- which is what I want.
I think
Mark Mielke m...@mark.mielke.cc writes:
Alvaro Herrera wrote:
That's not the problem. The problem is that it is kept in the same
directory as the checked out copy. It would be a lot more usable if it
was possible to store it elsewhere.
I'm not following. CVS and SVN both kept such
On Tue, Jun 2, 2009 at 3:38 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
What *really* bugs me is that it's so difficult to have one pulled
tree and create a bunch of checked out copies from that.
Yeah. It basically doesn't work, hacks to the contrary on this thread
nonwithstanding,
On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund and...@anarazel.de wrote:
On 06/02/2009 09:38 PM, Alvaro Herrera wrote:
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git directory bug you now? I'm
genuinely
On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Blowing away your working directory shouldn't result in loss of your
entire project history.
Such an outcome could not possibly be less likely with any other
system than it is with git. Every single developer has a copy of your
Tom Lane wrote:
Mark Mielke m...@mark.mielke.cc writes:
I'm not following. CVS and SVN both kept such directories in the
checked out copy. Recall the CSV/*,v files?
I can't speak to SVN, but that is *not* how CVS does it. There's a
small CVS/ directory, but the repository (with all
Robert Haas wrote:
On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund and...@anarazel.de wrote:
#Method 1
cd /../child1
git clone --reference /../master/ git://git.postgresql.org/whatever .
cd /../child2
git clone --reference /../master/ git://git.postgresql.org/whatever .
This way you can fetch
Robert Haas robertmh...@gmail.com writes:
I wonder whether it would help with this problem if we had a way to
locate the build products outside the tree, and maybe fix things up so
that you can make the build products go to a different location
depending on which branch you're on.
I'm
Andres Freund wrote:
On 06/02/2009 09:38 PM, Alvaro Herrera wrote:
What *really* bugs me is that it's so difficult to have one pulled
tree and create a bunch of checked out copies from that.
I dont see were the difficulty resides?
#Setup a base repository
cd /../master
git [--bare] clone
Mark Mielke m...@mark.mielke.cc writes:
As a for example, you could have a local repo that you publish from.
Your work spaces could be from that local repo.
Yes, exactly. How do I do that? My complaint is that git fails to
provide a distinction between a repo and a workspace --- they seem
to
On Jun 2, 2009, at 4:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder whether it would help with this problem if we had a way to
locate the build products outside the tree, and maybe fix things up
so
that you can make the build products go to a
On 06/02/2009 10:13 PM, Robert Haas wrote:
On Tue, Jun 2, 2009 at 3:58 PM, Andres Freundand...@anarazel.de wrote:
On 06/02/2009 09:38 PM, Alvaro Herrera wrote:
Mark Mielke wrote:
I just don't understand why you care. If the CVS directories didn't bug
you before, why does the single .git
Andres Freund escribió:
On 06/02/2009 10:13 PM, Robert Haas wrote:
Yeah but now you have to push and pull commits between your numerous
local working copies. Boo, hiss.
In the end thats the same with cvs and multiple checkouts?
You don't pull and push in CVS, you just commit and update.
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Blowing away your working directory shouldn't result in loss of your
entire project history.
Such an outcome could not possibly be less likely with any other
system than it is with
Robert Haas wrote:
The arguments that were put forward for switching to git all had to do
with managing patches against HEAD. AFAIK hardly anyone but the core
committers deals with back-patching at all, and so a structure like this
isn't going to affect anyone else --- you'd just ignore the
Robert Haas wrote:
And, unfortunately, I'm not sure there's a good solution. Tom could
create 1 local repository cloned from the origin and then N-1 copies
cloned with --local from that one, but this sort of defeats the
purpose of using git, because now if he commits a change to one of
them
Andrew Dunstan and...@dunslane.net writes:
The only reason Tom sees a single line history is because he uses an
addon tool for CVS called cvs2cl: see http://www.red-bean.com/cvs2cl/.
It's not part of CVS, and I'm not sure how many others use it. I sure
don't.
FWIW, I believe Bruce uses
On Jun 2, 2009, at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Blowing away your working directory shouldn't result in loss of your
entire project history.
Such an outcome could not
On Jun 2, 2009, at 2:31 PM, Tom Lane wrote:
It's a bit premature to speculate about alternate history tools when
we haven't figured out what the repository is going to look like.
Right
at the moment I'm much more concerned about the question of supporting
a checkout-per-branch workflow.
David E. Wheeler da...@kineticode.com writes:
Perhaps there's a master repository that corresonds to CVS HEAD, and
then release branches are actually separate git repositories.
Yeah, I was speculating about that one too. It might be workable.
Just cp -r the master whenever we fork a new
On Jun 2, 2009, at 3:11 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Perhaps there's a master repository that corresonds to CVS HEAD, and
then release branches are actually separate git repositories.
Yeah, I was speculating about that one too. It might be workable.
Just
On Tue, Jun 2, 2009 at 5:28 PM, Ron Mayer rm...@cheapcomplexdevices.com wrote:
Robert Haas wrote:
And, unfortunately, I'm not sure there's a good solution. Tom could
create 1 local repository cloned from the origin and then N-1 copies
cloned with --local from that one, but this sort of
I think it all makes a lot more sense if you think of your local git
clone as just a cache. The real repo is still separate in a real repo
on a server.
In that mental model the equivalent of CVS commit is actually git
push not git commit. And the equivalent of CVS update is actually git
On 06/02/2009 10:43 PM, Alvaro Herrera wrote:
Andres Freund wrote:
On 06/02/2009 09:38 PM, Alvaro Herrera wrote:
What *really* bugs me is that it's so difficult to have one pulled
tree and create a bunch of checked out copies from that.
I dont see were the difficulty resides?
#Setup a base
David E. Wheeler da...@kineticode.com writes:
On Jun 2, 2009, at 3:11 PM, Tom Lane wrote:
Maybe that special log tool Andrew was
speculating about would take the form of a program to aggregate the
change histories of several repositories.
You mean so that such patches in back branches show
On Jun 2, 2009, at 3:33 PM, Tom Lane wrote:
A back-branch-only fix would look the same except for not having any
unannotated filenames. I'm too lazy to go trolling for one just now.
God Tom, you're such a bloody slacker. Sheesh!
It's also possible to get it to produce histories that
Mark Mielke wrote:
Alvaro Herrera wrote:
Mark Mielke wrote:
I am curious about why an end user would really care? CVS and SVN both
kept local workspace directories containing metadata. If anything, I
find GIT the least intrusive of these three, as the .git is only in the
top-level
David E. Wheeler da...@kineticode.com writes:
I should think that it'd be pretty damned easy to generate such a
report from a Git repository's log. `git log` is extremely powerful,
and provides a lot of interfaces for hooking things in and sorting.
It's eminently do-able.
Well, it's not
On Jun 2, 2009, at 3:56 PM, Tom Lane wrote:
Well, it's not like CVS makes it easy ... cvs2cl is about 50K of perl,
and is not very speedy or without bugs :-(. So maybe we are setting
the goalposts in the wrong place by supposing that the lowest-level
git
history needs to be exactly what's
David E. Wheeler da...@kineticode.com writes:
On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote:
Running recursive grep on a
subversion working copy is quite nasty.
`git grep` to avoid this issue with Git.
One thing that git does do right is that the .git subdirectory exists
only at the top
David E. Wheeler da...@kineticode.com writes:
On Jun 2, 2009, at 3:56 PM, Tom Lane wrote:
Meanwhile, there seem to have been ten different solutions proposed to
the problem of working with multiple branches/checkouts, and I plead
confusion. Anyone want to try to sort out the pluses and
On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote:
Umm, no. there are *no* ,v files in my working copies (I just
checked, to make sure I wasn't on crack). The repository has them,
but the working copy does not. SVN does keep the equivalent - that's
how you can work offline for doing things
On Jun 2, 2009, at 4:13 PM, Tom Lane wrote:
I think you missed the part of the discussion about not wishing to
share
a single working directory across all the branches.
No, I was just ignoring it for the moment to focus on the commit and
history issue.
The time to rebuild
derived files
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths that it allows you to easily
and quickly switch your
On 06/03/2009 12:56 AM, Tom Lane wrote:
David E. Wheelerda...@kineticode.com writes:
I should think that it'd be pretty damned easy to generate such a
report from a Git repository's log. `git log` is extremely powerful,
and provides a lot of interfaces for hooking things in and sorting.
It's
On 06/03/2009 01:39 AM, Tom Lane wrote:
David E. Wheelerda...@kineticode.com writes:
Does that make sense?
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths that it allows you to easily
and quickly switch your attention among
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Umm, no. there are *no* ,v files in my working copies (I just checked,
to make sure I wasn't on crack). The repository has them, but the
working copy does not. SVN does keep the equivalent - that's how you can
On Jun 2, 2009, at 4:39 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths that it allows you to easily
and quickly switch your attention among multiple development branches.
Well, so it does, if you haven't got any
Andres Freund escribió:
git clone --reference common_repo
+ small
+ staying small
+ fast
+ windows supported
+- push/fetch needed
- possibly unsecure if you delete from the master repository - which one
can easily prevent
git clone --shared
Essentially the same as the last above
I
Stephen Frost escribió:
I hope this isn't anything particularly special because I feel like I've
been doing it forever, but..
==# cvs -z3 co pgsql
==# mkdir pgsql.build
==# cd pgsql.build
==# ../pgsql/configure --my-args-here
==# make
...
Keeps all the build files and everything in
Andres Freund and...@anarazel.de writes:
On 06/03/2009 01:39 AM, Tom Lane wrote:
But rebuilding the Linux kernel is hardly a zero-cost operation,
so how have Linus and co failed to notice this problem? There
must be some trick they're using that I haven't heard about, or
they'd not be nearly
* Tom Lane t...@sss.pgh.pa.us [090602 20:18]:
Yeah, I thought about building out of tree, with a different build tree
for each branch and VPATH pointing at the common source tree (working
copy). That would probably work if it weren't that switching to branch
B and then back to branch A has
On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Andres Freund escribió:
git clone --reference common_repo
+ small
+ staying small
+ fast
+ windows supported
+- push/fetch needed
- possibly unsecure if you delete from the master repository - which one
can
1 - 100 of 105 matches
Mail list logo
