* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Hervé Cauwelier @ 2009-10-14 15:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0910140548g2ad99ec4ia0f4cd4cb6fc409c@mail.gmail.com>
On 14/10/2009 14:48, Sverre Rabbelier wrote:
> Heya,
>
> 2009/10/14 Hervé Cauwelier<herve@itaapy.com>:
>
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter).
Hi, indeed I forgot and send-email sent them without asking confirmation.
The only change is the comment by Shawn about keeping the PACK_TOC
constant as is and calling the other one PACK_HDR.
Regards
--
Hervé Cauwelier - ITAAPY - 9 rue Darwin 75018 Paris
Tél. 01 42 23 67 45 - Fax 01 53 28 27 88
http://www.itaapy.com/ - http://www.cms-migration.com
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-14 15:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0910141233060.4985@pacific.mpi-cbg.de>
On Wed, Oct 14, 2009 at 12:33:22PM +0200, Johannes Schindelin wrote:
> > > +char *get_detached_head_string(void)
> > > +{
> > > + char *filename = git_path("DETACH_NAME");
> > > + struct stat st;
> > > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
> > > + return NULL;
> > > + struct strbuf buf = STRBUF_INIT;
> > > + strbuf_read_file(&buf, filename, st.st_size);
> > > + strbuf_trim(&buf);
> > > + return strbuf_detach(&buf, 0);
> > > +}
> >
> > Would it hurt to tuck this information into HEAD itself, as we already
> > put arbitrary text into FETCH_HEAD?
>
> AFAIR we still remember HEAD to be a symlink.
I think that has been abandoned for detached HEAD (that is, if you
support only symlinked HEAD, then you cannot detach at all). But I might
be wrong. It has been a while since I looked at that code.
-Peff
^ permalink raw reply
* Re: Changing branches in supermodule does not affect submodule?
From: Jens Lehmann @ 2009-10-14 15:39 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0910140728420.16100@ds9.cixit.se>
Peter Krefting schrieb:
> Jens Lehmann:
>
>> just calling "git submodule update" every time you want the submodule
>> to be updated according to the state committed in the superproject
>> will do the trick (but keep in mind that all referenced commits have
>> to be accessible in the local clone of your submodule, so you might
>> have to do a fetch there once in a while).
BTW: unless you use the -N or --no-fetch option, git submodule update
will do the fetch for you.
> Is it possible to automate this from a hook or something else?
Yep, you can use the post-checkout hook for that, just put a "git
submodule update" in it.
*But*: If you do a checkout in the superproject while the submodule
has new commits not contained in any branch (remember submodules
often have a detached head) you'll silently lose these commits!
Then only the reflog can help you ...
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-14 15:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091014050851.GE31810@coredump.intra.peff.net>
On Wed, 14 Oct 2009, Jeff King wrote:
> On Wed, Oct 14, 2009 at 12:44:34AM -0400, Daniel Barkalow wrote:
>
> > +char *get_detached_head_string(void)
> > +{
> > + char *filename = git_path("DETACH_NAME");
> > + struct stat st;
> > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
> > + return NULL;
> > + struct strbuf buf = STRBUF_INIT;
> > + strbuf_read_file(&buf, filename, st.st_size);
> > + strbuf_trim(&buf);
> > + return strbuf_detach(&buf, 0);
> > +}
>
> Would it hurt to tuck this information into HEAD itself, as we already
> put arbitrary text into FETCH_HEAD?
I don't know; I'll have to try that and see if the tools that handle HEAD
are happy with extra text there. If it works, it's a good solution.
I think I tried it at some point and things failed all over the place, but
that may have been before symrefs, when you could get the actual sha1
hash out of HEAD with "$(cat .git/HEAD)".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Laurent Boulard @ 2009-10-14 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Raible, git
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>
On Wed, Oct 14, 2009 at 16:03, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>>
>> In which Junio suggests:
>> $ rm .git/index
>> $ git reset --hard
>>
>> in order to "restore sanity to your work tree"
>
> Of course this is insane as a user interface. It is not even plumbing.
>
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface. I think that Git should
> realize itself that something went wrong with the line endings. If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.
I have to work on win32 at work and depending of projects, I have to
play with autocrlf/crlf config.
So I cannot do a git clone because it will inherit the global crlf
configuration which is not want I want. My flow is often:
$ git init ...
$ git config core.autocrlf ...
$ git remote add origin ...
$ git fetch origin ...
I stuffed those four lines behind a few git alias but I think having a
config option for git init and git clone to set core.autocrlf in
repository would be a (small) improvement, isn't it ?
Laurent.
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Nicolas Pitre @ 2009-10-14 16:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, Junio C Hamano, git
In-Reply-To: <20091014142351.GI9261@spearce.org>
On Wed, 14 Oct 2009, Shawn O. Pearce wrote:
> Andy Isaacson <adi@hexapodia.org> wrote:
> > We're looping in unpack_compressed_entry, adding a fprintf immediately
> > after the call to git_inflate() shows:
>
> Thanks, that was really quite helpful. Junio/Nico, I think we can
> just apply this patch to maint and include it in the next release:
>
> --8<--
> [PATCH] sha1_file: Fix infinite loop when pack is corrupted
>
> Some types of corruption to a pack may confuse the deflate stream
> which stores an object. In Andy's reported case a 36 byte region
> of the pack was overwritten, leading to what appeared to be a valid
> deflate stream that was trying to produce a result larger than our
> allocated output buffer could accept.
>
> Z_BUF_ERROR is returned from inflate() if either the input buffer
> needs more input bytes, or the output buffer has run out of space.
> Previously we only considered the former case, as it meant we needed
> to move the stream's input buffer to the next window in the pack.
>
> We now abort the loop if inflate() returns Z_BUF_ERROR without
> consuming the entire input buffer it was given, or has filled
> the entire output buffer but has not yet returned Z_STREAM_END.
> Either state is a clear indicator that this loop is not working
> as expected, and should not continue.
>
> This problem cannot occur with loose objects as we open the entire
> loose object as a single buffer and treat Z_BUF_ERROR as an error.
>
> Reported-by: Andy Isaacson <adi@hexapodia.org>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
This is unfortunate that making a test case for this isn't exactly
trivial.
> ---
> sha1_file.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 4ea0b18..4cc8939 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1357,6 +1357,8 @@ unsigned long get_size_from_delta(struct packed_git *p,
> in = use_pack(p, w_curs, curpos, &stream.avail_in);
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while ((st == Z_OK || st == Z_BUF_ERROR) &&
> stream.total_out < sizeof(delta_head));
> @@ -1594,6 +1596,8 @@ static void *unpack_compressed_entry(struct packed_git *p,
> in = use_pack(p, w_curs, curpos, &stream.avail_in);
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while (st == Z_OK || st == Z_BUF_ERROR);
> git_inflate_end(&stream);
> --
> 1.6.5.52.g0ff2e
>
> --
> Shawn.
>
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Michael J Gruber @ 2009-10-14 16:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <94a0d4530910140726i4465e919h77045904aa33c61a@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 14.10.2009 16:26:
> On Tue, Oct 13, 2009 at 10:19 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 12.10.2009 19:09:
>>> On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Well, you do talk about "system" below, and that's about it. Also, the
>>>> configuration is not really distributed among different locations. Most
>>>> newbies interested in a *D*VCS will misunderstand this (as git having
>>>> distributed configuration).
>>>>
>>>> Alternative:
>>>>
>>>> Git's default configuration can be changed on a system wide, global (per
>>>> user) and local (per repository) level, in the order of increasing
>>>> precedence.
>>>
>>> When I read that it's not clear if the local level discards the global
>>> level completely or it's aggregated. If we specify that it's only the
>>> variables that take precedence it might be clearer:
>>>
>>> Git's configuration is composed of variables that are stored in
>>> multiple locations: 'system' (all users), 'global' (for the user), and
>>> 'repository' -- in decreasing order of precedence.
>>
>> Yep, although established lingo is "options" (not "variables"), and it's
>> really increasing order, not decreasing.
>
> Really? I remember clearly Junio stating otherwise:
> http://marc.info/?l=git&m=123460371724873&w=2
>
> ----
>> + OPT_BOOLEAN(0, "unset", &do_unset, "removes an option: name [value-regex]"),
>
> Please don't introduce a new noun "option" that has never been used to
> mean a "configuration variable" in git documentation. It unnecessarily
> confuses everybody.
> ----
Well, Junio certainly is authoritative, and I don't want to risk any bad
patch-acceptance-fu ( :) ), but
2d2465c (Add documentation for git-config-set, 2005-11-17)
is the origin of that doc for git-config. I'm not just claiming it
myself. That commit introduced "option", uses it in all but one place,
and this never changed since then! [The ratio went up from 6:1 to 40:5]
I have no objection to changing this established notion, but established
it is. I haven't tracked down the use of option vs. variable in other
places than git-config.txt and its predecessors.
Michael
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-14 16:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andy Isaacson, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0910141208170.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> > Some types of corruption to a pack may confuse the deflate stream
> > which stores an object. In Andy's reported case a 36 byte region
> > of the pack was overwritten, leading to what appeared to be a valid
> > deflate stream that was trying to produce a result larger than our
> > allocated output buffer could accept.
...
> This is unfortunate that making a test case for this isn't exactly
> trivial.
Hmmm. We could do something like manually create a pack file of
one non-delta blob whose pack header length is 16, but use a zlib
stream whose result body is 64. Prior to this fix, we'd be stuck
in the infinite loop. :-)
Its a PITA to create though, you have to hand-craft the test vector
and save it in the repository, we can't produce such a pack with
any real code we ship.
--
Shawn.
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Avery Pennarun @ 2009-10-14 16:28 UTC (permalink / raw)
To: Eric Wong; +Cc: Bruno Harbulot, git
In-Reply-To: <20091014060307.GA17178@dcvr.yhbt.net>
On Wed, Oct 14, 2009 at 2:03 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> wrote:
>> What surprises me is that it looks like it's looping over and over,
>> since sometimes it starts back from SVN revision 1 when it's trying to
>> import a new tag.
>
> Yeah, that's an unfortunate thing about the flexibility of Subversion,
> basically anything can be a "tag" or a directory and it's extremely
> hard for git svn to support any uncommon cases for tags/branches
> out-of-the box, so the manual config editing is needed.
I've been thinking about this myself for some time. One option that
might be "interesting" would be to just grab the *entire* svn tree
(from the root), and then use git-subtree[1] to slice and dice it into
branches using your local copy of git (which is fast and uses no
bandwidth) instead of during the svn fetch (which is slow and uses
lots of bandwidth). I think it would also simplify the git-svn code
quite a lot, at least for fetching, since there would always be a
global view of the tree and SVN things like "copy branch A to tag B"
would just be exactly that.
Of course I have no time to code this up myself, so I apologize for
just dumping ideas on you without code behind them. If this inspires
anyone, I'd be happy to help with any missing features (or
documentation) this exposes in git-subtree, though.
Have fun,
Avery
[1] http://github.com/apenwarr/git-subtree
^ permalink raw reply
* Re: [PATCH] gitweb: linkify author/committer names with search
From: Wincent Colaiuta @ 2009-10-14 16:55 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
El 14/10/2009, a las 04:12, Stephen Boyd escribió:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
What about installs where search is turned off? (ie. with "$feature
{'search'}{'default'} = [undef];" in gitweb.conf)
Cheers,
Wincent
^ permalink raw reply
* Re: git-commit feature request: pass editor command line options
From: Miklos Vajna @ 2009-10-14 17:23 UTC (permalink / raw)
To: Matthew Cline; +Cc: git
In-Reply-To: <25885354.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Tue, Oct 13, 2009 at 09:58:51PM -0700, Matthew Cline <matt@nightrealms.com> wrote:
>
> I'd like to be able to have git-commit pass the commit-message editor command
> line options which aren't passed to the editor for other usages. Right now
> I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'",
> where git-commit-editor is a wrapper around my editor-of-choice which passes
> the editor the command line options I want, but it'd be simpler and cleaner
> if I could just set "commit.editor_options=-BAR". Or even let there be a
> separate editor for commits, so I could do "core.editor=foo" and
> "commit.editor=foo -BAR".
Hmm, what is the use-case when using an option --foo is useful when
creating a commit, but not useful when crating a tag?
Apart from introducing inconsistency...
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Nicolas Pitre @ 2009-10-14 16:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, Junio C Hamano, git
In-Reply-To: <20091014161259.GK9261@spearce.org>
On Wed, 14 Oct 2009, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@fluxnic.net> wrote:
> > > Some types of corruption to a pack may confuse the deflate stream
> > > which stores an object. In Andy's reported case a 36 byte region
> > > of the pack was overwritten, leading to what appeared to be a valid
> > > deflate stream that was trying to produce a result larger than our
> > > allocated output buffer could accept.
> ...
> > This is unfortunate that making a test case for this isn't exactly
> > trivial.
>
> Hmmm. We could do something like manually create a pack file of
> one non-delta blob whose pack header length is 16, but use a zlib
> stream whose result body is 64. Prior to this fix, we'd be stuck
> in the infinite loop. :-)
Ah, of course.
> Its a PITA to create though, you have to hand-craft the test vector
> and save it in the repository, we can't produce such a pack with
> any real code we ship.
Can be done easily with dd though, see do_corrupt_object() in t5303 for
example.
Nicolas
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Eric Wong @ 2009-10-14 18:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Bruno Harbulot, git
In-Reply-To: <32541b130910140928jdac0187x754423e8d5c64e53@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Wed, Oct 14, 2009 at 2:03 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> wrote:
> >> What surprises me is that it looks like it's looping over and over,
> >> since sometimes it starts back from SVN revision 1 when it's trying to
> >> import a new tag.
> >
> > Yeah, that's an unfortunate thing about the flexibility of Subversion,
> > basically anything can be a "tag" or a directory and it's extremely
> > hard for git svn to support any uncommon cases for tags/branches
> > out-of-the box, so the manual config editing is needed.
>
> I've been thinking about this myself for some time. One option that
> might be "interesting" would be to just grab the *entire* svn tree
> (from the root), and then use git-subtree[1] to slice and dice it into
> branches using your local copy of git (which is fast and uses no
> bandwidth) instead of during the svn fetch (which is slow and uses
> lots of bandwidth). I think it would also simplify the git-svn code
> quite a lot, at least for fetching, since there would always be a
> global view of the tree and SVN things like "copy branch A to tag B"
> would just be exactly that.
>
> Of course I have no time to code this up myself, so I apologize for
> just dumping ideas on you without code behind them. If this inspires
> anyone, I'd be happy to help with any missing features (or
> documentation) this exposes in git-subtree, though.
This was actually the original use case of git svn back when I started.
git svn clone SVNREPO_ROOT (without --stdlayout)
It's still an option if you have the disk space for the working copies,
but I had to create the branches/tags support since the working copies
would be become prohibitively large. If git-subtree could be
taught to work on a bare repo (git svn has a --no-checkout option)
it might be an option, too.
> Have fun,
>
> Avery
>
> [1] http://github.com/apenwarr/git-subtree
--
Eric Wong
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-14 18:03 UTC (permalink / raw)
To: Nicolas Pitre, Junio C Hamano; +Cc: Andy Isaacson, git
In-Reply-To: <alpine.LFD.2.00.0910141234540.20122@xanadu.home>
> Nicolas Pitre <nico@fluxnic.net> wrote:
> ...
> > This is unfortunate that making a test case for this isn't exactly
> > trivial.
Junio, can you please squash this in?
diff --git a/t/t5303-pack-corruption-resilience.sh b/t/t5303-pack-corruption-resilience.sh
index 5132d41..5f6cd4f 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -275,4 +275,13 @@ test_expect_success \
git cat-file blob $blob_2 > /dev/null &&
git cat-file blob $blob_3 > /dev/null'
+test_expect_success \
+ 'corrupting header to have too small output buffer fails unpack' \
+ 'create_new_pack &&
+ git prune-packed &&
+ printf "\262\001" | do_corrupt_object $blob_1 0 &&
+ test_must_fail git cat-file blob $blob_1 > /dev/null &&
+ test_must_fail git cat-file blob $blob_2 > /dev/null &&
+ test_must_fail git cat-file blob $blob_3 > /dev/null'
+
test_done
--
Shawn.
^ permalink raw reply related
* Re: [msysgit? bug] crlf double-conversion on win32
From: Eric Raible @ 2009-10-14 18:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>
On Wed, Oct 14, 2009 at 7:03 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 13 Oct 2009, Eric Raible wrote:
>
>>
>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>>
>> In which Junio suggests:
>> $ rm .git/index
>> $ git reset --hard
>>
>> in order to "restore sanity to your work tree"
>
> Of course this is insane as a user interface. It is not even plumbing.
>
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface. I think that Git should
> realize itself that something went wrong with the line endings. If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.
I fully agree that "git reset --hard" should actually, uh, do a hard reset,
as should be clear in the my reply to Junio's suggestion. So I'm not
advocating "rm .git/index" as a good solution, but simply one that works.
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Avery Pennarun @ 2009-10-14 18:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Bruno Harbulot, git
In-Reply-To: <20091014180013.GA24741@dcvr.yhbt.net>
On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Avery Pennarun <apenwarr@gmail.com> wrote:
>> I've been thinking about this myself for some time. One option that
>> might be "interesting" would be to just grab the *entire* svn tree
>> (from the root), and then use git-subtree[1] to slice and dice it into
>> branches using your local copy of git (which is fast and uses no
>> bandwidth) instead of during the svn fetch (which is slow and uses
>> lots of bandwidth). I think it would also simplify the git-svn code
>> quite a lot, at least for fetching, since there would always be a
>> global view of the tree and SVN things like "copy branch A to tag B"
>> would just be exactly that.
>
> This was actually the original use case of git svn back when I started.
>
> git svn clone SVNREPO_ROOT (without --stdlayout)
>
> It's still an option if you have the disk space for the working copies,
> but I had to create the branches/tags support since the working copies
> would be become prohibitively large. If git-subtree could be
> taught to work on a bare repo (git svn has a --no-checkout option)
> it might be an option, too.
I've never tested git-subtree without a working tree, however, it
doesn't *use* the working tree for anything when splitting, so at
worst, there might be a minor bug or two. Thus, there ought never be
a need to check out the whole huge tree (which I agree would be both
slow and huge).
dcommit might be a little weirder. Though I guess if we fixed the
git-svn-id tags in the split branches, you could just commit directly
into a branch, then fetch the new commit back from the root, then
rebase the branch, as dcommit already does.
You know, maybe this is actually easier than I thought... I was
thinking committing back to svn would be complicated since it requires
a working tree, but if we let you commit straight from one of the
branches, it shouldn't actually be too bad at all. Hmm.
Have fun,
Avery
^ permalink raw reply
* [PATCH 2/4] fix indentation depth for git diff --submodule-summary
From: Jens Lehmann @ 2009-10-14 18:31 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Indentation depth was 4, but submodule summary uses 2 as other shortlogs
do too.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
submodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/submodule.c b/submodule.c
index 129583b..5076113 100644
--- a/submodule.c
+++ b/submodule.c
@@ -42,7 +42,7 @@ void show_submodule_summary(FILE *f, const char *path,
struct commit_list *merge_bases, *list;
const char *message = NULL;
struct strbuf sb = STRBUF_INIT;
- static const char *format = " %m %s";
+ static const char *format = " %m %s";
int fast_forward = 0, fast_backward = 0;
if (add_submodule_odb(path))
--
1.6.5.4.g707c
^ permalink raw reply related
* [PATCH 3/4] fix output for deleted submodules in git diff --submodule-summary
From: Jens Lehmann @ 2009-10-14 18:31 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
When a submodule has been deleted, add_submodule_odb() returns false
because the directory of the submodule is gone. So we have to test the
second sha for null before we call add_submodule_odb() to get the correct
output.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
submodule.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index 5076113..d5fce7a 100644
--- a/submodule.c
+++ b/submodule.c
@@ -45,12 +45,12 @@ void show_submodule_summary(FILE *f, const char *path,
static const char *format = " %m %s";
int fast_forward = 0, fast_backward = 0;
- if (add_submodule_odb(path))
+ if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (add_submodule_odb(path))
message = "(not checked out)";
else if (is_null_sha1(one))
message = "(new submodule)";
- else if (is_null_sha1(two))
- message = "(submodule deleted)";
else if (!(left = lookup_commit_reference(one)) ||
!(right = lookup_commit_reference(two)))
message = "(commits not present)";
--
1.6.5.4.g707c
^ permalink raw reply related
* [PATCH 1/4] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-14 18:30 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Now you can see the submodule summaries inlined in the diff, instead of
not-quite-helpful SHA-1 pairs.
The format imitates what "git submodule summary" shows.
To do that, <path>/.git/objects/ is added to the alternate object
databases (if that directory exists).
This option was requested by Jens Lehmann at the GitTogether in Berlin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-options.txt | 4 ++
Makefile | 2 +
diff.c | 14 +++++
diff.h | 3 +
submodule.c | 113 ++++++++++++++++++++++++++++++++++++++++
submodule.h | 8 +++
6 files changed, 144 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9276fae..5fcc5a8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -87,6 +87,10 @@ endif::git-format-patch[]
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
+--submodule-summary::
+ Instead of showing pairs of commit names, list the commits in that
+ commit range in the same style as linkgit:git-submodule[1].
+
--color::
Show colored diff.
diff --git a/Makefile b/Makefile
index fea237b..2356de4 100644
--- a/Makefile
+++ b/Makefile
@@ -452,6 +452,7 @@ LIB_H += sideband.h
LIB_H += sigchain.h
LIB_H += strbuf.h
LIB_H += string-list.h
+LIB_H += submodule.h
LIB_H += tag.h
LIB_H += transport.h
LIB_H += tree.h
@@ -550,6 +551,7 @@ LIB_OBJS += sideband.o
LIB_OBJS += sigchain.o
LIB_OBJS += strbuf.o
LIB_OBJS += string-list.o
+LIB_OBJS += submodule.o
LIB_OBJS += symlinks.o
LIB_OBJS += tag.o
LIB_OBJS += trace.o
diff --git a/diff.c b/diff.c
index e1be189..bcf2f77 100644
--- a/diff.c
+++ b/diff.c
@@ -13,6 +13,7 @@
#include "utf8.h"
#include "userdiff.h"
#include "sigchain.h"
+#include "submodule.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -1453,6 +1454,17 @@ static void builtin_diff(const char *name_a,
const char *a_prefix, *b_prefix;
const char *textconv_one = NULL, *textconv_two = NULL;
+ if (DIFF_OPT_TST(o, SUMMARIZE_SUBMODULES) &&
+ (!one->mode || S_ISGITLINK(one->mode)) &&
+ (!two->mode || S_ISGITLINK(two->mode))) {
+ const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
+ const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
+ show_submodule_summary(o->file, one ? one->path : two->path,
+ one->sha1, two->sha1,
+ del, add, reset);
+ return;
+ }
+
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
textconv_one = get_textconv(one);
textconv_two = get_textconv(two);
@@ -2640,6 +2652,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--submodule-summary"))
+ DIFF_OPT_SET(options, SUMMARIZE_SUBMODULES);
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/diff.h b/diff.h
index 6616877..9019f6f 100644
--- a/diff.h
+++ b/diff.h
@@ -66,6 +66,9 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
+
+#define DIFF_OPT_SUMMARIZE_SUBMODULES (1 << 23)
+
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/submodule.c b/submodule.c
new file mode 100644
index 0000000..129583b
--- /dev/null
+++ b/submodule.c
@@ -0,0 +1,113 @@
+#include "cache.h"
+#include "submodule.h"
+#include "dir.h"
+#include "diff.h"
+#include "commit.h"
+#include "revision.h"
+
+int add_submodule_odb(const char *path)
+{
+ struct strbuf objects_directory = STRBUF_INIT;
+ struct alternate_object_database *alt_odb;
+
+ strbuf_addf(&objects_directory, "%s/.git/objects/", path);
+ if (!is_directory(objects_directory.buf))
+ return -1;
+
+ /* avoid adding it twice */
+ for (alt_odb = alt_odb_list; alt_odb; alt_odb = alt_odb->next)
+ if (alt_odb->name - alt_odb->base == objects_directory.len &&
+ !strncmp(alt_odb->base, objects_directory.buf,
+ objects_directory.len))
+ return 0;
+
+ alt_odb = xmalloc(objects_directory.len + 42 + sizeof(*alt_odb));
+ alt_odb->next = alt_odb_list;
+ strcpy(alt_odb->base, objects_directory.buf);
+ alt_odb->name = alt_odb->base + objects_directory.len;
+ alt_odb->name[2] = '/';
+ alt_odb->name[40] = '\0';
+ alt_odb->name[41] = '\0';
+ alt_odb_list = alt_odb;
+ prepare_alt_odb();
+ return 0;
+}
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset)
+{
+ struct rev_info rev;
+ struct commit *commit, *left = left, *right;
+ struct commit_list *merge_bases, *list;
+ const char *message = NULL;
+ struct strbuf sb = STRBUF_INIT;
+ static const char *format = " %m %s";
+ int fast_forward = 0, fast_backward = 0;
+
+ if (add_submodule_odb(path))
+ message = "(not checked out)";
+ else if (is_null_sha1(one))
+ message = "(new submodule)";
+ else if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (!(left = lookup_commit_reference(one)) ||
+ !(right = lookup_commit_reference(two)))
+ message = "(commits not present)";
+
+ if (!message) {
+ init_revisions(&rev, NULL);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.left_right = 1;
+ rev.first_parent_only = 1;
+ left->object.flags |= SYMMETRIC_LEFT;
+ add_pending_object(&rev, &left->object, path);
+ add_pending_object(&rev, &right->object, path);
+ merge_bases = get_merge_bases(left, right, 1);
+ if (merge_bases) {
+ if (merge_bases->item == left)
+ fast_forward = 1;
+ else if (merge_bases->item == right)
+ fast_backward = 1;
+ }
+ for (list = merge_bases; list; list = list->next) {
+ list->item->object.flags |= UNINTERESTING;
+ add_pending_object(&rev, &list->item->object,
+ sha1_to_hex(list->item->object.sha1));
+ }
+ if (prepare_revision_walk(&rev))
+ message = "(revision walker failed)";
+ }
+
+ strbuf_addf(&sb, "Submodule %s %s..", path,
+ find_unique_abbrev(one, DEFAULT_ABBREV));
+ if (!fast_backward && !fast_forward)
+ strbuf_addch(&sb, '.');
+ strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
+ if (message)
+ strbuf_addf(&sb, " %s\n", message);
+ else
+ strbuf_addf(&sb, "%s:\n", fast_backward ? " (rewind)" : "");
+ fwrite(sb.buf, sb.len, 1, f);
+
+ if (!message) {
+ while ((commit = get_revision(&rev))) {
+ strbuf_setlen(&sb, 0);
+ if (commit->object.flags & SYMMETRIC_LEFT) {
+ if (del)
+ strbuf_addstr(&sb, del);
+ }
+ else if (add)
+ strbuf_addstr(&sb, add);
+ format_commit_message(commit, format, &sb,
+ rev.date_mode);
+ if (reset)
+ strbuf_addstr(&sb, reset);
+ strbuf_addch(&sb, '\n');
+ fprintf(f, "%s", sb.buf);
+ }
+ clear_commit_marks(left, ~0);
+ clear_commit_marks(right, ~0);
+ }
+ strbuf_release(&sb);
+}
diff --git a/submodule.h b/submodule.h
new file mode 100644
index 0000000..4c0269d
--- /dev/null
+++ b/submodule.h
@@ -0,0 +1,8 @@
+#ifndef SUBMODULE_H
+#define SUBMODULE_H
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset);
+
+#endif
--
1.6.5.4.g707c
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-14 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20091014153934.GA3680@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 14, 2009 at 12:33:22PM +0200, Johannes Schindelin wrote:
>
>> > > +char *get_detached_head_string(void)
>> > > +{
>> > > + char *filename = git_path("DETACH_NAME");
>> > > + struct stat st;
>> > > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
>> > > + return NULL;
>> > > + struct strbuf buf = STRBUF_INIT;
>> > > + strbuf_read_file(&buf, filename, st.st_size);
>> > > + strbuf_trim(&buf);
>> > > + return strbuf_detach(&buf, 0);
>> > > +}
>> >
>> > Would it hurt to tuck this information into HEAD itself, as we already
>> > put arbitrary text into FETCH_HEAD?
>>
>> AFAIR we still remember HEAD to be a symlink.
>
> I think that has been abandoned for detached HEAD (that is, if you
> support only symlinked HEAD, then you cannot detach at all). But I might
> be wrong. It has been a while since I looked at that code.
If I understand what Daniel is doing correctly, the idea is to keep this
extra information only while the HEAD is detached, no? "HEAD itself
could be a symlink" is an irrelevant issue, isn't it?
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Jens Lehmann @ 2009-10-14 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> * js/diff-verbose-submodule (2009-10-04) 1 commit.
> - Add the --submodule-summary option to the diff option family
>
> Dscho sounded like he has some corrections after list comments, but I did
> not pick up his interdiff in the middle.
Dscho condensed his initial patch with the interdiff you mentioned,
additionally silenced a compiler warning and activated --first-parent.
This follows as patch 1/4. Patches 2/4 to 4/4 contain my two bugfixes
and the testcase i copied from submodule summary while adapting it to
the changes of the output format.
The remaining differences from the output shown by submodule summary are:
1) git diff shows only two dots for a fast forward (submodule summary
always shows three)
2) git diff shows "Submodule" instead of a single '*' in the first line
3) git diff doesn't add a newline after each shortlog
4) submodule summary prints out the number of shortlog entries, this
version does not
5) submodule summary can limit the number of shortlog lines, git diff
can't do that right now
6) When files are replaced by a submodules or vice versa, git diff
generates an extra hunk for the deleted/added file and one saying
"(new submodule)"/"(submodule deleted)"
> The output format needs to be described better here and also in
> Documentation/diff-format.txt.
Will do when it is clear which of the 6 differences should be fixed and
which can stay.
Jens Lehmann (3):
fix indentation depth for git diff --submodule-summary
fix output for deleted submodules in git diff --submodule-summary
add tests for git diff --submodule-summary
Johannes Schindelin (1):
Add the --submodule-summary option to the diff option family
Documentation/diff-options.txt | 4 +
Makefile | 2 +
diff.c | 14 +++
diff.h | 3 +
submodule.c | 113 ++++++++++++++++++++
submodule.h | 8 ++
t/t4041-diff-submodule-summary.sh | 206 +++++++++++++++++++++++++++++++++++++
7 files changed, 350 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
create mode 100755 t/t4041-diff-submodule-summary.sh
^ permalink raw reply
* [PATCH 4/4] add tests for git diff --submodule-summary
From: Jens Lehmann @ 2009-10-14 18:32 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Copied from the submodule summary test and changed to reflect the
differences in the output of git diff --submodule-summary.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
t/t4041-diff-submodule-summary.sh | 206 +++++++++++++++++++++++++++++++++++++
1 files changed, 206 insertions(+), 0 deletions(-)
create mode 100755 t/t4041-diff-submodule-summary.sh
diff --git a/t/t4041-diff-submodule-summary.sh b/t/t4041-diff-submodule-summary.sh
new file mode 100755
index 0000000..dbb19eb
--- /dev/null
+++ b/t/t4041-diff-submodule-summary.sh
@@ -0,0 +1,206 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+#
+
+test_description='Summary support for submodules implemented in git diff
+
+This test tries to verify the sanity of --submodule-summary option of git diff.
+'
+
+. ./test-lib.sh
+
+add_file () {
+ sm=$1
+ shift
+ owd=$(pwd)
+ cd "$sm"
+ for name; do
+ echo "$name" > "$name" &&
+ git add "$name" &&
+ test_tick &&
+ git commit -m "Add $name"
+ done >/dev/null
+ git rev-parse --verify HEAD | cut -c1-7
+ cd "$owd"
+}
+commit_file () {
+ test_tick &&
+ git commit "$@" -m "Commit $*" >/dev/null
+}
+
+test_create_repo sm1 &&
+add_file . foo >/dev/null
+
+head1=$(add_file sm1 foo1 foo2)
+
+test_expect_success 'added submodule' "
+ git add sm1 &&
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+head2=$(add_file sm1 foo3)
+
+test_expect_success 'modified submodule(forward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward)' "
+ git diff --submodule-summary >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+commit_file sm1 &&
+cd sm1 &&
+git reset --hard HEAD~2 >/dev/null &&
+head3=$(git rev-parse --verify HEAD | cut -c1-7) &&
+cd ..
+
+test_expect_success 'modified submodule(backward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+head4=$(add_file sm1 foo4 foo5) &&
+head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
+test_expect_success 'modified submodule(backward and forward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2...$head4:
+ > Add foo5
+ > Add foo4
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+commit_file sm1 &&
+mv sm1 sm1-bak &&
+echo sm1 >sm1 &&
+head5=$(git hash-object sm1 | cut -c1-7) &&
+git add sm1 &&
+rm -f sm1 &&
+mv sm1-bak sm1
+
+test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+ git diff --submodule-summary --cached >actual &&
+ diff actual - <<-EOF
+Submodule sm1 41fbea9...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..9da5fb8
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff --submodule-summary >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index 9da5fb8..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head4 (new submodule)
+EOF
+"
+
+rm -rf sm1 &&
+git checkout-index sm1
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..$head5
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+rm -f sm1 &&
+test_create_repo sm1 &&
+head6=$(add_file sm1 foo6 foo7)
+test_expect_success 'nonexistent commit' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...$head6 (commits not present)
+EOF
+"
+
+commit_file
+test_expect_success 'typechanged submodule(blob->submodule)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index $head5..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head6 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+rm -rf sm1
+test_expect_success 'deleted submodule' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+EOF
+"
+
+test_create_repo sm2 &&
+head7=$(add_file sm2 foo8 foo9) &&
+git add sm2
+
+test_expect_success 'multiple submodules' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'path filter' "
+ git diff-index -p --submodule-summary HEAD sm2 >actual &&
+ diff actual - <<-EOF
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+commit_file sm2
+test_expect_success 'given commit' "
+ git diff-index -p --submodule-summary HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_done
--
1.6.5.4.g707c
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-14 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <7vljjdese3.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 11:34:44AM -0700, Junio C Hamano wrote:
> >> AFAIR we still remember HEAD to be a symlink.
> >
> > I think that has been abandoned for detached HEAD (that is, if you
> > support only symlinked HEAD, then you cannot detach at all). But I might
> > be wrong. It has been a while since I looked at that code.
>
> If I understand what Daniel is doing correctly, the idea is to keep this
> extra information only while the HEAD is detached, no? "HEAD itself
> could be a symlink" is an irrelevant issue, isn't it?
Right. That is what I was trying to say, but somehow it didn't come out
very clearly.
-Peff
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Junio C Hamano @ 2009-10-14 18:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Raible, git
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface. I think that Git should
> realize itself that something went wrong with the line endings. If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.
I tend to agree. "git reset --hard-without-cached-stat-info" that ignores
the cached stat information while it does the equivalent of the usual
"reset --hard" may be a reasonably safe and usable alternative for
"checkout --fix-crlf". When people see "reset --hard...", it will tell
them that this is about matching the index and the work tree with the
named commit, as opposed to "checkout", so enhancing "reset" would make
more sense, I think.
Obviously, I am not seriously suggesting "--hard-without-cached-stat-info"
as the name of this mode of operation, and you need to come up with a
better one. But it is better than "--crlf", as it is not limited to the
crlf conversion that brings the inconsistency you will be resetting away.
It arises from any silent invalidation of the cached stat optimization
after you touch attributes and config.
^ permalink raw reply
* Re: [msysgit? bug] CRLF in info/grafts causes parse error
From: Junio C Hamano @ 2009-10-14 18:51 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <ecf590a0d9e21f480529f64e465825c5.squirrel@intranet.linagora.com>
"Yann Dirson" <ydirson@linagora.com> writes:
> When creating an info/grafts under windows, one typically gets a CRLF file.
> Then:
>
> * gitk loudly complains about "bad graft data"
> * "git log > /dev/null" does not report any problem
> * "git log > foo" does report the problem on sdterr, but exit code is still 0
>
> Recreating the graft as a LF file (eg with "echo" or "printf") causes the
> graft to be properly interpreted.
I do not see any reason to forbid trailing CR at the end of the line (for
that matter, any trailing whitespaces) in the said file.
How about doing this?
commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index fedbd5e..0db2124 100644
--- a/commit.c
+++ b/commit.c
@@ -132,8 +132,8 @@ struct commit_graft *read_graft_line(char *buf, int len)
int i;
struct commit_graft *graft = NULL;
- if (buf[len-1] == '\n')
- buf[--len] = 0;
+ while (isspace(buf[len-1]))
+ buf[--len] = '\0';
if (buf[0] == '#' || buf[0] == '\0')
return NULL;
if ((len + 1) % 41) {
^ 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