[PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname

Signed-off-by: Sun He --- builtin/pack-objects.c | 17 +++-- bulk-checkin.c | 8 +--- pack-write.c | 20 pack.h | 2 +- 4 files changed, 25 insertions(+), 22 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-o

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

On Fri, Feb 28, 2014 at 04:28:38PM +0900, Brian Gesiak wrote: > I would be in favor of using test_i18ngrep, but it seems like this > test file overwhelmingly uses test_(i18n)cmp, even when inspecting > stderr output. We generally prefer "cmp" checks to "grep" checks, because they are more rigorou

Re: How to mark a complete sub-directory assume-unchanged/skip-worktree?

From: "Duy Nguyen" On Fri, Feb 28, 2014 at 6:46 AM, Philip Oakley wrote: Is there a particular bit of code I'd be worth studying for the partial index example to see how well it might fit my ideas? My last attempt was http://git.661346.n2.nabble.com/PATCH-00-17-Narrow-clone-v3-was-subtree-c

Re: [PATCH] repack: add `repack.honorpackkeep` config var

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 fully understand the ", beca

Re: An idea for "git bisect" and a GSoC enquiry

Mh. Haven't thought of that. I have no experience with TK, so I'm having trouble digging up where the "good" and "bad" labels in the GUI are generated. I guess that a solution might involve writing a temporary file in $GIT_DIR called something like BISECT_LABELS in which the chosen labels are list

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

Jonathan Nieder writes: > Hi, > > Andrew Wong wrote: > >> The first two patches are just about rewording a message, and adding messages >> to tell users to use "git merge --abort" to abort a merge. > > Sounds like a good idea. I look forward to reading the patches. > >> We could stop here and ho

Re: An idea for "git bisect" and a GSoC enquiry

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 Matthieu Moy remarked in a previous email, the ma

Re: [PATCH] archive: add archive.restrictRemote option

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 before they joined GitHub, by the

Re: An idea for "git bisect" and a GSoC enquiry

This email was sent privately by Michael to me as a result of my previous error. I'm quoting it in its entirety so that he doesn't have to submit it twice. On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty wrote: > Please forgive my typos and brevity; this was typed on a phone. > > Michael > On F

[PATCH] parse-options.c:parse_options_check() change OPTION_NUMBER to OPTION_CMDMODE

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)

Re: Branch Name Case Sensitivity

Karsten Blees writes: > If I understand the issue correctly, the problem is that packed-refs > are always case-sensitive, even if core.ignorecase=true. Perhaps that could be changed? if core.ignorecase=true, packed-refs should be compared with case-insensitive string compares. -- -- Stephe --

Re: An idea for "git bisect" and a GSoC enquiry

> - git could emit an error message and refuse to continue > - git could interpret the command one way or the other, with or without a > warning > > By my count that gives at least five possibilities. The feature cannot be > implemented without choosing one. > Let me explain what I meant with an

Re: Branch Name Case Sensitivity

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 packed refs?". Now I will answer the question "what would be the d

Re: [PATCH] rewrite bulk-checkin.c:finish_bulk_checkin() using strbuf

On Fri, Feb 28, 2014 at 2:58 AM, Faiz Kothari wrote: > Signed-off-by: Faiz Kothari > > Notes: > I finally got what's happening, and why the errors were caused. > packname is supposed to contain the complete path to the .pack file. > Packs are stored as /path/to/.pack which I overlooke

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote: > Jonathan Nieder writes: > > And for experienced users, this would be a bad regression. > > Backward incompatibility is a real concern. > > It might be best if "git reset" (with _no_ option) be made to error out, > so all users have

[PATCH v2 00/11] Use ALLOC_GROW() instead of inline code

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() cache-tree.c: change find_subtree() to use ALLOC_GROW() commit

[PATCH v2 01/11] builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- builtin/pack-objects.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index c733379..56a6fc8 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1213,12 +1213,7 @@ st

[PATCH v2 02/11] bundle.c: change add_to_ref_list() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- bundle.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/bundle.c b/bundle.c index e99065c..1388a3e 100644 --- a/bundle.c +++ b/bundle.c @@ -14,11 +14,7 @@ static const char bundle_signature[] = "# v2 git bundle\n"; static void add_

[PATCH v2 03/11] cache-tree.c: change find_subtree() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- cache-tree.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index 0bbec43..30149d1 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -75,11 +75,7 @@ static struct cache_tree_sub *find_subtree(struct cache_t

[PATCH v2 04/11] commit.c: change register_commit_graft() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- commit.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/commit.c b/commit.c index 6bf4fe0..e004314 100644 --- a/commit.c +++ b/commit.c @@ -147,12 +147,8 @@ int register_commit_graft(struct commit_graft *graft, int ignore_dups)

[PATCH v2 05/11] diff.c: use ALLOC_GROW() instead of inline code

Signed-off-by: Dmitry S. Dolzhenko --- diff.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/diff.c b/diff.c index e800666..aebdfda 100644 --- a/diff.c +++ b/diff.c @@ -1361,11 +1361,7 @@ static struct diffstat_file *diffstat_add(struct diffstat_t *diffstat, {

[PATCH v2 06/11] diffcore-rename.c: use ALLOC_GROW() instead of inline code

Affected functions: locate_rename_dst(), register_rename_src() Signed-off-by: Dmitry S. Dolzhenko --- diffcore-rename.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/diffcore-rename.c b/diffcore-rename.c index 9b4f068..fbf3272 100644 --- a/diffcore-rename.c ++

[PATCH v2 07/11] patch-ids.c: change add_commit() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- patch-ids.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/patch-ids.c b/patch-ids.c index bc8a28f..bf81b92 100644 --- a/patch-ids.c +++ b/patch-ids.c @@ -83,10 +83,7 @@ static struct patch_id *add_commit(struct commit *commit,

Re: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname

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 microproject. It's really now about finish_tmp_packfile() rather than finish_b

[PATCH v2 08/11] replace_object.c: change register_replace_object() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- replace_object.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/replace_object.c b/replace_object.c index cdcaf8c..843deef 100644 --- a/replace_object.c +++ b/replace_object.c @@ -36,12 +36,8 @@ static int register_replace_object

[PATCH v2 09/11] reflog-walk.c: use ALLOC_GROW() instead of inline code

Affected functions: read_one_reflog(), add_commit_info() Signed-off-by: Dmitry S. Dolzhenko --- reflog-walk.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/reflog-walk.c b/reflog-walk.c index b2fbdb2..879d2ed 100644 --- a/reflog-walk.c +++ b/reflog-walk.c @@

[PATCH v2 10/11] dir.c: change create_simplify() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- dir.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/dir.c b/dir.c index 98bb50f..4ae38e4 100644 --- a/dir.c +++ b/dir.c @@ -1341,10 +1341,7 @@ static struct path_simplify *create_simplify(const char **pathspec) for (nr =

[PATCH v2 11/11] attr.c: change handle_attr_line() to use ALLOC_GROW()

Signed-off-by: Dmitry S. Dolzhenko --- attr.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/attr.c b/attr.c index 8d13d70..734222d 100644 --- a/attr.c +++ b/attr.c @@ -338,12 +338,7 @@ static void handle_attr_line(struct attr_stack *res, a = parse_attr_line(lin

Re: Branch Name Case Sensitivity

On 02/28/2014 10:11 AM, Stephen Leake wrote: > Karsten Blees writes: > >> If I understand the issue correctly, the problem is that packed-refs >> are always case-sensitive, even if core.ignorecase=true. > > Perhaps that could be changed? if core.ignorecase=true, packed-refs > should be compared

[PATCH v2 0/2] lifting upload-archive restrictions

On Fri, Feb 28, 2014 at 04:07:09AM -0500, Jeff King wrote: > > As this does not affect local use of "git archive", "requested by > > refnames" may need to be clarified further. Perhaps "remote > > archives can be requested only for published refnames" or something. > > I was hoping to be vague.

[PATCH v2 1/2] docs: clarify remote restrictions for git-upload-archive

Commits ee27ca4 and 0f544ee introduced rules by which git-upload-archive would restrict clients from accessing unreachable objects. However, we never documented those rules anywhere, nor their reason for being. Let's do so now. Signed-off-by: Jeff King --- Documentation/git-archive.txt|

[PATCH v2 2/2] add uploadarchive.allowUnreachable option

From: Scott J. Goldman In commit ee27ca4, we started restricting remote git-archive invocations to only accessing reachable commits. This matches what upload-pack allows, but does restrict some useful cases (e.g., HEAD:foo). We loosened this in 0f544ee, which allows `foo:bar` as long as `foo` is

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

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 them does not mean they are not confusi

Re: [PATCH] parse-options.c:parse_options_check() change OPTION_NUMBER to OPTION_CMDMODE

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/parse-options.c > @@ -371,7 +371,7 @@ s

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

> If you feel like continuing on this series, converting the warning() > into a die() would be a much more productive use of time (but if you > don't, I do not see any reason not to take the patches you've posted). I'd be happy to keep working on this. In fact, I think I have a patch for this read

Re: [PATCH] parse-options.c:parse_options_check() change OPTION_NUMBER to OPTION_CMDMODE

On Fri, Feb 28, 2014 at 6:15 PM, Michael Haggerty wrote: > > 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 100

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

On Fri, Feb 28, 2014 at 07:44:10PM +0900, Brian Gesiak wrote: > > I notice that the warning comes from install_branch_config, which gets > > used both for "branch -u", but also in the "side effect" case I > > mentioned above. Is it possible to trigger this as part of such a case? > > I think maybe

[PATCH] branch.c: delete size check of newly tracked branch names

Since commit 6f084a56 the length of a newly tracked branch name was limited to 1019 = 1024 - 7 - 7 - 1 characters, a bound derived by having to store this name in a char[1024] called key with two strings of length at most 7 and a '\0' character. This was no longer necessary as of commit a9f2c136,

Re: [PATCH] branch.c: delete size check of newly tracked branch names

> This patch removes this unneeded check and thus allows for branch names > longer than 1019 characters. > Ach! I amended the commit in my local history to read "Remove this unneded check and thus allow for branch names longer than 1019 characters", but for some reason git format-patch -1 --signof

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

> 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 code), so I'm also stumped as to what kind of workflow this would be incl

Re: [PATCH] branch.c: delete size check of newly tracked branch names

On Fri, Feb 28, 2014 at 6:09 PM, Jacopo Notarstefano wrote: > Since commit 6f084a56 the length of a newly tracked branch name was limited > to 1019 = 1024 - 7 - 7 - 1 characters, a bound derived by having to store > this name in a char[1024] called key with two strings of length at most 7 > and a

Re: [PATCH 17/19] Portable alloca for Git

Hi! On Mon, 24 Feb 2014 20:21:49 +0400, Kirill Smelkov wrote: > Both autoconf and config.mak.uname configurations were updated. For > autoconf, we are not bothering considering cases, when no alloca.h is > available, but alloca() works some other way - its simply alloca.h is > available and works

Re: [PATCH] branch.c: delete size check of newly tracked branch names

> Nice. new_ref is passed in install_branch_config() in latest code. I > guess you already made sure this function did not make any assumption > about new_ref's length? > The function install_branch_config uses the strbuf, as I wrote in the commit message. The contents of this buffer are then fed

Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

On Thu, 2014-02-27 at 12:19 -0800, Junio C Hamano wrote: > Carlos Martín Nieto writes: > > > From: Carlos Martín Nieto > > > > We need to consider that a remote-tracking branch may match more than > > one rhs of a fetch refspec. > > Hmph, do we *need* to, really? > > Do you mean fetching one r

Re: [PATCH v2 01/11] builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()

On Fri, Feb 28, 2014 at 4:40 PM, Dmitry S. Dolzhenko wrote: > Signed-off-by: Dmitry S. Dolzhenko > --- > builtin/pack-objects.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c > index c733379..56a6fc8 100644 > --- a/b

Re: [PATCH v2 09/11] reflog-walk.c: use ALLOC_GROW() instead of inline code

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. -- Duy -- To unsubscribe from this list: send the line "unsubsc

Re: [PATCH v2 01/11] builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()

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 -- To unsubscribe from this list: send the line "un

Re: [PATCH] branch.c: delete size check of newly tracked branch names

On Fri, Feb 28, 2014 at 7:14 PM, Jacopo Notarstefano wrote: >> Nice. new_ref is passed in install_branch_config() in latest code. I >> guess you already made sure this function did not make any assumption >> about new_ref's length? >> > > The function install_branch_config uses the strbuf, as I wr

Re: GSoC idea: allow "git rebase --interactive" todo lines to take options

On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote: > On Wed, Feb 26, 2014 at 5:52 AM, Jeff King wrote: > > This seems like a reasonable feature to me. All of your examples are > > possible with an "e"dit and another git command, but the convenience may > > be worth it (though persona

Re: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname

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

Re: [PATCH 17/19] Portable alloca for Git

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

Re: [PATCH 17/19] Portable alloca for Git

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

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

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

Re: Branch Name Case Sensitivity

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

Re: GSoC idea: allow "git rebase --interactive" todo lines to take options

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

Re: Branch Name Case Sensitivity

> 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

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

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

Re: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname

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

Re: [PATCH v2 01/11] builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()

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,

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

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.

RFC GSoC idea: new "git config" features

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

Re: Branch Name Case Sensitivity

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

[PATCH] OPTION_CMDMODE should be used when not accept an argument, and OPTION_NUMBER is of special type. So change the mode to OPTION_CMDMODE

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)

Re: [PATCH] OPTION_CMDMODE should be used when not accept an argument, and OPTION_NUMBER is of special type. So change the mode to OPTION_CMDMODE

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

Re: [PATCH v2 01/11] builtin/pack-objects.c: change check_pbase_path() to use ALLOC_GROW()

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

Re: Branch Name Case Sensitivity

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

Re: [PATCH] OPTION_CMDMODE should be used when not accept an argument, and OPTION_NUMBER is of special type. So change the mode to OPTION_CMDMODE

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]"

Re: [PATCH v2 00/11] Use ALLOC_GROW() instead of inline code

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

Re: [PATCH 1/2] t3200-branch: test setting branch as own upstream

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

Re: `git stash pop` UX Problem

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

Re: [PATCH] OPTION_CMDMODE should be used when not accept an argument, and OPTION_NUMBER is of special type. So change the mode to OPTION_CMDMODE

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

[PATCH] OPTION_NUMBER should be replaced by OPTION_CMDMODE

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)

[PATCH] builtin/pack-objects.c:write_pack_file() replace tmpname with pack_tmp_name in warning

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

Re: `git stash pop` UX Problem

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

Fwd: [PATCH] Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname

-- 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

RE: difftool sends malformed path to exernal tool on Windows

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.

Re: `git stash pop` UX Problem

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

[PATCH] builtin/pack-objects.c:write_pack_file() replace tmpname with pack_tmp_name in warning

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

[PATCH v2 1/2] Add docstrings for lookup_replace_object() and do_lookup_replace_object()

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

[PATCH v2 0/2] More object-related docstrings

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

[PATCH v2 2/2] Document some functions defined in object.c

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

[PATCH] finish_tmp_packfile():use strbuf for pathname construction

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

git reset returns unwanted failure status

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

Re: [PATCH 17/19] Portable alloca for Git

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 > >>

Re: [PATCH] repack: add `repack.honorpackkeep` config var

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

Re: [PATCH/RFC] rebase: new convenient option to edit a single commit

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

Re: [PATCH 17/19] Portable alloca for Git

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

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

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

Re: `git stash pop` UX Problem

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

Re: `git stash pop` UX Problem

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

Re: `git stash pop` UX Problem

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

Re: [PATCH v2 2/2] Document some functions defined in object.c

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

Re: [PATCH] archive: add archive.restrictRemote option

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

Re: [PATCH v2 0/2] lifting upload-archive restrictions

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

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

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

Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

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

Re: [PATCH] rewrite bulk-checkin.c:finish_bulk_checkin() using strbuf

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

Re: An idea for "git bisect" and a GSoC enquiry

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

Re: [PATCH] repack: add `repack.honorpackkeep` config var

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

Re: Branch Name Case Sensitivity

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

  1   2   >