Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day > > wrote: > > > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > > > On

Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > wrote: > > > > > > > > > from "man git-reset": > > > > > >

Re: why doesn't "git reset" mention optional pathspec?

On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > from "man git-reset": > > SYNOPSIS > git reset [-q] [] [--] ... > git reset (--patch | -p) [] [--] [...] > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > [] > > oddly, the third form says nothing about

Re: [PATCH] mailmap: update brandon williams's email address

On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote: > If this were "Jonathan asked Brandon if we want to record an address > we can reach him in our .mailmap file and sent a patch to add one", Not sure about Jonathan, but I did. > then the story is different, and I tend to agree with you that

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

On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote: > Personally, I would rather err on the side which requires the least > interaction from users to avoid silently clobbering an ignored file. > > Either Duy's solution with a sort of "untracked" reflog, or the > garbage/trashable notion. The

Re: git, monorepos, and access control

On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote: > This directory-level security is not a goal for VFS for Git, and I don't > see itbecoming a priority as it breaks a number of design decisions we > made in our object storage and communication models. > > The best I can think about when

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

On Tue, Dec 4, 2018 at 7:31 PM Elijah Newren wrote: > > On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen wrote: > > > > On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren wrote: > > > > > > - Two more fancy features (the "git checkout --index" being the

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

On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren wrote: > > > > - Two more fancy features (the "git checkout --index" being the > > > > default mode and the backup log for accidental overwrites) are of > > > > course still missing. But they are coming. > > > > > > > > I did not go replace

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

On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren wrote: > > > > +--ours:: > > > > +--theirs:: > > > > + Check out stage #2 ('ours') or #3 ('theirs') for unmerged > > > > + paths. > > > > ++ > > > > +Note that during `git rebase` and `git pull --rebase`, 'ours' and > > > > +'theirs' may

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

On Tue, Dec 4, 2018 at 2:29 AM Elijah Newren wrote: > > On Thu, Nov 29, 2018 at 2:01 PM 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

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

Thanks for all the comments! There are still some I haven't replied (either I'll agree and do it anyway, or I'll need some more time to digest) On Tue, Dec 4, 2018 at 1:45 AM Elijah Newren wrote: > > +'git restore-files' [--from=] ... > > Isn't this already inferred by the previous line? Or was

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

On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote: > I sometimes add "x false" to the top of the todo list to stop and create > new commits before the first one. And here I've been doing the same by "edit" the first commit, add a new commit then reorder them in the second interactive

Re: "git add -p" versus "git add -i", followed by "p"

On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > Patch update>> 2 > > staged unstaged path > > * 1:unchanged+1/-0 README.md > > * 2:unchanged+1/-0 contrib/README > > 3:unchanged+1/-0 t/README > > Patch update>> > > > >

Re: Confusing inconsistent option syntax

On Sun, Dec 2, 2018 at 11:13 AM Robert White wrote: > > `git log --pretty short` gives the error message "ambiguous argument > 'short'". To get the expected result, you need to use `git log > --pretty=short`. However, `git log --since yesterday` and `git log > --since=yesterday` both work as

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/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 > &g

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

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

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

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

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

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

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

On Tue, Nov 27, 2018 at 5:53 PM Nguyễn Thái Ngọc Duy wrote: > > v2 is just a bit better to look at than v1. This is by no means final. > If you think the command name is bad, the default behavior should > change, or something else, speak up. It's still very "RFC". > > v2 breaks down the giant

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

On Wed, Nov 28, 2018 at 8:08 PM Stefan Beller wrote: > > On Wed, Nov 28, 2018 at 7:31 AM Duy Nguyen wrote: > > > > On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano wrote: > > > > > > Nguyễn Thái Ngọc Duy writes: > > > > > > > The good o

Re: [PATCH v3 1/7] rebase: fix incompatible options error message

On Thu, Nov 22, 2018 at 7:32 PM Elijah Newren wrote: > > In commit f57696802c30 ("rebase: really just passthru the `git am` > options", 2018-11-14), the handling of `git am` options was simplified > dramatically (and an option parsing bug was fixed), but it introduced > a small regression in the

Re: [PATCH v2 7/7] Suggest other commands instead of "git checkout"

On Wed, Nov 28, 2018 at 7:04 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > The assumption made is here > > > > - "git checkout" is a horrible monster that should only be touched > > with a two-meter pole > > > > - there are other commands that can achieve the same thing > >

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

On Wed, Nov 28, 2018 at 7:03 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > The good old "git checkout" command is still here and will be until > > all (or most of users) are sick of it. > > Two comments on the goal (the implementation looked reasonable > assuming the reader

Re: [PATCH v2 1/7] parse-options: allow parse_options_concat(NULL, options)

On Tue, Nov 27, 2018 at 8:44 PM Stefan Beller wrote: > > On Tue, Nov 27, 2018 at 8:53 AM Nguyễn Thái Ngọc Duy > wrote: > > > > There is currently no caller that calls this function with "a" being > > NULL. But it will be introduced shortly. It is used to construct the > > option array from

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

On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote: > > On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg wrote: > > > > On 11/26/18 5:55 PM, Duy Nguyen wrote: > > > On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason > > > wrote: > > >> Some o

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 26, 2018 at 5:01 PM Ævar Arnfjörð Bjarmason wrote: > > So, what do you think? > > That "git checkout" does too many things is something that keeps coming > up in online discussions about Git's UI. Two things: > > a) It would really help to have some comparison of cases where these >

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

On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason wrote: > >> >> How about something like this: > >> >> > >> >> 1. Introduce a concept with "garbage" files, which git is "permitted to > >> >> delete" without prompting. > >> >> > >> >> 2. Retain the current default, i.e. "ignored files are

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

On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason wrote: > > > On Mon, Nov 26 2018, Duy Nguyen wrote: > > > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote: > >> > >> On 11/13/18 1:22 AM, brian m. carlson wrote: > >> > This is going to

Re: [RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 26, 2018 at 4:03 AM Junio C Hamano wrote: > > Thomas Gummerer writes: > > > I like the idea of splitting those commands up, in fact it is > > something I've been considering working on myself. I do think we > > should consider if we want to change the behaviour of those new > >

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

On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote: > > On 11/13/18 1:22 AM, brian m. carlson wrote: > > This is going to totally hose automation. My last job had files which > > might move from tracked to untracked (a file that had become generated), > > and long-running CI and build systems

Re: [PATCH] files-backend.c: fix build error on Solaris

On Sun, Nov 25, 2018 at 11:19 AM Carlo Arenas wrote: > > Signed-off-by: Carlo Marcelo Arenas Belón > > clang with -Wpedantic also catch this (at least with Apple LLVM > version 10.0.0); recent versions of gcc also include that flag and at > least 8.2.0 shows a warning for it, so it might be

Re: [PATCH] clone: fix colliding file detection on APFS

On Tue, Nov 20, 2018 at 8:35 PM Carlo Arenas wrote: > IMHO it would be ideal if test would be enabled/validated for windows > (native, not only cygwin) as it might even work without the override > and if we are to see conflicts, that is probably where most users with > file insensitive

[RFC] Introduce two new commands, switch-branch and restore-paths

On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote: > I promise to come back with something better (at least it still > sounds better in my mind). If that idea does not work out, we can > come back and see if we can improve this. So this is it. The patch isn't pretty, mostly a

Re: [PATCH 1/3] pack-objects: fix tree_depth and layer invariants

On Tue, Nov 20, 2018 at 11:04 AM Jeff King wrote: > > Commit 108f530385 (pack-objects: move tree_depth into 'struct > packing_data', 2018-08-16) dynamically manages a tree_depth array in > packing_data that maintains one of these invariants: > > 1. tree_depth is NULL (i.e., the requested

Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems

On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote: > Thanks Carlo for the file and "stat" output. The problem is APFS has > 64-bit inode (according to the Internet) while we store inodes as > 32-bit, so it's truncated. > ... > We will have to deal with the same > trunc

Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems

... and I "dear Ramsay" without CCing him.. sigh.. sorry for the noise. On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote: > > First of all, Ramsay, it would be great if you could test the below > patch and see if it works on Cygwin. I assume since Cygwin shares the >

Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems

e?). Back to the APFS problem... On Mon, Nov 19, 2018 at 07:24:26PM +0100, Duy Nguyen wrote: > Could you send me the "index" file in t/trash\ > directory.t5601-clone/icasefs/bogus/.git/index ? Also the output of > "stat /path/to/icase/bogus/x" > > My only e

Re: [PATCH v5] clone: report duplicate entries on case-insensitive filesystems

On Mon, Nov 19, 2018 at 6:14 PM Carlo Arenas wrote: > > On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote: > > > > Did you test it on Mac ? > > macOS 10.14.1 but only using APFS, did you test my patch with HFS+? > > > So what exactly are you trying to fix ? > > I get > > not ok 99 -

Re: [PATCH 5/5] tree-walk: support :(attr) matching

On Sun, Nov 18, 2018 at 8:58 PM Ævar Arnfjörð Bjarmason wrote: > > > On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote: > > As noted in > https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm > happy to see this implemented. I have not read this patch in much > detail... > > > [...]

Re: [PATCH 0/5] Make :(attr) pathspec work with "git log"

On Mon, Nov 19, 2018 at 12:42 PM Ævar Arnfjörð Bjarmason wrote: > > > On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote: > > > When :(attr) was added, it supported one of the two main pathspec > > matching functions, the one that works on a list of paths. The other > > one works on a tree,

Re: [PATCH 0/5] Make :(attr) pathspec work with "git log"

On Mon, Nov 19, 2018 at 12:16 PM Ævar Arnfjörð Bjarmason wrote: > As an aside, how do you do the inverse of matching for an attribute by > value? I.e.: > > $ git ls-files | wc -l; git ls-files ':(attr:diff=perl)' | wc -l > 3522 > 65 > > I'd like something gives me all files that don't

Re: [PATCH/RFC] checkout: print something when checking out paths

On Mon, Nov 19, 2018 at 2:08 PM Ævar Arnfjörð Bjarmason wrote: > > > On Mon, Nov 12 2018, Duy Nguyen wrote: > > > On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote: > >> > >> Nguyễn Thái Ngọc Duy writes: > >> > >> > Since the

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

On Thu, Nov 15, 2018 at 2:00 AM wrote: > +Goals > +- > +Legend: Goals marked with P0 are required. Goals marked with Pn should be > +attempted unless they interfere with goals marked with Pn-1. > + > +P0. All commands that modify commits (such as the normal commit --amend or > +rebase

Re: [RFC/PATCH] read-cache: write all indexes with the same permissions

On Fri, Nov 16, 2018 at 8:07 PM SZEDER Gábor wrote: > > On Fri, Nov 16, 2018 at 06:41:43PM +0100, Christian Couder wrote: > > On Tue, Nov 13, 2018 at 6:34 PM Ævar Arnfjörð Bjarmason > > wrote: > > > > I'm asking whether the bug in this patch isn't revealing an existing > > > issue with us not

Re: [PATCH v2] read-cache: write all indexes with the same permissions

On Fri, Nov 16, 2018 at 8:10 PM Christian Couder wrote: > > On Fri, Nov 16, 2018 at 7:03 PM Duy Nguyen wrote: > > > > On Fri, Nov 16, 2018 at 6:31 PM Christian Couder > > wrote: > > > diff --git a/read-cache.c b/read-cache.c > > > index 8c924506dd..

Re: [PATCH v2] read-cache: write all indexes with the same permissions

On Fri, Nov 16, 2018 at 6:31 PM Christian Couder wrote: > diff --git a/read-cache.c b/read-cache.c > index 8c924506dd..ea80600bff 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -3165,7 +3165,8 @@ int write_locked_index(struct index_state *istate, > struct lock_file *lock, >

Re: [PATCH v2 1/1] bundle: cleanup lock files on error

On Thu, Nov 15, 2018 at 1:59 PM Johannes Schindelin wrote: > So yes, we are trying to unlink the `.lock` file, and as far as I can tell > that > `unlink()` call comes from the tempfile cleanup asked for by Martin. However, > as > we still have a handle open to that file, that call fails. > > I

Re: [PATCH v2] checkout: print something when checking out paths

On Wed, Nov 14, 2018 at 11:12 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > One of the problems with "git checkout" is that it does so many > > different things and could confuse people specially when we fail to > > handle ambiguation correctly. > > You would have realized

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On Tue, Nov 13, 2018 at 7:42 PM Derrick Stolee wrote: > > On 11/4/2018 6:44 PM, brian m. carlson wrote: > > +int hash_algo_by_name(const char *name) > > +{ > > + int i; > > + if (!name) > > + return GIT_HASH_UNKNOWN; > > + for (i = 1; i < GIT_HASH_NALGOS; i++) > > +

Re: [RFC/PATCH] read-cache: write all indexes with the same permissions

On Tue, Nov 13, 2018 at 4:32 PM Ævar Arnfjörð Bjarmason wrote: > I won't have time to finish this today, as noted in > https://public-inbox.org/git/874lcl2e9t@evledraar.gmail.com/ > there's a pretty major bug here in that we're now writing out literal > sharedindex_XX files. It's not the

Re: [PATCH 2/3] ieot: default to not writing IEOT section

On Tue, Nov 13, 2018 at 2:12 AM Jonathan Nieder wrote: > > Junio C Hamano wrote: > > > How about > > > > hint: ignoring an optional IEOT extension > > > > to make it clear that it is totally harmless? > > > > With that, we can add advise.unknownIndexExtension=false to turn all > > of them

Re: [PATCH] checkout: disambiguate dwim tracking branches and local files

On Mon, Nov 12, 2018 at 7:44 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > @@ -1079,9 +1079,15 @@ static int parse_branchname_arg(int argc, const char > > **argv, > >*/ > > int recover_with_dwim = dwim_new_local_branch_ok; > > > > -

Re: [PATCH/RFC] checkout: print something when checking out paths

On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > Since the purpose of printing this is to help disambiguate. Only do it > > when "--" is missing (the actual reason though is many tests check > > empty stderr to see that no error is raised and I'm too

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

On Sun, Nov 11, 2018 at 2:06 PM Ævar Arnfjörð Bjarmason wrote: > +Trashable files > +~~~ > + > +`trashable` > +^^ > + > +Provides an escape hatch for re-enabling a potentially data destroying > +feature which was enabled by default between Git versions 1.5.2 and > +2.20. See

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

On Mon, Nov 12, 2018 at 10:09 AM Matthieu Moy wrote: > May I remind an idea I sugested in an old thread: add an intermediate level > where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs' > backup files): > > https://public-inbox.org/git/vpqd3t9656k@bauges.imag.fr/ > >

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

On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason wrote: > The users who need protection against git deleting their files the most > are exactly the sort of users who aren't expert-level enough to > understand the nuances of how the semantics of .gitignore and "precious" > are going to

Re: [PATCH v2 15/16] fsck: reduce word legos to help i18n

On Tue, Nov 6, 2018 at 4:41 AM Junio C Hamano wrote: > > static int fsck_error_func(struct fsck_options *o, > > struct object *obj, int type, const char *message) > > { > > - objreport(obj, (type == FSCK_WARN) ? "warning" : "error", message); > > - return (type == FSCK_WARN) ? 0 :

Re: [PATCH v2 12/16] parse-options: replace opterror() with optname()

On Tue, Nov 6, 2018 at 3:07 PM Ramsay Jones wrote: > Also, this patch does not replace opterror() calls outside of > the 'parse-options.c' file with optname(). This tickles my > static-check.pl script, since optname() is an external function > which is only called from 'parse-options.c'. > > So,

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Fri, Nov 9, 2018 at 11:19 AM Jeff King wrote: > > The form `/abc/def` would not be confused with anything > > that it is not, I would think. The only thing against this form (at least > > that I can think of) is that some people use this way to talk about paths > > that vary between different

Re: [RFC PATCH] index-pack: improve performance on NFS

On Fri, Nov 9, 2018 at 2:46 PM Ævar Arnfjörð Bjarmason wrote: > I'm planning to re-submit mine with some minor changes after the great > Documentation/config* move lands. > > As noted in > https://public-inbox.org/git/87bm7clf4o@evledraar.gmail.com/ and >

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Thu, Nov 8, 2018 at 2:14 PM Johannes Schindelin wrote: > > Hi Peff, > > On Wed, 7 Nov 2018, Jeff King wrote: > > > All that said, if we're just interested in allowing this for config, > > then we already have such a wrapper function: git_config_pathname(). > > Good point. I agree that

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

On Tue, Nov 6, 2018 at 11:11 PM Jeff King wrote: > > On Tue, Nov 06, 2018 at 06:48:22PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > The implementation looks fine to me, but as noted in > > https://public-inbox.org/git/8736se6qyc@evledraar.gmail.com/ I > > wonder what the plausible end-game

Re: What's cooking in git.git (Nov 2018, #03; Wed, 7)

On Wed, Nov 7, 2018 at 2:09 PM SZEDER Gábor wrote: > > On Wed, Nov 07, 2018 at 06:41:45PM +0900, Junio C Hamano wrote: > > * nd/i18n (2018-11-06) 16 commits > > - fsck: mark strings for translation > > - fsck: reduce word legos to help i18n > > - parse-options.c: mark more strings for

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Tue, Nov 6, 2018 at 7:15 PM Ramsay Jones wrote: > >> @@ -709,6 +710,10 @@ char *expand_user_path(const char *path, int > >> real_home) > >> > >> if (path == NULL) > >> goto return_null; > >> +#ifdef __MINGW32__ > >> +if (path[0] == '/') > >> +return

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Tue, Nov 6, 2018 at 3:55 PM Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin > > On Windows, an absolute POSIX path needs to be turned into a Windows > one. > > Signed-off-by: Johannes Schindelin > --- > path.c | 5 + > 1 file changed, 5 insertions(+) > > diff

Re: [PATCH] format-patch: respect --stat when explicitly specified

On Tue, Nov 6, 2018 at 6:25 PM Leif Lindholm wrote: > > > Sure. Only today was the first time I had a look at the git sources, > > > so some guidance would be most appreciated. > > > > No problem (and if you don't have time to do it, just say the word and > > I will continue; this is my bug after

Re: [PATCH] format-patch: respect --stat when explicitly specified

On Tue, Nov 6, 2018 at 5:31 PM Leif Lindholm wrote: > > > diff --git a/builtin/log.c b/builtin/log.c > > > index 061d4fd86..07e6ae2c1 100644 > > > --- a/builtin/log.c > > > +++ b/builtin/log.c > > > @@ -1009,7 +1009,8 @@ static void show_diffstat(struct rev_info *rev, > > > > > > memcpy(,

Re: [PATCH] format-patch: respect --stat when explicitly specified

On Tue, Nov 6, 2018 at 5:18 PM Laszlo Ersek wrote: > >> + opts.stat_width = MAIL_DEFAULT_WRAP; > > > > How about a test to make sure this will not be broken in future? > > Oh, looks like I won't have to test this patch at all! ;) > > (Just kidding, I'll test the next iteration.)

Re: [PATCH/RFC] sequencer.c: record revert/cherry-pick commit with trailer lines

On Tue, Nov 6, 2018 at 9:57 AM Ævar Arnfjörð Bjarmason wrote: > Leaving aside the question of whether the pain of switching is worth it, > I think it's a worthwihle to consider if we could stop hardcoding one > specific human language in commit messages, and instead leave something >

Re: Understanding pack format

On Tue, Nov 6, 2018 at 3:23 AM Farhan Khan wrote: > To follow-up from the other day, I have been reading the code that > retrieves the pack entry for the past 3 days now without much success. > But there are quite a few abstractions and I get lost half-way down > the line. Jeff already gave you

Re: [PATCH] format-patch: respect --stat when explicitly specified

On Tue, Nov 6, 2018 at 11:48 AM Leif Lindholm wrote: > > Commit 43662b23abbd > ("format-patch: keep cover-letter diffstat wrapped in 72 columns") made > format-patch keep the diffstat to within 72 characters. However, it does > this even when --stat is explicitly set on the command line. > > Make

Re: [PATCH v1] refresh_index: remove unnecessary calls to preload_index()

On Mon, Nov 5, 2018 at 8:30 PM Ben Peart wrote: > > From: Ben Peart > > With refresh_index() learning to utilize preload_index() to speed up its > operation there is no longer any benefit to having the caller preload the > index first. Remove those unneeded calls by calling read_index() instead

Re: Design of multiple hash support

On Mon, Nov 5, 2018 at 2:02 AM brian m. carlson wrote: > > I'm currently working on getting Git to support multiple hash algorithms > in the same binary (SHA-1 and SHA-256). In order to have a fully > functional binary, we'll need to have some way of indicating to certain > commands (such as

Re: [PATCH 0/13] parseopt fixes from -Wunused-parameters

On Mon, Nov 5, 2018 at 7:49 PM Jeff King wrote: > > On Mon, Nov 05, 2018 at 05:51:07PM +0100, Duy Nguyen wrote: > > > On Mon, Nov 5, 2018 at 7:39 AM Jeff King wrote: > > > > > > Continuing my exploration of what -Wunused-parameters can show us, here > >

Re: [PATCH 12/12] fsck: mark strings for translation

On Mon, Oct 29, 2018 at 12:53 PM SZEDER Gábor wrote: > The contents of 'out': > > broken link fromtree be45bbd3809e0829297cefa576e699c134abacfd > (refs/heads/master@{1112912113}:caesar.t) > toblob be45bbd3809e0829297cefa576e699c134abacfd >

Re: [PATCH 0/13] parseopt fixes from -Wunused-parameters

On Mon, Nov 5, 2018 at 7:39 AM Jeff King wrote: > > Continuing my exploration of what -Wunused-parameters can show us, here > are some bug-fixes related to parse-options callbacks. > > This is the last of the actual bug-fixes I've found. After this, I have > about 60 patches worth of cleanups

Re: [PATCH/RFC] sequencer.c: record revert/cherry-pick commit with trailer lines

On Mon, Nov 5, 2018 at 1:56 AM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > A reverted commit will have a new trailer > > > > Revert: > > Please don't, unless you are keeping the current "the effect of > commit X relative to its parent Y was reverted" writtein in prose, >

Re: [PATCH/RFC v2] sequencer.c: record revert/cherry-pick commit with trailer lines

On Sun, Nov 4, 2018 at 10:30 PM brian m. carlson wrote: > However, I do have concerns about breaking compatibility with existing > scripts. I wonder if we could add a long alias for git cherry-pick -x, > say "--notate" and have "--notate=text" mean "-x" and "--notate=trailer" > mean this new

Re: "git checkout" safety feature

On Mon, Nov 5, 2018 at 7:53 AM Jeff King wrote: > > On Mon, Nov 05, 2018 at 07:24:42AM +0100, Matthias Urlichs wrote: > > > Hi, > > > "git checkout " is a feature to overwrite local > > > changes. It is what you use when you make a mess editing the files > > > and want to go back to a known

Re: [RFC v1] Add virtual file system settings and hook proc

On Mon, Nov 5, 2018 at 12:40 PM Ævar Arnfjörð Bjarmason wrote: > > > On Sun, Nov 04 2018, Duy Nguyen wrote: > > > On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote: > >> >> +core.virtualFilesystem:: > >> >> + If set, the v

Re: [RFC v1] Add virtual file system settings and hook proc

On Sun, Nov 4, 2018 at 10:01 PM brian m. carlson wrote: > > On Sun, Nov 04, 2018 at 07:34:01AM +0100, Duy Nguyen wrote: > > On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote: > > > It's more than a dynamic sparse-checkout because the same list is also > > > u

Re: [PATCH/RFC] sequencer.c: record revert/cherry-pick commit with trailer lines

On Sun, Nov 4, 2018 at 5:45 PM Phillip Wood wrote: > > On 04/11/2018 07:22, Nguyễn Thái Ngọc Duy wrote: > > When a commit is reverted (or cherry-picked with -x) we add an English > > sentence recording that commit id in the new commit message. Make > > these real trailer lines instead so that

Re: [RFC v1] Add virtual file system settings and hook proc

On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote: > >> +core.virtualFilesystem:: > >> + If set, the value of this variable is used as a command which > >> + will identify all files and directories that are present in > >> + the working directory. Git will only track and update

Re: [PATCH] tree-walk.c: fix overoptimistic inclusion in :(exclude) matching

On Sun, Nov 4, 2018 at 7:27 AM Eric Sunshine wrote: > > On Sat, Nov 3, 2018 at 8:25 PM Eric Sunshine wrote: > > On Sat, Nov 3, 2018 at 11:31 AM Nguyễn Thái Ngọc Duy > > wrote: > > > +test_expect_success 't_e_i() exclude case #8' ' > > > + git init case8 && > > > + ( > > > +

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

On Sat, Nov 3, 2018 at 4:32 PM Michał Górny wrote: > Perhaps this is indeed specific to this version of GnuPG. The tests > pass for me with both 1.4.21 and 2.2.10. We don't have 2.1* in Gentoo > anymore. Updated to 2.2.8 and the test is passed. -- Duy

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

On Sat, Nov 3, 2018 at 4:32 PM Michał Górny wrote: > > Perhaps my gpg is too old? > > > > $ gpg --version > > gpg (GnuPG) 2.1.15 > > libgcrypt 1.7.3 > > Copyright (C) 2016 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > >

Re: [PATCH v4] gpg-interface.c: detect and reject multiple signatures on commits

On Sat, Oct 20, 2018 at 9:31 PM Michał Górny wrote: > +test_expect_success GPG 'detect fudged commit with double signature' ' > + sed -e "/gpgsig/,/END PGP/d" forged1 >double-base && > + sed -n -e "/gpgsig/,/END PGP/p" forged1 | \ > + sed -e "s/^gpgsig//;s/^ //" | gpg

Re: [[PATCH v2]] commit: add a commit.allowempty config variable

On Sat, Nov 3, 2018 at 12:55 PM tanushree27 wrote: > > Add commit.allowempty configuration variable as a convenience for those > who always prefer --allow-empty. > > Add tests to check the behavior introduced by this commit. > > This closes https://github.com/git-for-windows/git/issues/1854 > >

Re: [PATCH v2] completion: use builtin completion for format-patch

On Sat, Nov 3, 2018 at 8:59 AM Denton Liu wrote: > > @@ -2081,7 +2077,7 @@ _git_send_email () > > return > > ;; > > --*) > > - __gitcomp "--annotate --bcc --cc --cc-cmd --chain-reply-to > > + __gitcomp_builtin send-email "--annotate --bcc

Re: [PATCH v2] completion: use builtin completion for format-patch

On Fri, Nov 02, 2018 at 08:52:30AM +0900, Junio C Hamano wrote: > Duy Nguyen writes: > > >> > I have no comment about this. In an ideal world, sendemail.perl could > >> > be taught to support --git-completion-helper but I don't think my > >> > little re

Re: [PATCH v1] add: speed up cmd_add() by utilizing read_cache_preload()

On Sat, Nov 3, 2018 at 1:38 AM Junio C Hamano wrote: > > Duy Nguyen writes: > > > On Fri, Nov 2, 2018 at 2:32 PM Ben Peart wrote: > >> > >> From: Ben Peart > >> > >> During an "add", a call is made to run_diff_files() which calls

Re: submodule support in git-bundle

On Fri, Nov 2, 2018 at 6:09 PM Stefan Beller wrote: > > On Fri, Nov 2, 2018 at 9:10 AM Duy Nguyen wrote: > > > > I use git-bundle today and it occurs to me that if I want to use it to > > transfer part of a history that involves submodule changes, things > > ar

submodule support in git-bundle

I use git-bundle today and it occurs to me that if I want to use it to transfer part of a history that involves submodule changes, things aren't pretty. Has anybody given thought on how to do binary history transfer that contains changes from submodules? Since .bundle files are basically .pack

Re: Understanding pack format

On Fri, Nov 2, 2018 at 7:19 AM Junio C Hamano wrote: > > Farhan Khan writes: > > > ...Where is this in the git code? That might > > serve as a good guide. > > There are two major codepaths. One is used at runtime, giving us > random access into the packfile with the help with .idx file. The >

  1   2   3   4   5   6   7   8   9   10   >