* Re: git-status too verbose?
From: Joshua N Pritikin @ 2006-03-07 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacc36r4v.fsf@assigned-by-dhcp.cox.net>
On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
> HEAD->index index->files
> ------------------------------------------------
> hello.c unmodified modified
> world.c modified unmodified
> frotz.c new unmodified
> ...
> garbage.c~ ??? n/a
For what it's worth, this chart immediately made sense to me and I would
prefer it to the current git-status output.
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Shawn Pearce @ 2006-03-07 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkvn54sv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I totally didn't expect that behavior. But I should have. It makes
> > perfect sense.
>
> Good to hear that you two did not lose any data. I think the
> command should be documented as "not for interactive use without
> understanding what it does" ;-).
>
> What was the reason you wanted to use it? I think we should
> have a wrapper command to do what you wanted to achieve, so that
> people do not have to run unpack-objects by hand.
Don't bother.
I wanted to explode a pack because I'm starting work on an Eclipse
plugin for GIT. I thought I'd try going down the road of letting
the plugin read the repository directly, and write loose objects
directly, but leave pack construction to the native C code. So I
tried to clone my local GIT repository to a new directory (thus
had no loose objects at all) and unpack it to get loose objects.
That didn't go so well. :-)
So now I'm currently just playing around with a tiny repository I
created for testing (something like 50 objects total). Since I have
never packed it everything is loose, and that's working out OK...
I've already got loose object reading working, but thanks to
the trivially simple repository format in GIT (thanks Linus,
et.al.!) that amounted to a trivial Java implementation so its
nothing to really brag about yet. :-)
--
Shawn.
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: Mike McCormack @ 2006-03-07 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpskz5aqh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The only two and half minor issues I might have about this are:
>
> (1) is the type text/x-patch appropriate?
I'm no expert on MIME types, unfortunately. Maybe text/x-diff makes
more sense? A few different projects require one of those two types
for diffs sent as attachments. My main concern is that mailers can
recognize that the attachment is text, then displayed with the message
so that people can see the patch without opening the attachment.
> (2) is it possible to cheaply come up with a safe mime-magic,
> instead of a hardcoded long string and hope it does not
> clash?
I agree that using a hardcoded long string isn't that great. Reading
all of the "diff-tree -p" output seems a bit expensive. How about using
some part of the patch's SHA1 combined with date/time?
> The remaining half issue is if would it make sense to sometimes
> optionally use non 8-bit CTE for the patch part.
Maybe allow something like:
git-format-patch --attach=quoted-printable
where the default would be 8bit. This require adding a perl script for
each Content-Transfer-Encoding that we support.
Mike
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: A Large Angry SCM @ 2006-03-07 3:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike McCormack, git
In-Reply-To: <7vpskz5aqh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicely done.
...
> The only two and half minor issues I might have about this are:
>
...
>
> (2) is it possible to cheaply come up with a safe mime-magic,
> instead of a hardcoded long string and hope it does not
> clash?
Base64 encode a large number (160?) of bits from /dev/urandom.
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Junio C Hamano @ 2006-03-07 3:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060307022926.GB29180@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I totally didn't expect that behavior. But I should have. It makes
> perfect sense.
Good to hear that you two did not lose any data. I think the
command should be documented as "not for interactive use without
understanding what it does" ;-).
What was the reason you wanted to use it? I think we should
have a wrapper command to do what you wanted to achieve, so that
people do not have to run unpack-objects by hand.
One thing I _could_ think of is to explode a contaminated pack
so that you can repack. For example, every time I do "git
repack -a -d", the resulting pack ends up containing a couple of
commits from my "pu" branch that will become dangling when I
redo "pu" the next time. But then "git repack -a -d" is so
inexpensive these days, without unpacking things first, I do not
see the point of exploding a pack using unpack-objects in the
first place.
^ permalink raw reply
* Re: cvsimport woes
From: Martin Langhoff @ 2006-03-07 3:06 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <440C68B9.9030305@asianetindia.com>
On 3/7/06, Rajkumar S <rajkumars@asianetindia.com> wrote:
> You can use this script to reproduce this problem.
Rajkumar, does it work better if you add "sleep 10" before each
invocation of git-cvsimport?
cheers,
martin
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Shawn Pearce @ 2006-03-07 2:29 UTC (permalink / raw)
To: git
In-Reply-To: <200603070213.02805.blaisorblade@yahoo.it>
Blaisorblade <blaisorblade@yahoo.it> wrote:
> It's not a bug, it's an undocumented feature. It should be documented as
> "git-unpack-objects < $pack; rm $pack" is something one would deem correct at
> first glance (luckily I just moved the pack away and did git-fsck-cache).
>
> To write an object, git-unpack-objects ends in
>
> unpack-objects.c:write_object -> sha1_file.c:write_sha1_file:
>
> /* Normally if we have it in the pack then we do not bother writing
> * it out into .git/objects/??/?{38} file.
> */
>
> This indeed works, so the files aren't unpacked.
Funny, I just did the exact same thing today, scratched my head and
said ``what did I just do!?!?!'' as I had deleted the pack before
discovering that nothing was actually unpacked. *sigh* At least
it was a clone of the real repository and thus didn't matter to me.
I totally didn't expect that behavior. But I should have. It makes
perfect sense.
--
Shawn.
^ permalink raw reply
* git-unpack-objects < pack file in repository doesn't work!
From: Blaisorblade @ 2006-03-07 1:13 UTC (permalink / raw)
To: git
It's not a bug, it's an undocumented feature. It should be documented as
"git-unpack-objects < $pack; rm $pack" is something one would deem correct at
first glance (luckily I just moved the pack away and did git-fsck-cache).
To write an object, git-unpack-objects ends in
unpack-objects.c:write_object -> sha1_file.c:write_sha1_file:
/* Normally if we have it in the pack then we do not bother writing
* it out into .git/objects/??/?{38} file.
*/
This indeed works, so the files aren't unpacked.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: PATCH: Allow format-patch to attach patches
From: Junio C Hamano @ 2006-03-07 1:01 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <440C352C.9070009@codeweavers.com>
Nicely done.
Especially I like the part that you explicitly set charset to
UTF-8 to the primary part.
The only two and half minor issues I might have about this are:
(1) is the type text/x-patch appropriate?
(2) is it possible to cheaply come up with a safe mime-magic,
instead of a hardcoded long string and hope it does not
clash?
You can just say "Yes it is an established practice, widely
accepted and that is what you are responding to so obviously you
can grok it ;-)" to (1). About (2), you would probably need to
read the "diff-tree -p" output beforehand if we want to be
absolutely sure, so punting on the issue like this might be the
best practical approach for now, but I am asking it anyway
because people may have better ideas.
The remaining half issue is if would it make sense to sometimes
optionally use non 8-bit CTE for the patch part. I do _NOT_
want to receive CTE=QP patch myself, nor I want to encourage it
(actually I would want to actively discourage it), but I do not
mind if people find use of such a patch in a distant corner of
the galaxy where I do not have to touch such a patch.
^ permalink raw reply
* Re: git-status too verbose?
From: Junio C Hamano @ 2006-03-07 0:21 UTC (permalink / raw)
To: Eric Jaffe, Carl Worth; +Cc: git
In-Reply-To: <38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com>
"Eric Jaffe" <jaffe.eric@gmail.com> writes:
> I was wondering if anyone else thinks that git-status should be more
> like "git-diff --name-status". That is,
> # A a/newfile.c
> # M a/oldfile.c
>
> instead of
> # new file: a/newfile.c
> # modified: a/oldfile.c
Why do people think mysterious single letter abbreviation is
better than spelled out words in an output meant for human
consumption?
The tag letters you get from "ls-files -t" are inconsistent with
what you would get from all the other git tools for historical
reasons, so if you want to do a single-letter abbreviation, you
first need to come up with a set of letters and translate the
output from ls-files -t into that.
Although I personally like Carl's suggestion a lot, I am still
ambivalent about it a bit.
I agree that it would be useful if we had a tool that showed the
two status that matter for each file, grouped together on one
line, e.g.
HEAD->index index->files
------------------------------------------------
hello.c unmodified modified
world.c modified unmodified
frotz.c new unmodified
...
garbage.c~ ??? n/a
for the current index file and the current HEAD commit.
You obviously need to learn how to read it though. The first
column means what you _would_ commit if you just said "git
commit" without doing anything else now; the second column is
what you _could_ commit if you did some update-index and then
said "git commit" (or ran "git commit" with paths arguments).
I think it is a valid view for people who know how internally
git barebone porcelain works using git lowlevel, and to them
(including me), the above is more concise and appear useful.
But I am not sure if it is appropriate for "git status", which
is the tool for commit-preview. The index "git status" is
showing is the index you would get if you were to run "git
commit" with the same set of parameters, exactly for that reason
(e.g. "git status -a -v" would see "unmodified" for all tracked
paths in index->files column in the above output).
^ permalink raw reply
* Re: SSH with alternative port number?
From: Brandon Philips @ 2006-03-06 21:59 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060306214418.66E153525CB@atlas.denx.de>
Hello Wolfgang-
man(5) ssh_config
Add something like this to your .ssh/config file:
Host example
Hostname ssh.example.com
Port 2222
User wolfgang
Then use "example" as the hostname for the git commands instead of
ssh.example.com.
Best,
Brandon
--
http://ifup.org
On 22:44 Mon 06 Mar , Wolfgang Denk wrote:
> Hi,
>
> is there any way to specify an alternative port number for SSH based
> remote repository access?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> "Here's a fish hangs in the net like a poor man's right in the law.
> 'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: SSH with alternative port number?
From: Belmar-Letelier @ 2006-03-06 22:01 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20060306214418.66E153525CB@atlas.denx.de>
Wolfgang Denk a écrit :
> Hi,
>
> is there any way to specify an alternative port number for SSH based
> remote repository access?
>
> Best regards,
>
> Wolfgang Denk
>
Use your .ssh/config file
$ more /home/luis/.ssh/config
host 217.111.187.226
hostname bmi
port 1234
Luis
--
Luis Belmar-Letelier
^ permalink raw reply
* SSH with alternative port number?
From: Wolfgang Denk @ 2006-03-06 21:44 UTC (permalink / raw)
To: git
Hi,
is there any way to specify an alternative port number for SSH based
remote repository access?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Here's a fish hangs in the net like a poor man's right in the law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
^ permalink raw reply
* Re: Looking for SCM that lets me publish part of a repository
From: Sam Vilain @ 2006-03-06 20:58 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1141608679.16980.12.camel@mattlaptop>
Matt McCutchen wrote:
>Dear GIT people,
>
>For the last week or so, I have been looking for a SCM system to hold
>many of my projects, some of which are available to the public and
>others of which are not. It would be nice if I could use a single large
>private repository on my computer with each project in a separate
>folder. Then I would like to pull some of the projects (but not all)
>into a world-readable repository on my Web site. I have looked at
>several SCMs and have not found a way to make any of them do this, but I
>like GIT best on other grounds. Is there a way I can coerce GIT to
>clone and pull one folder out of a repository but ignore the rest?
>
>
SVK works like this, you get one (by default) repository in your ~ which
you then mirror published projects to, and it tracks local changes as a
branch which you can then commit back 'upstream' (or to your published
repository) with.
Jeff King also recently posted a script to extract out a part of a
repository into another one, which is a related concept.
Sam.
^ permalink raw reply
* Re: any problems with new branch of gitk?
From: Alex Riesen @ 2006-03-06 20:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17419.24973.402408.237865@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Paul Mackerras, Sun, Mar 05, 2006 23:09:17 +0100:
> I'm planning to pull the `new' branch of the gitk repository into the
> master branch, making the new version of gitk the standard version
> that will go into the git.git repository. As far as I know the new
> version does everything the old version does. Does anyone know of any
> problems with the new gitk that weren't in the old one?
I don't if that was intended (see the screenshot attached), but some
lines miss arrows. Click on where the arrow would be works (jump to
counterpart arrow). Never have this with the old gitk.
Tcl/Tk 8.4.9 (Gentoo).
[-- Attachment #2: no-arrows.jpg --]
[-- Type: image/jpeg, Size: 21201 bytes --]
[-- Attachment #3: no-arrows2.jpg --]
[-- Type: image/jpeg, Size: 14369 bytes --]
^ permalink raw reply
* Re: [PATCH] git-blame: Make the output human readable
From: linux @ 2006-03-06 19:33 UTC (permalink / raw)
To: junkio; +Cc: git
Well, getting 15 characters in UTF-8 is easy (just stop before the 16th
byte for which ((b & 0xc0) != 0x80)), but what about combining characters?
You've got accents and stuff to worry about. And the annoying fact that
Unicode defined accents as suffixes, so you have to go past the 15th
column to include all of the
And then there's that fact that many characters are traditionally
represented as double-wide forms, even on character terminals.
See http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c for details
an an example implementation of wcwidth().
Using that, it would be something like (compiles but untested):
/*
* Return the number of bytes from the nul-terminated utf8 string
* that can be printed in at most max columns using a monospaced
* font. *actual returns the number of columns actually occupied,
* which may be less than max.
*
* Output is truncated before any control characters or illegal
* UTF-8 sequences.
*/
unsigned
fit_columns(char const *utf8, unsigned max, unsigned *actual)
{
char const * const origin = utf8;
unsigned width = 0;
unsigned pos = 0;
unsigned c;
for (;;) {
unsigned w;
unsigned c = *utf8++;
/* Part 1: Parse the next Unicode code point */
if (c < 0x20) {
break; /* Control character - stop */
} else if (c < 0x7F) {
w = 1; /* Standard ASCII */
} else if (c < 0xC2 || c > 0xF4) {
break; /* DEL or illegal Unicode */
} else {
/* Multi-byte UTF-8 sequence */
unsigned n;
unsigned char byte = *utf8++;
if (c < 0xE0) {
/* 2-byte sequence: U+0080..U+07FF */
n = 1;
c &= 0x1F;
} else if (c < 0xF0) {
/* 3-byte sequence: U+0800..U+FFFF */
if (c == 0xE0 && byte < 0xA0)
break; /* < /U+0800 */
n = 2;
c &= 0x0F;
} else {
/* 4-byte sequence: U+10000..U+10FFFF */
if (byte < 0x90 ? c == 0xF0 : c == 0xF4)
break; /* < 10000 or > 10FFFF */
n = 3;
c &= 0x07;
}
for (; n--; byte = *utf8++) {
if (byte & 0xc0 != 0x80)
goto done; /* Double break */
c = (c << 6) | (byte & 0x3f);
}
/* Now find the width of it */
w = wcwidth(c);
if (w == -1)
break;
}
/* Part 2: Figure out if it will fit */
if (width + w > max)
break; /* Would exceed space - stop */
/* Part 3: It fits; update our statistics */
width += w;
pos = (unsigned)(utf8 - origin);
}
done:
if (actual)
*actual = width;
return pos;
}
^ permalink raw reply
* Pulling tags from git.git
From: David Ho @ 2006-03-06 18:44 UTC (permalink / raw)
To: git
Hi,
I have been trying to pull from the git repo via rsync.
(rsync://rsync.kernel.org/pub/scm/git/git.git) I got all the commits
up to today but the tags since my initial cloning are missing.
I tried git pull --tags, I still only have old tags.
I switched to using the git protocol but that failed too.
git ls-remotes --tags showed, as expected, all the tags up to 1.2.4.
Is there a switch I missed?
Regards,
David
^ permalink raw reply
* Re: Pulling tags from git.git
From: David Ho @ 2006-03-06 18:54 UTC (permalink / raw)
To: git
In-Reply-To: <4dd15d180603061044h3f70d48bk8006c15e605fdca1@mail.gmail.com>
Okay sorry, git fetch --tags did the trick.
Just out of curiosity, should git pull --tags behave similarly since
the difference is git pull does a merge after a fetch?
David
On 3/6/06, David Ho <davidkwho@gmail.com> wrote:
> Hi,
>
> I have been trying to pull from the git repo via rsync.
> (rsync://rsync.kernel.org/pub/scm/git/git.git) I got all the commits
> up to today but the tags since my initial cloning are missing.
>
> I tried git pull --tags, I still only have old tags.
> I switched to using the git protocol but that failed too.
>
> git ls-remotes --tags showed, as expected, all the tags up to 1.2.4.
>
> Is there a switch I missed?
>
> Regards,
> David
>
^ permalink raw reply
* Re: git-status too verbose?
From: Shawn Pearce @ 2006-03-06 17:56 UTC (permalink / raw)
To: Carl Worth; +Cc: Eric Jaffe, git
In-Reply-To: <87irqrzcs7.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> On Sat, 4 Mar 2006 12:52:17 -0500, "Eric Jaffe" wrote:
> > I was wondering if anyone else thinks that git-status should be more
> > like "git-diff --name-status". That is,
> > # A a/newfile.c
> > # M a/oldfile.c
>
> Something like that does seem appealing.
>
> There are at least two issues with doing it:
>
> 1) It might be tricky coming up with canonical single characters to be
> used consistently within git. For example, git-ls-files currently
> does do some single-character state indication, but it can be
> rather confusing at times. For example:
>
> State Option Character
> ----- ------ ---------
> Modified -m C
> Unmerged -u M
> Cached -c H
>
> And that looks like a permanent problem. For legacy reasons,
> I don't think we can change either the options or the output
> characters of git-ls-files. But perhaps we could at least
> agree on a single, consistent mapping for all future uses.
>
> 2) In an important sense, git-status is not verbose enough. For
> example, given a single line such as the following:
>
> modified: some-file
>
> This could indicate at least two different states for some-file:
>
> 1) Modified and updated into the index
>
> 2) Modified in working tree, but not updated in the index
I've played around with this idea a little bit in pg's pg-status
command but I most likely do not have all cases covered.
In general I try to show HEAD<-->index first using uppercase letters
then index<-->working directory second in lowercase letters.
Here's the critical portion of pg-status:
git-diff-index --cached --name-status HEAD | sed -e 's/ / /'
if test $index_only = n
then
git-diff-files --name-status | sed \
-e 's/ / /' \
-e 's/^D /g /' \
-e 's/^M /m /' \
-e '/^U /d'
pg--ls-others | sed 's/^/x /'
fi
Thus far I've found it useful to behave this way and I haven't run
up against any states which didn't make immediate sense to me.
Here's the documentation I have in pg-status describing what it
can show:
Status indicators (displayed in column 1):
A : New file has been marked for addition with pg-add.
D : Existing file has been marked as deleted with pg-rm.
M : Existing file has been modified (and is known to the index).
U : File still has unmerged hunks, see pg-resolved.
m : Existing file (maybe) has been modified (use -q to know for sure).
g : File has been removed from directory but not marked with pg-rm.
x : File is not known to repository and isn't being ignored.
--
Shawn.
^ permalink raw reply
* Re: git-status too verbose?
From: Carl Worth @ 2006-03-06 17:46 UTC (permalink / raw)
To: Eric Jaffe; +Cc: git
In-Reply-To: <38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
On Sat, 4 Mar 2006 12:52:17 -0500, "Eric Jaffe" wrote:
> I was wondering if anyone else thinks that git-status should be more
> like "git-diff --name-status". That is,
> # A a/newfile.c
> # M a/oldfile.c
Something like that does seem appealing.
There are at least two issues with doing it:
1) It might be tricky coming up with canonical single characters to be
used consistently within git. For example, git-ls-files currently
does do some single-character state indication, but it can be
rather confusing at times. For example:
State Option Character
----- ------ ---------
Modified -m C
Unmerged -u M
Cached -c H
And that looks like a permanent problem. For legacy reasons,
I don't think we can change either the options or the output
characters of git-ls-files. But perhaps we could at least
agree on a single, consistent mapping for all future uses.
2) In an important sense, git-status is not verbose enough. For
example, given a single line such as the following:
modified: some-file
This could indicate at least two different states for some-file:
1) Modified and updated into the index
2) Modified in working tree, but not updated in the index
Currently, git-status makes this distinction only in the header
lines for the separate chunks of its output. But, when there are a
lot of files involved, and things start scrolling, it's sometimes
"hard" to associate the right header with the file of interest.
So, what I've wanted from git-status is a complete encoding of the
file's state on the same line as the output of the filename. Maybe
something that uses two characters per file would work well.
But I don't have a concrete suggestion for that---I don't think
I've even successfully enumerated all possible file states with git
yet...
-Carl
PS. If we do tighten up the output of git-status, I'd also vote for
making the per-chunk headers use only 1 line each instead of 2, and
also eliminating the second blank line separating each chunk.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Any news on an Eclipse plugin?
From: Shawn Pearce @ 2006-03-06 17:32 UTC (permalink / raw)
To: git
I'm considering starting an Eclipse plugin for GIT. So I did
some digging to see if any existing projects have anything I can
contribute to (rather than starting from scratch) but I only turned
up a thread from May 2005 started by Jon Seymour:
http://www.gelato.unsw.edu.au/archives/git/0505/3357.html
anyone know anything newer? If there's nothing existing worth
starting with other than the CVS or SVN plugins (as mentioned in
this thread) I'll probably start putting together a prototype and
start making it available early next week.
I'm going to carefully read the thread that I linked to above before
writing anything, so there's no need to start getting into the core
and not so core discussion again. I'll read it over for myself. :-)
--
Shawn.
^ permalink raw reply
* Re: cvsimport woes
From: Rajkumar S @ 2006-03-06 16:52 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90603060137o758ea7ch6c40652ad86a102a@mail.gmail.com>
Martin Langhoff wrote:
> On 3/6/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> you don't seem to be making any silly mistake. Make sure you are using
>> a recent git, and a recent cvsps. Actually you want the _latest_ cvsps
>> (2.1 I think).
>
> Scratch this bit, naturally. I wasn't 100% paying attention. Still,
> the rest of the answer should kinda/sorta make sense.
Thanks for your kind replies.
I was also talking to Matthias Urlichs (the author of cvsimport) What he
says is that the first version is still checked out because
the import does not do the fast-forward/merge by itself.
I am wondering how can I do the fast-forward. I had a long chat in irc
but did not find any solution to this particular issue. I tried git
merge, but that does not work as the command needs more arguments. (I am
a git newbie and git concepts are still bit fuzzy for me)
I would appreciate a lot if some one can point me in the right direction.
If you are not following this thread, the problem I am talking about is
that when I do a cvsimport for a second time (ie do a git cvsimport;
update the cvs; do a cvsimport again) the second updates are not visible
in the current directory, though they are present in the git database.
You can use this script to reproduce this problem.
export CVSROOT=/home/raj/cvsroot
rm -rf cvsroot/ git/ src/ /home/raj/.cvsps
mkdir cvsroot git src
cvs init
cd src/
echo "Line one" > file.txt
echo "Line one" > file1.txt
echo "Line one" > file2.txt
cvs import -m "Imported sources" src start realstart
cd ..
rm -rf src/
cvs co src
git cvsimport -v -k -u -m -d $CVSROOT -C git/ src
cd git
git status
cd ..
cd src/
echo "Line two" >> file.txt
echo "Line two" >> file1.txt
cvs commit -m "v2.0"
cd ..
git cvsimport -v -k -u -m -d $CVSROOT -C git/ src
cd git
git status
cd ..
Now the cvs version of file.txt and git version are different.
Thanks and regards,
raj
^ permalink raw reply
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Ryan Anderson @ 2006-03-06 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0603061016320.1422@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Johannes Schindelin wrote:
>Hi,
>
>On Sun, 5 Mar 2006, Ryan Anderson wrote:
>
>
>
>>+use Data::Dumper;
>>
>>
>
>You really need this?
>
>
I keep adding it back in when debugging things, and then promptly forget
to remove it when I cull the debugging back out.
It's a core module, so it shouldn't be a significant issue for any porting
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* PATCH: Allow format-patch to attach patches
From: Mike McCormack @ 2006-03-06 13:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
The --attach patch to git-format-patch to attach patches instead of
inlining them. Some mailers linewrap inlined patches (eg. Mozilla).
---
git-format-patch.sh | 52
++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 45 insertions(+), 7 deletions(-)
[-- Attachment #2: b17ef6b06ebaaf9b6d1f47c6a788cffd77e2b927.diff --]
[-- Type: text/x-patch, Size: 3182 bytes --]
b17ef6b06ebaaf9b6d1f47c6a788cffd77e2b927
diff --git a/git-format-patch.sh b/git-format-patch.sh
index bbd2e55..2ebf7e8 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n | -k] [-o <dir> | --stdout] [--signoff] [--check] [--diff-options] <his> [<mine>]'
+USAGE='[-n | -k] [-o <dir> | --stdout] [--signoff] [--check] [--diff-options] [--attach] <his> [<mine>]'
LONG_USAGE='Prepare each commit with its patch since <mine> head forked from
<his> head, one file per patch formatted to resemble UNIX mailbox
format, for e-mail submission or use with git-am.
@@ -18,7 +18,9 @@ is ignored if --stdout is specified.
When -n is specified, instead of "[PATCH] Subject", the first
line is formatted as "[PATCH N/M] Subject", unless you have only
-one patch.'
+one patch.
+
+When --attach is specified, patches are attached, not inlined.'
. git-sh-setup
@@ -40,6 +42,8 @@ do
-d|--d|--da|--dat|--date|\
-m|--m|--mb|--mbo|--mbox) # now noop
;;
+ --at|--att|--atta|--attac|--attach)
+ attach=t ;;
-k|--k|--ke|--kee|--keep|--keep-|--keep-s|--keep-su|--keep-sub|\
--keep-subj|--keep-subje|--keep-subjec|--keep-subject)
keep_subject=t ;;
@@ -150,6 +154,11 @@ done >$series
me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
headers=`git-repo-config --get format.headers`
+case "$attach" in
+"") ;;
+*)
+ mimemagic="050802040500080604070107"
+esac
case "$outdir" in
*/) ;;
@@ -174,7 +183,7 @@ titleScript='
process_one () {
perl -w -e '
-my ($keep_subject, $num, $signoff, $headers, $commsg) = @ARGV;
+my ($keep_subject, $num, $signoff, $headers, $mimemagic, $commsg) = @ARGV;
my ($signoff_pattern, $done_header, $done_subject, $done_separator, $signoff_seen,
$last_was_signoff);
@@ -229,6 +238,16 @@ while (<FH>) {
print "$headers\n";
}
print "Subject: $_";
+ if ($mimemagic) {
+ print "MIME-Version: 1.0\n";
+ print "Content-Type: multipart/mixed;\n";
+ print " boundary=\"------------$mimemagic\"\n";
+ print "\n";
+ print "This is a multi-part message in MIME format.\n";
+ print "--------------$mimemagic\n";
+ print "Content-Type: text/plain; charset=UTF-8; format=fixed\n";
+ print "Content-Transfer-Encoding: 8bit\n";
+ }
$done_subject = 1;
next;
}
@@ -254,14 +273,33 @@ if (!$signoff_seen && $signoff ne "") {
}
print "\n---\n\n";
close FH or die "close $commsg pipe";
-' "$keep_subject" "$num" "$signoff" "$headers" $commsg
+' "$keep_subject" "$num" "$signoff" "$headers" "$mimemagic" $commsg
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
echo
+ case "$mimemagic" in
+ '');;
+ *)
+ echo "--------------$mimemagic"
+ echo "Content-Type: text/x-patch;"
+ echo " name=\"$commit.diff\""
+ echo "Content-Transfer-Encoding: 8bit"
+ echo "Content-Disposition: inline;"
+ echo " filename=\"$commit.diff\""
+ echo
+ esac
git-diff-tree -p $diff_opts "$commit"
- echo "-- "
- echo "@@GIT_VERSION@@"
-
+ case "$mimemagic" in
+ '')
+ echo "-- "
+ echo "@@GIT_VERSION@@"
+ ;;
+ *)
+ echo
+ echo "--------------$mimemagic--"
+ echo
+ ;;
+ esac
echo
}
^ permalink raw reply related
* [PATCH] Allow adding arbitary lines in the mail header generated by format-patch.
From: Mike McCormack @ 2006-03-06 13:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
Entries may be added to the config file as follows:
[format]
headers = "Organization: CodeWeavers\nTo: wine-patches
<wine-patches@winehq.org>\n"
---
git-format-patch.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
[-- Attachment #2: cdd5602230adecce4a7dd274b4f81d52681410cb.diff --]
[-- Type: text/x-patch, Size: 1147 bytes --]
cdd5602230adecce4a7dd274b4f81d52681410cb
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 2bd2639..bbd2e55 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -149,6 +149,7 @@ do
done >$series
me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
+headers=`git-repo-config --get format.headers`
case "$outdir" in
*/) ;;
@@ -173,7 +174,7 @@ titleScript='
process_one () {
perl -w -e '
-my ($keep_subject, $num, $signoff, $commsg) = @ARGV;
+my ($keep_subject, $num, $signoff, $headers, $commsg) = @ARGV;
my ($signoff_pattern, $done_header, $done_subject, $done_separator, $signoff_seen,
$last_was_signoff);
@@ -224,6 +225,9 @@ while (<FH>) {
s/^\[PATCH[^]]*\]\s*//;
s/^/[PATCH$num] /;
}
+ if ($headers) {
+ print "$headers\n";
+ }
print "Subject: $_";
$done_subject = 1;
next;
@@ -250,7 +254,7 @@ if (!$signoff_seen && $signoff ne "") {
}
print "\n---\n\n";
close FH or die "close $commsg pipe";
-' "$keep_subject" "$num" "$signoff" $commsg
+' "$keep_subject" "$num" "$signoff" "$headers" $commsg
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
echo
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox