On Mon, Nov 12, 2018 at 11:22:09PM +, 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 would need to be able to check out
> one
On Tue, Sep 18, 2018 at 12:41:30PM -0700, Jacob Keller wrote:
> I think having both is good. There are a lot of ways to accidentally
> throw away work, and it's pretty frustrating to have it happen. But
> the reflog is also somewhat complicated, and I've definitely seen a
> lot of developers
On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
> It is neither but if I have to pick one between the two, it is much
> closer to the former than the latter. The primary source of this is
> that we have only *one* pathspec given to the diff machinery, but in
> order to implement
On Tue, Jun 12, 2018 at 03:44:13PM -0400, Steve Litt wrote:
> git filter-branch --tree-filter 'rm -rf docs/propdir' HEAD
...
> What command do I do to remove all mention of doc/propdir and its
> files from my git history?
Are you sure that you pruned all branches? I would have expected a
command
On Fri, May 11, 2018 at 12:56:39PM +, Ben Peart wrote:
> After performing a merge that has conflicts git status will, by default,
> attempt to detect renames which causes many objects to be examined. In a
> virtualized repo, those objects do not exist locally so the rename logic
> triggers
On Tue, May 01, 2018 at 05:08:27PM -0700, Elijah Newren wrote:
> Eckhard, can you add some comments to your commit message mentioning
> the email pointed to by Junio about break detection and rename
> detection being unsafe to use together, as well as the inconsistencies
> in break detection
On Tue, May 01, 2018 at 02:23:51PM +0200, Matthieu Moy wrote:
> I'm fine with it as-is. Before your "fix", the config was ignored
> because overwritten by init_diff_ui_defaults() after reading the
> config, so effect of your change is indeed what the commit message
> describes.
>
> I'm often
On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote:
> That init_diff_ui_defaults() should indeed have been before
> git_config() from the beginning. My bad, I'm the one who
> misplaced it apparently :-(.
Should I have done this "bug fix" in a separate commit or mention it in
the commit
On Tue, May 01, 2018 at 01:00:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
> So didn't we use diff heuristics to begin with, and then regressed? I've
> only given this a skimming, but it's useful to have that sort of
> historical context mentioned explicitly with commit ids.
Sorry for not making
On Fri, Apr 27, 2018 at 01:23:20PM -0700, Elijah Newren wrote:
> I doubt it has ever been discussed before this thread. But, if you're
> curious, I'll try to dump a few thoughts.
Thank you, I try to dump some of mine, too. Maybe let me first stress
that for me copy detection without
On Fri, Apr 27, 2018 at 11:23:56AM +0900, Junio C Hamano wrote:
> I think demoting from copy to rename-only is a good idea, at least
> for now, because I do not believe we have figured out what we want
> to happen when we detect copied files are involved in a merge.
Does anyone know some threads
On Mon, Apr 23, 2018 at 09:15:09AM -0400, Ben Peart wrote:
> In commit 2a2ac926547 when merge.renamelimit was added, it was decided to
> have separate settings for merge and diff to give users the ability to
> control that behavior. In this particular case, it will default to the
> value of
On Fri, Apr 20, 2018 at 11:34:25AM -0700, Elijah Newren wrote:
> Sorry, I think I wasn't being clear. The documentation for the config
> options for e.g. diff.renameLimit, fetch.prune, log.abbrevCommit, and
> merge.ff all mention the equivalent command line parameters. Your
> patch doesn't do
13 matches
Mail list logo
