On Thu, May 2, 2019 at 11:58 PM Jeff King wrote:
> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, bu
Hi Brian,
brian m. carlson 於 2019年5月3日 週五 上午7:15寫道：
>
> On Thu, May 02, 2019 at 08:35:23AM +0800, 林自均 wrote:
> > Thank you for the support! I'll be very happy if my patch can get into
> > the code base. Is there any improvement I can make for this patch?
>
> The patch seems sane to me. There's le
On Thu, Apr 25, 2019 at 02:54:48AM +0200, Eugeniu Rosca wrote:
> > This is unrelated to --pickaxe-raw-diff, -U just implies -p in
> > general. See e.g. "git log -U1".
>
> Oops. Since I use `-U` mostly with `git show`, I missed the
> implication. You are right. Then, my question is how users are
>
On Tue, Apr 23, 2019 at 12:35 PM Emily Shaffer wrote:
>
> This tutorial covers how to add a new command to Git and, in the
> process, everything from cloning git/git to getting reviewed on the
> mailing list. It's meant for new contributors to go through
> interactively, learning the techniques ge
On Thu, May 02, 2019 at 08:35:23AM +0800, 林自均 wrote:
> Thank you for the support! I'll be very happy if my patch can get into
> the code base. Is there any improvement I can make for this patch?
The patch seems sane to me. There's less duplicate code than the patch I
started writing; the goto conc
On Thu, May 02, 2019 at 05:45:09PM -0400, Jeff King wrote:
> Here's what I came up with. Note that there's a bug in 'master' right
> now which causes perf to produce nonsense results. It's due to my
> 0baf78e7bc (perf-lib.sh: rely on test-lib.sh for --tee handling,
> 2019-03-15). I'll fix that sep
They both look fine to me, besides a couple typos in the commit message
in this one.
On Wed, May 01, 2019 at 08:11:52PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This allows to cancel the current merge without reseting worktree/index,
"resetting".
> which is what --abort is for. Like other --quit(s),
On Wed, May 01, 2019 at 10:52:06PM -0400, Jeff King wrote:
> > > * js/partial-clone-connectivity-check (2019-04-21) 1 commit
> > > (merged to 'next' on 2019-04-25 at ebd8b4bffd)
> > > + clone: do faster object check for partial clones
> > >
> > > During an initial "git clone --depth=..." part
Am 27.04.19 um 01:27 schrieb Johannes Schindelin via GitGitGadget:
> From: Johannes Schindelin
>
> They really are unsigned, and we are using e.g. BLOCKSIZE as `size_t`
> parameter to pass to `write_or_die()`.
True, but the compiler converts that value correctly to size_t without
complaint alread
Am 01.05.19 um 20:09 schrieb Jeff King:
> On Mon, Apr 29, 2019 at 05:32:50PM -0400, Johannes Schindelin wrote:
>
>>> Another is that I am not sure how your "fixed format" argument
>>> meshes with the "-b blocksize" parameter to affect the tar/pax
>>> output. The format may be fixed, but it is para
Am 27.04.19 um 01:27 schrieb Rohit Ashiwal via GitGitGadget:
> From: Rohit Ashiwal
>
> As we already link to the zlib library, we can perform the compression
> without even requiring gzip on the host machine.
>
> Note: the `-n` flag that `git archive` passed to `gzip` wants to ensure
> that a repr
On Fri, Apr 26 2019, Johannes Schindelin wrote:
> Hi brian,
>
> On Sat, 13 Apr 2019, brian m. carlson wrote:
>
>> On Fri, Apr 12, 2019 at 09:51:02PM -0400, Jeff King wrote:
>> > I wondered how you were going to kick this in, since users can define
>> > arbitrary filters. I think it's kind of nea
On Wed, May 1, 2019 at 6:30 PM Jonathan Nieder wrote:
>
> Jeffrey Walton wrote:
>
> > I'm attempting to install Git 2.21.0 on Solaris 11.3 x86_64.
> > /usr/gnu/bin is on-path.
> [...]
> > gmake -C gitweb install
> > gmake[1]: Entering directory `/export/home/build/git-2.21.0/gitw
> > eb'
> > gmake
On Thu, May 02 2019, Derrick Stolee wrote:
> On 5/1/2019 4:25 PM, Ævar Arnfjörð Bjarmason wrote:
>> I won't repeat my outstanding v2 feedback about v1 & v2
>> incompatibilities, except to say that I'd in principle be fine with
>> having a v2 format the way this series is adding it. I.e. saying "
On Thu, May 2, 2019 at 11:58 PM Jeff King wrote:
> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, bu
On Thu, May 02, 2019 at 08:05:57PM +0700, Duy Nguyen wrote:
> The difficulty will be coming up with some sane UI that can
> handle that and not leave too many traps behind. I can't see that UI.
Well, I'm still thinking about it. And perhaps a good UI is not that
far away. The following hacky patch
On Thu, May 02, 2019 at 11:38:51PM +0700, Duy Nguyen wrote:
> > Since the decision of whether to use the locks is dependent on the
> > operation being performed, it's an environment variable and not a config
> > option.
>
> And there's also tradeoff for doing it. If git-status will not take
> loc
On 2019.05.01 22:52, Jeff King wrote:
> On Thu, Apr 25, 2019 at 03:16:57PM -0700, Josh Steadmon wrote:
>
> > On 2019.04.25 19:15, Junio C Hamano wrote:
> > > * js/partial-clone-connectivity-check (2019-04-21) 1 commit
> > > (merged to 'next' on 2019-04-25 at ebd8b4bffd)
> > > + clone: do faster
On Thu, May 2, 2019 at 10:07 PM Jeff King wrote:
>
> On Thu, May 02, 2019 at 04:45:36PM +0300, Aleksey Midenkov wrote:
>
> > > Assuming that kdevelop is just running "git status" in the background,
> > > though, there's an easier solution. If it uses "git --no-optional-locks
> > > status" instead,
On Thu, May 2, 2019 at 10:45 PM Phillip Wood wrote:
>
> Hi wh
>
> On 14/04/2019 02:59, wh wrote:
> > Thanks for the info about the upcoming "precious" attribute. Looks useful.
> >
> > I didn't get the impression that Git normally overwrites ignored
> > files.
Please do not include me in these dis
Hi wh
On 14/04/2019 02:59, wh wrote:
Thanks for the info about the upcoming "precious" attribute. Looks useful.
I didn't get the impression that Git normally overwrites ignored
files. I ran some more experiments:
git rebase FETCH_HEAD# bails
git rebase -i FETCH_HEAD # overwrites
gi
On Thu, May 02, 2019 at 04:45:36PM +0300, Aleksey Midenkov wrote:
> > Assuming that kdevelop is just running "git status" in the background,
> > though, there's an easier solution. If it uses "git --no-optional-locks
> > status" instead, that will instruct it not to take the index lock at
> > all.
On Mon, Mar 11 2019, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> We have something much better now: --rebase-merges (which is a
> complete re-design --preserve-merges, with a lot of issues fixed such as
> the inability to reorder commits with --preserve-merges).
Extract dir creation code snippet from copy_or_link_directory to its own
function named mkdir_if_missing. This change will help to remove
copy_or_link_directory's explicit recursion, which will be done in a
following patch. Also makes the code more readable.
Signed-off-by: Matheus Tavares
---
bu
dir_iterator_advance() is a large function with two nested loops. Let's
improve its readability factoring out three functions and simplifying
its mechanics. The refactored model will no longer depend on
level.initialized and level.dir_state to keep track of the iteration
state and will perform on a
Replace usage of opendir/readdir/closedir API to traverse directories
recursively, at copy_or_link_directory function, by the dir-iterator
API. This simplifies the code and avoids recursive calls to
copy_or_link_directory.
This process also makes copy_or_link_directory call die() in case of an
err
Replace the use of strcmp by fspathcmp at copy_or_link_directory, which
is more permissive/friendly to case-insensitive file systems.
Signed-off-by: Matheus Tavares
Suggested-by: Nguyễn Thái Ngọc Duy
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin
Add the possibility of giving flags to dir_iterator_begin to initialize
a dir-iterator with special options.
Currently possible flags are:
- DIR_ITERATOR_PEDANTIC, which makes dir_iterator_advance abort
immediately in the case of an error, instead of keep looking for the
next valid entry;
- DIR_IT
Make the copy_or_link_directory function no longer skip hidden
directories. This function, used to copy .git/objects, currently skips
all hidden directories but not hidden files, which is an odd behaviour.
The reason for that could be unintentional: probably the intention was
to skip '.' and '..' o
This patchset contains:
- a replacement of explicit recursive dir iteration at
copy_or_link_directory for the dir-iterator API;
- some refactoring and behaviour changes at local clone, mainly to
take care of symlinks and hidden files at .git/objects, together
with tests for this types of file
Change warning(..., strerror(errno)) by warning_errno(...). This helps
to unify warning display besides simplifying a bit the code. Also,
improve warning messages by surrounding paths with quotation marks and
using more meaningful statements.
Signed-off-by: Matheus Tavares
---
dir-iterator.c | 2
There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
From: Daniel Ferreira
Create t/helper/test-dir-iterator.c, which prints relevant information
about a directory tree iterated over with dir-iterator.
Create t/t0066-dir-iterator.sh, which tests that dir-iterator does
iterate through a whole directory tree as expected.
Signed-off-by: Daniel Ferre
From: Ævar Arnfjörð Bjarmason
Add tests for what happens when we perform a local clone on a repo
containing odd files at .git/object directory, such as symlinks to other
dirs, or unknown files.
I'm bending over backwards here to avoid a SHA-1 dependency. See [1]
for an earlier and simpler versio
This section describes the two exceptions where refs inside refs/ are
not shared. Except that it's three exceptions, the third one being
refs/rewritten [1]. I was not aware of it when I wrote this part.
Update it to include refs/rewritten.
[1] a9be29c981 (sequencer: make refs generated by the `lab
On Thu, May 2, 2019 at 8:05 PM Duy Nguyen wrote:
> > Part of this is "doctor, it hurts when I stab my eye" :) but I wonder in
> > general whether users are more likely to expect different worktrees to
> > have different views of the refstore, since they way they're created is
> > "I want just this
On Wed, May 1, 2019 at 9:36 PM Jeff King wrote:
>
> On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:
>
> > > Usually when we see racy contention on index.lock, the culprit turns out
> > > to be another unrelated git process refreshing the index. Do you have
> > > anything else run
On 5/1/2019 4:25 PM, Ævar Arnfjörð Bjarmason wrote:
> I won't repeat my outstanding v2 feedback about v1 & v2
> incompatibilities, except to say that I'd in principle be fine with
> having a v2 format the way this series is adding it. I.e. saying "here
> it is, it's never written by default, we'll
On Thu, May 2, 2019 at 7:51 PM Ævar Arnfjörð Bjarmason wrote:
>
>
> On Thu, May 02 2019, Duy Nguyen wrote:
>
> > On Thu, May 2, 2019 at 6:59 PM frank kulow wrote:
> >>
> >> git version 2.21.0.windows.1
> >>
> >> > /c/tmp/gt (Branch_702091a0)
> >> $ git worktree add ../wt master
> >> Preparing wor
On Thu, May 02 2019, Duy Nguyen wrote:
> On Thu, May 2, 2019 at 6:59 PM frank kulow wrote:
>>
>> git version 2.21.0.windows.1
>>
>> > /c/tmp/gt (Branch_702091a0)
>> $ git worktree add ../wt master
>> Preparing worktree (checking out 'master')
>> HEAD is now at f534c32 4
>>
>> > /c/tmp/gt (Branc
On Thu, May 2, 2019 at 6:59 PM frank kulow wrote:
>
> git version 2.21.0.windows.1
>
> > /c/tmp/gt (Branch_702091a0)
> $ git worktree add ../wt master
> Preparing worktree (checking out 'master')
> HEAD is now at f534c32 4
>
> > /c/tmp/gt (Branch_702091a0)
> $ git branch -D master
> error: Cannot
git version 2.21.0.windows.1
> /c/tmp/gt (Branch_702091a0)
$ git worktree add ../wt master
Preparing worktree (checking out 'master')
HEAD is now at f534c32 4
> /c/tmp/gt (Branch_702091a0)
$ git branch -D master
error: Cannot delete branch 'master' checked out at 'C:/tmp/wt'
#but this is possibl
On Wed, May 1, 2019 at 9:58 PM Phillip Wood wrote:
>
>
>
> On 01/05/2019 11:31, Duy Nguyen wrote:
> > On Wed, May 1, 2019 at 5:14 PM Phillip Wood
> > wrote:
> >>
> >> From: Phillip Wood
> >>
> >> These two patches teach read-tree how to avoid overwriting untracked
> >> files when doing '--reset
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
>
> From: Phillip Wood
>
> Currently there is no way to get git to discard changes to the
> worktree without overwriting untracked files. `reset --hard`,
> `checkout --force`, `checkout :/` and `read-tree --reset -u`
"checkout :/" does not use
From: Phillip Wood
If a merge can be fast-forwarded then make sure that we still edit the
commit message if the user specifies -c. The implementation follows the
same pattern that is used for ordinary rewords that are fast-forwarded.
Signed-off-by: Phillip Wood
---
Thanks to Dscho for his comme
Hi Duy
On 01/05/2019 14:11, Nguyễn Thái Ngọc Duy wrote:
> nd/switch-and-restore suggests 'git merge --quit' to get out of a merge
> even though this option is not implemented [1]. It's a soft dependency, no
> actual functionality is broken by the lack of --quit, so I'm sending
> it separately.
Bo
[Trying to revive that discussion]
tbo...@web.de writes:
> The cygwin layer "knows" that "C:\cygwin" is an absolute path,
> but the new string operation does not.
Then use the Cygwin API to produce the corresponding POSIX path and use
that. Also, why does Git not use POSIX realpath on systems wh
47 matches
Mail list logo
