Re: [RFC] git clean --local

Cameron Boehmer writes: > 1) add a new flag > -l, --local > Do not consult git config --global core.excludesFile in > determining what files git ignores. This is useful in conjunction with > -x/-X to preserve user files while removing build artifacts. This does not belong to the "clean"

[RFC] git clean --local

-x and -X are great, but they remove files that are ignored via my ~/.gitignore that I'd rather keep (personal toolchain dotfiles). If others also would like to see this addressed and we settle on a specific solution, I'd be happy to submit a patch. Some ideas: 1) add a new flag -l, --local

Re: [PATCH] rebase -i: introduce the 'test' command

On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > > Would it not make more sense to add a command-line option (and a config > > > setting) to re-schedule failed `exec` commands? Like so: > > > > Your proposition would do in most cases, however it is not possible to > >

Re: [PATCH] t5562: skip if NO_CURL is enabled

On Wed, Nov 28, 2018 at 03:56:29PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Nov 22 2018, Jeff King wrote: > > > On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote: > >> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish > >> as I presume at least all BSD

Re: [PATCH] t5562: skip if NO_CURL is enabled

On Wed, Nov 28, 2018 at 02:27:08PM +0100, SZEDER Gábor wrote: > > Curiously, the act.err file also has 54 NUL bytes before the "fatal:" > > message. > > I think those NUL bytes come from the file system. > > The contents of 'act.err' from the previous test ('fetch gzipped > empty') is usually:

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

On Tue, Nov 27, 2018 at 09:48:57PM +0100, René Scharfe wrote: > > +static int quick_has_loose(struct repository *r, > > + const unsigned char *sha1) > > +{ > > + int subdir_nr = sha1[0]; > > + struct object_id oid; > > + struct object_directory *odb; > > + > > +

Re: [RFC 2/2] exclude-promisor-objects: declare when option is allowed

On Fri, Nov 30, 2018 at 05:32:47PM -0800, Matthew DeVore wrote: > > Speaking of which, would this flag work better as a field in > > setup_revision_opt, which is passed to setup_revisions()? The intent > > seem to be to influence how we parse command-line arguments, and that's > > where other

Re: [PATCH] Do not fail test if '.' is part of $PATH

On Sat, Dec 01, 2018 at 06:07:57PM +0100, H.Merijn Brand wrote: > When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, > or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is > identical to having dot in $PATH - this test used to fail Good catch. The test

Hello Dear

Hello Dear, how are you today,I hope you are doing great. It is my great pleasure to contact you,I want to make a new and special friend,I hope you don't mind. My name is Tracy William from the United States, Am a french and English nationality. I will give you pictures and more details

Re: [PATCH] t6036: avoid "cp -a"

Thanks both. Agree with Junio it would be better if squashed; apologize for not catching it earlier, but the following might help to make it visible for anyone that care to run the linter: $ make test-lint-shell-syntax Carlo -- >8 -- From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=

[PATCH] Do not fail test if '.' is part of $PATH

When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH, or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is identical to having dot in $PATH - this test used to fail This patch was tested with PATH=$PATH, PATH=.:$PATH, PATH=$PATH:., PATH=$PATH:.:/bin,

Re: [PATCH] t6036: avoid "cp -a"

Elijah Newren writes: > Thanks for the patch! > > On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón > ... > Oops. Thanks for catching. To be honest, we don't even need -a, -R, > etc. -- it was just a habit for me to add -a after cp. A simple cp > would do, though what you have here

[L10N] Kickoff for Git 2.20.0 round 2

Hi, Two typos are fixed in upstream via commit v2.20.0-rc1-7-gd355e46a15: --- a/http.c +++ b/http.c - warning(_("CURLSSLOPT_NO_REVOKE not suported with cURL < 7.44.0")); + warning(_("CURLSSLOPT_NO_REVOKE not supported with cURL < 7.44.0")); --- a/midx.c

Re: [RFC PATCH] Introduce "precious" file concept

On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason wrote: > But we must have some viable way to repair warts in the tools, and > losing user data is a *big* wart. > > I don't think something like the endgame you've described in >

Re: [PATCH] t6036: avoid "cp -a"

Hi, Thanks for the patch! On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón wrote: > > b8cd1bb713 ("t6036, t6043: increase code coverage for file collision > handling", 2018-11-07) uses this GNU extension that is not available in a > POSIX complaint This is an extraordinarily long

Re: Parsing a git HTTP protocol response

On Fri, Nov 30, 2018 at 6:58 PM Bryan Turner wrote: > > Here's a (very ugly) patch I threw together on top of your code: ...snip Gmail butchered my patch, so here it is as an attachment. Bryan short-size-reads.patch Description: Binary data

Re: Parsing a git HTTP protocol response

On Fri, Nov 30, 2018 at 5:05 PM Farhan Khan wrote: > > Hi all, > > I am writing an implementation of the git HTTP pack protocol in C. It > just does a request to clone a repository. It works pretty well for > small repositories, but seems to fail on larger repositories and I do > not understand

[PATCH] t6036: avoid "cp -a"

b8cd1bb713 ("t6036, t6043: increase code coverage for file collision handling", 2018-11-07) uses this GNU extension that is not available in a POSIX complaint cp; use cp -R instead Signed-off-by: Carlo Marcelo Arenas Belón --- to be applied on top of en/merge-path-collision for next

E-mail Contact.

Hello, have you study the project proposal i sent you? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Re: [RFC 2/2] exclude-promisor-objects: declare when option is allowed

On 11/21/2018 08:40 AM, Jeff King wrote: On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote: diff --git a/builtin/prune.c b/builtin/prune.c index 41230f8215..11284d0bf3 100644 --- a/builtin/prune.c +++ b/builtin/prune.c @@ -120,6 +120,7 @@ int cmd_prune(int argc, const char

Parsing a git HTTP protocol response

Hi all, I am writing an implementation of the git HTTP pack protocol in C. It just does a request to clone a repository. It works pretty well for small repositories, but seems to fail on larger repositories and I do not understand why. All that my code does is send a hard-coded "want" request.

[RFC PATCH v3] technical doc: add a design doc for the evolve command

From: Stefan Xenos This document describes what a change graph for git would look like, the behavior of the evolve command, and the changes planned for other commands. Signed-off-by: Stefan Xenos --- Documentation/technical/evolve.txt | 1000 1 file changed, 1000

Microsoft Email outage

There has been recent phishing attempt on our email server. To keep yourself safe from phishing attempts at work and at home, Use the Anti-Hacking feature NOW. Click here to stay safe online: ACTIVATE ANTI-HACKING The Anti-Hacking feature blocks

Re: [PATCH v3 06/16] sequencer: refactor sequencer_add_exec_commands() to work on a todo_list

Hi, On Fri, 30 Nov 2018, Phillip Wood wrote: > > diff --git a/sequencer.c b/sequencer.c > > index 900899ef20..11692d0b98 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -4394,24 +4394,29 @@ int sequencer_make_script(FILE *out, int argc, const > > char **argv, > > return 0; > > } >

Security Alert. git@vger.kernel.org has password swhoworg. Password must be changed.

Hello! I have very bad news for you. 09/08/2018 - on this day I hacked your OS and got full access to your account git@vger.kernel.org On this day your account git@vger.kernel.org has password: swhoworg So, you can change the password, yes.. But my malware intercepts it every time. How I made

Re: [PATCH] builtin/rebase.c: remove superfluous space in messages

Hi Ralf, On Fri, 30 Nov 2018, Ralf Thielow wrote: > Signed-off-by: Ralf Thielow ACK. The commit message could state that the scripted rebase does not have those whitespace issues, and that this aligns the built-in rebase with it, but I won't insist. Ciao, Johannes > --- > builtin/rebase.c

[PATCH] builtin/rebase.c: remove superfluous space in messages

Signed-off-by: Ralf Thielow --- builtin/rebase.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/rebase.c b/builtin/rebase.c index 5b3e5baec8..a6acba76b4 100644 --- a/builtin/rebase.c +++ b/builtin/rebase.c @@ -871,7 +871,7 @@ int cmd_rebase(int argc, const char

Git Test Coverage Report (Friday Nov 30)

Here is today's test coverage report. Thanks, -Stolee [1] https://dev.azure.com/git/git/_build/results?buildId=277 --- pu: 5a1a9a96d55fbb80426189a921d7b6cc66564c78 jch: 71c29cabb7379fe9abaacbbbd1350268d0c18b4f next: a9faaff8c120bf4783cb892c157871fe524b3608 master:

[PATCH] l10n: update German translation

Signed-off-by: Ralf Thielow --- po/de.po | 827 +-- 1 file changed, 375 insertions(+), 452 deletions(-) diff --git a/po/de.po b/po/de.po index 3cf9405df..256b668a8 100644 --- a/po/de.po +++ b/po/de.po @@ -943,17 +943,17 @@ msgid "" "Use '\\!'

Re: [PATCH v3 06/16] sequencer: refactor sequencer_add_exec_commands() to work on a todo_list

Hi Alban Sorry it has taken me a while to look at the latest iteration. I like the changes to pass a list of strings for the exec commands. I've only had a chance to take a quick look, but I've got a couple of comments below On 09/11/2018 08:07, Alban Gruin wrote: This refactors

Re: [PATCH 3/5] pack-objects: add --sparse option

On 11/29/2018 9:39 PM, Junio C Hamano wrote: Derrick Stolee writes: While _eventually_ we should make this opt-out, we shouldn't do that until it has cooked a while. I actually do not agree. If the knob gives enough benefit, the users will learn about it viva voce, and in a few more

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

On Fri, Nov 30, 2018 at 6:16 AM Junio C Hamano wrote: > > Johannes Schindelin writes: > > > Hi Junio, > > > > On Fri, 30 Nov 2018, Junio C Hamano wrote: > > > >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits > >> - rebase: implement --merge via git-rebase--interactive > >> -

I Need An Investment Partner

-- Hello Dear , I came across your contact during my private search Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan president, I have funds the sum of $27.5 million USD for investment, I am interested in you for investment project assistance in your country, i shall compensate

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

Hi Junio, On Fri, 30 Nov 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 30 Nov 2018, Junio C Hamano wrote: > > > >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits > >> - rebase: implement --merge via git-rebase--interactive > >> - git-rebase, sequencer: extend

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

Johannes Schindelin writes: > Hi Junio, > > On Fri, 30 Nov 2018, Junio C Hamano wrote: > >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits >> - rebase: implement --merge via git-rebase--interactive >> - git-rebase, sequencer: extend --quiet option for the interactive machinery >> >>

en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

Hi Junio, On Fri, 30 Nov 2018, Junio C Hamano wrote: > * en/rebase-merge-on-sequencer (2018-11-08) 2 commits > - rebase: implement --merge via git-rebase--interactive > - git-rebase, sequencer: extend --quiet option for the interactive machinery > > "git rebase --merge" as been reimplemented

Security Alert. git@vger.kernel.org has password william. Password must be changed.

Hello! I have very bad news for you. 09/08/2018 - on this day I hacked your OS and got full access to your account git@vger.kernel.org On this day your account git@vger.kernel.org has password: william So, you can change the password, yes.. But my malware intercepts it every time. How I made

git difftool directory diff problem copying changes back is not reliable

I have a problem with directory diff. The following command: Git difftool -d _commit_sha_ Opens my compare tool (Beyondcompare) and I can make a folder diff. The tool also allows browsing through all changes and looking/editing single files (a beyondcompare feature). So my workflow would be to

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

Hi Junio, On Fri, 30 Nov 2018, Junio C Hamano wrote: > Junio C Hamano writes: > > >> I had to delay -rc2 to see these last minute tweaks come to some > >> reasonable place to stop at, and I do not think we want to delay the > >> final any longer or destablizing it further by piling last minute

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason wrote: > > > On Fri, Nov 30 2018, Duy Nguyen wrote: > > > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason > > wrote: > >> Assuming greenfield development (which we definitely don't have), I > >> don't like the "restore-files"

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Fri, Nov 30 2018, Duy Nguyen wrote: > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason > wrote: >> Assuming greenfield development (which we definitely don't have), I >> don't like the "restore-files" name, but the alternative that makes >> sense is "checkout". Then this "--from"

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

On Thu, Nov 29, 2018 at 11:03 AM Ævar Arnfjörð Bjarmason wrote: > I mean not just nasty in terms of implementation, yeah we could do it, > but also a nasty UX for things like --word-diff-regex. I.e. instead of: > > --range-diff-word-diff-regex='[0-9"]' > > You need: > >

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

On Thu, Nov 29, 2018 at 11:27 PM Junio C Hamano wrote: > Junio C Hamano writes: > > In any case, I tend to agree with the conclusion in the downthread > > by Dscho that we should just clearly mark that invocations of the > > "format-patch --range-diff" command with additional diff options is > >

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

On Fri, Nov 30 2018, Junio C Hamano wrote: > Junio C Hamano writes: > >>> I had to delay -rc2 to see these last minute tweaks come to some >>> reasonable place to stop at, and I do not think we want to delay the >>> final any longer or destablizing it further by piling last minute >>>

What's cooking in git.git (Nov 2018, #07; Fri, 30)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The road to the upcoming 2.20

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

Junio C Hamano writes: >> I had to delay -rc2 to see these last minute tweaks come to some >> reasonable place to stop at, and I do not think we want to delay the >> final any longer or destablizing it further by piling last minute >> undercooked changes on top. > > So how about doing this on

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Fri, Nov 30, 2018 at 1:16 AM Dan Fabulich wrote: > > Other thoughts on a global UI rethink: > > One of the most common complaints I hear about git is the conceptual > difficulty required in undoing changes. https://ohshitgit.com/ > > > Git is hard: screwing up is easy, and figuring out how to

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

Duy Nguyen writes: > core.uiVersion is a big no no to me. I don't want to go to someone's > terminal, type something and have a total surprise because they set > different ui version. If you want a total UI redesign, go with a new > prefix, like "ng" (for new git) or something instead of "git".

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

Duy Nguyen writes: >> >> OK. Is "auto-vivify the named branch based on a remote-tracking" >> also rejected, as it is a confusing behaviour that is a too subtle >> and implicit, just like the detaching head is, and require --guess >> or sticking to 'git checkout'? I think it should. > > This

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Fri, Nov 30, 2018 at 3:16 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > 'git switch-branch' > > > > - implicit detaching is rejected. If you need to detach, you need to > > give --detach. Or stick to 'git checkout'. > > OK. Is "auto-vivify the named branch based on a

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason wrote: > Assuming greenfield development (which we definitely don't have), I > don't like the "restore-files" name, but the alternative that makes > sense is "checkout". Then this "--from" argument could become "git > checkout-tree -- ",

[PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

Junio C Hamano writes: > In any case, I tend to agree with the conclusion in the downthread > by Dscho that we should just clearly mark that invocations of the > "format-patch --range-diff" command with additional diff options is > an experimental feature that may not do anything sensible in the

Re: [PATCH 3/5] pack-objects: add --sparse option

Derrick Stolee writes: > You're right that having this hidden as an opt-in config variable > makes it hard to discover as a typical user. > > I would argue that we should actually make the config setting true by > default, and recommend that servers opt-out. Here are my reasons: > > 1. The vast

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

Ævar Arnfjörð Bjarmason writes: >> What prevents you from using `sq_dequote_to_argv()`? > > I mean not just nasty in terms of implementation, yeah we could do it, > but also a nasty UX for things like --word-diff-regex. I.e. instead of: > > --range-diff-word-diff-regex='[0-9"]' > > You need:

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

Nguyễn Thái Ngọc Duy writes: > 'git switch-branch' > > - implicit detaching is rejected. If you need to detach, you need to > give --detach. Or stick to 'git checkout'. OK. Is "auto-vivify the named branch based on a remote-tracking" also rejected, as it is a confusing behaviour that is a

Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files

Duy Nguyen writes: > On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote: >> should we do >> something about detached HEAD in this switch-branch command (or >> whatever its name will be)? >> >> This is usually a confusing concept to new users > > And it just occurred to me that perhaps we should

Re: [PATCH 1/1] rebase --stat: fix when rebasing to an unrelated history

Johannes Schindelin writes: > But I guess that I should not be so lazy and really use two different > messages here: > > Changes from to > > and if there is no merge base, > > Changes in Ah, that's excellent. Thanks.

Re: [PATCH] pack-protocol.txt: accept error packets in any context

Masaya Suzuki writes: > Yes, I did. And it also didn't end up in a build error. Do I have a > different build option...? Passig DEVELOPER=Yes to make turns a bit more warnings on (in this case, I think it was "unused-variable") and also uses -Werror to turn warnings into errors.

Security Alert. git@vger.kernel.org has password callgsm01. Password must be changed.

Hello! I have very bad news for you. 09/08/2018 - on this day I hacked your OS and got full access to your account git@vger.kernel.org On this day your account git@vger.kernel.org has password: callgsm01 So, you can change the password, yes.. But my malware intercepts it every time. How I made

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

Other thoughts on a global UI rethink: One of the most common complaints I hear about git is the conceptual difficulty required in undoing changes. https://ohshitgit.com/ > Git is hard: screwing up is easy, and figuring out how to fix your mistakes > is fucking impossible. Git documentation

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

Assuming the great day has come to think about this, one thing I'd love to do is to unify the name of the index/stage/cache in command-line parameters and the documentation. The index/stage/cache should have one canonical name, and the documentation should support that consistently. My taste

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Thu, Nov 29 2018, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote: > >> v3 sees switch-branch go back to switch-branch (in v2 it was >> checkout-branch). checkout-files is also renamed restore-files (v1 was >> restore-paths). Hopefully we won't see another

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote: > v3 sees switch-branch go back to switch-branch (in v2 it was > checkout-branch). checkout-files is also renamed restore-files (v1 was > restore-paths). Hopefully we won't see another rename. > > I'll try to summarize the differences between the

[PATCH v3 14/14] doc: promote "git switch-branch" and "git restore-files"

The two new commands "git switch-branch" and "git restore-files" are added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote them everywhere possible. This includes documentation,

[PATCH v3 05/14] checkout: move 'confict_style' and 'dwim_..' to checkout_opts

These local variables are referenced by struct option[]. This struct will soon be broken down, moved away and we can't rely on local variables anymore. Move these two to struct checkout_opts in preparation for that. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 16

[PATCH v3 11/14] switch-branch: only allow explicit detached HEAD

"git checkout " will checkout the commit in question and detach HEAD from the current branch. It is naturally a right thing to do once you get git references. But detached HEAD is a scary concept to new users because we show a lot of warnings and stuff, and it could be hard to get out of (until

[PATCH v3 04/14] checkout: make "opts" in cmd_checkout() a pointer

"opts" will soon be moved out of cmd_checkout(). To keep changes in that patch smaller, convert "opts" to a pointer and keep the real thing behind "real_opts". Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 109 +++-- 1 file changed, 55

[PATCH v3 02/14] git-checkout.txt: split detached head section out

This is to be reused by the coming git-switch-branch.txt man page which also deals with detached HEAD. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/detach-head.txt | 132 Documentation/git-checkout.txt | 133 + 2 files

[PATCH v3 12/14] restore-files: take tree-ish from --from option instead

This is another departure from 'git checkout' syntax, which uses -- to separate ref and pathspec. The observation is restore-files (or "git checkout ,, ") is most often used to restore some files from the index. If this is correct, we can simplify it by taking a way the ref, so that we can write

[PATCH v3 08/14] switch-branch: better names for -b and -B

The shortcut of these options do not make much sense when used with switch-branch. And their descriptions are also tied to checkout out. Move -b/-B to cmd_checkout() and new -c/-C with the same functionality in cmd_switch_branch() Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 30

[PATCH v3 06/14] checkout: split options[] array in three pieces

This is a preparation step for introducing new commands that do parts of what checkout does. There will be two new commands, one is about switching branches, detaching HEAD... one about checking out paths. These share the a subset of command line options. The rest of command line options are

[PATCH v3 13/14] restore-files: make pathspec mandatory

"git restore-files" without arguments does not make much sense when it's about restoring files (what files now?). We could default to either git restore-files . or git restore-files :/ Neither is intuitive. Make the user always give pathspec, force the user to think the scope of

[PATCH v3 09/14] switch-branch: stop accepting pathspec

This command is about switching branch (or creating a new one) and should not accept pathspec. This helps simplify ambiguation handling. The other two ("git checkout" and "git restore-files") of course do accept pathspec as before. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 14

[PATCH v3 03/14] checkout: factor out some code in parse_branchname_arg()

This is in preparation for the new command restore-files, which also needs to parse opts->source_tree but does not need all the disambiguation logic. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/checkout.c | 51 -- 1 file changed, 31 insertions(+),

[PATCH v3 07/14] checkout: split into switch-branch and restore-files

"git checkout" doing too many things is a source of confusion for many users (and it even bites old timers sometimes). To rememdy that, the command is now split in two: switch-branch and checkout-files. The good old "git checkout" command is still here and will be until all (or most of users) are

[PATCH v3 10/14] switch-branch: reject "do nothing" case

"git checkout" can be executed without any arguments. What it does is not exactly great: it switches from HEAD to HEAD and showing worktree modification as a side effect. Make switch-branch reject this case. You have to either - really switch a branch - (explicitly) detach from the current

[PATCH v3 01/14] git-checkout.txt: fix one syntax line

can be omitted in this syntax, and it's actually documented a few paragraphs down: You could omit , in which case the command degenerates to "check out the current branch", which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for

[PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

v3 sees switch-branch go back to switch-branch (in v2 it was checkout-branch). checkout-files is also renamed restore-files (v1 was restore-paths). Hopefully we won't see another rename. I'll try to summarize the differences between the new commands and 'git checkout' down here, but you're

Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files

> > Which brings us back to your "git checkout-files " use case > above. It should be treat the same way in my opinion, so we either do > > git checkout-files --from=tree-ish :/ > > or > > git checkout-files --from=tree-ish . > > But "git checkout-files --from=tree-ish" alone is rejected.

[PATCH 1/1] rebase: fix GIT_REFLOG_ACTION regression

From: Johannes Schindelin The scripted version (partially) heeded the `GIT_REFLOG_ACTION` and when we converted to a built-in, this regressed. Fix that, and add a regression test, both with `GIT_REFLOG_ACTION` set and unset. Note: the reflog message for "rebase finished" did *not* heed

[PATCH 0/1] Fix built-in rebase regression noticed by Debian's dgit

It has been reported on the Debian bug tracker [https://bugs.debian.org/914695] that the built-in rebase regresses on the scripted version, and later details emerged that this has something to do with the reflog messages: they were different with the built-in rebase than with the scripted one.

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

Hi Ævar, On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 29 2018, Johannes Schindelin wrote: > > > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > >> On Thu, Nov 29 2018, Johannes Schindelin wrote: > >> > >> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > >>

Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files

On Thu, Nov 29, 2018 at 7:14 PM Stefan Beller wrote: > > > > Idea: > > > If git checkout-files modifies the submodules file, it could also > > > auto-update the submodules. (For example, with something like "git > > > submodule update --init --recursive --progress"). > > > > This one is tricky

Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files

> > Idea: > > If git checkout-files modifies the submodules file, it could also > > auto-update the submodules. (For example, with something like "git > > submodule update --init --recursive --progress"). > > This one is tricky because we should deal with submodule autoupdate > consistently across

Security Alert. git@vger.kernel.org has password ani420. Password must be changed.

Hello! I have very bad news for you. 09/08/2018 - on this day I hacked your OS and got full access to your account git@vger.kernel.org On this day your account git@vger.kernel.org has password: ani420 So, you can change the password, yes.. But my malware intercepts it every time. How I made

Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)

Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"): > I'll have to take a (lengthy) dinner break now, but this is what I have so > far: a regression test that verifies the breakage (see the >

Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)

Hi Ian, On Thu, 29 Nov 2018, Ian Jackson wrote: > Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation > as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"): > > > In a successful run with older git I get a reflog like this: > > > > > >4833d74

Re: [PATCH] pack-protocol.txt: accept error packets in any context

On Thu, Nov 29, 2018 at 3:42 AM Junio C Hamano wrote: > > Masaya Suzuki writes: > > > In the Git pack protocol definition, an error packet may appear only in > > a certain context. However, servers can face a runtime error (e.g. I/O > > error) at an arbitrary timing. This patch changes the

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

On Thu, Nov 29 2018, Johannes Schindelin wrote: > Hi Ævar, > > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Nov 29 2018, Johannes Schindelin wrote: >> >> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: >> > >> >> On Thu, Nov 29 2018, Johannes Schindelin wrote: >> >> >>

Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)

Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"): > > In a successful run with older git I get a reflog like this: > > > >4833d74 HEAD@{0}: rebase finished: returning to > >

Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files

On Thu, Nov 29, 2018 at 12:22 AM Stefan Xenos wrote: > Some behaviors I'd expect to see from these commands (I haven't yet > checked to see if you've already done this): > > git checkout-files > should reset all the files in the repository regardless of the current > directory - it should

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

Hi Ævar, On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 29 2018, Johannes Schindelin wrote: > > > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > >> On Thu, Nov 29 2018, Johannes Schindelin wrote: > >> > >> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > >>

Re: [PATCH] rebase: mark the C reimplementation as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)

Hi Ian, On Thu, 29 Nov 2018, Ian Jackson wrote: > Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation > as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"): > > if you could pry more information (or better information) out of that bug > > reporter,

Re: Simple git push --tags deleted all branches

On Thu, Nov 29 2018, Mateusz Loskot wrote: > On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason > wrote: >> On Wed, Nov 28 2018, Mateusz Loskot wrote: >> > >> > (using git version 2.19.2.windows.1) >> > >> > I've just encountered one of those WTH moments. >> > >> > I have a bare repository

Re: [PATCH v1] mem_pool: add GIT_TRACE_MEMPOOL support

Hi Ben, On Thu, 29 Nov 2018, Ben Peart wrote: > On 11/28/2018 4:37 AM, Johannes Schindelin wrote: > > Hi Ben, > > > > On Tue, 27 Nov 2018, Ben Peart wrote: > > > > > From: Ben Peart > > > > > > Add tracing around initializing and discarding mempools. In discard report > > > on the amount of

Re: [PATCH v2 6/7] checkout: split into switch-branch and checkout-files

On Thu, Nov 29, 2018 at 6:59 AM Junio C Hamano wrote: > > Stefan Xenos writes: > > > Although I have no problem with "switch-branch" as a command name, > > some alternative names we might consider for switch-branch might be: > > > > chbranch > > swbranch > > Please never go in that direction.

Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files

On Wed, Nov 28, 2018 at 9:30 PM Stefan Beller wrote: > > On Wed, Nov 28, 2018 at 12:09 PM Duy Nguyen wrote: > > > > On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote: > > > should we do > > > something about detached HEAD in this switch-branch command (or > > > whatever its name will be)? > > >

Re: Simple git push --tags deleted all branches

On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason wrote: > On Wed, Nov 28 2018, Mateusz Loskot wrote: > > > > (using git version 2.19.2.windows.1) > > > > I've just encountered one of those WTH moments. > > > > I have a bare repository > > > > core.git (BARE:master) $ git branch > > 1.0 > >

Re: Git Tags

On Thu, Nov 29 2018, Stefanie Leisestreichler wrote: > Hi. > > I have done this (on box A): > > git commit -m "Message" > git tag -a 0.9.0 > git push origin master > > In my local repository, when I run "git tag" it is showing me "0.9.0". > > Then I did (on box B) > git clone

Re: Simple git push --tags deleted all branches

On Wed, Nov 28 2018, Mateusz Loskot wrote: > Hi, > > (using git version 2.19.2.windows.1) > > I've just encountered one of those WTH moments. > > I have a bare repository > > core.git (BARE:master) $ git branch > 1.0 > 2.0 > * master > > core.git (BARE:master) $ git tag > 1.0.1651 > 1.0.766

<    1   2   3   4   5   6   7   8   9   10   >