Jeff King writes:
> ...
> --commit-filter '
> commit=$(git commit-tree "$@")
> git notes copy $GIT_COMMIT $commit
> echo $commit
> '
Thanks. I was writing the same "git notes copy $this $that" based
response, but TIL we had --stdin to fe
On Thu, Aug 22, 2019 at 04:44:37PM -0400, Christopher Sean Morrison wrote:
> We’re migrating a very large old repository to Git (the oldest in
> continuous development!) and using the notes feature to preserve Svn
> data like revision IDs and branch information. We’ve run into what
> seems like a
user$ git checkout -b "environment-logging"
Switched to a new branch ' environment-logging'
user$ git status
On branch environment-logging
nothing to commit, working tree clean
user$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
user$ git branch
On Thu, Apr 11, 2019 at 03:16:22PM -0400, Can Gemicioglu wrote:
> I noticed a problem when trying to apply a patch file that contained
> many separate patches in a single file.
To quote the first line of its manpage :) 'git apply' is meant to
"Apply a patch to files and/or to the index". Note the
On 15-02-19, 08:09, Elijah Newren wrote:
> Hi Viresh,
>
> On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
> >
> > On 14-02-19, 13:23, Elijah Newren wrote:
> > > I think you're getting tripped up by double-dot vs triple-dot with
> > > diff being different than log:
> > >
> > > `git diff D..E`
Philip Oakley writes:
> It was my understanding that the end point would be total removal of
> any options and the typing of the double dot would be an error. Given
> that hard end point I was looking to ensure that users of double dots
> have a manageable route to unlearning old bad habits. Thus
Hi Junio,
On 17/02/2019 03:34, Junio C Hamano wrote:
Philip Oakley writes:
Those who do *not* opt into that "early warning" configuration dance
would eventually be warned whenever they type "diff A..B", and the
timing for that eventuality is not under their control, so quite
honestly, I do no
Philip Oakley writes:
>> Those who do *not* opt into that "early warning" configuration dance
>> would eventually be warned whenever they type "diff A..B", and the
>> timing for that eventuality is not under their control, so quite
>> honestly, I do not see much point in "giving users the chance"
On 15/02/2019 23:32, Junio C Hamano wrote:
Philip Oakley writes:
On 15/02/2019 20:12, Junio C Hamano wrote:
Historically, it was a mistake to allow A..B to be used for two
endpoints, which was made back when we haven't thought things
through. That is why I stopped "warn to deprecate and then
Philip Oakley writes:
> On 15/02/2019 20:12, Junio C Hamano wrote:
>>
>> Historically, it was a mistake to allow A..B to be used for two
>> endpoints, which was made back when we haven't thought things
>> through. That is why I stopped "warn to deprecate and then
>> completely remove", as I do n
On 15/02/2019 20:12, Junio C Hamano wrote:
Elijah Newren writes:
Instead of outright deprecating it, would it make sense to include a
configuration option, say "diff.sensibleDots", that would enable a user
to set the dots to the other form if they desire?
I think Junio's suggested steps would
On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > The only thing I seem to be able to retain is the following: "git
> > diff D..E is totally useless and should be an error because (1) it
> > doesn't do what I expect and (2) for folks that want the beha
Elijah Newren writes:
>> Instead of outright deprecating it, would it make sense to include a
>> configuration option, say "diff.sensibleDots", that would enable a user
>> to set the dots to the other form if they desire?
>
> I think Junio's suggested steps would still have to come first, and
> t
Denton Liu writes:
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
>
>> It might be _possible_ to spend a year (i.e. 4 cycles) to start
>> warning when two-dot notation is used for "git diff" (only, not any
>> plumbing like "git diff-files") and tell the user to use the more
>>
On Fri, Feb 15, 2019 at 10:52 AM Denton Liu wrote:
>
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> > > The only thing I seem to be able to retain is the following: "git
> > > diff D..E is totally useless and should be an error because (1) it
>
Hi Viresh,
On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
>
> On 14-02-19, 13:23, Elijah Newren wrote:
> > I think you're getting tripped up by double-dot vs triple-dot with
> > diff being different than log:
> >
> > `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> >
On 14-02-19, 13:23, Elijah Newren wrote:
> I think you're getting tripped up by double-dot vs triple-dot with
> diff being different than log:
>
> `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> two commits D and E.
Right, so both the branches have at least until rc2 (thou
Elijah Newren writes:
> The only thing I seem to be able to retain is the following: "git
> diff D..E is totally useless and should be an error because (1) it
> doesn't do what I expect and (2) for folks that want the behavior
> currently gotten with that syntax can instead just use a space inst
Hi,
On Thu, Feb 14, 2019 at 11:35 AM Viresh Kumar wrote:
>
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his t
Am 14.02.19 um 09:22 schrieb Viresh Kumar:
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his tree [2], which al
Nate Weaver wrote:
> Upon further digging, this is an issue in gettext's code on macOS:
> The function _nl_language_preferences_default (in langprefs.c) specifically
> breaks early when it sees the literal string "en" in the list (from the
> "AppleLanguages" defaults key), but not when it gets "en
Nate Weaver wrote:
>>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
Looks like the issue appeared after updating git from brew.
[...]
A quick search revealed that brew changed how it builds git recently.
I think, it just didn't include i18n by default before, so I never
On Tue, Jan 15, 2019 at 2:06 PM Nate Weaver wrote:
> Nevermind: I've been informed that this has already been fixed on the git
> trunk
> for gettext, and will be in the next release.
>
> (See: https://savannah.gnu.org/bugs/?49560)
Thanks for the follow-up report. It's good to know that this is f
--Nate Weaver (Wevah)
> On Jan 15, 2019, at 10:43:48, Nate Weaver wrote:
>
>> On Jan 15, 2019, at 09:35:52, Nate Weaver wrote:
>>
>>> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>>>
>>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
Looks like the issue appeared after upda
> On Jan 15, 2019, at 09:35:52, Nate Weaver wrote:
>
>> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>>
>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
>>> Looks like the issue appeared after updating git from brew.
>>>
>>> A quick search revealed that brew changed how it builds g
> On Sep 16, 2018, at 02:15:33, Eric Sunshine wrote:
>
> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
>> Looks like the issue appeared after updating git from brew.
>>
>> A quick search revealed that brew changed how it builds git recently.
>> I think, it just didn't include i18n by defau
On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote:
>
> I am talking about `git bisect replay`. The shell script, as far as I
> can see, only updates the references (ref/bisect/*) and never checks if
> the revisions marked as 'good' are ancestors of the 'bad' one.
> Therefore, $GIT_DIR/BISECT_ANCES
On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote:
> > When Git replays the bisect log, it only updates refs/bisect/bad,
> > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in
> > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies
> > that all good commit
Hi,
On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote:
>
> Hello again,
>
> after looking into this today, I'm not sure if this can be considered a
> bug - it's just that I expected Git to check out the exact commit to
> test that was there before resetting the bisect. That made me uncertain
> wh
Hello again,
after looking into this today, I'm not sure if this can be considered a
bug - it's just that I expected Git to check out the exact commit to
test that was there before resetting the bisect. That made me uncertain
whether Git restored the correct state.
When I looked at what Git actua
On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> To debug I think it would be interesting to see the output of the
> following commands just before we get different results:
>
> git for-each-ref 'refs/bisect/*'
>
> and
>
> git log -1 --format=oneline
>
I placed the following snippe
On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí wrote:
>
> On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> >
> > Could you try to check that? And first could you give us the output of:
> >
> > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> > 94710cac0ef4ee177a63b5227664b38c95b
(I'm sorry about the formatting, here's the message again.)
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.
On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
>
> Could you try to check that? And first could you give us the output of:
>
> git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> 94710cac0ef4ee177a63b5227664b38c95bbf703
$ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí wrote:
>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.
> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisecting: a merge base mus
Just checked gitk, it seems to work fine including children windows.
This problem seems to affect git-gui only.
On Thu, Nov 29, 2018 at 5:16 AM Eric Sunshine wrote:
>
> On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > > v2.19.2, ins
On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> >
> > `git-gui` is my much beloved go-to tool for everything git.
> > Unfortunately, on my new Macbook Air it seems to have a bug.
On 11/28/2018 2:45 PM, Derrick Stolee wrote:
I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
cop
On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
>
> v2.19.2, installed from brew on macOS Mojave 14.2.1.
>
> `git-gui` is my much beloved go-to tool for everything git.
> Unfortunately, on my new Macbook Air it seems to have a bug. When I
> first load the program, the parent window populates n
I was afraid that was the reason. Oh well, at least we know why :-)
Thanks Ævar!
Best-F
> On Nov 11, 2018, at 9:00 AM, Ævar Arnfjörð Bjarmason wrote:
>
>
>> On Sun, Nov 11 2018, Federico Lucifredi wrote:
>>
>> git clone of non-existent repository results in request for credentials
>>
>> REP
On Sun, Nov 11 2018, Federico Lucifredi wrote:
> git clone of non-existent repository results in request for credentials
>
> REPRODUCING:
> sudo apt install git
> git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does
> not exist
>
> Git will then prompt for username and pa
On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
> Looks like the issue appeared after updating git from brew.
>
> A quick search revealed that brew changed how it builds git recently.
> I think, it just didn't include i18n by default before, so I never
> noticed this.
>
> Anybody here familiar
Looks like the issue appeared after updating git from brew.
I tried it on a different mac laptop, git 2.18 still used English, but
after updating to 2.19 it started using secondary language.
A quick search revealed that brew changed how it builds git recently.
I think, it just didn't include i18n
Tried what you suggested - it seems, it only ignores English. In you
example, with Swedish as primary and German as secondary, git uses
Swedish.
With more that one secondary language, the one with a higher priority
is being used, as expected. I also tried using non-generic English
(English-UK and
On Fri, Sep 14 2018, Niko Dzhus wrote:
> It doesn't use English when other language is available as a secondary
> language.
>
> Reproducing:
>
> 1. Open "Language & Region" in macos settings
> 2. In "Preferred languages" box, set English as a primary language.
> 3. Add another language, that gi
On Thu, Jun 14, 2018 at 02:53:03PM +0200, Juan Navarro wrote:
> Gitk "find commit" search function doesn't follow the "IgnCase" option that
> is selectable with a combo selector on the right side of the window; it
> should be searching in a case-insensitive way, but it doesn't.
>
> Steps to reprod
On Fri, May 11, 2018 at 09:44:54PM -0400, Surenkumar Nihalani wrote:
> Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at
> cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected
> fdda486ad43a6e6b5dc5f2795ce27124e0686752)
This generally indicates that somebody was pushi
Hi,
On Fri, Apr 27, 2018 at 2:45 PM, Totsten Bögershausen wrote:
> On 2018-04-26 19:23, Elijah Newren wrote:
>> Sure. First, though, note that I can make it pass (or at least "not
>> ok...TODO known breakage") with the following patch (may be
>> whitespace-damaged by gmail):
>>
>> diff --git a/
On 2018-04-26 19:23, Elijah Newren wrote:
On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote:
Hm,
thanks for the report.
I don't have a high sierra box, but I can probably get one.
t0050 -should- pass automagically, so I feel that I can do something.
Unless someone is faster of cour
On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote:
> Hm,
> thanks for the report.
> I don't have a high sierra box, but I can probably get one.
> t0050 -should- pass automagically, so I feel that I can do something.
> Unless someone is faster of course.
Sweet, thanks for taking a look.
On 26.04.18 18:48, Elijah Newren wrote:
> On HFS (which appears to be the default Mac filesystem prior to High
> Sierra), unicode names are "normalized" before recording. Thus with a
> script like:
>
> mkdir tmp
> cd tmp
>
> auml=$(printf "\303\244")
> aumlcdiar=$(printf "\141\31
o way to replicate that on an existing repo
without re-cloning, as my
https://public-inbox.org/git/874lkuvtve@evledraar.gmail.com/
explains.
>
>> -----Original Message-
>> From: Bryan Turner [mailto:btur...@atlassian.com]V
>> Sent: 19 April 2018 23:14
>> To: Andrew Du
rosoft/vscode/issues/48211 if anyone wants
to chime in with advice over there :-)
Thanks,
Andy
> -Original Message-
> From: Bryan Turner [mailto:btur...@atlassian.com]
> Sent: 19 April 2018 23:14
> To: Andrew Ducker
> Cc: git@vger.kernel.org
> Subject: Re: Bug Report - Pull
Andrew,
On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
wrote:
>
> What happens:
> When I create a new tag on the remote (changing nothing else)
> "git pull origin master" produces the following:
> From git.internal.company.com:team/testrepo
>* branchmaster -> FETCH_HEAD
>
l.com] On Behalf Of Junio C Hamano
Sent: Wednesday, March 07, 2018 23:03
To: Vromen, Tomer
Cc: git@vger.kernel.org
Subject: Re: Bug report: git-stash doesn't return correct status code
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git c
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git checkout -b new-feature-branch && git stash pop
>>
>> This is useful when I realize that I want to open a new branch for my
>> changes (that I haven't committed yet).
>> However, I might have forgotten to save my changes in
"Vromen, Tomer" writes:
>> git stash && git checkout -b new-feature-branch && git stash pop
>
> This is useful when I realize that I want to open a new branch for my changes
> (that I haven't committed yet).
> However, I might have forgotten to save my changes in the editor, so
> git-stash will
Jeff King wrote:
> On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
>> Jeff King writes:
>>> That's probably a reasonable sanity check, but I think we need to abort
>>> and not just have a too-small DISPLAY array. Because later code like the
>>> hunk-splitting is going to assume th
On Fri, Mar 02, 2018 at 01:53:32PM -0800, Junio C Hamano wrote:
> Sam Kuper writes:
>
> > 1. It would yield, IIUC, less flexibility to create new kinds of view
> > based on a consistent, standardised underlying model.
> >
> > 2. It is harder to read, for some types of input (e.g. prose) than the
On Fri, Mar 02, 2018 at 05:30:28PM +, Sam Kuper wrote:
> On 02/03/2018, Jeff King wrote:
> > Unfortunately, I don't think there's an easy way to do what you want
> > (show word-diffs but apply the full diff).
>
> Oh :(
>
> That would be a *very* useful feature to have, especially where
> mu
On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > That's probably a reasonable sanity check, but I think we need to abort
> > and not just have a too-small DISPLAY array. Because later code like the
> > hunk-splitting is going to assume that there's a 1:1
Sam Kuper writes:
> 1. It would yield, IIUC, less flexibility to create new kinds of view
> based on a consistent, standardised underlying model.
>
> 2. It is harder to read, for some types of input (e.g. prose) than the
> view generated by the existing word-diff algorithm.
The loss of line-end
On 02/03/2018, Junio C Hamano wrote:
> Jeff King writes:
>> Unfortunately, I don't think there's an easy way to do what you want
>> (show word-diffs but apply the full diff).
>
> The current "word-diff" discards the information on where the lines
> end, and it is pretty much hopeless/useless in t
Jeff King writes:
> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).
The current "word-diff" discards the information on where the lines
end, and it is pretty much hopeless/useless in the context of "add
-p". It would be a good ad
On 02/03/2018, Jeff King wrote:
> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).
Oh :(
That would be a *very* useful feature to have, especially where
multiple small (e.g. single character or single word) changes are
sprinkled th
On 02/03/2018, Jonathan Nieder wrote:
> Is this reproducible for you?
Yes. It seems to occur consistently, given the same input.
> Do you have more details about how I can reproduce it?
Unfortunately, the particular git repo I encountered it on is private,
otherwise I would point you to it.
I
Jeff King writes:
> That's probably a reasonable sanity check, but I think we need to abort
> and not just have a too-small DISPLAY array. Because later code like the
> hunk-splitting is going to assume that there's a 1:1 line
> correspondence. We definitely don't want to end up in a situation wh
On Fri, Mar 02, 2018 at 08:53:34AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Because the array is full of "undef". See parse_diff(), which does this:
> >
> > my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
> > ...
> > @colored = run_cmd_pipe(@display_cmd);
> > ...
>
Jeff King writes:
> Because the array is full of "undef". See parse_diff(), which does this:
>
> my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
> ...
> @colored = run_cmd_pipe(@display_cmd);
> ...
> for (my $i = 0; $i < @diff; $i++) {
> ...
> push @{$hunk[-1
On Thu, Mar 01, 2018 at 11:04:34PM -0800, Jonathan Nieder wrote:
> > Use of uninitialized value $_ in print at
> > /usr/lib/git-core/git-add--interactive line 1371, line 75.
> [...]
>
> Strange. The relevant line, for reference:
>
> $ dpkg-deb --fsys-tarfile git_2.11.0-3+deb9u2_amd64.deb |
>
On Fri, Mar 02, 2018 at 01:19:35AM +, Sam Kuper wrote:
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch
That's not how interactive.diffFilter is supposed to work.
It's meant to have the output of an existing diff piped in
Hi,
Sam Kuper wrote:
> First, background. I encountered a bug on Debian Stretch, using this
> git version:
>
> $ git --version
> git version 2.11.0
>
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch
>
> and after having answere
Hi all,
On Thu, 22 Feb 2018, Stefan Beller wrote:
> On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote:
> > +git-for-windows
First of all, this is clearly not a Windows-specific problem, as the index
file *is* updated, and that is simply the same behavior as on Linux/macOS.
> > Raining Cha
On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote:
> +git-for-windows
> Hi,
>
> Raining Chain wrote:
>
>> On Windows 10, git version 2.16.2.windows.1, running the command
>>
>> git status
>>
>> will trigger a file change event to file C:\myPath\.git "Attributes
>> changed."
>>
>> This cause
+git-for-windows
Hi,
Raining Chain wrote:
> On Windows 10, git version 2.16.2.windows.1, running the command
>
> git status
>
> will trigger a file change event to file C:\myPath\.git "Attributes changed."
>
> This causes problems when using scripts that detect file changes such
> as tsc -w (Typ
On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote:
> Given that all references to this shell function seem to do
>
> sometree=$(toptree_for_commit $something)
>
> and then $sometree is used as if it were a tree object name, I can
> understand why the lack of --no-show-signature in the o
Hi Bulat,
Please make sure to keep the Git mailing list in Cc: (I get *very* prickly
when Git users treat me as a free-of-cost help desk, and when I get that
annoyed, I stop helping).
On Tue, 6 Feb 2018, Bulat Musin wrote:
> Yes, I tested again.
>
> With built 2.16... and it shows error message
Hi,
On Mon, 5 Feb 2018, Bulat Musin wrote:
> Now there are 3 sequential commits, I want to squash them into 1:
>
> git rebase -i HEAD~2
>
> In editor I changed all "pick" to "squash", saved file, I got:
>
> error: cannot 'squash' without a previous commit
You cannot start with a squash. You h
Stephen R Guglielmo writes:
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index cc033af73..dec085a23 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -475,7 +475,7 @@ squash_msg () {
>
> toptree_for_commit () {
>
On Mon, Feb 5, 2018 at 9:30 AM, Stephen R Guglielmo
wrote:
> On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
> wrote:
>> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
Stefan Beller writes:
> There has not been fe
On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
wrote:
> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
There has not been feedback for a while on this thread.
I think that is because subt
Stephen R Guglielmo writes:
> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
>>
>> Sorry I can't help more.
>>
>> Good luck,
>>
>> Avery
>
> Thanks all for the discussion/replies.
>
> We use subtrees extensively in our environment right now. The "sub"
> repos (90+) are located on GitHub,
On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun wrote:
> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>> There has not been feedback for a while on this thread.
>>> I think that is because subtrees are not in anyone's hot
>>> interest area currently.
>>>
>>> T
On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>> There has not been feedback for a while on this thread.
>> I think that is because subtrees are not in anyone's hot
>> interest area currently.
>>
>> This is definitely the right place to submit&discuss bugs.
>> Loo
Stefan Beller writes:
> There has not been feedback for a while on this thread.
> I think that is because subtrees are not in anyone's hot
> interest area currently.
>
> This is definitely the right place to submit&discuss bugs.
> Looking through "git log --format="%ae %s" -S subtree",
> it seems
On Tue, Jan 30, 2018 at 11:15 AM, Stephen R Guglielmo
wrote:
> Hi, just following up on this bug report. I have not heard back. Is
> there additional information that's needed? Is there a better place to
> file bug reports?
>
> Additionally, I have confirmed that this bug still exists with git
> v
Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?
Additionally, I have confirmed that this bug still exists with git
version 2.16.1.
Thanks
On Thu, Jan 18, 2018 at 11:19 AM, Stephen R Gugli
Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?
Thanks
On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
wrote:
> Hi all,
>
> I've noticed an issue regarding the use of `git subtree add
On Fri, Jan 05, 2018 at 02:37:25PM -0800, Junio C Hamano wrote:
> Well, MaintNotes on the 'todo' branch needs a bit of updating, as it
> says something somewhat misleading.
>
> -- >8 --
> Subject: MaintNotes: clarify the purpose of maint->master upmerge
Yup, this makes sense. Thanks for clarifyi
Jeff King writes:
> On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Out of curiosity, did this change at some point? I thought the process
>> > used to be to merge to maint, and then pick up topics in master by
>> > merging maint to master.
>>
>>
Hi Peff,
On Fri, 5 Jan 2018, Jeff King wrote:
> On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:
>
> > On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> >
> > > Done: https://github.com/git-for-windows/git/pull/1421
> > >
> > > I added credit to Jeff in the PR's description.
> >
Hi,
On Fri, 5 Jan 2018, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
> >
> >> Indeed interesting... this one's for the books...
> >> Thanks for the patches. Any idea when these are going to make it to the
> >> official Git clien
On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Out of curiosity, did this change at some point? I thought the process
> > used to be to merge to maint, and then pick up topics in master by
> > merging maint to master.
>
> If you look at "Sync with main
Jeff King writes:
> Out of curiosity, did this change at some point? I thought the process
> used to be to merge to maint, and then pick up topics in master by
> merging maint to master.
If you look at "Sync with maint" merges made to 'master', you'd
notice that most of them are only updating Do
On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:
> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
>
> > Done: https://github.com/git-for-windows/git/pull/1421
> >
> > I added credit to Jeff in the PR's description.
>
> Sadly, the PR's description won't make it into the commit hist
Johannes Schindelin writes:
> Hi Isaac,
>
> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
>
>> Done: https://github.com/git-for-windows/git/pull/1421
>>
>> I added credit to Jeff in the PR's description.
>
> Sadly, the PR's description won't make it into the commit history, and the
> authorship reall
Hi Isaac,
On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> Done: https://github.com/git-for-windows/git/pull/1421
>
> I added credit to Jeff in the PR's description.
Sadly, the PR's description won't make it into the commit history, and the
authorship really should have been retained.
I found Peff's
On Fri, Jan 05, 2018 at 11:53:50AM -0800, Junio C Hamano wrote:
> > They haven't even been reviewed yet. If they get good feedback, then the
> > maintainer will pick them up, then merge them to 'next', and then
> > eventually to 'master', after which they'd become part of the next
> > major releas
Jeff King writes:
> On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
>
>> Indeed interesting... this one's for the books...
>> Thanks for the patches. Any idea when these are going to make it to the
>> official Git client builds? (specifically the Windows one)
>
> They haven't even
Done: https://github.com/git-for-windows/git/pull/1421
I added credit to Jeff in the PR's description.
Note that I tried compiling master, but failed due to a reason
unrelated to this patch:
builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory
Maybe I wasn't building it r
1 - 100 of 331 matches
Mail list logo
