Re: [PATCH] check-ignore: Add option to ignore index contents

Am 8/30/2013 0:46, schrieb Dave Williams: > +-i, --ignore-index:: > + Don't look in the index when undertaking the checks. This means > + the results deviate from those seen by git add and git status > + but is useful when understanding why a path became tracked by > + e.g. git add

Re: [PATCH] revision: add --except option

Felipe Contreras writes: > So that it's possible to remove certain refs from the list without > removing the objects that are referenced by other refs. > > For example this repository: > > * 374e8dd (crap) crap > * 4cbbf7b (test) two > * d025ae0 (HEAD, master) one Can we make it more clear

[PATCH v6 13/28] rebase: split the cherry-pick stuff

They do something completely different from 'git am', it belongs in a different file. No functional changes. Signed-off-by: Felipe Contreras --- .gitignore| 1 + Makefile | 1 + git-rebase--am.sh | 11 +-- git-rebase--cherrypick.sh | 30 +++

[PATCH v6 22/28] t: rebase-autostash: fix setup

Signed-off-by: Felipe Contreras --- t/t3420-rebase-autostash.sh | 105 ++-- 1 file changed, 52 insertions(+), 53 deletions(-) diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 90eb264..c179262 100755 --- a/t/t3420-rebase-autostas

[PATCH v6 17/28] rebase: cherry-pick: fix command invocations

So that all the tests pass. Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index d8d32fe..e9e 100644 --- a/git-rebase--cherrypick.sh +++

[PATCH v6 19/28] rebase: cherry-pick: automatically commit stage

When there's changes in the staging area. Just like the other rebase modes. Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index be17ec4..241cda7 100644 --- a/git-rebase

[PATCH v6 12/28] cherry-pick: remember rerere-autoupdate

Signed-off-by: Felipe Contreras --- sequencer.c | 8 1 file changed, 8 insertions(+) diff --git a/sequencer.c b/sequencer.c index 076bb9d..453e4a4 100644 --- a/sequencer.c +++ b/sequencer.c @@ -847,6 +847,8 @@ static int populate_opts_cb(const char *key, const char *value, void *data)

[PATCH v6 07/28] cherry-pick: don't store skipped commit

Signed-off-by: Felipe Contreras --- sequencer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sequencer.c b/sequencer.c index 468fa54..56d791f 100644 --- a/sequencer.c +++ b/sequencer.c @@ -1047,7 +1047,7 @@ static int continue_single_pick(void) return run_co

[PATCH v6 25/28] rebase: use 'cherrypick' mode instead of 'am'

Unless any specific 'git am' options are used. Signed-off-by: Felipe Contreras --- git-rebase.sh | 8 t/t3407-rebase-abort.sh| 2 +- t/t3420-rebase-autostash.sh| 2 +- t/t3425-rebase-topology-merges.sh | 6 +++--- t/t5520-pull.sh

[PATCH v6 20/28] rebase: cherry-pick: set correct action-name

Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index 241cda7..d36b0dc 100644 --- a/git-rebase--cherrypick.sh +++ b/git-rebase--cherrypick.sh @@ -45,7 +45,7 @@ e

[PATCH v6 21/28] rebase: trivial cleanup

Signed-off-by: Felipe Contreras --- git-rebase--am.sh | 1 + git-rebase.sh | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index aae6a85..d6a434c 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -51,6 +51,7 @@ ret=0

[PATCH v6 11/28] cherry-pick: copy notes and run hooks

If no action-name is specified, nothing is done. Signed-off-by: Felipe Contreras --- Documentation/config.txt | 9 - Documentation/githooks.txt | 8 rewrite.c | 1 + sequencer.c| 25 - 4 files changed, 33 insertions(+

[PATCH v6 27/28] rebase: remove merge mode

The cherrypick mode does the job. Signed-off-by: Felipe Contreras --- .gitignore| 1 - Makefile | 1 - git-rebase--interactive.sh| 2 +- git-rebase--merge.sh | 151 -- git-rebase.sh

[PATCH v6 06/28] cherry-pick: store rewritten commits

Will be useful for the next commits. Signed-off-by: Felipe Contreras --- sequencer.c | 22 +- sequencer.h | 1 + 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index d0e65de..468fa54 100644 --- a/sequencer.c +++ b/sequencer.c @@ -14,

[PATCH v6 09/28] builtin: rewrite: add copy_rewrite_notes()

And use it on commit.c. Signed-off-by: Felipe Contreras --- builtin/commit.c | 8 +--- rewrite.c| 18 ++ rewrite.h| 1 + 3 files changed, 20 insertions(+), 7 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 7bfe9d0..cc589d5 100644 --- a/b

[PATCH v6 28/28] rebase: cherry-pick: add copyright

Probably enough changes to warrant that. Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index bda7cfc..da949aa 100644 --- a/git-rebase--cherrypick.sh +++ b/git

[PATCH v6 16/28] rebase: cherry-pick: fix abort of cherry mode

Signed-off-by: Felipe Contreras --- git-rebase.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/git-rebase.sh b/git-rebase.sh index b28addc..db2ea8d 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -368,6 +368,7 @@ skip) run_specific_rebase ;; abort) + test "$type" =

[PATCH v6 10/28] cherry-pick: add --action-name option

So it can be used by other tools (e.g. git rebase), and the right action is passed to the hooks and notes rewrite stuff. Signed-off-by: Felipe Contreras --- builtin/revert.c | 2 ++ git-rebase--interactive.sh | 4 ++-- sequencer.c| 6 +- sequencer.h|

[PATCH v6 14/28] rebase: cherry-pick: fix mode storage

We don't use the 'rebase-apply'. Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 5 - git-rebase.sh | 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index 2c16995..e142cfb 100644 --- a/

[PATCH v6 24/28] prompt: parse cherry-pick rebase mode

Signed-off-by: Felipe Contreras --- contrib/completion/git-prompt.sh | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index a81ef5a..a7bde16 100644 --- a/contrib/completion/git-prompt.sh +++ b

[PATCH v6 23/28] sequencer: store progress information

So that it can be used by shell prompts. Signed-off-by: Felipe Contreras --- sequencer.c | 24 ++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/sequencer.c b/sequencer.c index 453e4a4..c855dd4 100644 --- a/sequencer.c +++ b/sequencer.c @@ -21,6 +21,7 @@ co

[PATCH v6 05/28] builtin: add rewrite helper

So that we can load and store rewrites, as well as other operations on a list of rewritten commits. Signed-off-by: Felipe Contreras --- Makefile | 2 ++ rewrite.c | 71 +++ rewrite.h | 18 3 files changed, 91 insertio

[PATCH v6 08/28] builtin: move run_rewrite_hook() to rewrite.c

And use struct rewrite. Signed-off-by: Felipe Contreras --- builtin/commit.c | 38 +- rewrite.c| 32 rewrite.h| 1 + 3 files changed, 38 insertions(+), 33 deletions(-) diff --git a/builtin/commit.c b/builtin/c

[PATCH v6 26/28] rebase: cherry-pick: add merge options

Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index d36b0dc..bda7cfc 100644 --- a/git-rebase--cherrypick.sh +++ b/git-rebase--cherrypick.sh @@ -45,6 +45,15 @@ else f

[PATCH v6 15/28] rebase: cherry-pick: fix sequence continuation

We are not in am mode. Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index e142cfb..d8d32fe 100644 --- a/git-rebase--cherrypick.sh +++ b/git-rebase--cherr

[PATCH v6 18/28] rebase: cherry-pick: fix status messages

Signed-off-by: Felipe Contreras --- git-rebase--cherrypick.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git-rebase--cherrypick.sh b/git-rebase--cherrypick.sh index e9e..be17ec4 100644 --- a/git-rebase--cherrypick.sh +++ b/git-rebase--cherrypick.sh @@ -3,6 +3,9 @@ # Copyright (c)

[PATCH v6 02/28] cherry-pick: add --skip-empty option

Pretty much what it says on the tin. Signed-off-by: Felipe Contreras --- Documentation/git-cherry-pick.txt | 3 +++ builtin/revert.c| 8 sequencer.c | 6 ++ sequencer.h | 1 + t/t3508-cherry-pick-many-commits.

[PATCH v6 00/28] Massive improvents to rebase and cherry-pick

Hi, These are improvements to 'git rebase' by using a much improved 'git cherry-pick'. A new rewrite.c helper is added, and builtin/commit updated to use that. A new git-rebase--cherypick mode is added, and it replaces git-rebase--am and git-rebase--merge. Felipe Contreras (28): cherry-pick:

[PATCH v6 03/28] revert/cherry-pick: add --quiet option

Signed-off-by: Felipe Contreras --- Documentation/git-cherry-pick.txt | 6 +- Documentation/git-revert.txt | 6 +- builtin/revert.c | 1 + sequencer.c | 11 +++ sequencer.h | 1 + 5 files changed, 19 insertions(

[PATCH v6 04/28] revert/cherry-pick: add --skip option

Akin to 'am --skip' and 'rebase --skip'. Signed-off-by: Felipe Contreras --- Documentation/git-cherry-pick.txt | 1 + Documentation/git-revert.txt | 1 + Documentation/sequencer.txt | 3 +++ builtin/revert.c | 6 ++ sequencer.c | 24 +

[PATCH v6 01/28] cherry-pick: don't barf when there's nothing to do

Signed-off-by: Felipe Contreras --- sequencer.c | 2 +- t/t3510-cherry-pick-sequence.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sequencer.c b/sequencer.c index 351548f..a962b33 100644 --- a/sequencer.c +++ b/sequencer.c @@ -661,7 +661,7 @@ static

Re: [PATCH v2 1/5] replace: forbid replacing an object with one of a different type

From: Junio C Hamano > > Christian Couder writes: > >> But if all the objects that point to an object, called O, are to be >> replaced, then in most cases object O probably doesn't need to be >> replaced. It's probably sufficient to create the new object, called >> O2, that would replace object

Re: [PATCH] revision: add --except option

On Fri, Aug 30, 2013 at 12:00 AM, Felipe Contreras wrote: > So that it's possible to remove certain refs from the list without > removing the objects that are referenced by other refs. > > For example this repository: > > * 374e8dd (crap) crap > * 4cbbf7b (test) two > * d025ae0 (HEAD, master

Re: Officially start moving to the term 'staging area'

Drew Northup napisał: >I agree with Junio. This effort is better spent making the >documentation clearer and more succinct. The reality is that a user >needs to build a model in their mind of what they are doing which maps >enough (completely is not required) to what is actually going on to >get w

[PATCH] revision: add --except option

So that it's possible to remove certain refs from the list without removing the objects that are referenced by other refs. For example this repository: * 374e8dd (crap) crap * 4cbbf7b (test) two * d025ae0 (HEAD, master) one When using '--branches --except crap': * 4cbbf7b (test) two *

Re: [PATCH] has_sha1_file: re-check pack directory before giving up

On Thu, Aug 29, 2013 at 09:10:52PM -0400, Jeff King wrote: > In the case of git-fsck, which uses the > DO_FOR_EACH_INCLUDE_BROKEN flag, this will cause us to > erroneously complain that the ref points to an invalid > object. But for git-repack, which does not use that flag, we > will skip the ref

Re: [PATCH] has_sha1_file: re-check pack directory before giving up

On Thu, Aug 29, 2013 at 09:17:57PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > When we read a sha1 file, we first look for a packed > > version, then a loose version, and then re-check the pack > > directory again before concluding that we cannot find it. > > This lets us handle a pro

Re: [PATCH] has_sha1_file: re-check pack directory before giving up

Jeff King writes: > When we read a sha1 file, we first look for a packed > version, then a loose version, and then re-check the pack > directory again before concluding that we cannot find it. > This lets us handle a process that is writing to the > repository simultaneously (e.g., receive-pack w

Re: [PATCH] check-ignore: Add option to ignore index contents

Duy Nguyen writes: > On Fri, Aug 30, 2013 at 5:46 AM, Dave Williams > wrote: >> check-ignore currently shows how .gitignore rules would treat untracked >> paths. Tracked paths do not generate useful output. This prevents >> debugging of why a path became tracked unexpectedly unless that path is

наиполезнейший треннинг для глаз

Вы сможете располагать прекрасным зрением http://salmn.me/554439 -- 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

Re: [PATCH] has_sha1_file: re-check pack directory before giving up

On Thu, Aug 29, 2013 at 9:10 PM, Jeff King wrote: > When we read a sha1 file, we first look for a packed > version, then a loose version, and then re-check the pack > directory again before concluding that we cannot find it. > This lets us handle a process that is writing to the > repository simul

[PATCH] has_sha1_file: re-check pack directory before giving up

When we read a sha1 file, we first look for a packed version, then a loose version, and then re-check the pack directory again before concluding that we cannot find it. This lets us handle a process that is writing to the repository simultaneously (e.g., receive-pack writing a new pack followed by

Re: [PATCH] check-ignore: Add option to ignore index contents

Dave Williams writes: > check-ignore currently shows how .gitignore rules would treat untracked > paths. Tracked paths do not generate useful output. This prevents > debugging of why a path became tracked unexpectedly unless that path is > first removed from the index with git rm --cached > > T

Re: [PATCH] check-ignore: Add option to ignore index contents

On Fri, Aug 30, 2013 at 5:46 AM, Dave Williams wrote: > check-ignore currently shows how .gitignore rules would treat untracked > paths. Tracked paths do not generate useful output. This prevents > debugging of why a path became tracked unexpectedly unless that path is > first removed from the in

Re: [PATCH] check-ignore: Add option to ignore index contents

On Thu, Aug 29, 2013 at 11:46:52PM +0100, Dave Williams wrote: > check-ignore currently shows how .gitignore rules would treat untracked > paths. Tracked paths do not generate useful output. This prevents > debugging of why a path became tracked unexpectedly unless that path is > first removed fro

[PATCH] check-ignore: Add option to ignore index contents

check-ignore currently shows how .gitignore rules would treat untracked paths. Tracked paths do not generate useful output. This prevents debugging of why a path became tracked unexpectedly unless that path is first removed from the index with git rm --cached This option (-i, --ignore-index) sim

Re: [PATCH v3] remote-hg: support for notes

Felipe Contreras writes: > Keep track of Mercurial revisions as Git notes under the 'refs/notes/hg' > ref, this way, the user can easily see which Mercurial revision > correspond to certain Git commit. > > Unfortunately, there's no way to efficiently update the notes after > doing an export (push

Re: git-p4 out of memory for very large repository

cmt...@gmail.com wrote on Wed, 28 Aug 2013 11:41 -0400: > On Mon, Aug 26, 2013 at 09:47:56AM -0400, Corey Thompson wrote: > > You are correct that git-fast-import is killed by the OOM killer, but I > > was unclear about which process was malloc()ing so much memory that the > > OOM killer got invoke

Re: Stalled git cloning and possible solutions

On Friday, August 30, 2013 03:48:44 AM you wrote: > "V.Krishn" writes: > > On Friday, August 30, 2013 02:40:34 AM you wrote: > >> V.Krishn wrote: > >> > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c > >> > cleans what been downloaded, and process needs re-start. > >> > > >> > I

Re: [PATCH v2] git-p4: Ask "p4" to interpret View setting

ksaitoh...@gmail.com wrote on Tue, 27 Aug 2013 11:43 +0900: > > Do you have an updated patch? Want to take some time to clean up and > > resubmit the entire series? The batching should be incorporated with > > the last 2/2 that I sent out. > > I don't have other update. > I'm satisfied because a

[PATCH v3] remote-hg: support for notes

Keep track of Mercurial revisions as Git notes under the 'refs/notes/hg' ref, this way, the user can easily see which Mercurial revision correspond to certain Git commit. Unfortunately, there's no way to efficiently update the notes after doing an export (push), so they'll have to be updated when

Re: Stalled git cloning and possible solutions

"V.Krishn" writes: > On Friday, August 30, 2013 02:40:34 AM you wrote: >> V.Krishn wrote: >> > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c cleans >> > what been downloaded, and process needs re-start. >> > >> > Is there a way to recover or continue from already downloaded fi

Re: [PATCH] remote-hg: support for notes

Felipe Contreras writes: > Signed-off-by: Felipe Contreras > --- I somehow find this way under-explained to be useful for its users. Is it clear what "support for notes" means in the context of remote-hg? Do we send data stored in our notes when we push back to Hg? Does Hg have a mechanism t

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote: > On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> It has been discussed many times in the past that 'index' is not an >>> appropriate description for what the high-level user does with it, and >>> it h

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> It has been discussed many times in the past that 'index' is not an >> appropriate description for what the high-level user does with it, and >> it has been agreed that 'staging area' is the best term. > > "add

[PATCH] remote-hg: support for notes

Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-hg | 32 +++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 307d82c..e49fcfa 100755 --- a/contrib/re

Re: Stalled git cloning and possible solutions

On Friday, August 30, 2013 02:40:34 AM you wrote: > V.Krishn wrote: > > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c cleans > > what been downloaded, and process needs re-start. > > > > Is there a way to recover or continue from already downloaded files > > during cloning ? >

Re: Re* [PATCH 1/8] remote-bzr: fix export of utf-8 authors

Junio C Hamano writes: >> May I ask what pattern you used to replace all these or if you went >> through manually ? > > "M-x query-replace" from "> " to ">" with manual inspection. I never > use full automation myself, as I do not trust that I am careful > enough and it is prone to unexpected cha

Re: Re* [PATCH 1/8] remote-bzr: fix export of utf-8 authors

Antoine Pelisse writes: > On Thu, Aug 29, 2013 at 11:24 PM, Junio C Hamano wrote: >> -- >8 -- >> Subject: [PATCH 9/8] contrib/remote-helpers: style updates for test scripts >> >> During the review of the main series it was noticed that these test >> scripts can use updates to conform to our codi

Re: Re* [PATCH 1/8] remote-bzr: fix export of utf-8 authors

On Thu, Aug 29, 2013 at 11:24 PM, Junio C Hamano wrote: > -- >8 -- > Subject: [PATCH 9/8] contrib/remote-helpers: style updates for test scripts > > During the review of the main series it was noticed that these test > scripts can use updates to conform to our coding style better, but > fixing the

Re: Re* [PATCH 1/8] remote-bzr: fix export of utf-8 authors

Junio C Hamano writes: > Actually, I think not fixing it inside that 1/8 is good, as there > are many existing "cmd > file" (and worse, "cmd > file-$x") in these > test-*.sh scripts. Clean-up is better done as a follow-up patch. > > Here are two that I noticed. > > -- >8 -- > Subject: [PATCH 9/8

Re* [PATCH 1/8] remote-bzr: fix export of utf-8 authors

Junio C Hamano writes: > Matthieu Moy writes: > >> Do I really need to quote the paragraph in CodingGuidelines? > > Existing violations are not an excuse to make things worse by adding > more. I think with these comments we can expect a reroll coming, > and it should be trivial for any contribu

Re: [PATCH v3 3/4] get rid of "git submodule summary --for-status"

Jens Lehmann writes: > Am 29.08.2013 15:05, schrieb Matthieu Moy: >> The --for-status option was an undocumented option used only by >> wt-status.c, which inserted a header and commented out the output. We can >> achieve the same result within wt-status.c, without polluting the >> submodule comma

Re: Stalled git cloning and possible solutions

V.Krishn wrote: > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c cleans what > been downloaded, and process needs re-start. > > Is there a way to recover or continue from already downloaded files during > cloning ? No, sadly. The pack sent for a clone is generated dynamically

Re: [PATCH v3 3/4] get rid of "git submodule summary --for-status"

Junio C Hamano writes: > Matthieu Moy writes: > >> +/* prepend header, only if there's an actual output */ >> +if (len) { >> +if (uncommitted) >> +strbuf_addstr(&summary, _("Submodules changed but not >> updated:")); >> +else >> +

Re: Officially start moving to the term 'staging area'

Felipe Contreras writes: > Matthieu Moy wrote: > >> --work alone sounds weird. At least to me, it does not immediately imply >> "working tree". It is tempting to call the option --work-tree, but git >> already has a global option with that name (git --work-tree=foo bar). > > Yes, --work sounds we

Re: [PATCH 1/2] repack: rewrite the shell script in C

On Thu, Aug 29, 2013 at 3:39 PM, Stefan Beller wrote: > The motivation of this patch is to get closer to a goal of being > able to have a core subset of git functionality built in to git. > That would mean > > * people on Windows could get a copy of at least the core parts >of Git without hav

Re: [PATCHv7 0/2] Rewriting repack in C

Stefan Beller writes: > Here is a diff since the last time sending this patch series: This is very readable. There may be people who misread "LOOSE" as "LOSE"; the option -A is about making the unreachable ones loose so that they can be expired, so let's rename it LOOSEN_UNREACHABLE to avoid c

[PATCH 2/2] repack: retain the return value of pack-objects

During the review process of the previous commit (repack: rewrite the shell script in C), Johannes Sixt proposed to retain any exit codes from the sub-process, which makes it probably more obvious in case of failure. As the commit before should behave as close to the original shell script, the pro

[PATCHv7 0/2] Rewriting repack in C

Hi, I am sorry to have been delaying this patch series for a few days, as I was busy. I'll continue to be busy for the next 2 weeks, so my replies (if needed), will take some time. The first patch rewrites the repack shell script in C and tries to resemble the functionality as close to the origin

[PATCH 1/2] repack: rewrite the shell script in C

The motivation of this patch is to get closer to a goal of being able to have a core subset of git functionality built in to git. That would mean * people on Windows could get a copy of at least the core parts of Git without having to install a Unix-style shell * people using git in on serve

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote: > Am 29.08.2013 20:57, schrieb Felipe Contreras: >> >> Matthieu Moy wrote: >> >>> Felipe Contreras writes: Moreover, the --stage and --work >>> >>> >>> --work alone sounds weird. At least to me, it does not immediately imply >>> "work

Re: Officially start moving to the term 'staging area'

Am 29.08.2013 20:57, schrieb Felipe Contreras: Matthieu Moy wrote: Felipe Contreras writes: Moreover, the --stage and --work --work alone sounds weird. At least to me, it does not immediately imply "working tree". It is tempting to call the option --work-tree, but git already has a global op

Stalled git cloning and possible solutions

Hi, Quite sometimes when cloning a large repo stalls, hitting Ctrl+c cleans what been downloaded, and process needs re-start. Is there a way to recover or continue from already downloaded files during cloning ? Please point me to an archive url if solution exists. (though I continue to search

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 1:37 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> It has been discussed many times in the past that 'index' is not an >> appropriate description for what the high-level user does with it, and >> it has been agreed that 'staging area' is the best term. > > "add

Re: [PATCH v3 3/4] get rid of "git submodule summary --for-status"

Matthieu Moy writes: > + /* prepend header, only if there's an actual output */ > + if (len) { > + if (uncommitted) > + strbuf_addstr(&summary, _("Submodules changed but not > updated:")); > + else > + strbuf_addstr(&summary

Re: [PATCH v3 3/4] get rid of "git submodule summary --for-status"

Am 29.08.2013 15:05, schrieb Matthieu Moy: > The --for-status option was an undocumented option used only by > wt-status.c, which inserted a header and commented out the output. We can > achieve the same result within wt-status.c, without polluting the > submodule command-line options. > > This wi

Re: [PATCH/RFC 6/7] refs: add update_refs for multiple simultaneous updates

On 08/29/2013 02:20 PM, Brad King wrote: > I wasn't happy with the asymmetry either but forgot to raise it in > the cover letter. We need a way to represent "old value not given" > as different from "old value is_null_sha1". [snip] > Another approach is to add a dedicated member to struct ref_upda

Re: [PATCH 0/9] transport-helper: updates

On Thu, Aug 29, 2013 at 2:22 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Some of these were were sent before and rejected without a >> reason,... > > Earlier, you were asked to leave because many constructive criticism > or suggestion for improvement to your patches in reviews led t

Re: [PATCH 0/9] transport-helper: updates

Felipe Contreras writes: > Some of these were were sent before and rejected without a > reason,... Earlier, you were asked to leave because many constructive criticism or suggestion for improvement to your patches in reviews led to stubborn resistance, ended up wasting everybody's time and left

Re: Officially start moving to the term 'staging area'

Felipe Contreras writes: > add an explanation in Documentation/gitstagingarea.txt > or something. There's Documentation/gitcli.txt, that will need updating anyway (at the bottom, it talks about --cached and --index). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this

Re: Officially start moving to the term 'staging area'

Felipe Contreras writes: > Matthieu Moy wrote: >> These explanations make sense. I think it would be better to put part of >> it in commit messages, so that future contributors can "git blame" the >> doc/implem of these --stage and find them (i.e. avoid the >> misunderstanding that occured with "

Re: [PATCH 2/4] transport-helper: add dont-update-private capability

On Thu, Aug 29, 2013 at 1:58 PM, Matthieu Moy wrote: > Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update > remote helper namespace), a 'push' operation on a remote helper updates > the private ref by default. This is often a good thing, but it can also > be desirable to dis

Re: Officially start moving to the term 'staging area'

Matthieu Moy wrote: > Felipe Contreras writes: > > > It has been discussed many times in the past that 'index' is not an > > appropriate description for what the high-level user does with it, and > > it has been agreed that 'staging area' is the best term. > > Thanks for working on this. No time

Re: [PATCH 4/4] git-remote-mediawiki: no need to update private ref in non-dumb push

Matthieu Moy writes: > We used to update the private ref ourselves, but this update is now done > by default (since 664059fb62). > > Signed-off-by: Matthieu Moy > --- Thanks; will queue all four. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to major

Re: [PATCH 3/4] git-remote-mediawiki: use dont-update-private capability on dumb push

Matthieu Moy writes: > Signed-off-by: Matthieu Moy > --- > > I prefer not to bother with compatibility of git-remote-mediawiki with > older Git versions. The recommanded way is to install Git and > git-remote-mediawiki from the same source tree. People who want to > keep an old Git version can s

[PATCH 1/4] git-remote-mediawiki: add test and check Makefile targets

There are a few level 4 and 2 perlcritic issues in the current code. We make level 5 fatal, and keep level 2 as warnings. Signed-off-by: Matthieu Moy --- contrib/mw-to-git/Makefile | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/contrib/mw-to-git/Makefile b/contrib/

[PATCH 4/4] git-remote-mediawiki: no need to update private ref in non-dumb push

We used to update the private ref ourselves, but this update is now done by default (since 664059fb62). Signed-off-by: Matthieu Moy --- contrib/mw-to-git/git-remote-mediawiki.perl | 1 - 1 file changed, 1 deletion(-) diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl b/contrib/mw-to-git/

[PATCH 2/4] transport-helper: add dont-update-private capability

Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update remote helper namespace), a 'push' operation on a remote helper updates the private ref by default. This is often a good thing, but it can also be desirable to disable this update to force the next 'pull' to re-import the pus

[PATCH 3/4] git-remote-mediawiki: use dont-update-private capability on dumb push

Signed-off-by: Matthieu Moy --- I prefer not to bother with compatibility of git-remote-mediawiki with older Git versions. The recommanded way is to install Git and git-remote-mediawiki from the same source tree. People who want to keep an old Git version can still use old versions of git-remote-

Re: [PATCH 1/2] Add proper 'stage' command

Matthieu Moy wrote: > Felipe Contreras writes: > > > +COMMANDS > > + > > + > > +With no arguments, it's a synonym for linkgit:git-add[1]. > > This would not be very useful since "git add" errors out when called > without arguments ;-). Right. > The accurate description of your code wou

Re: Officially start moving to the term 'staging area'

Felipe Contreras writes: > It has been discussed many times in the past that 'index' is not an > appropriate description for what the high-level user does with it, and > it has been agreed that 'staging area' is the best term. Thanks for working on this. No time for a really detailed review, but

Re: [PATCH 2/2] stage: add edit command

Matthieu Moy wrote: > Felipe Contreras writes: > > > +'edit':: > > + > > +Manually edit the staging area (as a diff). > > + > > That sounds interesting. It reminds me "git add --edit", but they are > different ('stage edit' edits the patch with HEAD, 'add --edit' edits > the patch with the workt

Re: [PATCH 8/8] remote-hg: support for notes

Felipe Contreras writes: > @@ -629,6 +657,7 @@ def do_import(parser): > print "feature import-marks=%s" % path > print "feature export-marks=%s" % path > print "feature force" > +print "feature notes" The remaining patches in the series seem reasonable, but this patch seem

Re: [PATCH/RFC 7/7] update-ref: support multiple simultaneous updates

On 08/29/2013 02:34 PM, Junio C Hamano wrote: > Brad King writes: > >> +const char *c, *s, *oldvalue, *value[2] = {0,0}; > > This patch has many style issues of the same kind, lack of a SP at > places where there should be between operators and after comma. Okay, I can fix those. However,

Re: [PATCH/RFC 6/7] refs: add update_refs for multiple simultaneous updates

On 08/29/2013 02:32 PM, Junio C Hamano wrote: > But it may not be a bad idea to keep the callers dumb and have this > function always sort, dedup, *and* fail inconsistent request. I agree. I was just starting to write the comment for update_refs and it basically would have said "always use ref_up

Re: [PATCH 4/9] stash: add --stage option to save

Felipe Contreras writes: > +index are left intact. Same with `--no-stage`, which is a snynonym. s/snynonym/synonym/ -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majo

Re: [PATCH 1/2] Add proper 'stage' command

Felipe Contreras writes: > +COMMANDS > + > + > +With no arguments, it's a synonym for linkgit:git-add[1]. This would not be very useful since "git add" errors out when called without arguments ;-). The accurate description of your code would be closer to "When the first argument is not

Re: Officially start moving to the term 'staging area'

Felipe Contreras writes: > It has been discussed many times in the past that 'index' is not an > appropriate description for what the high-level user does with it, and > it has been agreed that 'staging area' is the best term. "add" is the verb, not "index" (which is a noun that refers to the th

Re: [PATCH 2/2] stage: add edit command

Felipe Contreras writes: > +'edit':: > + > +Manually edit the staging area (as a diff). > + That sounds interesting. It reminds me "git add --edit", but they are different ('stage edit' edits the patch with HEAD, 'add --edit' edits the patch with the worktree). Can we find a consistent user-int

  1   2   >