* Petr Baudis ([EMAIL PROTECTED]) wrote:
here is Cogito 0.12.1, another desperate attempt to keep pace with
'@' or Linus, the named Human Master Coder. (Linus, the Human Master
Coder, mumbles arcane do { formulae } while (0)! Some kind of force
seems to attack your mind. Everything
Hi, Marc Singer wrote:
v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
You can create your own parent-less commit for that tree.
(It's what I did...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. |
[EMAIL PROTECTED] (Eric W. Biederman) writes:
This patch adds a command git-id for use on
the command line to see what git will set your id too,
and for use in scripts (git-tag-script) so they can get your git id.
The common code for computing the git-id is moved to ident.c
Fix parse_date
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
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 having the
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 with just
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
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
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
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
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
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,
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 you
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
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
stuff,
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 example). Naming
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-diff-cache,
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't ever done
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
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/head-name
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 same
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
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 well.
Eric
-
To
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*
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
* 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 line
* 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
Provides:
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
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
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
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
*/
if
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
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
Matthias Urlichs smurf at 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
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
Chris Wedgwood cw at 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 clobber
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 should we pick a
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
Eric W. Biederman ebiederm at 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
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 intentions, but wouldn't
40 matches
Mail list logo
