When gc --auto is called in the presence of worktrees, it fails to take
*all* reflogs into account when trying to retain reachable objects, and as
a consequence data integrity goes pretty much to hell.
This patch provides a test case in the hopes that this bug gets fixed,
after an initial attempt
... and a half-working workaround for the auto-gc case.
This patch series really is just another attempt to prod Duy into fixing
this instead of dabbling with shiny new toys ;-)
Changes since "v0":
- split out the test case, both to make it easier for Duy to integrate
it into the patch series
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it,
A hundred years ago I added this code because a "standalone" ref
parsing code was not available from refs.c and the file was going through
some heavy changes that refactoring its ref parsing code out was not
an option. I promised to kill this parse_ref() eventually. I'm
fulfilling it today (or soon
This is basically the extended version of resolve_gitlink_ref() where we
have access to more info from the underlying resolve_ref_recursively() call.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 20 ++--
refs.h | 3 +++
2 files changed, 17 insertions(+), 6 deletions(-)
diff
Hi Christian,
We are using a private repo (Github Enterprise). Let me give you the
details you requested.
On Git Server: git version 2.6.5.1574.g5e6a493
On my client: git version 2.10.1 (Apple Git-78)
I’ve tried to reproduce it with public repos, but couldn’t do so. If I
could get an error/l
@Samuel Lijin
I tried now and I get:
"merge: branch_name
- not something we can merge".
Maybe that is something easy to fix but currently I am using a
workaround script so I am not putting any more effort at this at the
moment.
@David Aguilar
That's true but the trailing slash is already there. Th
Hi Git-developers,
First of all thanks for developing this wonderful scm tool. It's sooo versatile.
I have been using git rebase heavily these days and seem to have found a bug.
If there are two commit messages which have same prefix e.g.
yy This is prefix
xx This is prefix and message
x
Hi,
On Tue, Feb 7, 2017 at 12:27 PM, Serdar Sahin wrote:
> Hi,
>
> When we execute the following lines, the exit code is 1, but it is
> unclear what is the reason of this exit code. Do you have any idea?
>
> git clone --mirror --depth 50 --no-single-branch
> g...@github.hede.com:Casual/hodo-serve
Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10)
but probably never used outside refs-internal.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs/files-backend.c | 3 +++
refs/refs-internal.h | 4
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs/files-ba
On Wed, Feb 8, 2017 at 3:24 PM, David Turner wrote:
> On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote:
>> On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote:
>> > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote:
>> >> And we can't grep for fatal errors anyway. The problem that led to
>> >
On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote:
> On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote:
> > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote:
> >> And we can't grep for fatal errors anyway. The problem that led to
> >> 329e6e8794 was this line
> >>
> >> warning: There are
101 - 112 of 112 matches
Mail list logo
