* Re: newby question about merge.
From: picca @ 2007-05-16 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabw5iws8.fsf@assigned-by-dhcp.cox.net>
On Tue, 15 May 2007 14:47:51 -0700
Junio C Hamano <junkio@cox.net> wrote:
> picca <picca@synchrotron-soleil.Fr> writes:
>
> > Is it possible to add this git cat-file -p :2:filename > filename in
> > the man page of git-merge in the resolve conflict part ?
> >
> > Or a link to the documentation speaking of this stage part.
>
> See:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution
>
> As this walk through section from the user manual's already
> talks about it, I am not sure if we would want to duplicate its
> wording in git-merge manual page.
I had already red this manual but did not catch up that the :2:configure
was the git path of the files I want to retreive. In fact I was missing
the git-cat-file part and the git path.
regards, frederic
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: Junio C Hamano @ 2007-05-16 6:34 UTC (permalink / raw)
To: Jeff King; +Cc: git, kha, bfields
In-Reply-To: <20070515test.2@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is a test message to check how vger reacts to seeing 8bit
> characters (like Hasselström) in a message _with_ the right mime
> header.
>
> If your mail server doesn't advertise the 8BITMIME extensions, I expect
> this message to come through OK, since vger will (hopefully) respect the
> existing content-type header. Karl and Bruce, can you please report?
I think you are trying to figure out how vger adds/munges the
headers, and the above is not very useful for people but
yourself unless you explicitly say what headers you gave on your
end in the body of the message, is it?
Judging from the list responses, I am guessing the situation is
like this. Does that match your understanding?
botched one:
outgoing:
body in utf-8
Content-type: text/plain; charset=utf-8
no MIME-Version: header
vger relayed to recipients:
body untouched
Content-type: text/plain; charset=iso-8859-1
MIME-Version: 1.0
good one:
outgoing:
body in utf-8
Content-type: text/plain; charset=utf-8
MIME-Version: 1.0
vger relayed to recipients: everything intact.
I am not sure what exactly you meant by with/without "the right
mime header", but the above is based on my guess that you meant
only MIME-VERSION header.
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Jeff Garzik @ 2007-05-16 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtzudfgam.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
>
>> Grumble!
>>
>> When all this started, the branch 'upstream-fixes' exists, and branch
>> 'tmp' does not exist. This is my local clone of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>> [jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
>> error: Could not open config file!
>> fatal: Branch rename failed
>
> Sorry to hear that.
>
> We used to have a problem with "branch -m" when you did not have
> a .git/config file (or it was unwritable). I think 1.5.0.X
> series and 1.5.1 release had this bug; 1.5.1.1 and later should
> have the appropriate fix.
Using the latest version from Fedora Extras: git-core-1.5.0.6-1.fc6
> Was this really a "whee, data loss", I wonder...?
The branches definitely went away. The sha1-indexed commits are
probably still there...
Jeff
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Jan Hudec @ 2007-05-16 6:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Lars Hjemli, Git Mailing List
In-Reply-To: <464A9C9B.70904@garzik.org>
On Wed, May 16, 2007 at 01:54:35AM -0400, Jeff Garzik wrote:
> Lars Hjemli wrote:
> >On 5/16/07, Jeff Garzik <jeff@garzik.org> wrote:
> >>[jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
> >>error: Could not open config file!
> >>fatal: Branch rename failed
> >
> >This should have been fixed in v1.5.1.1, what version do you run?
>
> [jgarzik@core ~]$ rpm -q git-core
> git-core-1.5.0.6-1.fc6
>
>
> >>[jgarzik@pretzel libata-dev]$ git-branch -m upstream-fixes tmp
> >>fatal: A branch named 'tmp' already exists.
> >>
> >>[jgarzik@pretzel libata-dev]$ git branch -D tmp
> >>Deleted branch tmp.
> >
> >Could you try to run "git log -g" and see if it finds your lost branch?
>
> Doesn't seem to..
And does the .git/logs/refs/heads/upstream-fixes still exist?
If it does, than revspec upstream-fixes@{1} would still work, so you can
check it out, re-create the branch and update the ref (git update-ref).
If it does not, as last resort you'd have to git fsck --unreachable
(this gives you all things that are not reachable from any ref), filter
out only commit objects and than remember which one should have been on
that branch after reading it's log, date and changes.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Jeff Garzik @ 2007-05-16 6:40 UTC (permalink / raw)
To: Jan Hudec; +Cc: Lars Hjemli, Git Mailing List
In-Reply-To: <20070516061449.GA25273@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> And does the .git/logs/refs/heads/upstream-fixes still exist?
Nope.
> If it does not, as last resort you'd have to git fsck --unreachable
> (this gives you all things that are not reachable from any ref), filter
> out only commit objects and than remember which one should have been on
> that branch after reading it's log, date and changes.
Yeah, that will probably recover it. I wound up digging the emails out
of the trash bin, and applying them again.
Jeff
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Junio C Hamano @ 2007-05-16 6:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jan Hudec, Lars Hjemli, Git Mailing List
In-Reply-To: <464AA773.3090808@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Jan Hudec wrote:
>> And does the .git/logs/refs/heads/upstream-fixes still exist?
>
> Nope.
>
>
>> If it does not, as last resort you'd have to git fsck --unreachable
>> (this gives you all things that are not reachable from any ref), filter
>> out only commit objects and than remember which one should have been on
>> that branch after reading it's log, date and changes.
>
> Yeah, that will probably recover it. I wound up digging the emails
> out of the trash bin, and applying them again.
Ah, sorry to hear that. Trying to rename and lost both old and
new -- that is bad.
^ permalink raw reply
* Re: [StGIT RFC] Changing patch@branch syntax
From: Karl Hasselström @ 2007-05-16 6:54 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, Catalin Marinas
In-Reply-To: <20070515220310.GJ16903@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-16 00:03:10 +0200, Yann Dirson wrote:
> The patch@branch syntax is annoying, at least for bash-completion
> purposes: we don't want to provide all possible completions accross
> all branches, yet we'd like to get completion for foreign patches.
Yes, that's annoying.
> Another place where I feel it is bad is when using the full
> "patch@branch//top" syntax: the MSB is in the middle, and the LSB is
> on the right.
I agree. (Similarly, YYYYMMDD is the one true date format!)
> Both issues would be solved by switching to a MSB ordering, with a
> way to distinguish branchnames when given. Something similar to
> pathnames would fit well - eg. [/branchname/]patchname[//top].
> However, I'm not sure using slashes would be a good choice,
> precisely because of the similarity with real pathnames. But we
> don't have so many separator chars that are not special in one way
> or another, and would require quoting them to avoid more user
> confusion.
Branch names can contain slashes, and in the future patch names might
as well, so we'd need another separator. _Except_ for the fact that if
foo/bar is a branch, foo/bar/baz can't also be a branch, so using a
slash as separator is actually unambiguous.
If we similarly make it illegal for patches a/b and a/b/c to exist
simultaneously (whenever we get around to implementing slashy patch
names), we could use a single slash for patchname/{top,bottom} too.
The only remaining difficulty is to decide whether a/b/c is patch b/c
on branch a, or patch a/b/c on the current branch. We can't forbid
patch names and branch names to collide, since git can create new
branch names behind stgit's back. So I guess we'd need some way to
indicate whether branch name is included. The leading slash in your
suggestion seems as good a way as any.
However, I'm not going to recommend using only slashes. I believe life
will be much simpler if we simply use two different separators, like
this:
branch:patch@top
Then all these subsets will be trivially parseable:
branch:patch
patch
patch@top
And even this one, if we feel crazy some day:
/path/to/other/repository#branch:patch@top
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Lars Hjemli @ 2007-05-16 7:10 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jan Hudec, Git Mailing List
In-Reply-To: <464AA773.3090808@garzik.org>
On 5/16/07, Jeff Garzik <jeff@garzik.org> wrote:
> Jan Hudec wrote:
> > And does the .git/logs/refs/heads/upstream-fixes still exist?
>
> Nope.
>
>
> > If it does not, as last resort you'd have to git fsck --unreachable
> > (this gives you all things that are not reachable from any ref), filter
> > out only commit objects and than remember which one should have been on
> > that branch after reading it's log, date and changes.
>
> Yeah, that will probably recover it. I wound up digging the emails out
> of the trash bin, and applying them again.
>
That's bad.
Just out of curiosity: do you get any output from 'git log RENAMED-REF'?
--
larsh
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 7:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0705151301r7412109qd73a6008b888f8bc@mail.gmail.com>
On 2007-05-15 21:01:43 +0100, Catalin Marinas wrote:
> What is the impact on the bash completion for calling StGIT rather
> than reading those files? Is it visible?
Yes, it's visible, but not annoying (to me anyway). The overhead is
akin to the overhead we used to have when "stg help" generated the
command names -- on the order of 100-200 ms, when StGIT is in the
cache. The expensive part is to start stgit; the git calls are cheap.
So theoretically the completion script could duplicate the logic in
StGIT and avoid most of the overhead, if someone wanted it badly
enough.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-16 7:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Randal L. Schwartz, Jakub Narebski
In-Reply-To: <7vhcqdha4b.fsf@assigned-by-dhcp.cox.net>
On Wednesday 16 May 2007, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > +This typically includes files generated by a build process or temporary
> > +backup files made by your editor. Of course, 'not' tracking files with git
> > +is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
> > +annoying to have these untracked files lying around; e.g. they make
> > +"`git add .`" and "`git commit -a`" practically useless, and they keep
>
> I think we would want to s/and "`git commit -a`//; if you start
> tracking the file, .gitignore would not interfere with it AFAIK.
You're right. "git commit -a" doesn't actually add untracked files at all
(you still have to do "git add", anyway). Don't know what I was thinking.
Feel free to edit.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Junio C Hamano @ 2007-05-16 7:36 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff Garzik, Jan Hudec, Git Mailing List
In-Reply-To: <8c5c35580705160010s506b6f53y4209c1b541c3112a@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 5/16/07, Jeff Garzik <jeff@garzik.org> wrote:
>> Jan Hudec wrote:
>> > And does the .git/logs/refs/heads/upstream-fixes still exist?
>>
>> Nope.
>>
>>
>> > If it does not, as last resort you'd have to git fsck --unreachable
>> > (this gives you all things that are not reachable from any ref), filter
>> > out only commit objects and than remember which one should have been on
>> > that branch after reading it's log, date and changes.
>>
>> Yeah, that will probably recover it. I wound up digging the emails out
>> of the trash bin, and applying them again.
>>
>
> That's bad.
>
> Just out of curiosity: do you get any output from 'git log RENAMED-REF'?
Another probably easier way to recover them would be 'git
lost-found'.
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-16 7:38 UTC (permalink / raw)
To: git; +Cc: J. Bruce Fields, Junio C Hamano, Randal L. Schwartz,
Jakub Narebski
In-Reply-To: <20070516033032.GA20022@fieldses.org>
On Wednesday 16 May 2007, J. Bruce Fields wrote:
> On Wed, May 16, 2007 at 02:31:40AM +0200, Johan Herland wrote:
> > The todo list at the end of the user manual says that something must be
> > said about .gitignore. Also, there seems to be a lack of documentation
> > on how to choose between the various types of ignore files (.gitignore
> > vs. .git/info/exclude, etc.).
>
> Thanks for doing this!
>
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -1188,6 +1188,75 @@ description. Tools that turn commits into email, for example, use
> > the first line on the Subject line and the rest of the commit in the
> > body.
> >
> > +[[ignoring-files]]
> > +Ignoring files
> > +--------------
>
> This looks like a sensible place to add it....
>
> > +A project will often generate files that you do 'not' want to track with git.
> > +This typically includes files generated by a build process or temporary
> > +backup files made by your editor. Of course, 'not' tracking files with git
> > +is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
> > +annoying to have these untracked files lying around; e.g. they make
> > +"`git add .`" and "`git commit -a`" practically useless, and they keep
> > +showing up in the output of "`git status`", etc.
>
> It might be cute to introduce this with an example; "suppose you just
> imported a new project into git, build it, and run git-status. The
> output you get might look like:..." etc.
This would of course work as well, but I was trying to keep it as short as possible.
Ignoring files isn't a big part of what git is really about, so I'd like for this
section to stay as short and to-the-point as possible.
> > +Git therefore provides "exclude patterns" for telling git which files to
> > +actively ignore. Exclude patterns are thoroughly explained in the
> > +"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
> > +but the heart of the concept is simply a list of files which git should
> > +ignore. Entries in the list may contain globs to specify multiple files,
> > +or may be prefixed by "`!`" to explicitly include (un-ignore) a previously
> > +excluded (ignored) file (i.e. later exclude patterns override earlier ones).
>
> It might simplify things just to start off by talking about .gitignore
> exclusively, rather than talking about exclude patterns in general;
> something like: "Git therefore allows you to provide .gitignore files,
> which consist of a list of entries, processed in order from top to
> bottom, each telling git about some files to ignore...."
>
> Then introduce the other options at the end: "for exclude patterns that
> you want to be used just by one repo, or by a group of repos on one
> computer, you can use .git/info/exclude or core.excludesfile." In fact,
> I'd be *almost* tempted just to leave the discussion of these local
> exclude files at that, and refer elsewhere for the details. Do people
> really find them useful?
Sounds like a good idea. Feel free to rewrite. But the original impetus for
the section was Randal's question on the difference between the various
ignore files, so make sure that's still in there somewhere.
> But those are nits. I'll happily take it as is and then revise
> later....
Thanks :)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Sixt @ 2007-05-16 8:02 UTC (permalink / raw)
To: git
In-Reply-To: <f329bf540705151251n10c05452s5a74e8eaa513bf90@mail.gmail.com>
Han-Wen Nienhuys wrote:
>
> I think it might be a bug. Patches are welcome.
>
> I suppose git-clone has a hardcoded path. Paths under windows should
> be either taken from registry (yuck) or dynamically detected from
> $PATH and argv[0].
>
> 2007/5/15, Aaron Gray <angray@beeb.net>:
> > Han-Wen,
> >
> > Dont know whether you got the message or not so I'll try you again.
> >
> > On doing a git-clone I get the message :-
> >
> > warning: templates not found /usr/share/git-core/templates/
> >
This should have been fixed by 2d84ffaf (currently master~1 in
git://repo.or.cz/git/mingw.git) and its parent. Can you make sure that
your build picks up the new Makefile setting that these commits
introduce?
-- Hannes
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: Jan Hudec @ 2007-05-16 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, kha, bfields
In-Reply-To: <7vmz05ffad.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 11:34:02PM -0700, Junio C Hamano wrote:
> botched one:
>
> outgoing:
> body in utf-8
> Content-type: text/plain; charset=utf-8
> no MIME-Version: header
>
> vger relayed to recipients:
> body untouched
> Content-type: text/plain; charset=iso-8859-1
> MIME-Version: 1.0
The strange thing is, that I got it from vger -- with
Content-type: text/plain; charset=utf-8
Therefore either:
- It's not vger, but some other mail software, that munges it.
- Some software on my side correctly guesses that it should have been
utf-8, but I don't really believe that.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Opinions on bug fix organisation
From: Andy Parkins @ 2007-05-16 10:38 UTC (permalink / raw)
To: git
Hello,
This is not so much a question about git, but more about history organisation.
I'm undecided on the best way to deal with bug fix history.
Imagine this situation:
* -- * -- B -- * -- * -- *
"B" is a commit that introduced a feature and a bug, that bug is present
forever more in history (which I think is good - history is history). I've
pushed the repository to the rest of the developers in the meantime, so there
is no editing "B" and doing some rebase magic.
Now, I want to make a commit that fixes that bug. These are the options:
* -- * -- B -- * -- * -- * -- F
or
* -- * -- B -- * -- * -- * -- M
\ /
--------------- F
That is - just commit a fix or, commit the fix, "F", directly on "B" then
merge that fix back to HEAD with "M".
I quite like option 2 because it records intent - i.e. "I wish I could have
gone back and changed this revision, but I can't", but it makes a more
complicated history.
What do people think?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: Jeff King @ 2007-05-16 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, kha, bfields
In-Reply-To: <7vmz05ffad.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 11:34:02PM -0700, Junio C Hamano wrote:
> I think you are trying to figure out how vger adds/munges the
> headers, and the above is not very useful for people but
> yourself unless you explicitly say what headers you gave on your
> end in the body of the message, is it?
Yes, I'm sorry that the message itself looked a bit vague. It was
actually about the 4th or 5th such message I sent, as the list filter
kept blocking the previous ones, so with each iteration I made the
message shorter and shorter to try to remove any offending text.
So Karl and Bruce actually received several explanatory messages that
everyone else didn't, and I really only expected them to be replying.
> Judging from the list responses, I am guessing the situation is
> like this. Does that match your understanding?
Yes, this is close.
> outgoing:
> body in utf-8
> Content-type: text/plain; charset=utf-8
> no MIME-Version: header
>
> vger relayed to recipients:
> body untouched
> Content-type: text/plain; charset=iso-8859-1
> MIME-Version: 1.0
There is also a "Content-Transfer-Encoding: 8bit" that gets switched to
quoted-printable (and the body is actually encoded as QP). However, the
change of charset is the problem.
> I am not sure what exactly you meant by with/without "the right
> mime header", but the above is based on my guess that you meant
> only MIME-VERSION header.
Yes, the two messages differed _only_ in the presence of a MIME-Version
header.
So now that I have the data, let me explain the sequence of events in
the bug, which should hopefully explain what everyone has seen.
1. Bruce generates a message containing utf8 characters in the body and
the following headers:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
and _no_ MIME-Version header. This is produced by git-format-patch on a
commit with non-ascii in the body. The message is sent to vger, and cc'd
to some recipients, and we move to step 2.
2a. The cc'd recipients receive one copy of the message intact; none of
the mailservers along the route do any munging. This message is done.
2b. vger sends the message to each list member in turn. What the user
sees depends on the mail route. We move to step 3.
3a. If the next hop from vger advertises 8BITMIME in the SMTP session,
then vger submits the message intact. This is the case for me, so I see
all messages intact (and is why I needed responses from others --
specifically, I knew Karl and Bruce were seeing the problem). This
message is done.
3b. If the next hop does not advertise 8BITMIME, vger must convert the
message to a 7bit encoding (it chooses quoted-printable). Continue to
step 4.
4a. If the message has valid MIME headers, then vger can simply encode,
re-writing the content-transfer-encoding to quoted-printable and
encoding the body. vger considers valid mime headers to be a
MIME-version header and a content-type header. This is the case for the
second message I set, which appears correctly to all recipients.
4b. If the message doesn't have valid MIME headers, then vger adds the
headers. Without a MIME-Version header, it ignores the content-type and
guesses at a suitable one, using text/plain with some totally arbitrary
local charset (in this case "iso-8859-1"). This message has now been
incorrectly munged (claims latin1 charset, but has utf8 characters).
vger puts an explanation into the X-Warning headers of the munged
message (the only unexplained thing that I had to test is that
MIME-Version is critical to vger believing the current content-type).
So recipients see the bug IFF
the original has utf8 characters
AND the original lacks a MIME-Version header
AND their mailserver doesn't claim 8BITMIME
Interestingly, rfc1428 claims that in this case vger should actually set
the charset to "unknown-8bit":
If no information about the character set in use is available, the
gateway should upgrade the content by using the character set
"unknown-8bit". The unknown-8bit value of the charset parameter
indicates only that no reliable information about the character set(s)
used in the message was available.
Though that really just pushes the problem to the recipients MUA, and I
have no idea what the handling of "unknown-8bit" is like there.
-Peff
^ permalink raw reply
* Re: testing vger handling of charsets (part 2)
From: Jeff King @ 2007-05-16 10:57 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, git, kha, bfields
In-Reply-To: <20070516092915.GA10660@artax.karlin.mff.cuni.cz>
On Wed, May 16, 2007 at 11:29:15AM +0200, Jan Hudec wrote:
> The strange thing is, that I got it from vger -- with
> Content-type: text/plain; charset=utf-8
>
> Therefore either:
> - It's not vger, but some other mail software, that munges it.
> - Some software on my side correctly guesses that it should have been
> utf-8, but I don't really believe that.
It's option 3:
- vger selectively munges based on whether your server claims 8BITMIME
during the SMTP EHLO. So some list members never saw this issue at
all.
-Peff
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeff King @ 2007-05-16 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, J. Bruce Fields, git
In-Reply-To: <7vlkfqj5fm.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 11:41:01AM -0700, Junio C Hamano wrote:
> I do not want to break projects whose members consistently use a
> single non UTF-8 encoding, and I've been hoping that in such a
> use case they should not have to set any of these encoding
> configuration. So in that sense I would be somewhat reluctant
> to agree with the last one. But I am getting a feeling that it
> is a losing battle.
I think that is a good goal, but I think we have already failed, as
git-format-patch generates content-type headers with charset=utf-8
(unless the encoding variables are set up). This code was added last
year around this time (cdd406e38).
It looks like this is squelched in the presence of format.headers
configuration. However, that still means they have to do _something_ to
get it to work right (and I note that the fact that format.headers
squelches MIME headers doesn't seem to be documented anywhere...)
> I think it is a reasonable compromise to do it the way you
> outlined. Doing it at patch generation time would fix the
> ambiguity issues during the step 2, so it might turn out to be
> necessary to add the encoding header to format-patch output
> after all, but send-email needs to be able to handle messages
> that do not have the header anyway, so probably the first step
> is to do so in send-email.
As I noted in my other email, it actually _is_ there already. So the
MIME-Version fix just keeps the status quo, and we've been doing it this
way for a year.
Is it still worth making these guesses in send-email?
> > Also Junio, it looks like commit 7cbcf4d5 moved parsing of the
> > --encoding parameter into setup_revisions, but it's still being checked
> > for in cmd_log_init. Can you confirm that the latter is now superfluous
> > and can be removed?
> Thanks for noticing, and I think you are right. The code parses
> the same input and sets the same global variable the same way.
Well, I wouldn't have noticed it if you hadn't written git-log -S. :) In
case you haven't fixed it yet, here it is in patch form:
-- >8 --
cmd_log_init: remove parsing of --encoding command line parameter
This was moved to the setup_revisions parsing in 7cbcf4d5, so it was
never being triggered.
Signed-off-by: Jeff King <peff@peff.net>
---
diff --git a/builtin-log.c b/builtin-log.c
index 3744712..cebb958 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -60,13 +60,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
rev->always_show_header = 0;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- if (!prefixcmp(arg, "--encoding=")) {
- arg += 11;
- if (strcmp(arg, "none"))
- git_log_output_encoding = xstrdup(arg);
- else
- git_log_output_encoding = "";
- } else if (!strcmp(arg, "--decorate")) {
+ if (!strcmp(arg, "--decorate")) {
if (!decorate)
for_each_ref(add_ref_decoration, NULL);
decorate = 1;
^ permalink raw reply related
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeff King @ 2007-05-16 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Karl Hasselström, git
In-Reply-To: <7vabw6j5db.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 11:42:24AM -0700, Junio C Hamano wrote:
> > + "MIME-Version: 1.0\n"
> Thanks; I think this is a sane thing to do.
Do you want me to work up a commit message, or do you just want to
assemble it from my other discussion?
BTW, I also checked for other places where we generate a content-type.
The only other place I found was when we do multipart/mixed
(log-tree.c:209), but we correctly generate the MIME-Version header
there.
-Peff
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Johannes Schindelin @ 2007-05-16 11:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jan Hudec, git
In-Reply-To: <46a038f90705152225y529c9db3x8615822e876c25a8@mail.gmail.com>
Hi,
On Wed, 16 May 2007, Martin Langhoff wrote:
> On 5/16/07, Jan Hudec <bulb@ucw.cz> wrote:
> > Did anyone already think about fetching over HTTP working similarly to the
> > native git protocol?
>
> Do the indexes have enough info to use them with http ranges? It'd be
> chunkier than a smart protocol, but it'd still work with dumb servers.
It would not be really performant, would it? Besides, not all Web servers
speak HTTP/1.1...
Ciao,
Dscho
^ permalink raw reply
* Re: newby question about merge.
From: Johannes Schindelin @ 2007-05-16 11:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f2c23k$dm0$1@sea.gmane.org>
Hi,
On Tue, 15 May 2007, Jakub Narebski wrote:
> You can just do "git cat-file -p :2:filename > filename", then "git add
> filename" (or "git update-index filename") to resolve conflict.
Do we really want to advertise this obscure-looking plumbing? Wouldn't it
be better to teach people to use "git show" instead?
I mean, people can get intimidated by that...
Ciao,
Dscho
^ permalink raw reply
* Re: pull/push inconsistencies
From: Jeff King @ 2007-05-16 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <7vtzudhayr.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 05:24:28PM -0700, Junio C Hamano wrote:
> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
>
> The standard answer is not to push into a live repository
> without understanding what you are doing.
My impression here is that Martin is saying that pushing does not update
the remote tracking branch in the local repository (as, e.g., cogito has
always done). But I thought somebody (Ted?) recently submitted a patch
to change that.
> git-push without parameters and configuration pushes matching
> branches. This has been true from day one. Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.
I had done a patch in that direction (actually, it just avoided pushing
refs/remotes/) and have been planning to follow up with restricting
git-push to just refs/heads/. I'll try to work on that in the next day
or so.
-Peff
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-16 12:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070516071130.GB7453@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
On 16/05/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-15 21:01:43 +0100, Catalin Marinas wrote:
>
> > What is the impact on the bash completion for calling StGIT rather
> > than reading those files? Is it visible?
>
> Yes, it's visible, but not annoying (to me anyway). The overhead is
> akin to the overhead we used to have when "stg help" generated the
> command names -- on the order of 100-200 ms, when StGIT is in the
> cache. The expensive part is to start stgit; the git calls are cheap.
> So theoretically the completion script could duplicate the logic in
> StGIT and avoid most of the overhead, if someone wanted it badly
> enough.
I did a quick test of 'stg series' with the DAG patches applied, on a
Linux kernel repository ('du -sh .git' is 285M) with 42 patches (only
25 applied). It constantly takes over 2 seconds to complete (compared
to < 200ms without the DAG patches). The problem is that this delay
will happen for bash completion as well.
It seems that most of the time is spent in git._output_lines() called
from stack.read_refs() (for git-show-ref). I attach the profiling
output generated by stg-prof.
--
Catalin
[-- Attachment #2: prof.txt --]
[-- Type: text/plain, Size: 38609 bytes --]
+ cross-arm
+ init-err
+ ll-printk
+ compressed-head-stack
+ armv7-uncompress
+ armv7-tlb
+ armv7-xenon
+ armv7-vfpv3
+ armv7-neon
+ armv7-thumb2-user
+ pb926-pci-io
+ mpcore-smsc911x
+ smsc911x-driver
+ realview-eb-pci-mem
+ realview-eb-pci-io
+ nommu-consistent-api
+ nommu-fault
+ nommu-page-tlb
+ nommu-context-id
+ nommu-integrator
+ nommu-realview-eb
+ nommu-kconfig
+ nommu-ptrace
+ nommu-armv6
> nommu-armv7
- per-cpu-asids
- arch-dsb-mmiowb
- t2-arch-arm-clone
- t2-function-type
- t2-exception-handling
- t2-unified-syntax
- t2-exception-handling-alternative
- t2-srs-variant
- thumb2-kernel-port
- errata-arm1136-364296
- errata-arm1136-411920
- pipt-icache-flush
- smp-writealloc
3150 function calls (3112 primitive calls) in 2.229 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 2.229 2.229 <string>:1(?)
1 0.000 0.000 0.000 0.000 ConfigParser.py:105(Error)
1 0.000 0.000 0.000 0.000 ConfigParser.py:117(NoSectionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:124(DuplicateSectionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:131(NoOptionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:140(InterpolationError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:148(InterpolationMissingOptionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:161(InterpolationSyntaxError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:165(InterpolationDepthError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:176(ParsingError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:188(MissingSectionHeaderError)
1 0.000 0.000 0.009 0.009 ConfigParser.py:202(RawConfigParser)
1 0.000 0.000 0.000 0.000 ConfigParser.py:487(ConfigParser)
1 0.000 0.000 0.002 0.002 ConfigParser.py:570(SafeConfigParser)
1 0.000 0.000 0.011 0.011 ConfigParser.py:88(?)
1 0.000 0.000 0.000 0.000 UserDict.py:19(__getitem__)
1 0.000 0.000 0.000 0.000 UserDict.py:62(__contains__)
1 0.000 0.000 0.000 0.000 basedir.py:2(?)
1 0.007 0.007 0.007 0.007 basedir.py:23(__output)
1 0.000 0.000 0.007 0.007 basedir.py:33(get)
1 0.003 0.003 0.011 0.011 common.py:2(?)
1 0.000 0.000 0.000 0.000 common.py:32(CmdException)
1 0.000 0.000 0.000 0.000 common.py:37(RevParseException)
1 0.000 0.000 0.006 0.006 config.py:125(config_setup)
1 0.000 0.000 0.000 0.000 config.py:134(ConfigOption)
2 0.000 0.000 0.000 0.000 config.py:137(__init__)
1 0.000 0.000 0.000 0.000 config.py:2(?)
1 0.000 0.000 0.000 0.000 config.py:24(GitConfigException)
1 0.000 0.000 0.000 0.000 config.py:27(GitConfig)
1 0.006 0.006 0.006 0.006 config.py:65(get)
1 0.005 0.005 0.023 0.023 git.py:180(_output_one_line)
2 2.029 1.015 2.067 1.034 git.py:192(_output_lines)
1 0.002 0.002 0.003 0.003 git.py:2(?)
1 0.000 0.000 0.023 0.023 git.py:288(get_head_file)
1 0.000 0.000 0.000 0.000 git.py:30(GitException)
1 0.000 0.000 0.000 0.000 git.py:39(Person)
1 0.000 0.000 0.000 0.000 git.py:71(Commit)
1 0.000 0.000 0.000 0.000 gitmergeonefile.py:2(?)
1 0.000 0.000 0.000 0.000 gitmergeonefile.py:27(GitMergeException)
1 0.001 0.001 2.228 2.228 main.py:197(main)
1 0.000 0.000 0.000 0.000 main.py:32(canonical_cmd)
1 0.000 0.000 0.015 0.015 main.py:51(__getitem__)
1 0.000 0.000 0.000 0.000 optparse.py:1007(_create_option_list)
1 0.000 0.000 0.001 0.001 optparse.py:1012(_populate_option_list)
1 0.000 0.000 0.000 0.000 optparse.py:1022(_init_parsing_state)
1 0.000 0.000 0.000 0.000 optparse.py:1036(set_usage)
1 0.000 0.000 0.000 0.000 optparse.py:1059(get_default_values)
1 0.000 0.000 0.000 0.000 optparse.py:1091(_get_args)
1 0.000 0.000 0.000 0.000 optparse.py:1097(parse_args)
1 0.000 0.000 0.000 0.000 optparse.py:1136(check_values)
1 0.000 0.000 0.000 0.000 optparse.py:1149(_process_args)
1 0.000 0.000 0.000 0.000 optparse.py:140(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:247(__init__)
12 0.001 0.000 0.002 0.000 optparse.py:413(__init__)
12 0.000 0.000 0.000 0.000 optparse.py:432(_check_opt_strings)
12 0.000 0.000 0.000 0.000 optparse.py:441(_set_opt_strings)
12 0.000 0.000 0.000 0.000 optparse.py:462(_set_attrs)
12 0.000 0.000 0.000 0.000 optparse.py:480(_check_action)
12 0.000 0.000 0.000 0.000 optparse.py:486(_check_type)
12 0.000 0.000 0.000 0.000 optparse.py:504(_check_choice)
12 0.000 0.000 0.000 0.000 optparse.py:517(_check_dest)
12 0.000 0.000 0.000 0.000 optparse.py:528(_check_const)
12 0.000 0.000 0.000 0.000 optparse.py:534(_check_nargs)
12 0.000 0.000 0.000 0.000 optparse.py:543(_check_callback)
1 0.000 0.000 0.000 0.000 optparse.py:662(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:748(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:759(_create_option_mappings)
1 0.000 0.000 0.000 0.000 optparse.py:775(set_conflict_handler)
1 0.000 0.000 0.000 0.000 optparse.py:780(set_description)
13 0.000 0.000 0.000 0.000 optparse.py:786(_check_conflict)
13 0.000 0.000 0.001 0.000 optparse.py:815(add_option)
1 0.000 0.000 0.001 0.001 optparse.py:845(add_options)
1 0.000 0.000 0.001 0.001 optparse.py:975(__init__)
1 0.000 0.000 0.000 0.000 os.py:444(__setitem__)
4 0.000 0.000 0.000 0.000 popen2.py:21(_cleanup)
1 0.000 0.000 0.000 0.000 popen2.py:25(Popen3)
4 0.064 0.016 0.064 0.016 popen2.py:31(__init__)
1 0.000 0.000 0.000 0.000 popen2.py:7(?)
3 0.000 0.000 0.000 0.000 popen2.py:87(wait)
1 0.000 0.000 0.000 0.000 popen2.py:97(Popen4)
1 0.000 0.000 0.000 0.000 posixpath.py:110(basename)
5 0.000 0.000 0.000 0.000 posixpath.py:184(isdir)
4 0.000 0.000 0.000 0.000 posixpath.py:197(isfile)
8 0.000 0.000 0.000 0.000 posixpath.py:56(join)
1 0.000 0.000 0.000 0.000 posixpath.py:74(split)
1 0.000 0.000 2.229 2.229 profile:0(main())
0 0.000 0.000 profile:0(profiler)
1 0.001 0.001 2.163 2.163 series.py:111(func)
1 0.001 0.001 0.015 0.015 series.py:2(?)
38 0.001 0.000 0.001 0.000 series.py:88(__print_patch)
46 0.000 0.000 0.000 0.000 sets.py:119(__iter__)
1 0.000 0.000 0.000 0.000 sets.py:356(_update)
1 0.000 0.000 0.000 0.000 sets.py:393(ImmutableSet)
1 0.001 0.001 0.001 0.001 sets.py:41(?)
1 0.000 0.000 0.000 0.000 sets.py:418(Set)
72 0.001 0.000 0.001 0.000 sets.py:425(__init__)
89 0.001 0.000 0.001 0.000 sets.py:515(add)
25 0.000 0.000 0.000 0.000 sets.py:528(remove)
1 0.000 0.000 0.000 0.000 sets.py:564(_TemporarilyImmutableSet)
1 0.000 0.000 0.000 0.000 sets.py:83(BaseSet)
26 0.000 0.000 0.000 0.000 sets.py:99(__len__)
1 0.000 0.000 0.000 0.000 shutil.py:16(Error)
1 0.000 0.000 0.000 0.000 shutil.py:5(?)
896 0.017 0.000 0.028 0.000 sre.py:129(match)
4 0.000 0.000 0.013 0.003 sre.py:177(compile)
900 0.012 0.000 0.025 0.000 sre.py:216(_compile)
5 0.000 0.000 0.001 0.000 sre_compile.py:151(_compile_charset)
5 0.000 0.000 0.000 0.000 sre_compile.py:180(_optimize_charset)
17/4 0.001 0.000 0.002 0.001 sre_compile.py:24(_compile)
7 0.000 0.000 0.000 0.000 sre_compile.py:324(_simple)
4 0.000 0.000 0.001 0.000 sre_compile.py:331(_compile_info)
12 0.000 0.000 0.000 0.000 sre_compile.py:42(<lambda>)
8 0.000 0.000 0.000 0.000 sre_compile.py:440(isstring)
4 0.000 0.000 0.004 0.001 sre_compile.py:446(_code)
4 0.000 0.000 0.013 0.003 sre_compile.py:461(compile)
32 0.000 0.000 0.000 0.000 sre_parse.py:133(__len__)
51 0.000 0.000 0.000 0.000 sre_parse.py:137(__getitem__)
7 0.000 0.000 0.000 0.000 sre_parse.py:139(__setitem__)
7 0.000 0.000 0.000 0.000 sre_parse.py:141(__getslice__)
44 0.000 0.000 0.000 0.000 sre_parse.py:145(append)
24/11 0.001 0.000 0.001 0.000 sre_parse.py:147(getwidth)
4 0.000 0.000 0.000 0.000 sre_parse.py:183(__init__)
125 0.001 0.000 0.001 0.000 sre_parse.py:187(__next)
59 0.001 0.000 0.001 0.000 sre_parse.py:200(match)
98 0.002 0.000 0.003 0.000 sre_parse.py:206(get)
23 0.000 0.000 0.000 0.000 sre_parse.py:215(isident)
4 0.000 0.000 0.001 0.000 sre_parse.py:221(isname)
2 0.000 0.000 0.000 0.000 sre_parse.py:240(_class_escape)
6 0.000 0.000 0.000 0.000 sre_parse.py:269(_escape)
10/4 0.000 0.000 0.008 0.002 sre_parse.py:312(_parse_sub)
10/4 0.003 0.000 0.008 0.002 sre_parse.py:367(_parse)
4 0.000 0.000 0.009 0.002 sre_parse.py:614(parse)
4 0.000 0.000 0.000 0.000 sre_parse.py:75(__init__)
6 0.000 0.000 0.000 0.000 sre_parse.py:80(opengroup)
6 0.000 0.000 0.000 0.000 sre_parse.py:91(closegroup)
17 0.000 0.000 0.000 0.000 sre_parse.py:98(__init__)
1 0.000 0.000 0.000 0.000 stack.py:112(StgitObject)
1 0.000 0.000 0.000 0.000 stack.py:115(_set_dir)
6 0.000 0.000 0.000 0.000 stack.py:117(_dir)
1 0.000 0.000 0.000 0.000 stack.py:142(Patch)
1 0.004 0.004 0.008 0.008 stack.py:2(?)
1 0.000 0.000 0.000 0.000 stack.py:277(PatchorderCache)
1 0.000 0.000 0.000 0.000 stack.py:280(__init__)
1 0.000 0.000 0.000 0.000 stack.py:283(__invalidate)
59 0.001 0.000 0.001 0.000 stack.py:286(__cache)
2 0.000 0.000 0.000 0.000 stack.py:293(read_file)
1 0.000 0.000 0.000 0.000 stack.py:30(StackException)
59 0.005 0.000 0.007 0.000 stack.py:315(cmp)
1 0.014 0.014 0.110 0.110 stack.py:327(read_refs)
1 0.000 0.000 0.000 0.000 stack.py:33(FilterUntil)
1 0.002 0.002 2.006 2.006 stack.py:342(unapplied_patches)
1 0.026 0.026 0.037 0.037 stack.py:358(sort_applied_patches)
1 0.000 0.000 0.000 0.000 stack.py:382(AppliedCache)
1 0.000 0.000 0.000 0.000 stack.py:385(__init__)
2 0.000 0.000 2.161 1.080 stack.py:389(get_applied)
1 0.000 0.000 0.000 0.000 stack.py:392(get_unapplied)
1 0.000 0.000 0.000 0.000 stack.py:417(__invalidate)
3 0.000 0.000 0.000 0.000 stack.py:420(__cached)
3 0.001 0.000 2.161 0.720 stack.py:422(__cache)
1 0.000 0.000 0.000 0.000 stack.py:434(Series)
1 0.000 0.000 0.031 0.031 stack.py:437(__init__)
1 0.000 0.000 0.000 0.000 stack.py:479(get_branch)
1 0.000 0.000 0.000 0.000 stack.py:497(get_current)
2 0.000 0.000 2.161 1.080 stack.py:507(get_applied)
1 0.000 0.000 0.000 0.000 stack.py:510(get_unapplied)
1 0.000 0.000 0.000 0.000 stack.py:513(get_hidden)
2 0.000 0.000 0.000 0.000 stack.py:646(is_initialised)
8 0.000 0.000 0.000 0.000 stat.py:29(S_IFMT)
5 0.000 0.000 0.000 0.000 stat.py:45(S_ISDIR)
3 0.000 0.000 0.000 0.000 stat.py:54(S_ISREG)
1 0.000 0.000 0.000 0.000 templates.py:2(?)
1 0.000 0.000 0.000 0.000 utils.py:107(strip_prefix)
1 0.000 0.000 0.000 0.000 utils.py:153(EditorException)
1 0.001 0.001 0.001 0.001 utils.py:2(?)
Ordered by: standard name
Function called...
<string>:1(?) main.py:197(main)(1) 2.228
ConfigParser.py:105(Error) --
ConfigParser.py:117(NoSectionError) --
ConfigParser.py:124(DuplicateSectionError) --
ConfigParser.py:131(NoOptionError) --
ConfigParser.py:140(InterpolationError) --
ConfigParser.py:148(InterpolationMissingOptionError) --
ConfigParser.py:161(InterpolationSyntaxError) --
ConfigParser.py:165(InterpolationDepthError) --
ConfigParser.py:176(ParsingError) --
ConfigParser.py:188(MissingSectionHeaderError) --
ConfigParser.py:202(RawConfigParser) sre.py:177(compile)(2) 0.013
ConfigParser.py:487(ConfigParser) --
ConfigParser.py:570(SafeConfigParser) sre.py:177(compile)(1) 0.013
ConfigParser.py:88(?) ConfigParser.py:105(Error)(1) 0.000
ConfigParser.py:117(NoSectionError)(1) 0.000
ConfigParser.py:124(DuplicateSectionError)(1) 0.000
ConfigParser.py:131(NoOptionError)(1) 0.000
ConfigParser.py:140(InterpolationError)(1) 0.000
ConfigParser.py:148(InterpolationMissingOptionError)(1) 0.000
ConfigParser.py:161(InterpolationSyntaxError)(1) 0.000
ConfigParser.py:165(InterpolationDepthError)(1) 0.000
ConfigParser.py:176(ParsingError)(1) 0.000
ConfigParser.py:188(MissingSectionHeaderError)(1) 0.000
ConfigParser.py:202(RawConfigParser)(1) 0.009
ConfigParser.py:487(ConfigParser)(1) 0.000
ConfigParser.py:570(SafeConfigParser)(1) 0.002
UserDict.py:19(__getitem__) --
UserDict.py:62(__contains__) --
basedir.py:2(?) --
basedir.py:23(__output) --
basedir.py:33(get) UserDict.py:62(__contains__)(1) 0.000
basedir.py:23(__output)(1) 0.007
common.py:2(?) common.py:32(CmdException)(1) 0.000
common.py:37(RevParseException)(1) 0.000
stack.py:2(?)(1) 0.008
utils.py:2(?)(1) 0.001
common.py:32(CmdException) --
common.py:37(RevParseException) --
config.py:125(config_setup) config.py:65(get)(1) 0.006
os.py:444(__setitem__)(1) 0.000
config.py:134(ConfigOption) --
config.py:137(__init__) --
config.py:2(?) basedir.py:2(?)(1) 0.000
config.py:24(GitConfigException)(1) 0.000
config.py:27(GitConfig)(1) 0.000
config.py:134(ConfigOption)(1) 0.000
config.py:24(GitConfigException) --
config.py:27(GitConfig) --
config.py:65(get) --
git.py:180(_output_one_line) popen2.py:31(__init__)(1) 0.064
popen2.py:87(wait)(1) 0.000
git.py:192(_output_lines) popen2.py:31(__init__)(2) 0.064
popen2.py:87(wait)(2) 0.000
git.py:2(?) git.py:30(GitException)(1) 0.000
git.py:39(Person)(1) 0.000
git.py:71(Commit)(1) 0.000
gitmergeonefile.py:2(?)(1) 0.000
sets.py:41(?)(1) 0.001
shutil.py:5(?)(1) 0.000
git.py:288(get_head_file) git.py:180(_output_one_line)(1) 0.023
utils.py:107(strip_prefix)(1) 0.000
git.py:30(GitException) --
git.py:39(Person) --
git.py:71(Commit) --
gitmergeonefile.py:2(?) config.py:137(__init__)(2) 0.000
gitmergeonefile.py:27(GitMergeException)(1) 0.000
gitmergeonefile.py:27(GitMergeException) --
main.py:197(main) ConfigParser.py:88(?)(1) 0.011
UserDict.py:19(__getitem__)(1) 0.000
config.py:125(config_setup)(1) 0.006
main.py:32(canonical_cmd)(1) 0.000
main.py:51(__getitem__)(1) 0.015
optparse.py:975(__init__)(1) 0.001
optparse.py:1097(parse_args)(1) 0.000
posixpath.py:110(basename)(1) 0.000
series.py:111(func)(1) 2.163
stack.py:437(__init__)(1) 0.031
main.py:32(canonical_cmd) --
main.py:51(__getitem__) series.py:2(?)(1) 0.015
optparse.py:1007(_create_option_list) optparse.py:759(_create_option_mappings)(1) 0.000
optparse.py:1012(_populate_option_list) optparse.py:815(add_option)(1) 0.001
optparse.py:845(add_options)(1) 0.001
optparse.py:1022(_init_parsing_state) --
optparse.py:1036(set_usage) --
optparse.py:1059(get_default_values) optparse.py:662(__init__)(1) 0.000
optparse.py:1091(_get_args) --
optparse.py:1097(parse_args) optparse.py:1059(get_default_values)(1) 0.000
optparse.py:1091(_get_args)(1) 0.000
optparse.py:1136(check_values)(1) 0.000
optparse.py:1149(_process_args)(1) 0.000
optparse.py:1136(check_values) --
optparse.py:1149(_process_args) --
optparse.py:140(__init__) --
optparse.py:247(__init__) optparse.py:140(__init__)(1) 0.000
optparse.py:413(__init__) optparse.py:432(_check_opt_strings)(12) 0.000
optparse.py:441(_set_opt_strings)(12) 0.000
optparse.py:462(_set_attrs)(12) 0.000
optparse.py:480(_check_action)(12) 0.000
optparse.py:486(_check_type)(12) 0.000
optparse.py:504(_check_choice)(12) 0.000
optparse.py:517(_check_dest)(12) 0.000
optparse.py:528(_check_const)(12) 0.000
optparse.py:534(_check_nargs)(12) 0.000
optparse.py:543(_check_callback)(12) 0.000
optparse.py:432(_check_opt_strings) --
optparse.py:441(_set_opt_strings) --
optparse.py:462(_set_attrs) --
optparse.py:480(_check_action) --
optparse.py:486(_check_type) --
optparse.py:504(_check_choice) --
optparse.py:517(_check_dest) --
optparse.py:528(_check_const) --
optparse.py:534(_check_nargs) --
optparse.py:543(_check_callback) --
optparse.py:662(__init__) --
optparse.py:748(__init__) optparse.py:775(set_conflict_handler)(1) 0.000
optparse.py:780(set_description)(1) 0.000
optparse.py:1007(_create_option_list)(1) 0.000
optparse.py:759(_create_option_mappings) --
optparse.py:775(set_conflict_handler) --
optparse.py:780(set_description) --
optparse.py:786(_check_conflict) --
optparse.py:815(add_option) optparse.py:786(_check_conflict)(13) 0.000
optparse.py:845(add_options) optparse.py:815(add_option)(12) 0.001
optparse.py:975(__init__) optparse.py:247(__init__)(1) 0.000
optparse.py:748(__init__)(1) 0.000
optparse.py:1012(_populate_option_list)(1) 0.001
optparse.py:1022(_init_parsing_state)(1) 0.000
optparse.py:1036(set_usage)(1) 0.000
os.py:444(__setitem__) --
popen2.py:21(_cleanup) --
popen2.py:25(Popen3) --
popen2.py:31(__init__) popen2.py:21(_cleanup)(4) 0.000
popen2.py:7(?) popen2.py:25(Popen3)(1) 0.000
popen2.py:97(Popen4)(1) 0.000
popen2.py:87(wait) --
popen2.py:97(Popen4) --
posixpath.py:110(basename) posixpath.py:74(split)(1) 0.000
posixpath.py:184(isdir) stat.py:45(S_ISDIR)(5) 0.000
posixpath.py:197(isfile) stat.py:54(S_ISREG)(3) 0.000
posixpath.py:56(join) --
posixpath.py:74(split) --
profile:0(main()) <string>:1(?)(1) 2.229
profile:0(profiler) profile:0(main())(1) 2.229
series.py:111(func) series.py:88(__print_patch)(38) 0.001
stack.py:497(get_current)(1) 0.000
stack.py:507(get_applied)(1) 2.161
stack.py:510(get_unapplied)(1) 0.000
stack.py:513(get_hidden)(1) 0.000
series.py:2(?) common.py:2(?)(1) 0.011
optparse.py:413(__init__)(12) 0.002
series.py:88(__print_patch) --
sets.py:119(__iter__) --
sets.py:356(_update) --
sets.py:393(ImmutableSet) --
sets.py:41(?) sets.py:83(BaseSet)(1) 0.000
sets.py:393(ImmutableSet)(1) 0.000
sets.py:418(Set)(1) 0.000
sets.py:564(_TemporarilyImmutableSet)(1) 0.000
sets.py:418(Set) --
sets.py:425(__init__) sets.py:356(_update)(1) 0.000
sets.py:515(add) --
sets.py:528(remove) --
sets.py:564(_TemporarilyImmutableSet) --
sets.py:83(BaseSet) --
sets.py:99(__len__) --
shutil.py:16(Error) --
shutil.py:5(?) shutil.py:16(Error)(1) 0.000
sre.py:129(match) sre.py:216(_compile)(896) 0.025
sre.py:177(compile) sre.py:216(_compile)(4) 0.025
sre.py:216(_compile) sre_compile.py:440(isstring)(4) 0.000
sre_compile.py:461(compile)(4) 0.013
sre_compile.py:151(_compile_charset) sre_compile.py:42(<lambda>)(6) 0.000
sre_compile.py:180(_optimize_charset)(5) 0.000
sre_compile.py:180(_optimize_charset) sre_compile.py:42(<lambda>)(6) 0.000
sre_compile.py:24(_compile) sre_compile.py:24(_compile)(13) 0.002
sre_compile.py:151(_compile_charset)(5) 0.001
sre_compile.py:324(_simple)(7) 0.000
sre_parse.py:137(__getitem__)(27) 0.000
sre_compile.py:324(_simple) sre_parse.py:137(__getitem__)(7) 0.000
sre_parse.py:147(getwidth)(7) 0.001
sre_compile.py:331(_compile_info) sre_parse.py:133(__len__)(4) 0.000
sre_parse.py:137(__getitem__)(3) 0.000
sre_parse.py:147(getwidth)(4) 0.001
sre_compile.py:42(<lambda>) --
sre_compile.py:440(isstring) --
sre_compile.py:446(_code) sre_compile.py:24(_compile)(4) 0.002
sre_compile.py:331(_compile_info)(4) 0.001
sre_compile.py:461(compile) sre_compile.py:440(isstring)(4) 0.000
sre_compile.py:446(_code)(4) 0.004
sre_parse.py:614(parse)(4) 0.009
sre_parse.py:133(__len__) --
sre_parse.py:137(__getitem__) --
sre_parse.py:139(__setitem__) --
sre_parse.py:141(__getslice__) sre_parse.py:98(__init__)(7) 0.000
sre_parse.py:145(append) --
sre_parse.py:147(getwidth) sre_parse.py:147(getwidth)(13) 0.001
sre_parse.py:183(__init__) sre_parse.py:187(__next)(4) 0.001
sre_parse.py:187(__next) --
sre_parse.py:200(match) sre_parse.py:187(__next)(23) 0.001
sre_parse.py:206(get) sre_parse.py:187(__next)(98) 0.001
sre_parse.py:215(isident) --
sre_parse.py:221(isname) sre_parse.py:215(isident)(23) 0.000
sre_parse.py:240(_class_escape) --
sre_parse.py:269(_escape) --
sre_parse.py:312(_parse_sub) sre_parse.py:200(match)(16) 0.001
sre_parse.py:367(_parse)(10) 0.008
sre_parse.py:367(_parse) sre_parse.py:80(opengroup)(6) 0.000
sre_parse.py:91(closegroup)(6) 0.000
sre_parse.py:98(__init__)(10) 0.000
sre_parse.py:133(__len__)(28) 0.000
sre_parse.py:137(__getitem__)(14) 0.000
sre_parse.py:139(__setitem__)(7) 0.000
sre_parse.py:141(__getslice__)(7) 0.000
sre_parse.py:145(append)(44) 0.000
sre_parse.py:200(match)(43) 0.001
sre_parse.py:206(get)(94) 0.003
sre_parse.py:221(isname)(4) 0.001
sre_parse.py:240(_class_escape)(2) 0.000
sre_parse.py:269(_escape)(6) 0.000
sre_parse.py:312(_parse_sub)(6) 0.008
sre_parse.py:614(parse) sre_parse.py:75(__init__)(4) 0.000
sre_parse.py:183(__init__)(4) 0.000
sre_parse.py:206(get)(4) 0.003
sre_parse.py:312(_parse_sub)(4) 0.008
sre_parse.py:75(__init__) --
sre_parse.py:80(opengroup) --
sre_parse.py:91(closegroup) --
sre_parse.py:98(__init__) --
stack.py:112(StgitObject) --
stack.py:115(_set_dir) --
stack.py:117(_dir) --
stack.py:142(Patch) --
stack.py:2(?) git.py:2(?)(1) 0.003
popen2.py:7(?)(1) 0.000
stack.py:30(StackException)(1) 0.000
stack.py:33(FilterUntil)(1) 0.000
stack.py:112(StgitObject)(1) 0.000
stack.py:142(Patch)(1) 0.000
stack.py:277(PatchorderCache)(1) 0.000
stack.py:382(AppliedCache)(1) 0.000
stack.py:434(Series)(1) 0.000
templates.py:2(?)(1) 0.000
stack.py:277(PatchorderCache) --
stack.py:280(__init__) stack.py:283(__invalidate)(1) 0.000
stack.py:283(__invalidate) --
stack.py:286(__cache) posixpath.py:56(join)(3) 0.000
posixpath.py:197(isfile)(3) 0.000
stack.py:117(_dir)(3) 0.000
stack.py:293(read_file)(2) 0.000
stack.py:293(read_file) --
stack.py:30(StackException) --
stack.py:315(cmp) stack.py:286(__cache)(59) 0.001
stack.py:327(read_refs) git.py:192(_output_lines)(1) 2.067
sre.py:129(match)(896) 0.028
sre.py:177(compile)(1) 0.013
stack.py:33(FilterUntil) --
stack.py:342(unapplied_patches) git.py:192(_output_lines)(1) 2.067
sets.py:119(__iter__)(19) 0.000
sets.py:425(__init__)(46) 0.001
sets.py:515(add)(64) 0.001
stack.py:358(sort_applied_patches) popen2.py:31(__init__)(1) 0.064
sets.py:99(__len__)(26) 0.000
sets.py:119(__iter__)(25) 0.000
sets.py:425(__init__)(26) 0.001
sets.py:515(add)(25) 0.001
sets.py:528(remove)(25) 0.000
stack.py:382(AppliedCache) --
stack.py:385(__init__) stack.py:280(__init__)(1) 0.000
stack.py:417(__invalidate)(1) 0.000
stack.py:389(get_applied) stack.py:422(__cache)(2) 2.161
stack.py:392(get_unapplied) stack.py:422(__cache)(1) 2.161
stack.py:417(__invalidate) --
stack.py:420(__cached) --
stack.py:422(__cache) sets.py:119(__iter__)(2) 0.000
stack.py:315(cmp)(59) 0.007
stack.py:327(read_refs)(1) 0.110
stack.py:342(unapplied_patches)(1) 2.006
stack.py:358(sort_applied_patches)(1) 0.037
stack.py:420(__cached)(3) 0.000
stack.py:479(get_branch)(1) 0.000
stack.py:434(Series) --
stack.py:437(__init__) basedir.py:33(get)(1) 0.007
git.py:288(get_head_file)(1) 0.023
posixpath.py:56(join)(5) 0.000
posixpath.py:184(isdir)(3) 0.000
stack.py:115(_set_dir)(1) 0.000
stack.py:117(_dir)(3) 0.000
stack.py:385(__init__)(1) 0.000
stack.py:646(is_initialised)(2) 0.000
stack.py:479(get_branch) --
stack.py:497(get_current) stack.py:507(get_applied)(1) 2.161
stack.py:507(get_applied) stack.py:389(get_applied)(2) 2.161
stack.py:510(get_unapplied) stack.py:392(get_unapplied)(1) 0.000
stack.py:513(get_hidden) posixpath.py:197(isfile)(1) 0.000
stack.py:646(is_initialised) posixpath.py:184(isdir)(2) 0.000
stat.py:29(S_IFMT) --
stat.py:45(S_ISDIR) stat.py:29(S_IFMT)(5) 0.000
stat.py:54(S_ISREG) stat.py:29(S_IFMT)(3) 0.000
templates.py:2(?) --
utils.py:107(strip_prefix) --
utils.py:153(EditorException) --
utils.py:2(?) config.py:2(?)(1) 0.000
utils.py:153(EditorException)(1) 0.000
^ permalink raw reply
* Re: newby question about merge.
From: Christian MICHON @ 2007-05-16 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705161241560.6410@racer.site>
On 5/16/07, Johannes Schindelin wrote:
> > You can just do "git cat-file -p :2:filename > filename", then "git add
> > filename" (or "git update-index filename") to resolve conflict.
>
> Do we really want to advertise this obscure-looking plumbing? Wouldn't it
> be better to teach people to use "git show" instead?
>
> I mean, people can get intimidated by that...
>
> Ciao,
> Dscho
>
I could be wrong, but git-show works in this way only after version 1.5, right ?
As far as I can tell, using git-1.4.4.4 or ealier, you would still need
git-cat-file -p... to fix this merge conflict.
--
Christian
^ permalink raw reply
* Re: newby question about merge.
From: Johannes Schindelin @ 2007-05-16 14:45 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660705160721u24e43f7bmb5171555158089fb@mail.gmail.com>
Hi,
[please, Christian, do not cut the Cc: list. In particular, do _not_ cut
the person you are _responding_ to from the Cc: list]
On Wed, 16 May 2007, Christian MICHON wrote:
> On 5/16/07, Johannes Schindelin wrote:
> > > You can just do "git cat-file -p :2:filename > filename", then "git
> > > add filename" (or "git update-index filename") to resolve conflict.
> >
> > Do we really want to advertise this obscure-looking plumbing? Wouldn't
> > it be better to teach people to use "git show" instead?
> >
> > I mean, people can get intimidated by that...
>
> I could be wrong, but git-show works in this way only after version 1.5,
> right ?
Yes. So what?
> As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> git-cat-file -p... to fix this merge conflict.
If you are using pre-1.5 Git, you should really, really upgrade.
If you do not want to do that, then _at least_ you should not confuse
newbies, who _should_ use Git 1.5+.
And most importantly: if you suggest a change in the man pages, it should
reflect the new Git versions, _not_ the old ones.
Okay?
Ciao,
Dscho
^ permalink raw reply
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