Hi,
On Fri, 19 Oct 2012, Erik Faye-Lund wrote:
> On Fri, Oct 19, 2012 at 12:13 AM, Chris B
> wrote:
> > Hi.. it is such a crime to have that default option of MSysGit mess
> > around with the line endings.
>
> No it's not.
Let's keep things professional. Eliciting emotions, especially negativ
Cristian Tibirna writes:
> This error:
>
> fatal: cannot convert from utf8 to UTF-8
> ...
> This is in part our fault: during the standardisation of our git environment,
> we (re)enforced UTF-8 encodings by setting "i18n.commitenconding" and
> "i18n.logOutputEncoding" to "utf8".
> ...
> I know
On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz wrote:
> I'm testing out the sparse checkout feature of Git on my large (14GB)
> repository and am running into a problem. When I add "dir1/" to
> sparse-checkout and then run "git read-tree -mu HEAD" I see dir1 as
> expected. But when I add "dir2/"
This error:
fatal: cannot convert from utf8 to UTF-8
occured in two distinct situations in our work group with git binaries older
or equal to 1.7.7. Once during a commit, the other time during a rebase. Both
occurences are 100% reproductible. But the commit that gives the error during
a rebas
Junio C Hamano writes:
> We end up calling select() without any bit set in fds, so it would
> become micro-sleep of select_timeout in such a case, but as far as I
> can see, the existing code either
>
> * does not select() and keeps polling step_active_slots() without
>delay, when curl_timeo
sza...@google.com writes:
> From aa77ab3dd5b98a5786ac158528f45355fc0ddbc3 Mon Sep 17 00:00:00 2001
> From: Stefan Zager
> Date: Thu, 18 Oct 2012 16:23:53 -0700
> Subject: [PATCH] Fix potential hang in https handshake.
Please don't do the above (as usual ;-)
> It will sometimes happen that curl_
I think I finally agree that it's best to develop submodules further
rather than introduce a new tool for the functionality I require. Here
are some explicit proposals for submodules so we can at least establish
agreement on what should be done. These are in order of decreasing
importance (to me)
>From aa77ab3dd5b98a5786ac158528f45355fc0ddbc3 Mon Sep 17 00:00:00 2001
From: Stefan Zager
Date: Thu, 18 Oct 2012 16:23:53 -0700
Subject: [PATCH] Fix potential hang in https handshake.
It will sometimes happen that curl_multi_fdset() doesn't
return any file descriptors. In that case, it's recomm
I'm testing out the sparse checkout feature of Git on my large (14GB)
repository and am running into a problem. When I add "dir1/" to
sparse-checkout and then run "git read-tree -mu HEAD" I see dir1 as
expected. But when I add "dir2/" to sparse-checkout and read-tree
again I see dir2 and dir3 appea
I noticed today that if you leave off the branch name from git subtree like so:
$ git subtree add --prefix somewhere -m "adding CDH as subtree" path/to/repo
warning: read-tree: emptying the index with no arguments is deprecated; use
--empty
fatal: just how do you expect me to merge 0 trees?
The
sza...@google.com writes:
> From 700b8075c578941c8f951711825c390ac68b190f Mon Sep 17 00:00:00 2001
> From: Stefan Zager
> Date: Thu, 18 Oct 2012 14:03:59 -0700
> Subject: [PATCH] Fix potential hang in https handshake.
>
> It will sometimes happen that curl_multi_fdset() doesn't
> return any file
From: Jari Aalto
Signed-off-by: Jari Aalto
---
Documentation/fetch-options.txt |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index b4d6476..90d50fb 100644
--- a/Documentation/fetch-options.txt
+++ b/Do
On Fri, Oct 19, 2012 at 12:13 AM, Chris B wrote:
> Hi.. it is such a crime to have that default option of MSysGit mess
> around with the line endings.
No it's not.
> There is no thought to the fact that it's possible the Git users are
> not using Git the exact way the authors thought it would be
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> When inserting the note after the commit log message to format-patch
>> output, add three dashes before the note. Record the fact that we
>> did so in the rev_info and omit showing duplicated three dashes in
>> the usual codepath that is used
>From 700b8075c578941c8f951711825c390ac68b190f Mon Sep 17 00:00:00 2001
From: Stefan Zager
Date: Thu, 18 Oct 2012 14:03:59 -0700
Subject: [PATCH] Fix potential hang in https handshake.
It will sometimes happen that curl_multi_fdset() doesn't
return any file descriptors. In that case, it's recomm
From: "Junio C Hamano"
When inserting the note after the commit log message to format-patch
output, add three dashes before the note. Record the fact that we
did so in the rev_info and omit showing duplicated three dashes in
the usual codepath that is used when notes are not being shown.
Signe
René Scharfe writes:
> Before a branch is deleted, we check that it points to a valid
> commit. With -d we also check that the commit is a merged; this
> check is not done with -D.
>
> The reason for that is that commits pointed to by branches should
> never go missing; if they do then something
On Thu, Oct 18, 2012 at 02:16:11PM -0700, Junio C Hamano wrote:
> I guess combining both is fine, but then the commit is no longer "in
> preparation for adding" the option, but it already adds "--long", I
> would think.
Maybe a better commit message is:
-- >8 --
Subject: status: add --long outpu
Nguyễn Thái Ngọc Duy writes:
> From: Jeff King
>
> When deciding which output format to use, we default an internal enum
> to STATUS_FORMAT_LONG and modify it if "--porcelain" or "--short" is
> given. If this enum is set to LONG, then we know the user has not
> specified any format, and we can
Thomas Ackermann writes:
> Yes; in e2399e9 the following hunks where left out from the patch to
> update-hook-example.txt:
>
> @@ -111,12 +114,12 @@ then
>
>info "Found matching head pattern: '$head_pattern'"
>for user_pattern in $user_patterns; do
> - info "Checking user:
On Thu, Oct 18, 2012 at 09:15:50PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 18, 2012 at 9:03 AM, Jeff King wrote:
> > I think that is fine to split it like this, but you would want to update
> > the commit message above. Probably just remove those two cases and say
> > something like:
>
> That means that for the patch [6/8], which adds content-type to the
> text files, to be complete, it needs to update Makefile to produce
> html files from them.
>
IMHO also for the new files in ./technical html should be created because
now as we have asciidoc markup why not also use it.
>
Nguyen Thai Ngoc Duy writes:
> On Thu, Oct 18, 2012 at 12:45 PM, Junio C Hamano wrote:
>> This replaces the earlier "wip" with a real thing.
>>
>> We never advertised the "--notes" option to format-patch (or
>> anything related to the pretty format options for that matter)
>> because the behavio
From: Jan H. Schönherr
git-format-patch does currently not parse user supplied extra header
values (e. g., --cc, --add-header) and just replays them. That forces
users to add them RFC 2822/2047 conform in encoded form, e. g.
--cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>'
which is inconven
From: Jan H. Schönherr
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822
quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822
specials behind, the quoting is also no longer necessary to create a
standard-conform mail.
Remove the quoting, when RFC 2047 enc
From: Jan H. Schönherr
RFC 2047 requires more characters to be encoded than it is currently done.
Especially, RFC 2047 distinguishes between allowed remaining characters
in encoded words in addresses (From, To, etc.) and other headers, such
as Subject.
Make add_rfc2047() and is_rfc2047_special()
From: Jan H. Schönherr
Currently, an open-coded loop to calculate the length of the last
line of a string buffer is used in multiple places.
Move that code into a function of its own.
Signed-off-by: Jan H. Schönherr
---
pretty.c | 25 +
1 Datei geändert, 13 Zeilen hinz
From: Jan H. Schönherr
Encoded characters add more than one character at once to an encoded
header. Include all characters that are about to be added in the length
calculation for wrapping.
Additionally, RFC 2047 imposes a maximum line length of 76 characters
if that line contains an rfc2047 enc
From: Jan H. Schönherr
Do not wrap the second and later lines of non-rfc2047-encoded headers
substantially before the 78 character limit.
Instead of passing the remaining length of the first line as wrapping
width, use the correct maximum length and tell strbuf_add_wrapped_bytes()
how many chara
From: Jan H. Schönherr
The wrapping logic in strbuf_add_wrapped_text() does currently not allow
lines that entirely fill the allowed width, instead it wraps the line one
character too early.
For example, the text "This is the sixth commit." formatted via
"%w(11,1,2)" (wrap at 11 characters, 1 ch
Hi all.
[This is the second version of this series. If you still remember
the first version, you might want to jump directly to the summary
of changes below.]
The main point of this series is to teach git to encode my name
correctly, see patches 5+6, so that the decoded version is actually
my nam
On Thu, Oct 18, 2012 at 3:18 PM, Michael J Gruber
wrote:
> Felipe Contreras venit, vidit, dixit 17.10.2012 14:58:
>> Signed-off-by: Felipe Contreras
>> ---
>>
>> I've looked at many hg<->git tools and none satisfy me. Too complicated, or
>> too
>> slow, or to difficult to setup, etc.
>
> It's in
From: Jeff King
When deciding which output format to use, we default an internal enum
to STATUS_FORMAT_LONG and modify it if "--porcelain" or "--short" is
given. If this enum is set to LONG, then we know the user has not
specified any format, and we can kick in default behaviors. This works
becau
Felipe Contreras venit, vidit, dixit 17.10.2012 14:58:
> Signed-off-by: Felipe Contreras
> ---
>
> I've looked at many hg<->git tools and none satisfy me. Too complicated, or
> too
> slow, or to difficult to setup, etc.
It's in an unsatisfying state, I agree. We have a great remote helper
infra
Nguyen Thai Ngoc Duy venit, vidit, dixit 18.10.2012 13:06:
> On Thu, Oct 18, 2012 at 12:45 PM, Junio C Hamano wrote:
>> This replaces the earlier "wip" with a real thing.
>>
>> We never advertised the "--notes" option to format-patch (or
>> anything related to the pretty format options for that ma
Jeff King venit, vidit, dixit 17.10.2012 21:05:
> On Wed, Oct 17, 2012 at 07:30:56AM -0600, Eric Blake wrote:
>
>>> We've talked about it several times, but it's never happened (probably
>>> because most people don't actually use notes).
>>
>> And people (like me) don't use notes because they aren
git branch reports the abbreviated hash of the head commit of
a deleted branch to make it easier for a user to undo the
operation. For symref branches this doesn't help. Print the
symref target instead for them.
Signed-off-by: Rene Scharfe
---
builtin/branch.c | 19 +++
t/t320
Before a branch is deleted, we check that it points to a valid
commit. With -d we also check that the commit is a merged; this
check is not done with -D.
The reason for that is that commits pointed to by branches should
never go missing; if they do then something broke and it's better
to stop ins
If a branch that is to be deleted happens to be a symref to another
branch, the current code removes the targeted branch instead of the
one it was called for.
Change this surprising behaviour and delete the symref branch
instead.
Signed-off-by: Rene Scharfe
---
builtin/branch.c | 2 +-
t/t320
Provide a small helper function for deleting branch config sections.
Signed-off-by: Rene Scharfe
---
builtin/branch.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 852019e..97c7361 100644
--- a/builtin/branch.c
+++
Move the code to perform checks on the tip commit of a branch
to its own function.
Signed-off-by: Rene Scharfe
---
builtin/branch.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ffd2684..852019e 1
Am 16.10.2012 18:09, schrieb Junio C Hamano:
> Having said all that, I think your patch is going in the right
> direction. If somebody had a symbolic ref in refs/heads/, the
> removal should remove it, not the pointee, which may not even
> exist. Does "branch -d sym" work correctly with your patc
On Thu, Oct 18, 2012 at 12:45 PM, Junio C Hamano wrote:
> This replaces the earlier "wip" with a real thing.
>
> We never advertised the "--notes" option to format-patch (or
> anything related to the pretty format options for that matter)
> because the behaviour of these options was whatever they
This saves us some code, but it also reduces the number of
processes we start for each filtered commit. Since we can
parse both author and committer in the same sed invocation,
we save one process. And since the new interface avoids tr,
we save 4 processes.
It also avoids using "tr", which has had
On Thu, Oct 18, 2012 at 06:22:17AM -0400, Jeff King wrote:
> Hrm. We _do_ test this in t7003. Weirder, if I instrument filter-branch
> like this:
> [...]
> and run t7003, it shows that the variable is properly exported to the
> sub-process! But I can't seem to figure out why. Confused...
Oh, I se
On Thu, Oct 18, 2012 at 03:54:29AM -0400, Jeff King wrote:
> On Thu, Oct 18, 2012 at 09:49:04AM +0200, Johannes Sixt wrote:
>
> > > - s/.*/GIT_'$uid'_NAME='\''&'\''; export GIT_'$uid'_NAME/p
> >
> > Didn't you lose the export GIT_$uid_{NAME,EMAIL,DATE} parts somewhere on
> > the
On Wed, Oct 17, 2012 at 10:45:22PM -0700, Junio C Hamano wrote:
> We never advertised the "--notes" option to format-patch (or
> anything related to the pretty format options for that matter)
> because the behaviour of these options was whatever they happened to
> do, not what they were designed t
On Thu, Oct 18, 2012 at 03:49:21AM -0400, Jeff King wrote:
> This last line seems like it is caused by a bug in the strbuf API.
> Detaching an empty string will sometimes get you NULL and sometimes not.
> For example, this:
>
> struct strbuf foo = STRBUF_INIT;
> strbuf_detach(&foo, NULL);
>
Felipe Contreras writes:
> Basically what I already described:
> 1) You need a non-vanilla version of git
> 2) It's not easy to set up
> 3) It's not even clear which branch you should be using (in case you
> are not using msysgit)
I do not read that as "it does not work", but instead as "no one
On Thu, Oct 18, 2012 at 11:26 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> As to the functionality you seek: git-remote-hg found in
>>> git://github.com/msysgit/git works. It has the following advantages over
>>> every other solution, including the one proposed in this thread:
>>>
>
Felipe Contreras writes:
>> As to the functionality you seek: git-remote-hg found in
>> git://github.com/msysgit/git works. It has the following advantages over
>> every other solution, including the one proposed in this thread:
>>
>> - it works
>>
>> - no really, it works
>
> Not for me.
Felipe
On Thu, Oct 18, 2012 at 11:13 AM, Johannes Schindelin
wrote:
> Hi,
>
> On Thu, 18 Oct 2012, Felipe Contreras wrote:
>
>> On Thu, Oct 18, 2012 at 8:12 AM, Sverre Rabbelier
>> wrote:
>> > On Wed, Oct 17, 2012 at 10:18 PM, Felipe Contreras
>> > wrote:
>> >> Right now I've just added an error when
Hi,
On Thu, 18 Oct 2012, Felipe Contreras wrote:
> On Thu, Oct 18, 2012 at 8:12 AM, Sverre Rabbelier
> wrote:
> > On Wed, Oct 17, 2012 at 10:18 PM, Felipe Contreras
> > wrote:
> >> Right now I've just added an error when using remote repositories.
> >> But it seems there's no way around it; if
On Thu, Oct 18, 2012 at 02:17:01AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's possible that switching it would create bugs elsewhere (there are
> > over 100 uses of strbuf_detach, so maybe somebody really does want this
> > NULL behavior), but I tend to think it is just as likel
Hi Felipe,
On Thu, 18 Oct 2012, Felipe Contreras wrote:
> On Thu, Oct 18, 2012 at 10:47 AM, Johannes Schindelin
> wrote:
>
> So your idea of collaboration is accept that your code is awesome, and
> my code sucks, and that I should fix your code, and throw my code to the
> trash, while you do abs
Jeff King writes:
> It's possible that switching it would create bugs elsewhere (there are
> over 100 uses of strbuf_detach, so maybe somebody really does want this
> NULL behavior), but I tend to think it is just as likely to be fixing
> undiscovered bugs.
Yeah, I tend to agree.
This "format-p
On Thu, Oct 18, 2012 at 8:12 AM, Sverre Rabbelier wrote:
> On Wed, Oct 17, 2012 at 10:18 PM, Felipe Contreras
> wrote:
>> Right now I've just added an error when using remote repositories. But
>> it seems there's no way around it; if we want to have support for
>> remote repos, we need to make a
On Thu, Oct 18, 2012 at 10:47 AM, Johannes Schindelin
wrote:
> Hi Felipe,
>
> On Wed, 17 Oct 2012, Felipe Contreras wrote:
>
>> On Wed, Oct 17, 2012 at 8:18 PM, Sverre Rabbelier
>> wrote:
>> > On Wed, Oct 17, 2012 at 11:12 AM, Felipe Contreras
>> > wrote:
>> >> But fine, lets remove the tests o
On Thu, Oct 18, 2012 at 5:44 AM, Felipe Contreras
wrote:
> On Thu, Oct 18, 2012 at 12:59 AM, Jeff King wrote:
>> The first thing I tried was:
>>
>> $ git clone hg::https://code.google.com/p/dactyl/
>
> Right, doesn't look like it works for remote repositories. I think
> that's the next feature
Hi Felipe,
On Wed, 17 Oct 2012, Felipe Contreras wrote:
> On Wed, Oct 17, 2012 at 8:18 PM, Sverre Rabbelier
> wrote:
> > On Wed, Oct 17, 2012 at 11:12 AM, Felipe Contreras
> > wrote:
> >> But fine, lets remove the tests out of the equation (150 lines), the
> >> number of lines of code still ex
On Thu, Oct 18, 2012 at 09:49:04AM +0200, Johannes Sixt wrote:
> > - s/.*/GIT_'$uid'_NAME='\''&'\''; export GIT_'$uid'_NAME/p
>
> Didn't you lose the export GIT_$uid_{NAME,EMAIL,DATE} parts somewhere on
> the way?
Yikes, you're right. I didn't even notice, as the test suite sti
On Wed, Oct 17, 2012 at 10:45:25PM -0700, Junio C Hamano wrote:
> + if (opt->show_notes) {
> + int raw;
> + struct strbuf notebuf = STRBUF_INIT;
> +
> + raw = (opt->commit_format == CMIT_FMT_USERFORMAT);
> + format_display_notes(commit->object.sh
Am 10/18/2012 9:25, schrieb Jeff King:
> -# When piped a commit, output a script to set the ident of either
> -# "author" or "committer
> +# Ensure non-empty id name.
> +fallback_name() {
> + echo "case \"\$GIT_$1_NAME\" in \"\")
> GIT_$1_NAME=\"\${GIT_$1_EMAIL%%@*}\" && export GIT_$1_NAME;; e
On Thu, Oct 18, 2012 at 7:13 AM, Sverre Rabbelier wrote:
> On Wed, Oct 17, 2012 at 1:27 AM, Felipe Contreras
> wrote:
>> The marks options are being ignored right now.
>
> It seems unlikely to me that this never worked, surely no reviewer
> would accept a patch that doesn't actually implement the
This saves us some code, but it also reduces the number of
processes we start for each filtered commit. Since we can
parse both author and committer in the same sed invocation,
we save one process. And since the new interface avoids tr,
we save 4 processes.
It also avoids using "tr", which has had
The only ident-parsing function we currently provide is
get_author_ident_from_commit. This is not very
flexible for two reasons:
1. It takes a commit as an argument, and can't read from
commit headers saved on disk.
2. It will only parse authors, not committers.
This patch provides a mo
On Thu, Oct 18, 2012 at 02:08:47AM -0400, Jeff King wrote:
> Working on it now. git-sh-setup works, but chasing an annoying bug in
> filter-branch. I'm sure it's something silly and stupid.
Ugh. I was being caught by crazy dash-versus-bash stuff.
Try this:
$ bash -c 'echo ""'
\\
$ das
67 matches
Mail list logo
