Eric Blake wrote:
> I think the easiest way to do this is with git-clone. First, grab the
> entire repository:
>
> $ git clone git://git.sv.gnu.org/gnulib
>
> Then create your topic clone, which shares as much repository information
> as possible with the original, but can reside on a different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 9/17/2007 5:12 PM:
>
> I would like to avoid using "git checkout" to switch from one branch to
> another in the same directory. Simply, I'm more comfortable working in
> different directories. I assume it makes it easier t
On Monday 17 September 2007, Bruno Haible wrote:
> What do you use for recursive grepping? Is "grep -r --exclude=dir=.git"
> working fine?
there is no way to filter directories with grep directly ... you have to chain
find|xargs-grep sort of junk
since git only takes up the toplevel with .git it
> What do you use for recursive grepping? Is "grep -r --exclude=dir=.git"
> working fine?
'git grep' works nicely - it recursively greps all files tracked
under version control, while omitting generated files.
--
Eric Blake
--
View this message in context:
http://www.nabble.com/git-and-grep-
I've made bad experiences with git repositories stored on NFS volumes
(because git apparently likes to make hard links, which has problems
if the NFS server is on MacOS X). Can you confirm that?
Bruno
What do you use for recursive grepping? Is "grep -r --exclude=dir=.git"
working fine?
Bruno
Hi Jim,
Thanks for reminding us how git works; it's indeed 8 months since I last
used it.
Three questions though:
I) About merge commits.
> However, I have one strong preference that I haven't yet mentioned:
> =
> Be careful not to push merge commits.
> =
Jim Meyering wrote:
> I seem to recall that the RCSINIT envvar can
> influence the format of dates output by cvs, too.
>
> From back when I cared more about that, I used this:
> export RCSINIT='-zLT'
This has no effect for me. Possible explanation: I don't see any mention of
RCSINIT in the cvs s
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> > - The expansion of dates is different (see attached diff). Here the
>> > git-based
>> > server uses ISO 8601 notation. (Not that it's bad. It's just different.)
>> >
>> > - Regarding the dates in "cvs log", it's the opposite: Her
Jim Meyering wrote:
> > - The expansion of dates is different (see attached diff). Here the
> > git-based
> > server uses ISO 8601 notation. (Not that it's bad. It's just different.)
> >
> > - Regarding the dates in "cvs log", it's the opposite: Here the original
> > CVS uses ISO 8601 notation
Here's a preliminary draft.
If you go through it, please tell me about anything
that seems confusing, pointless, etc.
Eventually I'll merge into it some of the things mentioned
in http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268.
Jim
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> Now that the cvs-to-git gateway is set up, I am ready to switch
>> gnulib development to git.
>
> I like it.
>
>> There are probably tools and services (web?) that rely on having
>> an actual CVS repository, bu
Jim Meyering <[EMAIL PROTECTED]> writes:
> Now that the cvs-to-git gateway is set up, I am ready to switch
> gnulib development to git.
I like it.
> There are probably tools and services (web?) that rely on having
> an actual CVS repository, but people who care about those can take
> it upon the
Now that the cvs-to-git gateway is set up, I am ready to switch
gnulib development to git.
There are probably tools and services (web?) that rely on having
an actual CVS repository, but people who care about those can take
it upon themselves to adapt them to git -- or to the git/cvs
emulation, if
14 matches
Mail list logo
