On Tue, Oct 15, 2019 at 2:13 PM Wink Saville wrote:
>>
>> Something like this makes sense and I've thought about the problem for
>> a long time. Unfortunately it's quite a bit trickier to do this.
>>
>> It would solve the problem more generally though, and definitely seems
>> like the right approa
On Mon, Oct 14, 2019 at 8:07 PM Junio C Hamano wrote:
>
> Wink Saville writes:
>
> > When --prefix-tags is passed to `git remote add` the tagopt is set to
> > --prefix-tags and a second fetch line is added so tags are placed in
> > a separate hierarchy per remote.
>
>
> In the olden days, there w
From: Jacob Keller
The depth variable already contains "--depth=", so expanding it with an
additional --depth when invoking the update-clone git submodule--helper
is incorrect.
Signed-off-by: Jacob Keller
---
I'm *reasonably* sure this is correct, but I am not sure how t
On Wed, Jun 26, 2019 at 3:44 PM Taylor Blau wrote:
>
Ok, now I've got some time to look at the code itself.
> ref-filter.c| 89 +
> t/t6300-for-each-ref.sh | 26
> 2 files changed, 89 insertions(+), 26 deletions(-)
>
> diff --git
On Wed, Jun 26, 2019 at 3:44 PM Taylor Blau wrote:
>
> Since cfe004a5a9 (ref-filter: limit traversal to prefix, 2017-05-22),
> the ref-filter code has sought to limit the traversals to a prefix of
> the given patterns.
>
> That code stopped short of handling more than one pattern, because it
> mea
On Mon, Jun 3, 2019 at 3:39 PM Matthew DeVore wrote:
>
> On Mon, Jun 03, 2019 at 03:07:40PM -0700, Jacob Keller wrote:
> > > +/*
> > > + * Similar to ALLOC_GROW but handles updating of the nr value and
> > > + * zeroing the bytes of the newly-grown array element
On Fri, May 31, 2019 at 5:40 PM Matthew DeVore wrote:
>
> Introduce a new macro ALLOC_GROW_BY which automatically zeros the added
> array elements and takes care of updating the nr value. Use the macro in
> code introduced earlier in this patchset.
>
> Signed-off-by: Matthew DeVore
> ---
> cache
On Wed, May 22, 2019 at 5:04 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Thu, May 23 2019, Jacob Keller wrote:
>
> > Hi,
> >
> > I've had a few times where I was curious of when a submodule got set
> > to a specific commit.
> >
> > I notice
Hi,
I've had a few times where I was curious of when a submodule got set
to a specific commit.
I noticed that git describe has "blob" support, which outputs something like
:/path/to/file
using the revision walking machinery.
I'm curious if anyone knows if that sort of revision walk could be
ex
On Mon, May 6, 2019 at 7:55 PM Jeff King wrote:
> Here's what a patch might look like to implement "0". By still using
> xargs in the unlimited code path, it's not too bad. I dunno.
>
> ---
> diff --git a/Makefile b/Makefile
> index daba958b8f..0765a59b7a 100644
> --- a/Makefile
> +++ b/Makefile
>
On Mon, May 6, 2019 at 4:43 PM Jeff King wrote:
>
> On Mon, May 06, 2019 at 04:34:09PM +0700, Duy Nguyen wrote:
>
> > > However, it comes at a cost. The RSS of each spatch process goes from
> > > ~50MB to ~1500MB (and peak memory usage may be even higher if make runs
> >
> > 1.5G should be fine. T
On Sun, May 5, 2019 at 11:16 AM brian m. carlson
wrote:
>
> On Sun, May 05, 2019 at 12:27:31PM +0200, Ax Da wrote:
> > The documentation doesn't seem to be clear about which characters are
> > allowed as branch names.
> >
> > We have been using umlauts and apostrophes in our branch names, and bot
On Fri, May 3, 2019 at 11:09 AM Jeff King wrote:
>
> On Fri, May 03, 2019 at 04:42:11PM +0200, SZEDER Gábor wrote:
>
> > > Since you *could* include it, I now assume that Coccinelle does not need
> > > to follow the `#include`s (otherwise, it would have complained about not
> > > finding the `wind
On Sat, May 4, 2019 at 10:28 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > I think spatch is smart enough not to hit the same header multiple
> > times. But the problem is that we invoke it once per file, so it
> > actually processes cache.h many times. That's slow, but also produces
> > b
On Fri, Apr 5, 2019 at 8:03 AM Elijah Newren wrote:
>
> This series adds a new configuration option, merge.directoryRenames,
> for setting how to make use of directory rename detection heuristics.
> The default becomes "conflict", meaning that conflicts are reported
> instead of silently moving pa
On Mon, Mar 25, 2019 at 4:37 PM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 11:21:19PM +, Michael Platings wrote:
>
> > > I work on a project that needs a major reformatting, and one thing
> > > delaying me was the lack of an ability to ignore commits during blame.
> >
> > I think we understa
On Tue, Mar 12, 2019 at 9:52 AM Elijah Newren wrote:
>
> On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine wrote:
> >
> > On Tue, Mar 12, 2019 at 8:19 AM Duy Nguyen wrote:
> > > On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood
> > > wrote:
> > > > I tend to agree with this but that's probably because
On Mon, Mar 11, 2019 at 2:09 AM wrote:
>
> Hey Git people,
>
> I didn't get a reply and I'm not sure what the appropriate ping
> interval is, or when I should conclude that no one is interested.
>
> There seemed to be some vaguely positive feedback before I embarked on
> this project. At the same
On March 8, 2019 1:57:41 AM PST, "Nguyễn Thái Ngọc Duy"
wrote:
>"git checkout" doing too many things is a source of confusion for many
>users (and it even bites old timers sometimes). To remedy that, the
>command will be split into two new ones: switch and
>something-to-checkout-paths. The goo
On March 10, 2019 4:19:28 AM PDT, Duy Nguyen wrote:
>On Fri, Mar 8, 2019 at 5:17 PM Nguyễn Thái Ngọc Duy
>wrote:
>> - --index has a different meaning in git-apply. I don't have a good
>> suggestion except "yeah we have two different worlds now, the old
>> and the new one"
>
>I will rename
From: Jacob Keller
If you try to use git describe --contains with --all, the exclude and
match patterns are silently ignored.
This results in unexpected behavior, as you may try to provide patterns
and expect it to change the result.
Check for this, and have describe die when it encounters
On Wed, Jan 30, 2019 at 1:51 PM Victor Porton wrote:
>
> On 30/01/2019 23:49, Jacob Keller wrote:
> > On Wed, Jan 30, 2019 at 7:22 AM Victor Porton wrote:
> >> I want Git to display all branches created by me.
> >>
> >> So we need the new feature of Gi
On Wed, Jan 30, 2019 at 7:22 AM Victor Porton wrote:
>
> I want Git to display all branches created by me.
>
> So we need the new feature of Git, to display all branches created by a
> given user ("me" by default).
>
> I think, the similar feature for tags may also be useful.
>
Branches don't con
On Tue, Jan 8, 2019 at 12:47 PM Markus Wiederkehr
wrote:
>
> On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab wrote:
> >
> > On Jan 08 2019, Markus Wiederkehr wrote:
> >
> > > Would it be possible to retain this information?
> >
> > You could use the reflog of the current branch, where it is the se
On Wed, Dec 19, 2018 at 2:36 PM Jonathan Nieder wrote:
> In Linux kernel land, Documentation/process/submitting-patches.rst
> contains the following:
>
> -- >8 --
> If your patch fixes a bug in a specific commit, e.g. you found an issue using
> ``git bisect``, please use the 'Fixes:' tag with the
On Fri, Dec 14, 2018 at 9:47 AM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:38 PM Duy Nguyen wrote:
> >
> > On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> > >
> > > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > > Even wit
On Fri, Dec 14, 2018 at 9:38 AM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> >
> > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > > FETCH_HEA
On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> FETCH_HEAD... will forever be backed by filesystem. HEAD for example
> is part of the repository signature and must exist as a file. We could
> also lookup pseudo refs with re
On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo wrote:
>
> On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
> >
> > > > The current situation is definitely a problem. If I am in a worktree,
> > > > using "head" should be the same as "HEAD".
> >
> > By any chance, is your file system case insen
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 of the solutions overlap with this thing you want, but I think it's
> >> worth keeping the distinction between the two in
On Mon, Oct 8, 2018 at 8:22 PM Jeff King wrote:
>
> On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
>
> > Julia Lawall writes:
> >
> > >> Doing the same for -S is much harder at the machinery level, as it
> > >> performs its thing without internally running "diff" twice, but just
On Fri, Oct 5, 2018 at 12:00 PM Jeff King wrote:
> That's OK, too, assuming people would actually want to use it. I'm also
> OK shipping this (with the "make -j" fix you suggested) and seeing if
> anybody actually complains. I assume there are only a handful of people
> running coccicheck in the f
On Fri, Oct 5, 2018 at 1:17 AM Junio C Hamano wrote:
> If one wants to emulate this with the versions of Git that are
> currently deployed, would it be sufficient to insert "exec false"
> instead of "break"?
>
> The reason I am asking is *not* to imply that we do not need this
> new feature. It i
On Tue, Oct 2, 2018 at 1:18 PM Jacob Keller wrote:
>
> On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:
> >
> > From: Jacob Keller
> >
> > make coccicheck is used in order to apply coccinelle semantic patches,
> > and see if any of the transformations foun
On Wed, Oct 3, 2018 at 8:05 AM SZEDER Gábor wrote:
> In fact, it works finer than ever, because running 1.0.0 with this
> patch on Travis CI notices a possible memmove() -> MOVE_ARRAY()
> conversion:
>
> https://travis-ci.org/szeder/git/jobs/436542684#L576
>
> Surprisingly, running 1.0.0 without
On Wed, Oct 3, 2018 at 3:17 AM SZEDER Gábor wrote:
>
> On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote:
> > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
> >
> > > make coccicheck is used in order to apply coccinelle semantic patches,
On Tue, Oct 2, 2018 at 2:19 PM Jeff King wrote:
>
> We added faster equality-comparison functions for hashes in
> 14438c4497 (introduce hasheq() and oideq(), 2018-08-28). A
> few topics were in-flight at the time, and can now be
> converted. This covers all spots found by "make coccicheck"
> in ma
On Tue, Oct 2, 2018 at 1:31 PM Jeff King wrote:
> Actually, I guess we do not need to save $? at all, since we have only a
> single process to care about. So even simpler:
>
> spatch ... 2>$@+ 2>$@.log ||
> {
> cat $@.log
> exit 1
> }
> # if we get here, we were successful
On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:
>
> From: Jacob Keller
>
> make coccicheck is used in order to apply coccinelle semantic patches,
> and see if any of the transformations found within contrib/coccinelle/
> can be applied to the current code base.
>
> Pas
From: Jacob Keller
make coccicheck is used in order to apply coccinelle semantic patches,
and see if any of the transformations found within contrib/coccinelle/
can be applied to the current code base.
Pass every file to a single invocation of spatch, instead of running
spatch once per source
On Tue, Oct 2, 2018 at 1:03 PM Jacob Keller wrote:
>
> From: Jacob Keller
>
> make coccicheck is used in order to apply coccinelle semantic patches,
> and see if any of the transformations found within contrib/coccinelle/
> can be applied to the current code base.
>
> Pas
From: Jacob Keller
make coccicheck is used in order to apply coccinelle semantic patches,
and see if any of the transformations found within contrib/coccinelle/
can be applied to the current code base.
Pass every file to a single invocation of spatch, instead of running
spatch once per source
On Tue, Oct 2, 2018 at 12:55 PM Jeff King wrote:
>
> On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
>
> > make coccicheck is used in order to apply coccinelle semantic patches,
> > and see if any of the transformations found within contrib/coccinelle/
>
From: Jacob Keller
make coccicheck is used in order to apply coccinelle semantic patches,
and see if any of the transformations found within contrib/coccinelle/
can be applied to the current code base.
Pass every file to a single invocation of spatch, instead of running
spatch once per source
On Mon, Sep 17, 2018 at 12:26 PM Junio C Hamano wrote:
> FWIW, I didn't mean to say that we should give users a way to
> recover. Your "commit -a" or "commit $path" protection just
> prevents the situation from happening, and I think it is sufficient.
>
> The sole point I wanted to raise by bring
On Mon, Sep 17, 2018 at 11:15 AM Jeff King wrote:
>
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
>
> > > On the other hand, if I am keeping some change that should never be
> > > in a commit in the working tree file, and building the contents in
> > > the index using "add -p" to i
On Mon, Sep 17, 2018 at 10:09 AM Junio C Hamano wrote:
>
> It usually is safer (simply because you do not have to think about
> it) to start a behaviour change like this as a strict opt-in to gain
> confidence.
I tend to agree, however.. in this case it could be considered safer
to err on the sid
On Fri, Aug 24, 2018 at 7:42 AM Duy Nguyen wrote:
>
> On Fri, Aug 24, 2018 at 5:02 AM Jacob Keller wrote:
> >
> > On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> > > I think the above example forgets "-a" on the final "git commit"
> >
On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> I think the above example forgets "-a" on the final "git commit"
> step. With it added, I can understand the concern (and I am sure
> you would, too).
>
> The user is trying to add everything done in the working tree, and
> "commit -a" would
On Mon, Aug 20, 2018 at 8:43 AM Nguyễn Thái Ngọc Duy wrote:
> Instead, let's handle just this problem for now. This new option
> commit.preciousDirtyIndex, if set to false, will not allow `commit -a`
> to continue if the final index is different from the existing one. I
> don't think this can be a
On Thu, Aug 23, 2018 at 5:16 PM Jeff King wrote:
>
> On Thu, Aug 23, 2018 at 08:06:37PM -0400, Jeff King wrote:
>
> > This almost works:
> >
> > @@
> > expression a, b;
> > statement s;
> > @@
> > - if (oidcmp(a, b)) s
> > + if (!oideq(a, b)) s
> >
> > [...]
>
> > So I really do want s
On Thu, Aug 23, 2018 at 9:30 AM Jeff King wrote:
> I think that audit isn't actually too bad (but definitely not something
> we should do for v2.19). The cocci patch I showed earlier hits most of
> them. It misses the negated ones (e.g., "if (oidcmp(...))"). I'm not
> sure if there's a way to ask
On Sun, Jul 8, 2018 at 9:05 PM Eric Sunshine wrote:
>
> On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller wrote:
> > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > wrote:
> > > static inline int oidcmp(const struct object_id *oid1, const st
On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
wrote:
>
> This is the fourteenth series of patches to switch to using struct
> object_id and the_hash_algo. This series converts several core pieces
> to use struct object_id, including the oid* and hex functions.
>
> All of these patches have been
On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
wrote:
> static inline int oidcmp(const struct object_id *oid1, const struct
> object_id *oid2)
> {
> - return hashcmp(oid1->hash, oid2->hash);
> + return memcmp(oid1->hash, oid2->hash, the_hash_algo->rawsz);
> }
>
Just curious, what
On Thu, May 17, 2018 at 12:46 PM, Stefan Beller wrote:
>>> * sb/diff-color-move-more (2018-04-25) 7 commits
>>...
>>>
>>> Will merge to 'next'.
>>
>>I did not get around to fix it up, there are still review
>>comments outstanding. (The test is broken in the last commit.)
>
> This is a reroll of s
On Fri, Jun 1, 2018 at 10:46 AM, Phillip Wood wrote:
> From: Phillip Wood
>
> recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p:
> calculate offset delta for edited patches", 2018-03-05) required all
> context lines to start with a space, empty lines are not counted. This
> was inten
On Mon, May 21, 2018 at 2:54 PM, Jeff King wrote:
> Yes, I think this is clearly a case where all of the single merge-bases
> we could show are equally good. And I don't think we should promise to
> show a particular one, but I _do_ think it's friendly for us to have
> deterministic tie-breakers (
On Sun, May 20, 2018 at 3:17 AM, Martin Ågren wrote:
> +/**
> + * Add formatted string to the end of `list`. This function ignores
> + * the value of `list->strdup_strings` and always appends a freshly
> + * allocated string, so you will probably not want to use it with
> + * `strdup_strings = 0`.
On Fri, May 18, 2018 at 4:31 AM, Anmol Sethi wrote:
> This definitely works but it would be more clean to just have git ignore the
> binary files from the get go.
>
Sure it'd be more convenient for you. But there are loads of possible
combinations, and the idea of what constitutes unwanted files
On Thu, May 17, 2018 at 2:48 PM, Junio C Hamano wrote:
> Martin Ågren writes:
>
>> After we initialize the various fields in `opts` but before we actually
>> use them, we might return early. Move the initialization further down,
>> to immediately before we use `opts`.
>>
>> This limits the scope
On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
> I think it’d be great to have an option to have git ignore binary files. My
> repositories are always source only, committing a binary is always a mistake.
> At the moment, I have to configure the .gitignore to ignore every binary file
> and
On Wed, May 16, 2018 at 12:29 PM, Martin Ågren wrote:
> On 16 May 2018 at 18:41, Stefan Beller wrote:
>> On Wed, May 16, 2018 at 9:30 AM, Martin Ågren wrote:
>>>
>>> This patch is best viewed using something like this (note the tab!):
>>> --color-moved --anchored=" trees[nr_trees] = parse_t
On Wed, May 16, 2018 at 9:41 AM, Stefan Beller wrote:
> + Jonathan Tan for a side discussion on anchoring.
>
> On Wed, May 16, 2018 at 9:30 AM, Martin Ågren wrote:
>>
>> This patch is best viewed using something like this (note the tab!):
>> --color-moved --anchored=" trees[nr_trees] = parse
On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic
wrote:
> Hi Dscho,
>
> On 05/05/2018 23:57, Johannes Schindelin wrote:
>>
>> > > This builtin does not do a whole lot so far, apart from showing a
>> > > usage that is oddly similar to that of `git tbdiff`. And for a
>> > > good reason: the next comm
On Fri, Apr 27, 2018 at 12:13 PM, Bryan Turner wrote:
> On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote:
>>
>> The other change was rather than using
>> ""+refs/tags/*:refs/remote-tags/$name/*"
>> I've changed it to "+refs/tags/*:refs/remote/tags/$name/*" which seems
>> cleaner.
>> Again,
On Thu, May 3, 2018 at 11:05 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, May 03 2018, Johannes Schindelin wrote:
>
>> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
>> what changed between two iterations sent to the Git mailing list) is slightly
>> less useful for
On Wed, May 2, 2018 at 6:45 AM, Derrick Stolee wrote:
> On 5/2/2018 8:42 AM, Derrick Stolee wrote:
>>
>> On 5/1/2018 2:40 PM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> The biggest change in v3 is the no change at all to the code, but a
>>> lengthy explanation of why I didn't go for Derrick's simpler
On Tue, May 1, 2018 at 4:24 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> I also agree, I'd prefer if we aim for the mapping to be something
>> which works for all refs in the future, even if such support isn't
>> added now, which is why i've prop
On Tue, May 1, 2018 at 12:24 PM, Ævar Arnfjörð Bjarmason
wrote:
> Thanks a lot for working on this, it's great to have something the
> direction of getting rid of this discrepancy between the 1=1 mapping for
> branches, but the 1=many mapping for tags. My recent patch series and
> the pruneTags fe
On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote:
> Hi,
>
> I discovered that I was able to delete the feature branch I was in, due to
> some fat fingering on my part and case insensitivity. I never realized this
> could be done before. A quick google search did not give me a whole lot
On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote:
> On Thu, Apr 26, 2018 at 4:24 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>
>> Hence (1) we should detect and error out when --prefix-tags is used
>> with mirror fetch near where we do the same for track used without
>> mirror fe
On Fri, Apr 27, 2018 at 5:24 PM, Elijah Newren wrote:
> I would expect that a different example involving non-linear history
> would behave the same, if both sides update the submodule in a fashion
> that is just fast-forwarding and one commit contains the other in its
> history. I'm curious if y
On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote:
> We often treating a submodule as a file from the superproject, but not always.
> And in case of a merge, git seems to be a bit smarter than treating it
> as a textfile
> with two different lines.
Sure, but a submodule is checked out "at a c
On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote:
> Wink Saville writes:
>
>> Ideally I would have liked the tags fetched from gbenchmark to have a prefix
>> of gbenchmark/, like the branches have, maybe something like:
>>
>> $ git fetch --tags gbenchmark
>> ...
>> * [new branch] v2
On Tue, Apr 24, 2018 at 12:57 PM, Wink Saville wrote:
> If have a repository with a tag "v1.0.0" and I add a remote repository
> which also has a tag "v1.0.0" tag is overwritten.
>
> Google found [1] from 2011 and option 3 is what I'd like to see. Has it been
> implemented and I just don't see it?
On Mon, Apr 23, 2018 at 10:13 PM, Martin Ågren wrote:
> After we initialize the various fields in `opts` but before we actually
> use them, we might return early. Move the initialization further down,
> to immediately before we use `opts`.
>
> This limits the scope of `opts` and will help a subseq
On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe wrote:
> Kevin, thanks for your feedback.
>
> You have a reasonable point, because usually you don't put the outputs of a
> build into version control, but the build script checks them for being
> current.
>
> On the other hand, when you change branc
On Fri, Apr 20, 2018 at 1:26 AM, Johannes Schindelin
wrote:
> Hi Jake,
>
> On Thu, 19 Apr 2018, Jacob Keller wrote:
>
>> On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote:
>> > Johannes Schindelin writes:
>> >
>> >> On Fri, 13 Apr 2018, Ph
On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote:
> Johannes Schindelin writes:
>
>> Hi Phillip,
>>
>> On Fri, 13 Apr 2018, Phillip Wood wrote:
>>
>>> On 12/04/18 23:02, Johannes Schindelin wrote:
>>> >
>>> > [...]
>>> >
>>> > So: the order of the 3-way merges does matter.
>>> >
>>> > [...]
On Tue, Apr 17, 2018 at 10:27 AM, Lars Schneider
wrote:
>
>> On 16 Apr 2018, at 19:45, Jacob Keller wrote:
>>
>> On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller
>> wrote:
>>> On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider
>>> wrote:
>>>
On Tue, Apr 17, 2018 at 8:34 AM, Robert P. J. Day wrote:
> On Tue, 17 Apr 2018, Junio C Hamano wrote:
>
>> Jacob Keller writes:
>>
>> > Things won't work so well if you set the push url and fetch url to
>> > different repositories. Git assumes that
On Mon, Apr 16, 2018 at 4:13 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> Things won't work so well if you set the push url and fetch url to
>> different repositories. Git assumes that refs updated by "push" will
>> also be reflected via "
On Mon, Apr 16, 2018 at 3:30 PM, Christian Couder
wrote:
> On Mon, Apr 16, 2018 at 5:19 PM, Sergey Organov wrote:
>> Kaartic Sivaraam writes:
>>
>>> 1. I see the following sentence in the "Rebasing merges: a jorney to the
>>> ultimate solution (Road Cle
On Mon, Apr 16, 2018 at 9:19 AM, Robert P. J. Day wrote:
> On Mon, 16 Apr 2018, Andreas Schwab wrote:
>
>> On Apr 16 2018, "Robert P. J. Day" wrote:
>>
>> > i don't understand how you can clearly set the fetch and push URLs
>> > of a remote independently, while the man page nonetheless insists
>>
On Sat, Apr 14, 2018 at 6:27 AM, Jakub Narebski wrote:
> SZEDER Gábor writes:
>> On Fri, Apr 13, 2018 at 11:44 PM, Jakub Narebski wrote:
>>> SZEDER Gábor writes:
In Bash we can do better: run the 'compgen -v __gitcomp_builtin_'
builtin command, which lists the same variables, but
On Mon, Apr 16, 2018 at 7:03 AM, Robert P. J. Day wrote:
>
> another feature i've seen for the very first time ... working with
> kubernetes so i checked it out of github, and part of the instructions
> for that is to make sure you don't accidentally try to push back to
> the github remote, so th
On Mon, Apr 16, 2018 at 10:43 AM, Jacob Keller wrote:
> On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider
> wrote:
>> What if Git kept a LRU list that contains file path, content hash, and
>> mtime of any file that is removed or modified during a checkout. If a
>> file i
On Mon, Apr 16, 2018 at 9:07 AM, Lars Schneider
wrote:
>
>> On 16 Apr 2018, at 04:03, Linus Torvalds
>> wrote:
>>
>> On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano wrote:
>>>
>>> I think Elijah's corrected was_tracked() also does not care "has
>>> this been renamed".
>>
>> I'm perfectly happy
e or fix it? or should we deprecate it?)
>> followed.
>>
>>Rebasing merges: a jorney to the ultimate solution (Road Clear)
>>(written by Jacob Keller)
>
> What article by Jacob is actually meant here I have no idea, please
> check, as this one, and the RFC this
Hi,
I use git blame sometimes to blame against specific revisions, i.e.
"git blame -- " and it would be nice if blame could
figure out how to complete the or revision reference..
I tried to take a stab at adding support for this, but I couldn't
figure out which completion function to use...
I
On Thu, Apr 12, 2018 at 3:02 PM, Johannes Schindelin
wrote:
> Hi Jake,
>
> On Thu, 12 Apr 2018, Jacob Keller wrote:
>
>> On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov wrote:
>> >
>> > Jacob Keller writes:
>> >> On Wed, Apr 11, 2018 at 6:13
On Thu, Apr 12, 2018 at 2:30 AM, Johannes Schindelin
wrote:
>> I think it would be worthwhile to point out that unlike the other commands
>> this will not preserve untracked files. Maybe something like
>> "Note that unlike the `pick` or `merge` commands or initial checkout when the
>> rebase start
On Wed, Apr 11, 2018 at 10:42 PM, Sergey Organov wrote:
> Hi Jacob,
>
> Jacob Keller writes:
>> On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote:
>>> It was rather --recreate-merges just a few weeks ago, and I've seen
>>> nobody actually co
On Wed, Apr 11, 2018 at 6:13 AM, Sergey Organov wrote:
> It was rather --recreate-merges just a few weeks ago, and I've seen
> nobody actually commented either in favor or against the
> --rebase-merges.
>
> git rebase --rebase-merges
>
I'm going to jump in here and say that *I* prefer --rebase-me
On Thu, Apr 5, 2018 at 10:27 PM, Taylor Blau wrote:
> *** BLURB HERE ***
>
Missing subject and cover letter stuff.. did you submit before you
were ready? or did you not mean to include the cover letter? :)
-Jake
> Taylor Blau (2):
> builtin/config.c: treat type specifiers singularly
> built
On Thu, Apr 5, 2018 at 3:48 PM, Johannes Schindelin
wrote:
> From: Ryan Dammrose
>
> This is an attempt to resolve an issue I experience with people that are
> new to Git -- especially colleagues in a team setting -- where they miss
> that their push to a remote location failed because the failur
On Tue, Apr 3, 2018 at 11:53 AM, Alex Ivanov wrote:
> Hi.
> I want to use systemd as fastcgi spawner for gitweb + nginx.
> The traffic is low and number of users is limited + traversal bots. For that
> reason I've decided to use following mimimal services
>
> gitweb.socket
> [Unit]
> Description=
On Tue, Apr 3, 2018 at 12:00 PM, Stefan Beller wrote:
The fun is in the last patch, which allows white space sensitive
languages to trust the move detection, too. Each block that is marked as
moved will have the same delta in {in-, de-}dentation.
I would think this mode might b
On Mon, Apr 2, 2018 at 4:47 PM, Jonathan Tan wrote:
> On Mon, 2 Apr 2018 15:48:47 -0700
> Stefan Beller wrote:
>
>> This is a re-attempt of [1], which allows the moved code detection to
>> ignore blanks in various modes.
>>
>> patches 1-5 are refactoring, patch 6 adds all existing white space op
1 - 100 of 1143 matches
Mail list logo
