But just because mv's error essage isnt very good, does that mean git
mv's error message mustn't be better? That would strike me as an odd
bit of reasoning.
On Fr 16 Nov 2012 02:34:32 CET, Junio C Hamano wrote:
Patrick Lehner writes:
To reproduce:
- cd into a git repo
- assuming "filea.txt"
Thanks for the quick reply!
On Fri, Nov 16, 2012 at 3:25 PM, Nguyen Thai Ngoc Duy wrote:
> On Fri, Nov 16, 2012 at 12:44 PM, Thomas Gay wrote:
>> Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
>
> How large exactly?
2.46 GB
> If you set receive.unpacklimit to 1 on the re
On Fri, Nov 16, 2012 at 12:44 PM, Thomas Gay wrote:
> Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
How large exactly?
> my repo, and each time I try to push it, Git crashes. I've attached
> the crash log to this email and pasted the console output below.
>
> Counting obj
Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
my repo, and each time I try to push it, Git crashes. I've attached
the crash log to this email and pasted the console output below.
Counting objects: 27, done.
Delta compression using up to 4 threads.
Compressing objects: 100%
Jeff King writes:
> That is a good question. That confirmation step does come after they
> have typed their cover letter. However, if they are using --compose,
> they are dumped in their editor with something like:
>
> From Jeff King # This line is ignored.
> GIT: Lines beginning in "GIT:" w
On Fri, Nov 16, 2012 at 12:13 AM, "Jan H. Schönherr"
wrote:
>> #define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
>> GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
>> - GIT_PATHSPEC_MAGIC))
>> + GIT_PATHSPEC_MAGIC) && \
>> +
On Fri, Nov 16, 2012 at 3:42 AM, Brandon Casey wrote:
>> Interestingly this patch triggers the fault that it fixes.
>> I was surprised that there was no blank line before my S-o-b
>> and thought I broke something. It turns out I used unmodified
>> format-patch and it mistook the S-o-b quote as
On Thu, Nov 15, 2012 at 5:58 PM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> The cherry-pick -s functionality is currently broken in two ways.
>>
>>1. handling of rfc2822 continuation lines has a bug, and the
>> continuation lines are not handled correctly.
>
> This is not limite
Brandon Casey writes:
> Detect whether the s-o-b already exists in the commit footer and refrain
> from adding a duplicate.
If you are trying to forbid
git cherry-pick -s $other
from adding s-o-b: A when $other ends with these two existing s-o-b:
s-o-b: A
s-o-b: B
the
Brandon Casey writes:
> The cherry-pick -s functionality is currently broken in two ways.
>
>1. handling of rfc2822 continuation lines has a bug, and the
> continuation lines are not handled correctly.
This is not limited to you, but people should think twice when
writing "has a bug" a
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam wrote:
> The current tcsh-completion support for Git, as can be found on the
> Internet, takes the approach of defining the possible completions
> explicitly. This has the obvious draw-back to require constant
> updating as the Git code base evolves.
Patrick Lehner writes:
> To reproduce:
> - cd into a git repo
> - assuming "filea.txt" is an existing file in the CWD, and "dirb" is
> neither a file nor a directory in the CWD, use the command "git mv
> filea.txt dirb/filea.txt"
> - this will produce an error message like `fatal: renaming 'filea
On 11/15/2012 02:35 PM, Torsten Bögershausen wrote:
On 11/15/2012 08:05 PM, Ramsay Jones wrote:
Did the cygwin project not bump an api version number somewhere?
ATB,
Ramsay Jones
Ramsay,
you can run uname -r to see the version number.
I myself haven't fully understood all the consequences,
s
Detect whether the s-o-b already exists in the commit footer and refrain
from adding a duplicate.
Update t3511 to test new behavior.
Signed-off-by: Brandon Casey
---
Hi Duy,
How about this patch on top of my series as a base for your patch to
unify the code paths that append signoff in format
Max Horn :
> > I'm still looking for a better name for it and would welcome suggestions.
>
> Isn't "gitar" the kind of natural choice? ;) At least for a stand-alone tool,
> not for a git subcommand.
I just renamed it git-weave. I keep talking about tarballs because I keep
thinking about using i
On 15.11.2012, at 22:28, Eric S. Raymond wrote:
> Some days ago I reported that I was attempting to write a tool that could
> (a) take a git repo and unpack it into a tarball sequence plus a metadata log,
> (b) reverse that operation, packing a tarball and log sequence into a repo.
Ah, I could h
Felipe Contreras writes:
> On Wed, Nov 14, 2012 at 11:42 PM, Junio C Hamano wrote:
>
>> * fc/completion-test-simplification (2012-10-29) 2 commits
>> - completion: simplify __gitcomp test helper
>> - completion: refactor __gitcomp related tests
>>
>> Clean up completion tests.
>>
>> There we
Matthieu Moy writes:
> I don't understand what you mean by "non-current". If you mean a local
> branch not pointed to by HEAD, then I don't understand the remark, as
> the message is shown by "git status" (looking more closely, it is also
> shown by "git checkout", but after switching branch so a
On Thu, Nov 15, 2012 at 4:32 AM, Nguyễn Thái Ngọc Duy wrote:
> There are two implementations of append_signoff in log-tree.c and
> sequencer.c, which do more or less the same thing. This patch
>
> - teaches sequencer.c's append_signoff() not to append the signoff if
>it's already there but no
Some days ago I reported that I was attempting to write a tool that could
(a) take a git repo and unpack it into a tarball sequence plus a metadata log,
(b) reverse that operation, packing a tarball and log sequence into a repo.
Thanks in part to advice by Andreas Schwab and in part to looking at
Junio C Hamano writes:
>> -if (!num_theirs)
>> +if (!num_theirs) {
>> strbuf_addf(sb,
>> Q_("Your branch is ahead of '%s' by %d commit.\n",
>> "Your branch is ahead of '%s' by %d commits.\n",
>> num_ours),
>
On 11/15/2012 08:05 PM, Ramsay Jones wrote:
Torsten Bögershausen wrote:
* ml/cygwin-mingw-headers (2012-11-12) 1 commit
- Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
Will merge to 'next'.
(Sorry for late answer, I managed to test the original patch
Johannes Sixt wrote:
> Am 11/14/2012 10:12, schrieb Martin Lichtin:
>> Maven's release plugin prepares a call Git like in this example:
>>
>> cmd.exe /X /C "git commit --verbose -F
>> C:\cygwin\tmp\maven-scm-915771020.commit pom.xml"
>>
>> Git doesn't seem to understand the -F argument and treats i
Torsten Bögershausen wrote:
> On 13.11.12 19:55, Ramsay Jones wrote:
>> Douglas Mencken wrote:
>>> *Any* git clone fails with:
>>>
>>> fatal: premature end of pack file, 106 bytes missing
>>> fatal: index-pack failed
>>>
>>> At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
>>>
Torsten Bögershausen wrote:
>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
>> - Update cygwin.c for new mingw-64 win32 api headers
>>
>> Make git work on newer cygwin.
>>
>> Will merge to 'next'.
>
> (Sorry for late answer, I managed to test the original patch minutes before
> Peff merged
Douglas Mencken wrote:
>> Could you try re-building git with the
>> NO_THREAD_SAFE_PREAD build variable set?
>
> Yeah! It works!!!
>
> --- evil/Makefile
> +++ good/Makefile
> @@ -957,6 +957,7 @@
> HAVE_PATHS_H = YesPlease
> LIBC_CONTAINS_LIBINTL = YesPlease
> HAVE_DEV_TTY = Yes
Hey guys,
as was brought up on #github today, the "git mv" command has a bit of a
little-helping output message when the target directory (or any
intermediate directories) dont exist.
To reproduce:
- cd into a git repo
- assuming "filea.txt" is an existing file in the CWD, and "dirb" is
neit
On Thu, Nov 15, 2012 at 10:10:01AM -0800, Carlos Martín Nieto wrote:
> When given a variable without a value, such as '[section] var' and
> asking git-config to treat it as a path, git_config_pathname returns
> an error and doesn't modify its output parameter. show_config assumes
> that the call i
When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed.
Currently, if the s-o-b footer of a commit message contains a
"(cherry picked from ..." line that was added by a previous cherry-pick -x,
it is not recognized as a s-o-b footer and will cause a newline to be
inserted before an additional s-o-b is added.
So, rework ends_rfc2822_footer to recognize
Matthieu Moy writes:
> Signed-off-by: Matthieu Moy
> ---
> I thought this was obvious enough not to deserve an advice, but a
> colleague of mine had troubles with "commited but not pushed" changes.
> Maybe an additional advice would have helped. After all, it's an
> advice, and can be deactivate
On Thu, Nov 15, 2012 at 08:56:37AM -0800, Junio C Hamano wrote:
> > I think a much more compelling argument/commit message for your
> > suggested patch would be:
> >
> > We currently prompt the user for the "From" address. This is an
> > inconvenience in the common case that the user has confi
Am 15.11.2012 13:19, schrieb Nguyễn Thái Ngọc Duy:
> On Thu, Nov 15, 2012 at 2:30 AM, René Scharfe
> wrote:
> > Nevertheless, it's unfortunate that we have an isspace() that *almost* does
> > what the widely known thing of the same name does. I'd shy away from
> > changing git's version dire
On Wed, Nov 14, 2012 at 01:27:33PM -0800, Junio C Hamano wrote:
> > Instead of
> > fatal: Not a valid object name: 'master'.
> > perhaps
> > fatal: Cannot create branch 'foo' from empty branch 'master'. To
> > rename 'master' use 'git branch -m master foo'.
>
> The first new sentence is a
Jeff King writes:
> I think a much more compelling argument/commit message for your
> suggested patch would be:
>
> We currently prompt the user for the "From" address. This is an
> inconvenience in the common case that the user has configured their
> identity in the environment, but is mea
Angelo Borsotti writes:
>> I am *not* convinced that the "refs/tags/ is the only special
>> hierarchy whose contents should not move" is a bad limitation we
>> should avoid, but if it indeed is a bad limitation, the above is one
>> possible way to think about avoiding it.
>
> What other hierarchy
Jeff King wrote:
> Yes. You can test it yourself with "bash t-basic.sh". The reason is
> that the "!" is part of history expansion, which is only enabled by
> default for interactive shells.
Nice to hear. Thanks much for looking into it.
> On Wed, Nov 14, 2012 at 11:46:58PM -0800, Jonathan
On Wed, Nov 14, 2012 at 11:46:58PM -0800, Jonathan Nieder wrote:
> > +test_expect_success !LAZY_TRUE 'missing lazy prereqs skip tests' '
>
> I have a visceral nervousness when reading this code, from too much
> unpleasant experience of bash's csh-style !history expansion. Luckily
> bash does not
On Thu, Nov 15, 2012 at 08:25:26AM -0800, Jeff King wrote:
> > Thanks, this version looks good to me.
>
> Oh wait. I did not look closely enough. The point was to move the option
> parser _out_ of git_diff_ui_config into git_diff_basic_config, so that
> it only triggers for porcelain, not plumbin
On Thu, Nov 15, 2012 at 08:23:34AM -0800, Jeff King wrote:
> On Tue, Nov 13, 2012 at 09:12:43PM +0530, Ramkumar Ramachandra wrote:
>
> > v1 is here:
> > http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
> > v2 is here:
> > http://mid.gmane.org/1351766630-4837-1-git-send-e
On Tue, Nov 13, 2012 at 09:12:43PM +0530, Ramkumar Ramachandra wrote:
> v1 is here:
> http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
> v2 is here:
> http://mid.gmane.org/1351766630-4837-1-git-send-email-artag...@gmail.com
> v3 is here:
> http://mid.gmane.org/1352653146
On Thu, Nov 15, 2012 at 08:11:50AM -0800, Jeff King wrote:
> Hmm, actually, we should probably propagate the error (I was thinking
> for some reason this was in the listing code, but it is really about
> getting a specific variable, and that variable does not have a sane
> format. We'll already ha
On Thu, Nov 15, 2012 at 08:08:49AM -0800, Jeff King wrote:
> That is definitely the right thing to do. But do we also need to take
> note of the error for later? After this code:
>
> > } else if (types == TYPE_PATH) {
> > - git_config_pathname(&vptr, key_, value_);
> > - m
On Tue, Nov 13, 2012 at 08:50:04PM -0800, Carlos Martín Nieto wrote:
> When given a variable without a value, such as '[section] var' and
> asking git-config to treat it as a path, git_config_pathname returns
> an error and doesn't modify its output parameter. show_config assumes
> that the call i
On Wed, Nov 14, 2012 at 2:55 AM, Douglas Mencken wrote:
>> Could you try re-building git with the
>> NO_THREAD_SAFE_PREAD build variable set?
>
> Yeah! It works!!!
>
> --- evil/Makefile
> +++ good/Makefile
> @@ -957,6 +957,7 @@
> HAVE_PATHS_H = YesPlease
> LIBC_CONTAINS_LIBINTL =
On Thu, Nov 15, 2012 at 2:03 PM, Sitaram Chamarty wrote:
> Hi,
>
> It seems to me that whatever namespaces can do, can functionally be
> done using just a subdirectory of branches. The only real
> differences I can see are (a) a client sees less branch clutter, and
> (b) a fetch/clone pulls down
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. This patch
- teaches sequencer.c's append_signoff() not to append the signoff if
it's already there but not at the bottom
- removes log-tree.c's
- make sure "Signed-off-by:
Current isprint() incorrectly includes control characters 9, 10 and
13, which is fixed by this patch.
Current isspace() lacks 11 and 12. But Git's isspace() has been
designed this way since the beginning and has over 100 call sites
relying on this. Instead of updating isspace() behavior (which cou
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advance
On Thu, Nov 15, 2012 at 03:13:47AM -0800, Jeff King wrote:
> I think a much more compelling argument/commit message for your
> suggested patch would be:
>
> We currently prompt the user for the "From" address. This is an
> inconvenience in the common case that the user has configured their
>
On Thu, Nov 15, 2012 at 02:43:58AM -0800, Jeff King wrote:
> > And doesn't have any of the following:
> >
> > * configured user.name/user.email
> > * specified $EMAIL
> > * configured sendemail.from
> > * specified --from argument
> >
> > Very unlikely.
>
> That is certainly the opinion you
Signed-off-by: Matthieu Moy
---
I thought this was obvious enough not to deserve an advice, but a
colleague of mine had troubles with "commited but not pushed" changes.
Maybe an additional advice would have helped. After all, it's an
advice, and can be deactivated ...
remote.c
On Thu, Nov 15, 2012 at 11:28:46AM +0100, Felipe Contreras wrote:
> I tried both:
>
> ok 19 # skip implicit ident prompts for sender (missing AUTOIDENT of
> PERL,AUTOIDENT)
> ok 20 - broken implicit ident aborts send-email
>
> ok 19 - implicit ident prompts for sender
> ok 20 # skip broken impli
On Thu, Nov 15, 2012 at 9:33 AM, Jeff King wrote:
> On Thu, Nov 15, 2012 at 03:08:42AM +0100, Felipe Contreras wrote:
>
>> I don't think there's any need for all that, this does the trick:
>>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index aea66a0..503e551 100755
>> --- a/git-se
On Thu, Nov 15, 2012 at 03:08:42AM +0100, Felipe Contreras wrote:
> I don't think there's any need for all that, this does the trick:
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index aea66a0..503e551 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -748,16 +74
Jeff King wrote:
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -191,15 +191,47 @@ test_expect_success $PREREQ 'Show all headers' '
>
> test_expect_success $PREREQ 'Prompting works' '
> clean_fake_sendmail &&
> - (echo "Example "
> - echo "t...@example.com"
> +
On 11/13/2012 09:50 PM, David Aguilar wrote:
> On Mon, Nov 12, 2012 at 9:47 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> The log message of the original commit (0454dd93bf) described the
>>> following scenario: a /home partition under which user home directories
>>> are automounte
Jeff King wrote:
> Signed-off-by: Jeff King
For what it's worth,
Acked-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King wrote:
> This patch lets callers specify multiple variables, and
> prints one per line.
[...]
> Signed-off-by: Jeff King
Very pleasantly done --- thanks. For what it's worth, assuming this
is tested, I can't see any reason not to apply it.
Reviewed-by: Jonathan Nieder
--
To unsubscr
Jeff King wrote:
> 1. GIT_COMMITTER_* is set explicitly, but we fallback for
> GIT_AUTHOR. We claim the ident is explicit, even though
> the author is not.
>
> 2. GIT_AUTHOR_* is set and we ask for author ident, but
> not committer ident. We will claim the ident is
> implic
60 matches
Mail list logo
