Hi, Dan Kohn wrote:
> UBUNTU 5.04
You want zlib1g-dev, libssl-dev, asciidoc, xmlto, libcurl3-dev.
I'll prepare a patch to do a simple set of Debian packages (so that "make
debian" works) for git(k)/cogito. I already use them locally, but that
branch is too unclean. :-/
--
Matthias Urlichs |
On Tue, Jul 12, 2005 at 09:37:00PM +, Junio C Hamano wrote:
> > if [ "$newhead" ]; then
> > echo "Committed as $newhead."
> > - echo $newhead >$_git/HEAD
> > + echo_to_file $newhead $_git/HEAD
> > [ "$merging" ] && rm $_git/merging $_git/merging-sym $_git/merge-base
>
> Good inten
When I run cg-init on an empty directory, it displays the following output:
$ cg-init
defaulting to local storage area
find: *: No such file or directory
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as d25f00309e336884854de8cab8ab9e819294bb83.
Is the find error mess
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> I switched to using the git version in source control.
> Checkout/branching works great. :-)
>
> But, this version of git doesn't let me do
>
> # git checkout -f v2.6.11
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
>
Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
curl's ssl peer verification.
Only use curl for http transfers, instead of curl and wget.
Make curl check ~/.netrc for credentials.
---
commit 229718f5723f81304c7c038c18d1e1bd630026ae
tree 501594e7b424855f08d7bef6bd4f9721d40d4a3c
p
Hi,
Sven Verdoolaege:
> Previously, git-cvsimport-script would fail
> on revisions with more than one digit.
>
Ouch. Thanks.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
When a guy
Eric W. Biederman xmission.com> writes:
> Since we are still looking at this there is one change in the user
> interface I would like to make to simplify things for the end user.
> The only time when GIT_COMMITTER != GIT_AUTHOR is in git_commit_script
> when we you are making a new commit based o
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Eric,
> I ended up coding the ident stuff a bit differently, and I didn't do done
> the tag/git-id part yet. Can you check out my latest commit (pushed out,
> but it will probably take a few minutes to mirror out), and do the final
> tag stuff based
On Mon, 11 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > But what about the branch name? Should we just ask the user? Together with
> > a flag, like
> >
> > git checkout -b new-branch v2.6.12
> >
> > for somebody who wants to specify the branch name? Or s
Chris Wedgwood f00f.org> writes:
> if [ "$newhead" ]; then
> echo "Committed as $newhead."
> - echo $newhead >$_git/HEAD
> + echo_to_file $newhead $_git/HEAD
> [ "$merging" ] && rm $_git/merging $_git/merging-sym $_git/merge-base
Good intentions, but wouldn't the above clobb
git-cvsimport-script: parse multidigit revisions.
Previously, git-cvsimport-script would fail
on revisions with more than one digit.
Signed-off-by: Sven Verdoolaege <[EMAIL PROTECTED]>
---
commit 7b5f7bcc470528beb4a0b6ef1c93ce634aaa0158
tree db66d0759f97016bd123e2351aa0e77585e3177b
parent e30e81
Matthias Urlichs smurf.noris.de> writes:
>
> Hi, Marc Singer wrote:
>
> > # git-update-cache `git-diff-cache | cut -f2`
>
> g-d-c should have an option to print file names only. All that cutting
> and argument-backtick-ing gets pretty nasty when there are a lot of files,
> or if they contain
Eric W. Biederman xmission.com> writes:
>
> Junio C Hamano cox.net> writes:
>
> > The only in-tree user after your patch is applied is the tagger
> > stuff, so in that sense committer_ident may make more sense.
>
> There is also the commit path, and that comes from C. I'm not
> quite certain
On Tue, 12 Jul 2005, Jerry Seutter wrote:
>
> The README file for cogito/git mentions that there is an ssl library
> included in the source which you can use if you don't have openssl. It
> doesn't give any directions on how to use it, however. You could try
> looking into using that.
Use
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Seutter
> Sent: Tuesday, July 12, 2005 1:01 PM
> To: Dan Kohn; git@vger.kernel.org
> Subject: RE: Compilation troubles
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> >
Sometimes (often actually) I do:
cp -Rl tree1 tree2# new tree with implied CoW semantics
cd tree2
cg-update # or similar
the latter well frob .git/HEAD or similar by doing echo foo > bar
which obviously breaks the intended CoW semantics.
How would pe
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dan Kohn
> Sent: Tuesday, July 12, 2005 12:34 PM
> To: git@vger.kernel.org
> Subject: Compilation troubles
>
> I apologize for what are probably obvious compilation questions, but I
> suspect other
apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1143,7 +1143,7 @@ static void show_rename_copy(struct patc
*/
i
Eric,
I ended up coding the ident stuff a bit differently, and I didn't do done
the tag/git-id part yet. Can you check out my latest commit (pushed out,
but it will probably take a few minutes to mirror out), and do the final
tag stuff based on that?
Linus
-
To unsubscribe fr
On Tue, Jul 12, 2005 at 11:33:36AM -0700, Dan Kohn wrote:
> I apologize for what are probably obvious compilation questions, but I
> suspect other newbies are encountering them as well. I'm having trouble
> installing cogito 0.12.1 on both a vanilla Ubuntu box and on my account
> on a FreeBSD mach
I apologize for what are probably obvious compilation questions, but I
suspect other newbies are encountering them as well. I'm having trouble
installing cogito 0.12.1 on both a vanilla Ubuntu box and on my account
on a FreeBSD machine. I'm used to autoconf-built programs, so there's
probably jus
* Petr Baudis ([EMAIL PROTECTED]) wrote:
> where Chris Wright <[EMAIL PROTECTED]> told me that...
> > This is leftover from early naming, and is no longer relevant.
> >
> > Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
>
> Thanks, applied. BTW, Josh Boyer of Fedora suggested having the
>
>
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Tue, 12 Jul 2005, Eric W. Biederman wrote:
> > The name of the tarball needs to be updated as well.
>
> Yes, I noticed.
>
> I ended up renaming the spec-file too.
>
> Pushed out,
Yup, looks good.
-chris
-
To unsubscribe from this list: send the l
On Tue, 12 Jul 2005, Eric W. Biederman wrote:
>
> The name of the tarball needs to be updated as well.
Yes, I noticed.
I ended up renaming the spec-file too.
Pushed out,
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL
Junio C Hamano wrote:
Dan Holmsand <[EMAIL PROTECTED]> writes:
Repacking all of that to a single pack file gives, somewhat
surprisingly, a pack size of 62M (+ 1.3M index). In other words, the
cost of getting all those branches, and all of the new stuff from
Linus, turns out to be *negative* (pro
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Ahh. Dang, I should have remembered this. We should call the rpm
> "git-core-0.99", not just "git-0.99".
>
> Chris, I assume this is just changing the name in the spec-file from "git"
> to "git-core"?
The name of the tarball needs to be updated as we
On Tue, 12 Jul 2005, Eric W. Biederman wrote:
>
> One last issue with building packages. Some distros are still shipping
> GNU interactive tools so git as a package name for the rpm is problematic.
> At the very least it is extremely confusing that git-0.99 is a more
> recent package that git-4
On Tue, 12 Jul 2005, Petr Baudis wrote:
>
> Could we please have the branch name written to .git/head-name in case
> we switch the branch?
I wouldn't mind per se, but on the other hand I really _hate_ having
"parallel" information that can get out of sync. If you have two places
holding the s
Hi, Junio C Hamano wrote:
> Having said that, I do like the concept of keeping track of
> "which development line are we on, and what's most recent in
> it". The way I read your description of cg-seek, you currently
> have that information is either in .git/head-name and
> .git/refs/heads/ pair (
Hi, Marc Singer wrote:
> # git-update-cache `git-diff-cache | cut -f2`
g-d-c should have an option to print file names only. All that cutting
and argument-backtick-ing gets pretty nasty when there are a lot of files,
or if they contain special characters.
--
Matthias Urlichs | {M:U} IT De
http://www.darcs.net/DarcsWiki/DarcsGit
You're welcome to leave any questions you might have -- I'll try to
answer.
Juliusz
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Chris Wright <[EMAIL PROTECTED]> writes:
> * Linus Torvalds ([EMAIL PROTECTED]) wrote:
>> > And it does not pass my torture test of building rpm's on debian,
>> > but that is not a huge problem.
>>
>> Ok, why is debian problematic? Is there some missing dependency or
>> something? I really haven
On Tue, Jul 12, 2005 at 01:14:24AM -0700, Junio C Hamano wrote:
> Marc Singer <[EMAIL PROTECTED]> writes:
>
> > # git-diff-cache HEAD
> >
> > is really nice. But, do I really have to invoke git-update-cache with
> > every modified file? I could write a script to cul the filenames from
> > git-
Dear diary, on Tue, Jul 12, 2005 at 05:04:23PM CEST, I got a letter
where "Eric W. Biederman" <[EMAIL PROTECTED]> told me that...
> > By the way, I do not particularly like the name "git-id". There
> > could be IDs for different kinds (not just people) we would want
> > later (file IDs, for exampl
Junio C Hamano <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Eric W. Biederman) writes:
>
>> Should this default to git_author_ident or git_committer_ident?
>> I'm not really certain how we expect to use the different flavors.
>
> The only in-tree user after your patch is applied is the tagger
Daniel Barkalow wrote:
If I understand the curl documentation, you should be able to set options
on the curl object when it has just been created, if those options aren't
going to change between requests. Note that I make requests from multiple
places, but I use the same curl object for all of t
Catalin Marinas wrote:
Bryan Larsen <[EMAIL PROTECTED]> wrote:
template files for the "series" output of export, to put it into a
format that "sendpatchset" understands.
I thought about integrating sendpatchset into stgit but it is much
simpler to just generate a control file (especially if y
Bryan Larsen <[EMAIL PROTECTED]> wrote:
> import: the complement to export
It is written in the TODO file but didn't have time to do it. I'm
working on moving all the commands from main.py into separate files
under stgit/commands/ for a clearer view. This should be ready in the
next day or two and
cg-commit currently chokes when passed a very large list of files. Fix it.
This patch depends on your filenames not containing line feeds. No big deal,
lots of other parts of cogito break on filenames containing line feeds.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
cg-commit |8
Catalin Marinas wrote:
Stacked GIT 0.4 release is available from http://procode.org/stgit/
Very nice.
Here's my wishlist. Hopefully I'll be able to dig in and help out.
import: the complement to export
template files for the "series" output of export, to put it into a
format that "sendpatc
I do want to see various Porcelains to agree on how to store
state information in $GIT_DIR for doing common operations, when
they are conceptually compatible. The way they handle branches
may fall into that category. With the barebone GIT Porcelain,
"seek" like operation may simply be done by cre
Hi, Linus Torvalds wrote:
> I also don't see why, if OS-X already _does_ include the GNU tools, they
> couldn't be under /opt/fsf/bin or something like that, and then you could
> just do
>
> PATH=/opt/fsf/bin:$PATH
We could prepend /usr/lib/git to $PATH, and symlink them with their "real
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> Should this default to git_author_ident or git_committer_ident?
> I'm not really certain how we expect to use the different flavors.
The only in-tree user after your patch is applied is the tagger
stuff, so in that sense committer_ident may make mor
Marc Singer <[EMAIL PROTECTED]> writes:
> # git-diff-cache HEAD
>
> is really nice. But, do I really have to invoke git-update-cache with
> every modified file? I could write a script to cul the filenames from
> git-diff-cache, but I'm having a hard time believing that that is how
> others are
Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> >
> > Of course, if you want to create a new branch "my-branch" and _not_
> > check it out, you could have done so wit
CVS uses tags for lots of things.
Git doesn't.
Document that, so people may understand.
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -230,3 +230,33 @@ that contain this changed "if" sta
Dear diary, on Tue, Jul 12, 2005 at 02:33:45AM CEST, I got a letter
where Chris Wright <[EMAIL PROTECTED]> told me that...
> This is leftover from early naming, and is no longer relevant.
>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Thanks, applied. BTW, Josh Boyer of Fedora suggested havi
Dear diary, on Tue, Jul 12, 2005 at 07:52:18AM CEST, I got a letter
where Marc Singer <[EMAIL PROTECTED]> told me that...
> # git-diff-cache HEAD
>
> is really nice. But, do I really have to invoke git-update-cache with
> every modified file? I could write a script to cul the filenames from
>
48 matches
Mail list logo