On Tue, Oct 4, 2016 at 11:15 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> We don't use it internally _yet_. I need to go through all the
>> external diff code and see --shift-ita should be there. The end goal
>> is still changing the default behavior and gett
On Fri, Sep 09, 2016 at 05:54:30PM +0700, Duy Nguyen wrote:
> On Tue, Sep 6, 2016 at 4:08 AM, Christian Neukirchen
> wrote:
> > Hi,
> >
> > I noticed the following suprising behavior:
> >
> > % git --version
> > git version 2.10.0
> >
> > %
On Wed, Oct 5, 2016 at 5:14 PM, Jakub Narębski wrote:
> [git@vger.kernel.org does not accept HTML emails]
>
> I just hope that this email don't get mangled too much...
>
> On 5 October 2016 at 04:55, Santiago Perez De Rosso
> wrote:
>> On Fri, Sep 30, 2016 at 6:25 PM Jakub Narębski wrote:
>>> W
On Thu, Oct 6, 2016 at 7:40 AM, Jacob Keller wrote:
> On Wed, Oct 5, 2016 at 3:15 PM, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>>> Gut feeling tells me that I should take this as a subtle
>>> encouragement to look into adding 'versionsort.postreleasesuffix',
>>> shouldn't I ;)
>>
>> It i
On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > Throwing something at the mailing list to see if anybody is
>> > interested.
>> >
>> > Current '!' aliases move cwd to $GIT_WORK_TREE fir
On Fri, Oct 7, 2016 at 7:47 PM, Matthieu Moy
wrote:
> Duy Nguyen writes:
>
>> On Fri, Oct 7, 2016 at 6:20 PM, Johannes Schindelin
>> wrote:
>>> Hi Junio,
>>>
>>> On Thu, 6 Oct 2016, Junio C Hamano wrote:
>>>
>>>> Nguyễn Thái Ngọ
On Fri, Oct 7, 2016 at 2:15 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Tue, Oct 4, 2016 at 11:15 PM, Junio C Hamano wrote:
>>> Duy Nguyen writes:
>>>
>>>> We don't use it internally _yet_. I need to go through all the
>>>>
On Fri, Oct 7, 2016 at 10:55 PM, Jakub Narębski wrote:
> W dniu 07.10.2016 o 16:19, Johannes Schindelin pisze:
>> On Fri, 7 Oct 2016, Jakub Narębski wrote:
>
>>> Note that we would have to teach git completion about new syntax;
>>> or new configuration variable if we go that route.
>>
>> Why would
On Sun, Oct 9, 2016 at 2:51 PM, Dennis Kaarsemaker
wrote:
> On Sat, 2016-10-08 at 19:30 -0500, Michael Tutty wrote:
>> Hey all,
>> I'm working on some server-side software to do a merge. By using git
>> worktree it's possible to check out a given branch for a bare repo and
>> merge another branch
On Sat, Oct 8, 2016 at 4:35 PM, Stéphane Klein
wrote:
> Hi,
>
> "git worktree add" write absolute path in ".git/gitdir"
>
> The code source is here
> https://git.kernel.org/cgit/git/git.git/tree/builtin/worktree.c?h=v2.10.1#n256
>
> Is it possible to use relative path in this config files:
>
> * [
On Sun, Oct 9, 2016 at 6:22 PM, Stéphane Klein
wrote:
> 2016-10-09 13:11 GMT+02:00 Duy Nguyen :
>
>>> * [worktree_foobar]/.git
>> This is made absolute on purpose. So that if you move worktree_foobar
>> away manually, it can still point back to
>> "[main_wo
On Sun, Oct 9, 2016 at 1:01 PM, Jeff King wrote:
> On Sat, Oct 08, 2016 at 10:36:13AM +0200, Johannes Schindelin wrote:
>
>> > > Maybe it's time to aim for
>> > >
>> > > git config alias.d2u.shell \
>> > >'f() { git ls-files "$@" | xargs dos2unix; }; f'
>> > > git config alias.d2u.cdup
On Mon, Oct 10, 2016 at 6:46 AM, Jeff King wrote:
> On Sun, Oct 09, 2016 at 03:24:17PM +0200, René Scharfe wrote:
>
>> Offering a way to enable terminal-detection for all color codes of a
>> format would be useful, but using the existing "auto," prefix for that
>> would be a behaviour change that
On Sun, Oct 9, 2016 at 8:42 PM, Michael Tutty wrote:
> Dennis,
> Thanks for the great response, and for spending time on my issue.
> I'll try that first patch and see what happens.
>
> In the meantime, it got weirder...
>
> I created a brand-new (bare) repo
Elaboration needed here. If I create a
On Tue, Oct 11, 2016 at 4:44 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Sun, 9 Oct 2016, Jeff King wrote:
>
>> On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
>>
>> > > If you mean ambiguity between the old "alias.X" and the new &
On Mon, Oct 10, 2016 at 10:15 PM, Jeff King wrote:
> On Mon, Oct 10, 2016 at 10:28:18AM -0400, Jeff King wrote:
>
>> > We could add some new tag to change the behavior of all following %C
>> > tags. Something like %C(tty) maybe (probably a bad name), then
>> > discourage the use if "%C(auto" for t
On Tue, Oct 11, 2016 at 1:36 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> I think there are some pros and some cons for relative path and absolute
>>> path.
>>> Maybe append a "--relative" option with `git worktree add` ?
>>>
>&
On Thu, Oct 13, 2016 at 1:50 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Dennis Kaarsemaker writes:
>>
>>> OK, so here it is as a proper patch.
>
> Here is what I queued. Duy, what do you think? It seems OK to me.
Ack. Thanks both.
--
Duy
On Thu, Oct 13, 2016 at 8:52 AM, Eric Wong wrote:
> +sub svn_dir {
> + my $git_dir = scalar @_ ? $_[0] : $ENV{GIT_DIR};
> + my $common = $ENV{GIT_COMMON_DIR} || "$git_dir/commondir";
> + $git_dir .= '/'.::file_to_s($common) if -e $common;
> + my $svn_dir = $git_dir . '/svn'
On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Sun, 16 Oct 2016, Stefan Beller wrote:
>
>> Conceptually I would prefer if we had a single switch that indicates a
>> case insensitive FS.
>
> AFAIU Lars' use case is where the FS is *case sensitive*, but he still
> ne
On Sat, Oct 8, 2016 at 2:59 AM, David Turner wrote:
>
>
>> -Original Message-
>> From: Stefan Beller [mailto:sbel...@google.com]
>> Sent: Friday, October 07, 2016 2:56 PM
>> To: David Turner
>> Cc: git@vger.kernel.org
>> Subject: Re: Uninitialized submodules as symlinks
>>
>> On Fri, Oct 7
On Mon, Oct 17, 2016 at 5:46 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Mon, 17 Oct 2016, Duy Nguyen wrote:
>
>> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
>> wrote:
>> > Hi Stefan,
>> >
>> > On Sun, 16 Oct 2016, Stefan Beller
On Sat, Oct 15, 2016 at 4:06 AM, Martin Langhoff
wrote:
> On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt wrote:
>> Correct, this only works when it's unambiguous what branch you actually
>> mean.
>
> That's not surprising, but there isn't a warning. IMHO, finding
> several branch matches is a stron
On Wed, Oct 19, 2016 at 1:05 AM, Luke Shumaker wrote:
>> I am not sure if it is even a bug. As you can easily lose that
>> tilde that appears in front of subdirectory of /srv/git/ or replace
>> it with something else (e.g. "u/"), this smells like "Don't do it if
>> it hurts" thing to me.
>
> I bu
On Tue, Oct 18, 2016 at 10:17 PM, Raffael Reichelt
wrote:
> Hello!
>
> I have a serious problem with git, After my provider had updated to a X86_64
> architecture git crashes with various memory-related errors. This is
> happening remote when pushing to the repository from my local machine as we
On Wed, Oct 19, 2016 at 08:27:43PM +0700, Duy Nguyen wrote:
> If you set the environment variable GIT_ALLOC_LIMIT ... git
> attempts to allocate more than that ... then it's caught and we get
> a glimpse of how much memory git may need. Unfortunately we can't
> get a stack
On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin
wrote:
> Hi Junio,
>
> I know you are a fan of testing things thoroughly in the test suite, but I
> have to say that it is getting out of hand, in particular due to our
> over-use of shell script idioms (which really only run fast on Linux, not
On Thu, Oct 20, 2016 at 11:40 PM, René Scharfe wrote:
> Am 20.10.2016 um 13:02 schrieb Duy Nguyen:
>> On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin
>> wrote:
>>> Hi Junio,
>>>
>>> I know you are a fan of testing things thoroughly in the test suite
On Fri, Oct 21, 2016 at 3:40 AM, Dennis Kaarsemaker
wrote:
> On Thu, 2016-10-20 at 08:31 -0400, Jeff King wrote:
>
>> I'm also not entirely convinced that the test suite being a shell script
>> is the main culprit for its slowness. We run git a lot of times, and
>> that's inherent in testing it. I
On Fri, Oct 21, 2016 at 7:26 AM, Jeff King wrote:
> I recently started using lt/abbrev-auto via 'next'. This is the fetch
> output I saw today:
>
> $ git fetch
> remote: Counting objects: 332, done.
> remote: Compressing objects: 100% (237/237), done.
> remote: Total 332 (delta 182), reused 64 (de
On Fri, Oct 21, 2016 at 7:11 PM, Duy Nguyen wrote:
> Yeah.. replacing the 4 DEFAULT_ABBREV in fetch.c with something
> sensible should do it.
Correction (if somebody will pick this up), it's
TRANSPORT_SUMMARY_WIDTH that needs to be adjusted, not those four.
--
Duy
On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer wrote:
> On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
>> [...]
>> I still think we're misunderstanding. I want git commit to complain
>> *only* under the following circumstance:
>>
>> I run "git add -p" and put a partial change into the inde
On Sun, Oct 23, 2016 at 8:38 AM, Jeff King wrote:
> On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:
>
>> I hit the same problem sometimes, but in my case sometimes I
>> accidentally do "git add" after "git add -p" and a configuration in
>>
On Tue, Oct 25, 2016 at 1:07 AM, Junio C Hamano wrote:
>> - splitIndex.sharedIndexExpire
>>
>> To make sure that old sharedindex files are eventually removed
>> when a new one has been created, we "touch" the shared index file
>> every time it is used by a new split index file. The
On Tue, Oct 25, 2016 at 12:58 AM, Junio C Hamano wrote:
>> The name ita-invisible-in-index is not perfect but I could not think
>> of any better. Another name could be diff-cached-ignores-ita, but
>> that's just half of what it does. The other half is
>> diff-files-includes-ita...
>
> I can't eit
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> +void remove_split_index(struct index_state *istate)
> +{
> + if (istate->split_index) {
> + /*
> +* can't discard_split_index(&the_index); because that
> +* will destroy split_index->bas
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> When users are using `git update-index --(no-)split-index`, they
> may expect the split-index feature to be used or not according to
> the option they just used, but this might not be the case if the
> new "core.splitIndex" config variable
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> This new function will be used in a following commit to get the
> +int git_config_get_max_percent_split_change(void)
> +{
> + int val = -1;
> +
> + if (!git_config_get_int("splitindex.maxpercentchange", &val)) {
> +
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> @@ -2233,7 +2263,8 @@ int write_locked_index(struct index_state *istate,
> struct lock_file *lock,
> if ((v & 15) < 6)
> istate->cache_changed |= SPLIT_INDEX_ORDERED;
> }
> - if (istat
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> @@ -2268,6 +2268,12 @@ int write_locked_index(struct index_state *istate,
> struct lock_file *lock,
Doing this in read_index_from() would keep the shared file even more
"fresher" since read happens a lot more often than write. But I thin
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> Goal
>
>
> We want to make it possible to use the split-index feature
> automatically by just setting a new "core.splitIndex" configuration
> variable to true.
Thanks. This definitely should help make split index a lot more
convenien
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
wrote:
> +static int can_delete_shared_index(const char *shared_sha1_hex)
> +{
> + struct stat st;
> + unsigned long expiration;
> + const char *shared_index = git_path("sharedindex.%s",
> shared_sha1_hex);
> +
> + /* Check
On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano wrote:
> The procedure to resolve a merge conflict typically goes like this:
>
> - first open the file in the editor, and with the help of conflict
>markers come up with a resolution.
>
> - save the file.
>
> - look at the output from "git dif
On Tue, Oct 25, 2016 at 6:06 PM, Duy Nguyen wrote:
> On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano wrote:
>> The procedure to resolve a merge conflict typically goes like this:
>>
>> - first open the file in the editor, and with the help of conflict
>>marker
On Mon, Oct 24, 2016 at 8:29 PM, Jeff King wrote:
> I'm looking into the oft-discussed idea of reducing the size of ref
> advertisements by having the client say "these are the refs I'm
> interested in". Let's set aside the protocol complexities for a
> moment and imagine we magically have some wa
On Thu, Oct 20, 2016 at 1:16 PM, Jeff King wrote:
> The low-level attribute and gitignore code will try to look
> in $GIT_DIR/info for any repo-level configuration files,
> even if we have not actually determined that we are in a
> repository (e.g., running "git grep --no-index"). In such a
> case
On Thu, Oct 20, 2016 at 1:24 PM, Jeff King wrote:
> This passes the test suite (after the adjustments in the
> previous patches), but there's a risk of regression for any
> cases where the fallback usually works fine but the code
> isn't exercised by the test suite. So by itself, this
> commit is
On Mon, Oct 10, 2016 at 9:28 PM, Jeff King wrote:
> On Mon, Oct 10, 2016 at 04:26:18PM +0700, Duy Nguyen wrote:
>
>> > If we do a revamp of the pretty-formats to bring them more in line with
>> > ref-filter (e.g., something like "%(color:red)") maybe that wo
On Tue, Oct 25, 2016 at 7:58 PM, Jeff King wrote:
> On Tue, Oct 25, 2016 at 07:52:21PM +0700, Duy Nguyen wrote:
>
>> > Yeah, adding a "%C(enable-auto-color)" or something would be backwards
>> > compatible and less painful than using "%C(auto)" ever
On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano wrote:
>> Timestamps allow us to say, ok this base index file has not been read
>> by anybody for N+ hours (or better, days), it's most likely not
>> referenced by any temporary index files (including
>> $GIT_DIR/index.lock) anymore because those fi
On Wed, Oct 26, 2016 at 6:28 AM, Junio C Hamano wrote:
> Somebody with a bright idea decided that vc-git-resolve-conflicts
> variable should be on by default in Emacs 25.1 X-<,
Oh good, I have an excuse to stick to 24.5.1 for a while longer then.
> which causes
> "save" after resolving conflict
On Tue, Oct 25, 2016 at 11:15:25AM -0400, Jeff King wrote:
> > The "once we've identified" part could be tricky though. This message
> > alone will not give us any clue where it's called since it's buried
> > deep in git_path() usually, which is buried deep elsewhere. Without
> > falling back to co
On Wed, Oct 26, 2016 at 7:10 PM, Jeff King wrote:
> On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote:
>
>> > I think you could conditionally make git_path() and all of its
>> > counterparts macros, similar to the way the trace code works. It seems
>> >
On Tue, Oct 11, 2016 at 10:01 PM, Jeff King wrote:
> On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote:
>
>> > Yeah, that's reasonable, too. So:
>> >
>> > [alias]
>> > d2u = "!dos2unix"
>> >
>> > acts exactly as if:
>> >
>> > [alias "d2u"]
>> > command = dos2unix
>> >
(sorry if this should have been answered if I went through the series
patch by patch, I wanted to do a proper review but finally have to
admit to myself I won't, so I just skim through a single giant diff
instead)
On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote:
> +attr;;
> +After `attr:` co
On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote:
> This revamps the API of the attr subsystem to be thread safe.
> Before we had the question and its results in one struct type.
> The typical usage of the API was
>
> static struct git_attr_check *check;
>
> if (!check)
> check
On Tue, Oct 25, 2016 at 2:18 AM, Stefan Beller wrote:
> On Mon, Oct 24, 2016 at 11:55 AM, Junio C Hamano wrote:
>
>>
>> Make that a double-asterisk. The same problem appears in an updated
>> example in technical/api-gitattributes.txt doc, but the example in
>> the commit log message (below) is c
On Wed, Oct 26, 2016 at 11:51 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> There are occasions when you decide to abort an in-progress rebase and
>> move on to do something else but you forget to do "git rebase --abort"
>> first. Or the rebase has been in progress for so long yo
On Tue, Oct 25, 2016 at 5:43 PM, Duy Nguyen wrote:
>> static int write_shared_index(struct index_state *istate,
>> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state
>> *istate,
>> }
>> ret = rename_t
On Fri, Oct 28, 2016 at 3:41 AM, Eric Wong wrote:
> Johannes Schindelin wrote:
>> I know you are a fan of testing things thoroughly in the test suite, but I
>> have to say that it is getting out of hand, in particular due to our
>> over-use of shell script idioms (which really only run fast on Li
On Thu, Oct 27, 2016 at 11:13 PM, Junio C Hamano wrote:
>> git-gc just can't match this because while it's running, somebody else
>> may be updating $GIT_DIR/index. Handling races would be a lot harder.
>
> It could attempt to take a lock on the primary index while it runs,
> and refrain to do any
On Wed, Oct 12, 2016 at 8:47 PM, wrote:
> From: Torsten Bögershausen
>
> When statistics are done for the autocrlf handling, the search in
> the content can be stopped, if e.g
> - a search for binary is done, and a NUL character is found
> - a search for CRLF is done, and the first CRLF is found
On Wed, Oct 12, 2016 at 8:47 PM, wrote:
> From: Torsten Bögershausen
>
> Factor out the retrieval of the sha1 for a given path in
> read_blob_data_from_index() into the function get_sha1_from_index().
>
> This will be used in the next commit, when convert.c can do the
> analyze for "text=auto" w
On Fri, Oct 28, 2016 at 4:04 AM, Jeff King wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>> > I think the normal behavior in such "foo.d" directory is to just sort
>> > the contents lexically and read them in order, as if they were all
>> > concatenated together, and wit
On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly wrote:
> Or how about a new githook that can intelligently create or return the
> details? This would be my least favourite option unless it was
> configured in an obvious place.
I wonder if smudge/clean filters can be used to recreate in-tree
.gitigno
(sorry I got sick in the last few weeks and could not respond to this earlier)
On Mon, Nov 7, 2016 at 4:44 AM, Christian Couder
wrote:
> Le 6 nov. 2016 09:16, "Junio C Hamano" a écrit :
>>
>> Christian Couder writes:
>>
>> > I think it is easier for user to be able to just set core.splitIndex
>
On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett wrote:
> Once we have gitrefs, you have both alternatives: reachable (gitref) or
> not reachable (gitlink).
>
> However, if you want some way to mark reachable objects as not
> reachable, such as for a sparse checkout, external large-object storage,
>
On Wed, Nov 2, 2016 at 8:08 PM, Jeff King wrote:
> The attributes system may sometimes read in-tree files from
> the filesystem, and sometimes from the index. In the latter
> case, we do not resolve symbolic links (and are not likely
> to ever start doing so). Let's open filesystem links with
> O_
On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder
wrote:
> On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen wrote:
>> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
>> wrote:
>>> +void remove_split_index(struct index_state *istate)
>>> +{
&g
On Tue, Nov 8, 2016 at 4:15 AM, Jeff King wrote:
> On Mon, Nov 07, 2016 at 04:10:10PM -0500, Jeff King wrote:
>
>> And I'll admit my main motivation is not that index/filesystem parity,
>> but rather just that:
>>
>> git clone git://host.com/malicious-repo.git
>> git log
>>
>> might create and
On Wed, Nov 9, 2016 at 5:21 AM, Jeff King wrote:
> On Tue, Nov 08, 2016 at 08:38:55AM +0700, Duy Nguyen wrote:
>
>> > Another approach is to have a config option to disallow symlinks to
>> > destinations outside of the repository tree (I'm not sure if it should
On Mon, Nov 7, 2016 at 5:08 PM, Duy Nguyen wrote:
> On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder
> wrote:
>> On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen wrote:
>>> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
>>> wrote:
>>>> +void rem
On Fri, Oct 28, 2016 at 1:29 AM, Junio C Hamano wrote:
> The reason why I am bringing this up in this discussion thread on
> this patch is because I wonder if we would benefit by a similar
> "let's not do too involved things and be cheap by erring on the safe
> and lazy side" strategy in the call
On Sat, Oct 29, 2016 at 1:54 AM, Stefan Beller wrote:
> The pathspec mechanism is extended via the new
> ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
> requires paths to not just match the given pattern but also have the
> specified attrs attached for them to be chosen.
>
On Thu, Nov 10, 2016 at 7:23 AM, Jeff King wrote:
> On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>> >
>> > I'm slightly confused. Did you mean "supporting any in-tree symlink to
>> >
On Thu, Nov 10, 2016 at 3:12 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> ---
>> v2 changes just the subject line
>
> That's not sufficient, is it? What you did in the documentation
> would raise the same "Hmph, is this only about HEAD?" and unlike the
> commit subject, it wil
On Thu, Nov 10, 2016 at 6:09 PM, Duy Nguyen wrote:
> On Thu, Nov 10, 2016 at 3:12 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> ---
>>> v2 changes just the subject line
>>
>> That's not sufficient, is it? What you did in t
On Fri, Nov 11, 2016 at 6:23 PM, Patrick Steinhardt wrote:
> With the introduction of the $GIT_COMMON_DIR variable, the
> repository layout manual was changed to reflect the location for
> many files in case the variable is set. While adding the new
> locations, one typo snuck in regarding the loc
On Sat, Nov 12, 2016 at 06:53:44PM -0800, Junio C Hamano wrote:
> not ok 12 - move worktree
> #
> # git worktree move source destination &&
> # test_path_is_missing source &&
> # git worktree list --porcelain | grep "^worktree" >actual &&
> # cat
On Wed, Nov 16, 2016 at 8:05 PM, Duy Nguyen wrote:
> diff --git a/worktree.c b/worktree.c
> index f7869f8..fe92d6f 100644
> --- a/worktree.c
> +++ b/worktree.c
> @@ -173,6 +173,13 @@ static void mark_current_worktree(struct worktree
> **worktrees)
> free(git_dir);
On Wed, Nov 16, 2016 at 3:28 AM, Ramsay Jones
wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Duy,
>
> If you need to re-roll your 'nd/worktree-move' branch, could you
> please squash this into the relevant patch [commit c49e92f5c
> ("worktree move: refuse to move worktrees with submodules",
On Tue, Nov 15, 2016 at 4:21 AM, Jeff King wrote:
> Thanks for responding to this.
Glad to help (or more precisely annoy you somewhat :D)
> I've been meaning to get back to it with
> some code experiments, but they keep getting bumped down in priority. So
> let me at least outline some of my tho
On Mon, Nov 21, 2016 at 9:18 PM, Johannes Schindelin
wrote:
> When eff80a9 (Allow custom "comment char", 2013-01-16) taught the
> `stripspace` command to respect the config setting `core.commentChar`,
> it forgot that this variable may be defined in .git/config.
>
> So when rebasing interactively
On Mon, Nov 21, 2016 at 9:18 PM, Johannes Schindelin
wrote:
> When 84c9dc2 (commit: allow core.commentChar=auto for character auto
> selection, 2014-05-17) extended the core.commentChar functionality to
> allow for the value 'auto', it forgot that rebase -i was already taught to
> handle core.comm
On Fri, Nov 18, 2016 at 9:34 PM, Christian Couder
wrote:
> On Mon, Nov 7, 2016 at 10:38 AM, Duy Nguyen wrote:
>> (sorry I got sick in the last few weeks and could not respond to this
>> earlier)
>
> (Yeah, I have also been sick during the last few weeks.)
>
>>
On Fri, Nov 11, 2016 at 3:34 AM, Stefan Beller wrote:
> @@ -139,7 +140,8 @@ static size_t common_prefix_len(const struct pathspec
> *pathspec)
>PATHSPEC_LITERAL |
>PATHSPEC_GLOB |
>PATHSPEC_ICASE |
> - PA
On Tue, Nov 22, 2016 at 8:13 PM, Christian Couder
wrote:
> So if we now mix things up just to avoid one more configuration
> option, we could very well make things harder to develop, to
> configure, to parse and to understand later, so it is not a trade off
> worth making.
OK since we're still in
On Wed, Nov 23, 2016 at 12:26 AM, Stefan Beller wrote:
> On Tue, Nov 22, 2016 at 2:41 AM, Duy Nguyen wrote:
>> On Fri, Nov 11, 2016 at 3:34 AM, Stefan Beller wrote:
>>> @@ -139,7 +140,8 @@ static size_t common_prefix_len(const struct paths
On Wed, Nov 23, 2016 at 12:49 AM, Jeff King wrote:
> On Tue, Nov 22, 2016 at 07:30:19PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This is the follow up of rs/qsort series, merged in b8688ad (Merge
>> branch 'rs/qsort' - 2016-10-10), where coccinelle was used to do
>> automatic transformation.
>>
>>
On Wed, Nov 23, 2016 at 7:52 AM, Van Oostenryck Luc
wrote:
> Hi,
>
> More or less by error I used the fsck command in a worktree and I had
> the surprised to see that it reported a lot of dangling commits while it was
> not supposed to have one.
> I quickly realized that it was the case only in th
On Fri, Nov 25, 2016 at 3:52 AM, Jeff King wrote:
> On Thu, Nov 24, 2016 at 06:45:36PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This started out to as a hunt for remaining qsort() calls after rs/qsort
>> series because qsort() API is a bit easy to get wrong (*). However,
>> since we have string_lis
On Thu, Nov 24, 2016 at 12:16 AM, Junio C Hamano wrote:
> More importantly, perhaps get_worktrees() should learn to take an
> optional pointer to int that returns how many items are in the list?
My first thought was "yeah I remember there are many counting loop
like this" then grepped and realize
On Wed, Nov 23, 2016 at 11:52 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This fixes two things:
>>
>> - make sure the first item is always the main worktree even if we
>>fail to retrieve some info
>>
>> - keep 'worktree list' order stable (which in turn fixes the random
On Fri, Nov 25, 2016 at 7:24 PM, Duy Nguyen wrote:
> Adding the test for the failed parse_ref() is possible, I think. But
> since that function is destined to die, as I promised to use
> refs-provided api instead of rolling out a custom ref parser, and I'm
> going to have ano
On Thu, Nov 24, 2016 at 6:21 AM, Junio C Hamano wrote:
> * nd/rebase-forget (2016-10-28) 1 commit
> - rebase: add --forget to cleanup rebase, leave HEAD untouched
>
> "git rebase" learned "--forget" option, which allows a user to
> remove the metadata left by an earlier "git rebase" that was
>
On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Does this round address the issue raised in
>>
>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>
>> by Dscho?
It does not (and is sort of expected), quoting from the commit messag
On Tue, Nov 29, 2016 at 4:25 AM, Johannes Sixt wrote:
> Am 28.11.2016 um 21:20 schrieb Junio C Hamano:
>>
>> Junio C Hamano writes:
>>
>>> Does this round address the issue raised in
>>>
>>>
>>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>>
>>> by Dscho?
>>>
>>> Ev
On Tue, Nov 29, 2016 at 07:08:16PM +0700, Duy Nguyen wrote:
> On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano wrote:
> > Junio C Hamano writes:
> >
> >> Does this round address the issue raised in
> >>
> >> http://public-inbox.org/git/alpine.DEB.2.20.
On Wed, Nov 30, 2016 at 4:14 AM, Johannes Sixt wrote:
>> diff --git a/copy.c b/copy.c
>> index 4de6a11..b232aec 100644
>> --- a/copy.c
>> +++ b/copy.c
>> @@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char
>> *src, int mode)
>> return copy_times(dst, src);
>>
On Wed, Nov 23, 2016 at 2:22 AM, Stefan Beller wrote:
> +/*
> + * Migrate the given submodule (and all its submodules recursively) from
> + * having its git directory within the working tree to the git dir nested
> + * in its superprojects git dir under modules/.
> + */
> +void migrate_submodule_g
401 - 500 of 4016 matches
Mail list logo
