On Sat, Mar 01, 2014 at 01:19:32AM +0100, Michael Haggerty wrote:
> I absolutely understand that changing all of the config parsers is not
> feasible. But I had imagined a third route:
>
> (3) parse the config once, storing the raw values to records in
> memory. When an "unset" is seen, del
2014-03-01 14:46 GMT+08:00 Faiz Kothari :
> From: Faiz Kotahri
>
> Signed-off-by: Faiz Kothari
> ---
> Sticking with implementation involving changing the prototype for
> pack-write.c:finish_tmp_packfile()
> Fixing a small bug in Sun He's implementation which caused a fail in some
> tests.
>
>
2014-03-01 14:46 GMT+08:00 Faiz Kothari :
> From: Faiz Kotahri
>
> Signed-off-by: Faiz Kothari
> ---
> Sticking with implementation involving changing the prototype for
> pack-write.c:finish_tmp_packfile()
> Fixing a small bug in Sun He's implementation which caused a fail in some
> tests.
>
>
On Fri, Feb 28, 2014 at 11:03:19AM -0800, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > So my vote is that the patches are OK the way Dmitry wrote them (mind, I
> > have only read through 05/11 so far).
>
> Seconded ;-)
>
> By the way, I do not like these long subjects. "change" is a
Michael,
On 28.02.2014 18:38, Michael Haggerty wrote:
> Everything looks fine to me. Assuming the test suite ran 100%,
>
> Acked-by: Michael Haggerty
All tests passed successfully for this patch, at least on my machine.
Can I do something else to improve this patch?
--
To unsubscribe from this
On 2014-03-01 03.42, Lee Hopkins wrote:
> I went ahead and took a stab at a solution. My solution is more
> aggressive than a warning, I actually prevent the creation of
> ambiguous refs. My changes are also in refs.c, which may not be
> appropriate, but it seemed like the natural place.
>
> I hav
From: Faiz Kotahri
Signed-off-by: Faiz Kothari
---
Sticking with implementation involving changing the prototype for
pack-write.c:finish_tmp_packfile()
Fixing a small bug in Sun He's implementation which caused a fail in some tests.
builtin/pack-objects.c | 25 -
bulk
On Fri, Feb 28, 2014 at 07:45:07PM +0100, Fabio D'Alfonso wrote:
> I get 12 of 15 tests faling.
>
> Any idea? the same build works fine on 11.04 where I have a desktop version.
No clue. It works fine for me here (Debian sid). Perhaps try running the
script like:
./t9200-git-cvsexportcommit.
On Fri, Feb 28, 2014 at 03:26:28PM -0800, Conley Owens wrote:
> test.sh
> "
> #!/bin/bash
> rungit() {
> mkdir $1
> GIT_DIR=$1 git init --bare
> echo '[remote "aosp"]' > $1/config
> echo 'url =
> https://android.googlesource.com/platform/exte
On Fri, Feb 28, 2014 at 10:09:08AM -0700, Nasser Grainawi wrote:
> > Exactly. The two features (bitmaps and .keep) are not compatible with
> > each other, so you have to prioritize one. If you are using static .keep
> > files, you might want them to continue being respected at the expense of
> > u
On Fri, Feb 28, 2014 at 10:45:39AM -0800, Junio C Hamano wrote:
> > Exactly. The two features (bitmaps and .keep) are not compatible with
> > each other, so you have to prioritize one. If you are using static .keep
> > files, you might want them to continue being respected at the expense of
> > us
On Wed, Feb 26, 2014 at 5:44 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> git_path() soon understands the path given to it. Some paths "abc" may
>> become "def" while other "ghi" may become "ijk". We don't want
>> git_path() to interfere with .lock path construction. Concatenate
On Thu, Feb 27, 2014 at 7:16 AM, Junio C Hamano wrote:
>> + if (file_exists(path.buf)) {
>> + if (strbuf_read_file(&data, path.buf, 0) <= 0)
>> + die_errno(_("failed to read %s"), path.buf);
>
> Do we care about the case where we cannot tell if the file exists
>
On Sat, Mar 1, 2014 at 8:07 AM, Sun He wrote:
> Signed-off-by: Sun He
> ---
> Find the potential places with memcpy by the bash command:
>$ find . | xargs grep "memcpy.*\(.*20.*\)"
>
> Helped-by: Michael Haggerty
You may want to put this Helped-by before "---" because it's supposed
to end
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano wrote:
>> --- a/strbuf.h
>> +++ b/strbuf.h
>> @@ -116,6 +116,10 @@ extern void strbuf_add(struct strbuf *, const void *,
>> size_t);
>> static inline void strbuf_addstr(struct strbuf *sb, const char *s
I went ahead and took a stab at a solution. My solution is more
aggressive than a warning, I actually prevent the creation of
ambiguous refs. My changes are also in refs.c, which may not be
appropriate, but it seemed like the natural place.
I have never contributed to Git (in fact this is my first
On Thu, Feb 20, 2014 at 6:26 AM, Junio C Hamano wrote:
> Is there a reason not to do just an equivalent of
>
> #define git_pathdup mkpathdup
>
> and be done with it? Am I missing something?
>
They have a subtle difference: mkpathdup() calls cleanup_path() while
git_pathdup() does not. Withou
2014-03-01 2:27 GMT+08:00 Faiz Kothari :
> Hi,
> Thanks for the suggestions and remarks.
> I rewrote bulk-checkin.c:finish_bulk_checkin() using strbuf. But saw
> that Sun He has already implemented the same way I have done.
> Should I submit my implementation as a patch?
>
> Secondly,
> I tried imp
Signed-off-by: Sun He
---
Find the potential places with memcpy by the bash command:
$ find . | xargs grep "memcpy.*\(.*20.*\)"
Helped-by: Michael Haggerty
bundle.c| 2 +-
grep.c | 2 +-
pack-bitmap-write.c | 2 +-
ppc/sha1.c | 3 ++-
reflog-walk.c |
Should I also update the relevant git.pot and *.po sections?
- Original Message -
From: "Junio C Hamano"
To: "Jonathan Nieder"
Cc: "Sandy Carter" , git@vger.kernel.org,
"jn avila" , "Carlos Martín Nieto"
Sent: Friday, February 28, 2014 6:31:32 PM
Subject: Re: [PATCH] i18n: proposed com
On 02/28/2014 09:00 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I just wrote up another double-idea that has been stewing in my head for
>> a while:
>>
>> * Allow configuration values to be unset via a config file
>> * Fix "git config --unset" to clean up detritus from sections that
2014-03-01 4:42 GMT+08:00 Eric Sunshine :
> On Fri, Feb 28, 2014 at 9:17 AM, 孙赫 wrote:
>> 2014-02-28 21:12 GMT+08:00 Eric Sunshine [via git]
>> :
>>> On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine <[hidden email]> wrote:
>>>
On Fri, Feb 28, 2014 at 3:28 AM, Sun He <[hidden email]> wrote:
2014-03-01 4:02 GMT+08:00 Junio C Hamano [via git]
:
> Duy Nguyen <[hidden email]> writes:
>
>> Way too long subject line. Keep it within 70-75 chars. The rest could
>> be put in the body.
>>
>> On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 <[hidden email]> wrote:
>>> I am not sure if this is a bug.
>>> I ne
2014-03-01 3:42 GMT+08:00 Junio C Hamano :
> Michael Haggerty writes:
>
>> On 02/28/2014 10:07 AM, Sun He wrote:
>>> Signed-off-by: Sun He
>>> ---
>>> parse-options.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/parse-options.c b/parse-options.c
>>> index 7b8d3f
Jonathan Nieder writes:
> To make life saner for translators, this should be either
> untranslatable or a single multi-line string, I suspect:
>
> diff --git i/builtin/branch.c w/builtin/branch.c
> index b4d7716..972040c 100644
> --- i/builtin/branch.c
> +++ w/builtin/branch.c
> @@ -1022,11 +1022
Duy Nguyen writes:
> On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano wrote:
>> Karsten Blees writes:
>>
If you are on a case-insensitive filesystem, or work on a cross-platform
project, ensure that you avoid ambiguous refs. Problem solved.
>>>
>>> So its OK to lose data if you acc
$ git --version # This is just the git from MacPorts
git version 1.8.5.5
$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.8.5
BuildVersion: 12F45
test.sh
"
#!/bin/bash
rungit() {
mkdir $1
GIT_DIR=$1 git init --bare
echo '[remote "aosp"]' > $1
On Sat, Mar 1, 2014 at 1:58 AM, Junio C Hamano wrote:
> Karsten Blees writes:
>
>>> If you are on a case-insensitive filesystem, or work on a cross-platform
>>> project, ensure that you avoid ambiguous refs. Problem solved.
>>>
>>
>> So its OK to lose data if you accidentally use an ambiguous ref
Commit 322bb6e12f (add update 'none' flag to disable update of submodule
by default) added the '--checkout' option to "git submodule update" but
forgot to explicitly document it in synopsis, usage string and man page
(It is only mentioned implicitly in the man page). In 23d25e48 (submodule:
explici
Is there a way to change color scheme in msysgit without going through
the Properties >> Colors settings?
Reason I ask is because I share the same HOME directory and .bashrc
file between msysgit and cygwin, and it'd be nice to use the same
color scheme defined in the bashrc between both.
Any tips
On Fri, Feb 28, 2014 at 01:27:15AM -0500, Jeff King wrote:
> On Fri, Feb 28, 2014 at 03:17:28PM +0900, Brian Gesiak wrote:
> > Patch is on the way, just waiting for the tests to complete. Thanks
> > for pointing that out! Also, sorry if it's in the Makefile somewhere,
> > but is there an easy way t
On Fri, Feb 28, 2014 at 1:27 PM, Faiz Kothari wrote:
> Thanks for the suggestions and remarks.
[Administrivia: On this list, top-posting is frowned upon; inline
responses are preferred.]
> I rewrote bulk-checkin.c:finish_bulk_checkin() using strbuf. But saw
> that Sun He has already implemented
Hi,
Sandy Carter wrote:
> Add missing leading dash to proposed commands in french output when
> using the command:
Thanks!
[...]
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -3266,7 +3266,7 @@ msgstr "git branch -d %s\n"
> #: builtin/branch.c:1027
> #, c-format
> msgid "git branch --set-up
Jens Lehmann writes:
> Good point. What about this?
>
>
> Documentation/git-submodule.txt | 13 +++--
> git-submodule.sh| 2 +-
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index
Ralf Thielow writes:
> The part "string_list" of the name of function
> "pretty_print_string_list" is just an implementation
> detail. The function pretty-prints command names so
> rename it to "pretty_print_cmdnames".
>
> Signed-off-by: Ralf Thielow
> ---
> Just noticed this while digging throu
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
Reviewed-by: Junio C Hamano
Thanks.
> cache.h | 13 +
> replace_object.c | 7 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/cache.h b/cache.h
> index b039abc..9407560 100644
> --- a/cache.h
Add missing leading dash to proposed commands in french output when
using the command:
git branch --set-upstream remotename/branchname
Signed-off-by: Sandy Carter
---
po/fr.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/fr.po b/po/fr.po
index e10263f..7b44229 100644
--
On Fri, Feb 28, 2014 at 10:54 AM, 孙赫 wrote:
> 2014-02-28 17:47 GMT+08:00 Eric Sunshine [via git]
> :
>> On Fri, Feb 28, 2014 at 3:28 AM, Sun He <[hidden email]> wrote:
>>> Signed-off-by: Sun He <[hidden email]>
>>> ---
>> > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
>>
>>> index
On Fri, Feb 28, 2014 at 9:17 AM, 孙赫 wrote:
> 2014-02-28 21:12 GMT+08:00 Eric Sunshine [via git]
> :
>> On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine <[hidden email]> wrote:
>>
>>> On Fri, Feb 28, 2014 at 3:28 AM, Sun He <[hidden email]> wrote:
Signed-off-by: Sun He <[hidden email]>
---
Sun He writes:
> Signed-off-by: Sun He
> ---
> The tmpname is uninitialized and it should a bug
>
> Please ignore the former patches about this with wrong format.
> I am sorry to cause a jam in your inbox. ^_^
>
> In the end, I wanna thank Michael Haggerty who give me help.
If you look at "git
Duy Nguyen writes:
> Way too long subject line. Keep it within 70-75 chars. The rest could
> be put in the body.
>
> On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 wrote:
>> I am not sure if this is a bug.
>> I need your help to find out it.
>
> Tip:git has a wonderful history (most of it anyway). Try "git
Michael Haggerty writes:
> I just wrote up another double-idea that has been stewing in my head for
> a while:
>
> * Allow configuration values to be unset via a config file
> * Fix "git config --unset" to clean up detritus from sections that are
> left empty.
The former is *way* too large for a
Stephen Leake writes:
> So a message "merge complete; you can drop the stash" would be the most
> git should do.
>From the user experience point of view, that would be good. It could
bother some users, but we have advice.* to silent this kind of warnings.
>From the implementation point of view,
Michael Haggerty writes:
> On 02/28/2014 10:07 AM, Sun He wrote:
>> Signed-off-by: Sun He
>> ---
>> parse-options.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/parse-options.c b/parse-options.c
>> index 7b8d3fa..59a52b0 100644
>> --- a/parse-options.c
>> +++ b/p
Stephen Leake writes:
> I was not aware that the git system could support more than one version
> of a file in one branch.
The index only. The history itself does not.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Hi,
I get 12 of 15 tests faling.
Any idea? the same build works fine on 11.04 where I have a desktop version.
Thanks
not ok 1 - New file
#mkdir A B C D E F &&
# echo hello1 >A/newfile1.txt &&
# echo hello2 >B/newfile2.txt &&
# cp "$TEST_DIRECTORY"/test-binary-
1.png
The part "string_list" of the name of function
"pretty_print_string_list" is just an implementation
detail. The function pretty-prints command names so
rename it to "pretty_print_cmdnames".
Signed-off-by: Ralf Thielow
---
Just noticed this while digging through Git codebase.
help.c | 7 +++
Duy Nguyen writes:
> On Fri, Feb 28, 2014 at 4:46 PM, Dmitry S. Dolzhenko
> wrote:
>> Affected functions: read_one_reflog(), add_commit_info()
>
> We can usually see this from @@ line so it's not really needed to
> describe. Same comment for a few other patches.
Not everybody always reads "git
Michael Haggerty writes:
> So my vote is that the patches are OK the way Dmitry wrote them (mind, I
> have only read through 05/11 so far).
Seconded ;-)
By the way, I do not like these long subjects. "change" is a
redundant word when one sends a patch---as all patches are about
changing someth
Karsten Blees writes:
>> If you are on a case-insensitive filesystem, or work on a cross-platform
>> project, ensure that you avoid ambiguous refs. Problem solved.
>>
>
> So its OK to lose data if you accidentally use an ambiguous ref? I
> cannot believe you actually meant that.
I think he mean
Jeff King writes:
> On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
>
>> I wonder if it makes sense to link it with "pack.writebitmaps" more
>> tightly, without even exposing it as a seemingly orthogonal knob
>> that can be tweaked, though.
>>
>> I think that is because I do not
Jacopo Notarstefano writes:
> On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty
> wrote:
>> I don't understand the benefit of adding a new command "mark" rather
>> than continuing to use "good", "bad", plus new commands "unfixed" and
>> "fixed". Does this solve any problems?
>>
>
> As Matthie
Hi,
Thanks for the suggestions and remarks.
I rewrote bulk-checkin.c:finish_bulk_checkin() using strbuf. But saw
that Sun He has already implemented the same way I have done.
Should I submit my implementation as a patch?
Secondly,
I tried implementing this WITHOUT changing the prototype of the
fun
Carlos Martín Nieto writes:
> ... However, we now
> have 'origin/master' and 'origin/pr/5' both of which match the
> 'refs/remotes/origin/*' pattern. The current behaviour is to stop at the
> first match, which would mark it as stale as there is no
> 'refs/heads/pr/5' branch in the remote.
OK, b
Stephen Leake writes:
> David Kastrup writes:
>
>> Stephen Leake writes:
>>
>>> David Kastrup writes:
>>>
"do the right thing" commands also tend to do the wrong thing
occasionally with potentially disastrous results when they are used
in scripts where the followup actions rely
Jeff King writes:
> Here's a series to handle this; I think the end result is much nicer. I
> ended up calling the option "uploadarchive.allowUnreachable". By moving
> it there instead of under "archive", it is more clear that this is about
> the _serving_ end of the remote connection, and the wo
Jeff King writes:
> On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:
>
>> > Signed-off-by: Jeff King
>>
>> Thanks.
>>
>> Do GitHub people have general aversion against signing off (or
>> sending out, for that matter) their own patches, unless they were
>> already active here bef
On Fri, 28 Feb 2014, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
Acked-by: Nicolas Pitre
> ---
> object.c | 29 -
> object.h | 7 +++
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/object.c b/object.c
> index 584f7ac..57a089
Stephen Leake writes:
> Matthieu Moy writes:
>
>> li...@haller-berlin.de (Stefan Haller) writes:
>>
>>> Your intention was clearly to drop the stash, it just wasn't dropped
>>> because of the conflict. Dropping it automatically once the conflict
>>> is resolved would be nice.
>>
>> Your intentio
David Kastrup writes:
> Stephen Leake writes:
>
>> Brandon McCaig writes:
>>
>>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
>>> wrote:
You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by 'git stash pop', it is not
g
Matthieu Moy writes:
> Stephen Leake writes:
>
>> So it appears that adding a file _does_ tell git that the conflict is
>> resolved.
>
> Yes it does. Git _knows_ that you consider the conflict to be resolved.
> It cannot know how happy you are with the result.
>
> Similarly, in a conflicted merg
David Kastrup writes:
> Stephen Leake writes:
>
>> David Kastrup writes:
>>
>>> "do the right thing" commands also tend to do the wrong thing
>>> occasionally with potentially disastrous results when they are used
>>> in scripts where the followup actions rely on the actual result.
>>
>> That i
On Fri, Feb 28, 2014 at 6:00 PM, Kirill Smelkov wrote:
> On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote:
>> On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote:
>> > On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
>> >> diff --git a/Makefile b/Makefile
>> >> index dddaf4
From: "Jeff King"
I'd expect "-$n" to mean "rebase the last $n commits" (as opposed to
everything not in the upstream). That does not work currently, of
course, but:
1. It has the potential to confuse people who read it, since it's
unlike what "-1" means in most of the rest of git.
2. It
On Feb 28, 2014, at 1:55 AM, Jeff King wrote:
> On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
>
>> I wonder if it makes sense to link it with "pack.writebitmaps" more
>> tightly, without even exposing it as a seemingly orthogonal knob
>> that can be tweaked, though.
>>
>> I th
On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote:
> On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote:
> > On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
> >> diff --git a/Makefile b/Makefile
> >> index dddaf4f..0334806 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >>
The use case:
I'm doing a 'git stash pop'; it had conflicts. At this point, 'git status'
shows:
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: Target.java
#
# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git ad
Signed-off-by: Sun He
---
I follow the suggestions of Eric Sunshine to fix the patch.
Of cause this patch has assumed that you have already fix the bug of
tmpname in builtin/pack-objects.c:write_pack_file() warning()
I want to say thank you to Eric Sunshine and Michael Haggerty who give me
lots
Signed-off-by: Michael Haggerty
---
object.c | 29 -
object.h | 7 +++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/object.c b/object.c
index 584f7ac..57a0890 100644
--- a/object.c
+++ b/object.c
@@ -43,14 +43,32 @@ int type_from_string(const cha
Signed-off-by: Michael Haggerty
---
cache.h | 13 +
replace_object.c | 7 +++
2 files changed, 20 insertions(+)
diff --git a/cache.h b/cache.h
index b039abc..9407560 100644
--- a/cache.h
+++ b/cache.h
@@ -798,13 +798,26 @@ static inline void *read_sha1_file(const unsign
This patch series applies on top of mh/replace-refs-variable-rename,
simply because one of the comments refers to the global variable
check_replace_refs by its new name.
This is a re-roll of patches 1/6 and 6/6 of the series
"mh/object-code-cleanup" that I submitted earlier [1]. Patches 2-5 of
th
Signed-off-by: Sun He
---
The tmpname is uninitialized and it should a bug
Please ignore the former patches about this with wrong format.
I am sorry to cause a jam in your inbox. ^_^
In the end, I wanna thank Michael Haggerty who give me help.
builtin/pack-objects.c | 2 +-
1 file changed, 1 i
Stephen Leake writes:
> Brandon McCaig writes:
>
>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
>> wrote:
>>> You might be adding other files for other reasons. But if you add a file
>>> that does resolve a conflict caused by 'git stash pop', it is not
>>> guessing.
>>
>> Staging a file does
OK, so what can we do next?
Paul
-Original Message-
From: Paul Lotz [mailto:pl...@lsst.org]
Sent: Monday, February 24, 2014 9:44 AM
To: 'David Aguilar'
Cc: 'git@vger.kernel.org'
Subject: RE: difftool sends malformed path to exernal tool on Windows
David,
Thanks for the helpful reply.
-- Forwarded message --
From: 孙赫
Date: 2014-02-28 21:37 GMT+08:00
Subject: Re: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to
use a strbuf for handling packname
To: "Eric Sunshine [via git]"
2014-02-28 17:47 GMT+08:00 Eric Sunshine [via git]
:
> On Fri, Feb 28, 2014 at
Stephen Leake writes:
> So it appears that adding a file _does_ tell git that the conflict is
> resolved.
Yes it does. Git _knows_ that you consider the conflict to be resolved.
It cannot know how happy you are with the result.
Similarly, in a conflicted merge, the last "git add" does not trigg
Signed-off-by: Sun He
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c733379..4922ce5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -823,7 +823,7 @@ static void write_pack_f
Signed-off-by: Sun He
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,7 +371,7 @@ static void parse_options_check(const struct option *opts)
2014-02-28 22:43 GMT+08:00 Duy Nguyen [via git]
:
> Way too long subject line. Keep it within 70-75 chars. The rest could
> be put in the body.
>
> On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 <[hidden email]> wrote:
>> I am not sure if this is a bug.
>> I need your help to find out it.
>
> Tip:git has a wo
Brandon McCaig writes:
> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
> wrote:
>> You might be adding other files for other reasons. But if you add a file
>> that does resolve a conflict caused by 'git stash pop', it is not
>> guessing.
>
> Staging a file doesn't tell git that you resolved a c
Jeff King writes:
> Don't die to let the caller finish its
> job in such case.
[...]
> Matthieu, can you remember anything else that
> led to that decision?
Not at all, unfortunately. I don't remember if I did that "in case
there's something like some cleanup to do" or because I had someth
Way too long subject line. Keep it within 70-75 chars. The rest could
be put in the body.
On Fri, Feb 28, 2014 at 9:32 PM, 孙赫 wrote:
> I am not sure if this is a bug.
> I need your help to find out it.
Tip:git has a wonderful history (most of it anyway). Try "git log
--patch parse-options.[ch]"
On 02/28/2014 10:29 AM, Dmitry S. Dolzhenko wrote:
> Thank you for your remarks. In this patch I tried to take them into account.
>
> Dmitry S. Dolzhenko (11):
> builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()
> bundle.c: change add_to_ref_list() to use ALLOC_GROW()
> c
On 02/28/2014 03:31 PM, Duy Nguyen wrote:
> On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty
> wrote:
>> On 02/28/2014 12:38 AM, Lee Hopkins wrote:
>>> [...] Based Michael Haggerty's response, it seems that always
>>> using loose refs would be a better workaround.
>>
>> No, I answered the questi
On Fri, Feb 28, 2014 at 9:20 PM, Michael Haggerty wrote:
> Duy,
>
> The example in Documentation/technical/api-allocation-growing.txt does
> it the same way as Dmitry:
>
> ALLOC_GROW(item, nr + 1, alloc);
> item[nr++] = value you like;
>
> The alternative,
>
> nr++;
> ALLOC_GROW(it
I am not sure if this is a bug.
I need your help to find out it.
Cheers,
He Sun
2014-02-28 22:29 GMT+08:00 Sun He :
> Signed-off-by: Sun He
> ---
> parse-options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/parse-options.c b/parse-options.c
> index 7b8d3fa..59a52b0
Signed-off-by: Sun He
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 7b8d3fa..59a52b0 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,7 +371,7 @@ static void parse_options_check(const struct option *opts)
On Fri, Feb 28, 2014 at 4:13 PM, Michael Haggerty wrote:
> On 02/28/2014 12:38 AM, Lee Hopkins wrote:
>> [...] Based Michael Haggerty's response, it seems that always
>> using loose refs would be a better workaround.
>
> No, I answered the question "what would be the disadvantages of using
> only
I just wrote up another double-idea that has been stewing in my head for
a while:
* Allow configuration values to be unset via a config file
* Fix "git config --unset" to clean up detritus from sections that are
left empty.
These ideas are more "out there" than the last, and might be too
controve
Stephen Leake writes:
> David Kastrup writes:
>
>> "do the right thing" commands also tend to do the wrong thing
>> occasionally with potentially disastrous results when they are used
>> in scripts where the followup actions rely on the actual result.
>
> That is bad, and should not be allowed.
On 02/28/2014 01:40 PM, Duy Nguyen wrote:
> On Fri, Feb 28, 2014 at 7:32 PM, Duy Nguyen wrote:
>>> done_pbase_paths_num++;
>>
>> If you move this up one line, then you don't have to "+ 1" in ALLOC_GROW
>>
>
> same comment to a few other patches. The rest of your series looks good.
Duy,
2014-02-28 21:12 GMT+08:00 Eric Sunshine [via git]
:
> On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine <[hidden email]> wrote:
>
>> On Fri, Feb 28, 2014 at 3:28 AM, Sun He <[hidden email]> wrote:
>>> Signed-off-by: Sun He <[hidden email]>
>>> ---
>>
>> Nicely done.
>>
>> Due to the necessary changes
David Kastrup writes:
> Stephen Leake writes:
>
>> I like commands that "do the right thing". So no, this would not be
>> confusing.
>
> I _hate_ commands that think they know better than to do what they are
> told. In particular when doing destructive things. And just because
> _you_ like the
> If you are on a case-insensitive filesystem, or work on a cross-platform
> project, ensure that you avoid ambiguous refs. Problem solved.
I agree this is the best solution, and I personally avoid the use of
ambiguous refs. However, since there is nothing in git stopping the
use of ambiguous refs
On 02/28/2014 01:52 PM, Jeff King wrote:
> [...]
> Sorry, I missed an important word in my final sentence. It should have
> been "the examples you gave are NOT particularly interesting to me".
>
> On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:
>> Particularly all of the ideas expr
Am 28.02.2014 07:41, schrieb Johannes Sixt:
> Am 2/28/2014 0:38, schrieb Lee Hopkins:
>>> If I understand the issue correctly, the problem is that packed-refs
>>> are always case-sensitive, even if core.ignorecase=true. OTOH,
>
> core.ignorecase is intended to affect filenames of the worktree, not
On Fri, Feb 28, 2014 at 08:16:13PM +0900, Brian Gesiak wrote:
> > I just don't want to regress somebody else's workflow due
> > to my lack of imagination.
>
> This makes a lot of sense to me, although as-is the function emits a
> warning and returns immediately (although with a successful status
On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote:
> On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
>> diff --git a/Makefile b/Makefile
>> index dddaf4f..0334806 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -316,6 +321,7 @@ endif
>> ifeq ($(uname_S),Windows)
>> GIT_VERSIO
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
> diff --git a/Makefile b/Makefile
> index dddaf4f..0334806 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -316,6 +321,7 @@ endif
> ifeq ($(uname_S),Windows)
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> + HAVE_ALL
On Fri, Feb 28, 2014 at 4:46 AM, Eric Sunshine wrote:
> On Fri, Feb 28, 2014 at 3:28 AM, Sun He wrote:
>> Signed-off-by: Sun He
>> ---
>
> Nicely done.
>
> Due to the necessary changes to finish_tmp_packfile(), the focus of
> this patch has changed slightly from that suggested by the
> microproj
1 - 100 of 149 matches
Mail list logo
