* Re: How to remove a specific hunk
From: Johannes Schindelin @ 2007-10-26 18:19 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Pascal Obry, git list
In-Reply-To: <2669F76D-6FF2-4CCF-9337-639D84EE65E8@lrde.epita.fr>
Hi,
On Fri, 26 Oct 2007, Benoit SIGOURE wrote:
> On Oct 26, 2007, at 5:38 PM, Pascal Obry wrote:
>
> > Andreas,
> >
> > > Once you've added the other two hunks, they'll no longer show up in
> > > git-diff, so you can do something like this:
> > >
> > > $ git-add -i; # add the other two hunks to commit
> > > $ git-diff > middle-hunk.patch
> > > $ git-apply -R middle-hunk.patch
> > > test, test, test
> > > $ git-apply middle-hunk.patch
> >
> > Thanks, this will clearly work. I was expecting something more
> > integrated like a "git reset --interactive" or something like that :)
>
> That'd be great! :)
I skipped over the beginnings of this thread because of time constraints,
but would "git reset HEAD^ && git add -i" not helped you? git add -i
allows you to stage hunks, so by just _not_ staging _that_ hunk but
everything else, should have worked for you, right?
There's also git-gui which does all that graphically for you (remember the
right mouse button).
Ciao,
Dscho
^ permalink raw reply
* Re: git-svnimport
From: Steven Grimm @ 2007-10-26 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerrit Pape, git
In-Reply-To: <Pine.LNX.4.64.0710261745110.4362@racer.site>
Johannes Schindelin wrote:
>> I'm not sure these are worth fixing, I'd rather suggest to drop
>> git-svnimport in favor of git-svn, and not installing it in future
>> versions.
>>
> I already proposed this. The outcome was... silent.
>
Me too, and same reaction.
So I vote we interpret that as, "No objections from anyone."
-Steve
^ permalink raw reply
* Re: [PATCH] Fix regression in fast-import.c due to strbufs.
From: Pierre Habouzit @ 2007-10-26 17:25 UTC (permalink / raw)
To: Junio C Hamano, Shun Kei Leung
Cc: Johannes Schindelin, Shawn O. Pearce, Git ML
In-Reply-To: <20071026075912.GA25365@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]
Dear Shun, the fast-import bug your reported has a fix.
Dear Junio, please merge the patch in the mail I'm answering to[0] into
master as it fixes a crash in fast-import.
Cheers,
[0] Message-Id: <20071026075912.GA25365@artemis.corp>
diff --git a/fast-import.c b/fast-import.c
index 6f888f6..f93d7d6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1616,6 +1616,7 @@ static void cmd_data(struct strbuf *sb)
char *term = xstrdup(command_buf.buf + 5 + 2);
size_t term_len = command_buf.len - 5 - 2;
+ strbuf_detach(&command_buf, NULL);
for (;;) {
if (strbuf_getline(&command_buf, stdin, '\n') == EOF)
die("EOF in data (terminator '%s' not found)", term);
--
1.5.3.4.1358.gfae55-dirty
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: How to remove a specific hunk
From: Benoit SIGOURE @ 2007-10-26 17:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <47220A05.4040705@wanadoo.fr>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
On Oct 26, 2007, at 5:38 PM, Pascal Obry wrote:
> Andreas,
>
>> Once you've added the other two hunks, they'll no longer show up in
>> git-diff, so you can do something like this:
>>
>> $ git-add -i; # add the other two hunks to commit
>> $ git-diff > middle-hunk.patch
>> $ git-apply -R middle-hunk.patch
>> test, test, test
>> $ git-apply middle-hunk.patch
>
> Thanks, this will clearly work. I was expecting something more
> integrated like a "git reset --interactive" or something like that :)
That'd be great! :)
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Steffen Prohaska @ 2007-10-26 16:34 UTC (permalink / raw)
To: Pascal Obry; +Cc: Jan Hudec, Johannes Schindelin, msysgit, git
In-Reply-To: <47220B54.60508@obry.net>
On Oct 26, 2007, at 5:44 PM, Pascal Obry wrote:
> The Cygwin/Git module is works very well. And Cygwin is definitely a
> nice toolset (X, bash, ssh, rsync, ...) when you are forced working on
> Windows :)
But beware of the textmode.
Steffen
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Pascal Obry @ 2007-10-26 16:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Hudec, Steffen Prohaska, msysgit, git
In-Reply-To: <Pine.LNX.4.64.0710261746380.4362@racer.site>
Johannes Schindelin a écrit :
> git-svn has nothing to do with external module support.
Ok, "external module" was not the proper term, sorry English is not my
main language. I should have said "conduit for changesets between
Subversion and Git".
> And remember, msysGit will fly sooner if people like _you_ help.
:) Of course, but I'm already doing lot of Open Source development,
can't do everything :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: How to remove a specific hunk
From: Jeff King @ 2007-10-26 16:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, git
In-Reply-To: <20071026164207.GB19673@coredump.intra.peff.net>
On Fri, Oct 26, 2007 at 12:42:08PM -0400, Jeff King wrote:
> That has the side effect of changing the index state. My preferred
> method would be to just excise the hunk from the diff using an editor
> (and this actually has nothing to do with git; you could be using
> diff/patch):
>
> git-diff file >patch
> # remove every hunk except what you want to cut out
> $EDITOR patch
> git-apply -R patch
BTW, since this is inherently a non-git operation, there are other tools
that some may find friendlier than an editor. Kompare will let you
unapply differences, for example, and I would be shocked if emacs didn't
have some tool for this.
-Peff
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Johannes Schindelin @ 2007-10-26 16:47 UTC (permalink / raw)
To: Pascal Obry; +Cc: Jan Hudec, Steffen Prohaska, msysgit, git
In-Reply-To: <47220B54.60508@obry.net>
Hi,
On Fri, 26 Oct 2007, Pascal Obry wrote:
> Jan Hudec a ?crit :
> > I got (or rather made me) a little time to try out it at work this week and
> > it looks really nice. Good job!
>
> I tried it some time ago but there was no external module support. For
> example git-svn is missing and looking at the missing feature on the Web
> page I won't use it at the moment...
git-svn has nothing to do with external module support.
And remember, msysGit will fly sooner if people like _you_ help.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svnimport
From: Johannes Schindelin @ 2007-10-26 16:45 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071026145520.2141.qmail@7a6a65599aed61.315fe32.mid.smarden.org>
Hi,
On Fri, 26 Oct 2007, Gerrit Pape wrote:
> http://bugs.debian.org/436930
> http://bugs.debian.org/447325
> http://bugs.debian.org/447965
>
> I'm not sure these are worth fixing, I'd rather suggest to drop
> git-svnimport in favor of git-svn, and not installing it in future
> versions.
I already proposed this. The outcome was... silent.
Ciao,
Dscho
^ permalink raw reply
* Re: How to remove a specific hunk
From: Jeff King @ 2007-10-26 16:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, git
In-Reply-To: <472207AA.8030100@op5.se>
On Fri, Oct 26, 2007 at 05:28:42PM +0200, Andreas Ericsson wrote:
> Once you've added the other two hunks, they'll no longer show up in
> git-diff, so you can do something like this:
>
> $ git-add -i; # add the other two hunks to commit
> $ git-diff > middle-hunk.patch
> $ git-apply -R middle-hunk.patch
> test, test, test
> $ git-apply middle-hunk.patch
That has the side effect of changing the index state. My preferred
method would be to just excise the hunk from the diff using an editor
(and this actually has nothing to do with git; you could be using
diff/patch):
git-diff file >patch
# remove every hunk except what you want to cut out
$EDITOR patch
git-apply -R patch
-Peff
^ permalink raw reply
* Re: [PATCH] Fix regression in fast-import.c due to strbufs.
From: cpettitt @ 2007-10-26 16:39 UTC (permalink / raw)
To: Pierre Habouzit, Shawn O. Pearce, cpettitt, Git Mailing List
In-Reply-To: <20071026075912.GA25365@artemis.corp>
On 10/26/07, Pierre Habouzit <madcoder@debian.org> wrote:
> Without this strbuf_release, it yields a double free later, the command is
> in fact stashed, and this is not a memory leak.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Pierre,
You nailed it! No more double frees and no segfault.
Thanks,
Chris
^ permalink raw reply
* Re: Trouble with case-insensitive filesystems
From: Jeff King @ 2007-10-26 16:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4722064C.1000201@op5.se>
On Fri, Oct 26, 2007 at 05:22:52PM +0200, Andreas Ericsson wrote:
> There are no areas in git to patch. There's no sane way to handle your
> case, so the best you could opt for is to import it to a system with
> sane case-handling, alter the repo so no two filenames clash, and then
> check it out on your case-insensitive filesystem. Note that you'll
You don't need a sane system, since git's index provides one:
# make our new repo without checking anything out
git-clone -n /path/to/other/repo repo
cd repo
# grab a text representation of what would be checked out
git-ls-tree -r HEAD >files
# fix up any broken filenames
$EDITOR files
# and shove it into the index
git-update-index --index-info <files
# update your working tree
git-checkout-index -a
# and optionally save the commit
git-commit -m 'broken filenames hack'
Of course, all of the prior commits won't be usable. You would have to
repeat this hack on every commit using git-filter-branch for that.
-Peff
^ permalink raw reply
* Re: Trouble with case-insensitive filesystems
From: Rocco Rutte @ 2007-10-26 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <4722064C.1000201@op5.se>
Hi,
* Andreas Ericsson [07-10-26 17:22:52 +0200] wrote:
> There are no areas in git to patch. There's no sane way to handle your
> case, so the best you could opt for is to import it to a system with
> sane case-handling, alter the repo so no two filenames clash, and then
> check it out on your case-insensitive filesystem. Note that you'll
> have to make sure that you never check anything out prior to the
> commit that renames the case-name clashes, or you'll end up with this
> same trouble all over again.
Personally I don't have a problem with that (since I do no work with
that repo). But IMHO it's bad to leave people without a clue what could
be wrong when git-status right after git-checkout/git-clone reports
changes. Btw, mercurial reports the problem so immediately know what's
wrong.
> On a side note; Please don't set the Reply-To: header for mails to
> git@vger.kernel.org. Some consider it rude, and it makes the ones
> you're asking for help have to work if they want to provide you
> with anything off-list. It's a tad rude.
I didn't set a Reply-To: header, just Mail-Followup-To: which is exactly
what I want (in mutt language): Private mails via reply only go to me
and list-reply goes to the list.
Rocco
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Fernando J. Pereda @ 2007-10-26 16:01 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Junio C Hamano
In-Reply-To: <20071026141539.29928.qmail@d3691352d65cf2.315fe32.mid.smarden.org>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Fri, Oct 26, 2007 at 02:15:39PM +0000, Gerrit Pape wrote:
> When saving patches to a maildir with e.g. mutt, the files are put into
> the new/ subdirectory of the maildir, not cur/. This makes git-am state
> "Nothing to do.". This patch lets git-mailsplit fallback to new/ if the
> cur/ subdirectory is empty.
>
> This was reported by Joey Hess through
> http://bugs.debian.org/447396
>
By that reasoning, you should make it parse both cur/ and new/.
This didn't bit me because I always check mails I queue, so they ended
up in cur/.
Other than that, ack from me.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Pascal Obry @ 2007-10-26 15:44 UTC (permalink / raw)
To: Jan Hudec; +Cc: Steffen Prohaska, Johannes Schindelin, msysgit, git
In-Reply-To: <20071026152143.GB4819@efreet.light.src>
Jan Hudec a écrit :
> I got (or rather made me) a little time to try out it at work this week and
> it looks really nice. Good job!
I tried it some time ago but there was no external module support. For
example git-svn is missing and looking at the missing feature on the Web
page I won't use it at the moment...
The Cygwin/Git module is works very well. And Cygwin is definitely a
nice toolset (X, bash, ssh, rsync, ...) when you are forced working on
Windows :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: How to remove a specific hunk
From: Pascal Obry @ 2007-10-26 15:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <472207AA.8030100@op5.se>
Andreas,
> Once you've added the other two hunks, they'll no longer show up in
> git-diff, so you can do something like this:
>
> $ git-add -i; # add the other two hunks to commit
> $ git-diff > middle-hunk.patch
> $ git-apply -R middle-hunk.patch
> test, test, test
> $ git-apply middle-hunk.patch
Thanks, this will clearly work. I was expecting something more
integrated like a "git reset --interactive" or something like that :)
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Trouble with case-insensitive filesystems
From: Jean-François Veillette @ 2007-10-26 15:29 UTC (permalink / raw)
To: Rocco Rutte; +Cc: git
In-Reply-To: <20071026145204.GA294@localhost.daprodeges.fqdn.th-h.de>
You can workaround this by creating a disk-image with a case-
sensitive filesystem, then do your work inside that virtual drive.
- jfv
Le 07-10-26 à 10:52, Rocco Rutte a écrit :
> Hi,
>
> after importing the opensolaris hg repo into git, I noticed that
> git gets confused if the repo contains files that clash on case-
> insensitive filesystems (here on OS X, I can't test Cygwin and
> Win32). git-checkout tells me that these files are modified, git-
> status gives me:
>
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HB
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/
> HB.name
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HI
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/
> HI.name
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HX
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/
> HX.name
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/
> charlib/LH
> # modified: usr/src/lib/libldap4/common/Version.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> ...without touching anything. Yes, there's a version.c file next to
> Version.c, HI.name next to Hi.name and so on.
>
> I'm not really sure what I'm expecting git to do, but I guess I
> want it to abort a checkout and only continue with -f. But at the
> very least, it should issue a big fat warning (one may decide to
> work in some area without clashes).
>
> I really have no idea how to efficiently detect that at runtime and
> which areas of git to look at for patching...
>
> Rocco
> -
> 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: How to remove a specific hunk
From: Andreas Ericsson @ 2007-10-26 15:28 UTC (permalink / raw)
To: Pascal Obry; +Cc: git
In-Reply-To: <4722036E.5030204@wanadoo.fr>
Pascal Obry wrote:
> Hello,
>
> I'm very new to Git... but start to love it :)
>
> Before committing sometimes I want to remove a specific hunk. Say in
> file a.txt I have in the diff 3 hunks, I want to revert/delete/remove
> the second one. Is there a way to do that ?
>
> I understand that I can git add interactive and select the hook I want
> to commit, but this is not fully equivalent. I'm not yet ready to commit
> I just want to undo a specific change and test the code without it...
>
> Any idea ?
>
Once you've added the other two hunks, they'll no longer show up in
git-diff, so you can do something like this:
$ git-add -i; # add the other two hunks to commit
$ git-diff > middle-hunk.patch
$ git-apply -R middle-hunk.patch
test, test, test
$ git-apply middle-hunk.patch
Completely untested, so take a copy before you try it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Jan Hudec @ 2007-10-26 15:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <A24982F6-40B2-4897-904E-99A135EC9D41@zib.de>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Sat, Oct 20, 2007 at 20:04:20 +0200, Steffen Prohaska wrote:
> On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
>> It would be nice to install an entry in the explorer menu to run git-gui
>> in
>> a selected directory. It can be done by just writing something like to the
>> registry (completely untested -- I just looked it up on the internet):
>
> What you propose is already there!
>
> Did you try the most recent setup?
>
> http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
I got (or rather made me) a little time to try out it at work this week and
it looks really nice. Good job!
Regards,
Jan
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Trouble with case-insensitive filesystems
From: Andreas Ericsson @ 2007-10-26 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <20071026145204.GA294@localhost.daprodeges.fqdn.th-h.de>
Rocco Rutte wrote:
> Hi,
>
> after importing the opensolaris hg repo into git, I noticed that git
> gets confused if the repo contains files that clash on case-insensitive
> filesystems (here on OS X, I can't test Cygwin and Win32). git-checkout
> tells me that these files are modified, git-status gives me:
>
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HB
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HB.name
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HI
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HI.name
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HX
> # modified: usr/src/cmd/lp/filter/postscript/font/devpost/HX.name
> # modified:
> usr/src/cmd/lp/filter/postscript/font/devpost/charlib/LH
> # modified: usr/src/lib/libldap4/common/Version.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> ...without touching anything. Yes, there's a version.c file next to
> Version.c, HI.name next to Hi.name and so on.
>
> I'm not really sure what I'm expecting git to do, but I guess I want it
> to abort a checkout and only continue with -f. But at the very least, it
> should issue a big fat warning (one may decide to work in some area
> without clashes).
>
> I really have no idea how to efficiently detect that at runtime and
> which areas of git to look at for patching...
>
There are no areas in git to patch. There's no sane way to handle your
case, so the best you could opt for is to import it to a system with
sane case-handling, alter the repo so no two filenames clash, and then
check it out on your case-insensitive filesystem. Note that you'll
have to make sure that you never check anything out prior to the
commit that renames the case-name clashes, or you'll end up with this
same trouble all over again.
On a side note; Please don't set the Reply-To: header for mails to
git@vger.kernel.org. Some consider it rude, and it makes the ones
you're asking for help have to work if they want to provide you
with anything off-list. It's a tad rude.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* How to remove a specific hunk
From: Pascal Obry @ 2007-10-26 15:10 UTC (permalink / raw)
To: git
Hello,
I'm very new to Git... but start to love it :)
Before committing sometimes I want to remove a specific hunk. Say in
file a.txt I have in the diff 3 hunks, I want to revert/delete/remove
the second one. Is there a way to do that ?
I understand that I can git add interactive and select the hook I want
to commit, but this is not fully equivalent. I'm not yet ready to commit
I just want to undo a specific change and test the code without it...
Any idea ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH 8/9] Git.pm: Add hash_and_insert_object and cat_blob
From: Eric Wong @ 2007-10-26 15:11 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio Hamano
In-Reply-To: <1193307927-3592-9-git-send-email-aroben@apple.com>
Adam Roben <aroben@apple.com> wrote:
> These functions are more efficient ways of executing `git hash-object -w` and
> `git cat-file blob` when you are dealing with many files/objects.
>
> Signed-off-by: Adam Roben <aroben@apple.com>
> ---
> Eric Wong wrote:
> > > +package Git::Commands;
> >
> > Can this be a separate file, or a part of Git.pm? I'm sure other
> > scripts can eventually use this and I've been meaning to split
> > git-svn.perl into separate files so it's easier to follow.
>
> I ended up making it part of Git.pm, because I realized that made far more
> sense than splitting it into a separate file.
>
> perl/Git.pm | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 95 insertions(+), 2 deletions(-)
Hi Adam,
Thanks.
> diff --git a/perl/Git.pm b/perl/Git.pm
> index 46c5d10..f23edef 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -39,6 +39,9 @@ $VERSION = '0.01';
> my $lastrev = $repo->command_oneline( [ 'rev-list', '--all' ],
> STDERR => 0 );
>
> + my $sha1 = $repo->hash_and_insert_object('file.txt');
> + my $contents = $repo->cat_blob($sha1);
I missed this the first time around. But I'd rather be able to pass a
file handle to cat_blob for writing, instead of returning a potentially
huge string in memory.
> @@ -675,6 +677,93 @@ sub hash_object {
> }
>
>
> +=item hash_and_insert_object ( FILENAME )
> +
> +Compute the SHA1 object id of the given C<FILENAME> and add the object to the
> +object database.
> +
> +The function returns the SHA1 hash.
> +
> +=cut
> +
> +# TODO: Support for passing FILEHANDLE instead of FILENAME
Filenames are fine for this input since they (are/should be) generated
by File::Temp and not from an untrusted repo.
We should, however assert that the caller of this function
isn't using a stupid filename with "\n" in it.
> +sub hash_and_insert_object {
> + my ($self, $filename) = @_;
> +
> + $self->_open_hash_and_insert_object_if_needed();
> + my ($in, $out) = ($self->{hash_object_in}, $self->{hash_object_out});
> +
> + print $out $filename, "\n";
> + chomp(my $hash = <$in>);
> + return $hash;
> +}
> +
> +sub _open_hash_and_insert_object_if_needed {
> + my ($self) = @_;
> +
> + return if defined($self->{hash_object_pid});
> +
> + ($self->{hash_object_pid}, $self->{hash_object_in},
> + $self->{hash_object_out}, $self->{hash_object_ctx}) =
> + command_bidi_pipe(qw(hash-object -w --stdin-paths));
> +}
> +
> +sub _close_hash_and_insert_object {
> + my ($self) = @_;
> +
> + return unless defined($self->{hash_object_pid});
> +
> + my @vars = map { 'hash_object' . $_ } qw(pid in out ctx);
It looks like you're missing a '_' in there.
> + command_close_bidi_pipe($self->{@vars});
> + delete $self->{@vars};
> +}
> +
> +=item cat_blob ( SHA1 )
> +
> +Returns the contents of the blob identified by C<SHA1>.
> +
> +=cut
> +
> +sub cat_blob {
> + my ($self, $sha1) = @_;
> +
> + $self->_open_cat_blob_if_needed();
> + my ($in, $out) = ($self->{cat_blob_in}, $self->{cat_blob_out});
> +
> + print $out $sha1, "\n";
> + chomp(my $size = <$in>);
> +
> + my $blob;
> + my $result = read($in, $blob, $size);
> + defined $result or carp $!;
> +
> + # Skip past the trailing newline.
> + read($in, my $newline, 1);
> +
> + return $blob;
> +}
However, I'd very much like to be able to pass a file handle to this
function. This should read()/print() to a file handle passed to it in a
loop rather than slurping all of $size at once, since the files we're
receiving can be huge.
I'd also be happier if we checked that we actually read $size bytes in
the loop, and that $newline is actually "\n" to safeguard against bugs
in cat-blob.
> +sub _open_cat_blob_if_needed {
> + my ($self) = @_;
> +
> + return if defined($self->{cat_blob_pid});
> +
> + ($self->{cat_blob_pid}, $self->{cat_blob_in},
> + $self->{cat_blob_out}, $self->{cat_blob_ctx}) =
> + command_bidi_pipe(qw(cat-file blob --stdin));
> +}
> +
> +sub _close_cat_blob {
> + my ($self) = @_;
> +
> + return unless defined($self->{cat_blob_pid});
> +
> + my @vars = map { 'cat_blob' . $_ } qw(pid in out ctx);
It looks like you're missing a '_' here, too.
> + command_close_bidi_pipe($self->{@vars});
> + delete $self->{@vars};
> +}
>
One more nit, I'm a bit paranoid, but I personally like to die/croak if
the result of every print()/syswrite() to make sure the pipe we're
writing to didn't die or if there were other error indicators.
Hopefully that's the last of tweaks I'd like to see :)
--
Eric Wong
^ permalink raw reply
* Re: git-svnimport
From: Gerrit Pape @ 2007-10-26 14:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710251132580.25221@racer.site>
On Thu, Oct 25, 2007 at 11:56:44AM +0100, Johannes Schindelin wrote:
> On Thu, 25 Oct 2007, Felipe Balbi wrote:
> > I was importing busybox svn repository to git but I got a connection
> > timeout after more than 19k commits... is there a way to continue where
> > the error happened or should I do it all over again ??
>
> AFAICT git-svn is better suited, even to one-shot importing svn.
AIUI git-svnimport provides a subset of git-svn's functionality.
There've been some problems with git-svnimport reported through the
Debian BTS
http://bugs.debian.org/436930
http://bugs.debian.org/447325
http://bugs.debian.org/447965
I'm not sure these are worth fixing, I'd rather suggest to drop
git-svnimport in favor of git-svn, and not installing it in future
versions.
Regards, Gerrit.
^ permalink raw reply
* Trouble with case-insensitive filesystems
From: Rocco Rutte @ 2007-10-26 14:52 UTC (permalink / raw)
To: git
Hi,
after importing the opensolaris hg repo into git, I noticed that git
gets confused if the repo contains files that clash on case-insensitive
filesystems (here on OS X, I can't test Cygwin and Win32). git-checkout
tells me that these files are modified, git-status gives me:
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HB
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HB.name
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HI
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HI.name
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HX
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/HX.name
# modified: usr/src/cmd/lp/filter/postscript/font/devpost/charlib/LH
# modified: usr/src/lib/libldap4/common/Version.c
#
no changes added to commit (use "git add" and/or "git commit -a")
...without touching anything. Yes, there's a version.c file next to
Version.c, HI.name next to Hi.name and so on.
I'm not really sure what I'm expecting git to do, but I guess I want it
to abort a checkout and only continue with -f. But at the very least, it
should issue a big fat warning (one may decide to work in some area
without clashes).
I really have no idea how to efficiently detect that at runtime and
which areas of git to look at for patching...
Rocco
^ permalink raw reply
* [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Gerrit Pape @ 2007-10-26 14:15 UTC (permalink / raw)
To: git, Junio C Hamano
When saving patches to a maildir with e.g. mutt, the files are put into
the new/ subdirectory of the maildir, not cur/. This makes git-am state
"Nothing to do.". This patch lets git-mailsplit fallback to new/ if the
cur/ subdirectory is empty.
This was reported by Joey Hess through
http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/git-am.txt | 3 ++-
builtin-mailsplit.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index e4a6b3a..49f79f6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -26,7 +26,8 @@ OPTIONS
<mbox>|<Maildir>...::
The list of mailbox files to read patches from. If you do not
supply this argument, reads from the standard input. If you supply
- directories, they'll be treated as Maildirs.
+ directories, they'll be treated as Maildirs, which should contain
+ the patches either in the cur/ subdirectory, or in new/.
-s, --signoff::
Add `Signed-off-by:` line to the commit message, using
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 43fc373..eaf3cbe 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -131,6 +131,11 @@ static int split_maildir(const char *maildir, const char *dir,
snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
if (populate_maildir_list(&list, curdir) < 0)
goto out;
+ if (list.nr == 0) {
+ snprintf(curdir, sizeof(curdir), "%s/new", maildir);
+ if (populate_maildir_list(&list, curdir) < 0)
+ goto out;
+ }
for (i = 0; i < list.nr; i++) {
FILE *f;
--
1.5.3.4
^ 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