Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility

On Mon, 2013-03-11 at 11:09 -0700, Junio C Hamano wrote: So strictly speaking there is no reason for an extra subshell here, but writing this in the way the patch does makes our intention crystal clear, I think. If you're concerned about the extra processing of the new shell you can use {}

[PATCH] git-new-workdir: Add -f to force new-workdir in existing directory.

From: Paul Smith p...@mad-scientist.net Date: Thu, 13 Nov 2014 14:01:34 -0500 Subject: [PATCH] git-new-workdir: Add -f to force new-workdir in existing directory. Signed-off-by: Paul Smith psm...@mad-scientist.net --- I have an environment I want to use new-workdir for, where the directory I

[PATCH] git-new-workdir: Don't fail if the target directory is empty

From 545c0d526eaa41f9306b567275a7d53799987482 Mon Sep 17 00:00:00 2001 From: Paul Smith p...@mad-scientist.net Date: Fri, 14 Nov 2014 17:11:19 -0500 Subject: [PATCH] git-new-workdir: Don't fail if the target directory is empty Also provide more error checking and clean up on failure. Signed-off

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

Junio C Hamano gits...@pobox.com writes: Paul Smith p...@mad-scientist.net writes: No need to resend only to correct the above, even though there may be comments on the patch itself from me or others that may make you want to reroll this patch, in which case I'd like to see these nits gone

[PATCH] git-new-workdir: Don't fail if the target directory is empty

Allow new workdirs to be created in an empty directory (similar to git clone). Provide more error checking and clean up on failure. Signed-off-by: Paul Smith p...@mad-scientist.net --- Getting rid of ls/wc was not as simple as I'd hoped, due to glob pathname expansion (can't rely on nullglob

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

On Tue, 2014-11-18 at 12:15 -0800, Junio C Hamano wrote: Paul Smith p...@mad-scientist.net writes: Getting rid of ls/wc was not as simple as I'd hoped, I didn't say ls/wc was not portable. Assuming that a directory for which the output from ls -a has two entries is empty may be. Yes, I

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

On Tue, 2014-11-18 at 12:58 -0800, Junio C Hamano wrote: Doesn't the description of the -A option I quoted upthread hint a simpler and clearer solution? I.e. test $(ls -A | wc -l) = 0? Yes, but unfortunately for us the -A flag was added to POSIX Issue 7. It's not present in the previous

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

On Tue, 2014-11-18 at 14:51 -0800, Junio C Hamano wrote: OK, thanks for digging. Let's go with this version, then. Thanks for your attention, Junio! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

On Wed, 2014-11-19 at 09:32 -0800, Junio C Hamano wrote: Paul Smith p...@mad-scientist.net writes: I took a look at this again, and I do not agree with one design decision it makes, namely: I split the creation of the directories from the symlinks: see the new loop above. This allows us

[PATCH] git-new-workdir: Don't fail if the target directory is empty

Allow new workdirs to be created in an empty directory (similar to git clone). Provide more error checking and clean up on failure. Signed-off-by: Paul Smith p...@mad-scientist.net --- contrib/workdir/git-new-workdir | 54 +++-- 1 file changed, 36 insertions

Re: [PATCH] git-new-workdir: Don't fail if the target directory is empty

On Thu, 2014-11-20 at 09:13 -0800, Junio C Hamano wrote: Paul Smith p...@mad-scientist.net writes: +# don't recreate a workdir over an existing directory, unless it's empty +if test -d $new_workdir then - die destination directory '$new_workdir' already exists. + if test $(ls -a1

Why does git merge --squash fail when merge.ff is set to only?

In our development process we always want to do rebase and only rarely create merge commits, and so we have a recommendation to set the merge.ff configuration attribute to only. This is great, however it appears to break git merge --squash (which we also use constantly). If I'm squash-merging

[PATCH v4] git-new-workdir: Don't fail if the target directory is empty

Allow new workdirs to be created in an empty directory (similar to git clone). Provide more error checking and clean up on failure. Signed-off-by: Paul Smith p...@mad-scientist.net --- Hopefully this doesn't contain unwanted stylistic changes. There's a kind of gross thing about the behavior

Re: [PATCH v4] git-new-workdir: Don't fail if the target directory is empty

On Wed, 2014-11-26 at 13:55 -0800, Junio C Hamano wrote: The comment in the original is somewhat misleading, but test -e was test -e and not test -d to stop when an existing file was given by mistake as $new_workdir, I think. I do not know what happens in the new code in that case. I did

Re: [PATCH v4] git-new-workdir: Don't fail if the target directory is empty

On Wed, 2014-11-26 at 15:16 -0800, Junio C Hamano wrote: $ ./src/git/contrib/workdir/git-new-workdir src/git foo master mkdir: cannot create directory ‘foo’: Not a directory unable to create new workdir foo! ;-) That comes from mkdir || fail which is indeed sufficient. Right. Often I

Re: [PATCH v4] git-new-workdir: Don't fail if the target directory is empty

On Wed, 2014-11-26 at 15:16 -0800, Junio C Hamano wrote: Paul Smith p...@mad-scientist.net writes: This is what happens for a file: $ rm -f foo $ touch foo $ ./src/git/contrib/workdir/git-new-workdir src/git foo master mkdir: cannot create directory ‘foo’: Not a directory

profile-fast is failing in my Git 2.2.1 build from tar in a Git repo

Is anyone aware of this? It seems that profile-fast fails when invoked from a downloaded tarball, if you are in a Git repository when you unpack it. So, for example, I have: $ cd $HOME/src $ git status On branch master Your branch is up-to-date with 'origin/master'. (this is NOT the

Re: [PATCH] git-new-workdir: add windows compatibility

On Tue, 2015-05-26 at 11:53 +0200, Johannes Schindelin wrote: The biggest problem with `mklink` is that it is only supported on Windows Vista and later, while I really like to keep Windows XP support in Git for Windows. No, the biggest problem with mklink is that you have to have

Building Git with HTTPS support: avoiding libcurl?

I'm trying to build Git (2.6.4) on GNU/Linux, but without any requirements (other than basic libc etc.) on the local system. This works fine except for one thing: git-remote-https. In order to build this I need to have libcurl, but libcurl is a MONSTER library with an enormous number of

Re: Building Git with HTTPS support: avoiding libcurl?

On Tue, 2015-12-22 at 09:08 -0800, Dave Borowitz wrote: > Well, IIUC one of the reasons for Git's fork-everything strategy is to > avoid having to dynamically link the core git binary against large > libraries like libcurl, so the dependency size has been taken into > account at least in that

git 2.9.2: is RUNTIME_PREFIX supposed to work?

Hi all.  I'm trying to create a relocatable installation of Git 2.9.2, so I can copy it anywhere and it continues to run without any problem. This is on GNU/Linux systems, FWIW. Looking through the code (for some other reason) I discovered the RUNTIME_PREFIX setting which appears to attempt to

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote: > On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <p...@mad-scientist.net> wrote: > > > > Hi all. I'm trying to create a relocatable installation of Git 2.9.2, > > so I can copy it anywhere and it continues

Re: git merge deletes my changes

On Mon, 2016-10-10 at 10:19 +, Eduard Egorov wrote: > # ~/gitbuild/git-2.10.1/git merge -s subtree --squash ceph_ansible > > Can somebody confirm this please? Doesn't "merge -s subtree" really > merges branches? I think possibly you're not fully understanding what the --squash flag does...

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote: > I have in the back of my mind a fear that it is harder to unset a > make variable than it is to override it with a new value (which is > what you'd want to do here to turn openssl back on), It depends on what you mean by "unset". If you mean

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Mon, 2016-11-07 at 12:46 -0500, Jeff King wrote: > Specifically I wanted to make sure that > >   FOO = bar >   FOO = >   ifdef FOO >   ... something ... >   endif > > works as if FOO had never been set in the first place. Which it seems > to, at least in GNU make (and that is the only one we

Re: git stash filename - stashing single files.

On Wed, 2016-12-14 at 09:44 -0500, Jeff King wrote: > Personally, I think this is a pretty terrible interface. Besides the > fact that I have never written a stash message in all my years of using > git, it's totally inconsistent with the rest of git (which would use > "-m" for the message, and

Re: Git Bash Bug

On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote: > Sorry for not being specific. What I meant by not working was that the > bash commands are not found. > Here is an example > > $ ls > bash: ls: command not found The most obvious issue is your PATH is wrong. What does "echo $PATH" show?

Re: Git Bash Bug

On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote: > > You absolutely have to have /bin and /usr/bin on your PATH, > > As Kavita talks about Git Bash, it is probably Git for Windows, for > which /bin should not be in the PATH but /mingw64/bin or /mingw32/bin > (depending on the

Re: Git Bash Bug

On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote: > What does "echo $PATH" show? > /c/Users/Kavita/ Well, there you go. That's clearly wrong. You absolutely have to have /bin and /usr/bin on your PATH, _at least_ if you want to be able to run standard UNIX tools. And most likely you'll

Re: Git Strange behaviour with remote deleted branch

On Mon, 2017-06-19 at 23:33 +0200, Reda Lyazidi wrote: > with git I noticed when I removed a remote branch with git push origin > --delete > in my clone when I used git branch -a I don't the deleted branch > but my colleagues still see it. > > I tried with two clones in my PC, with the first

Re: Minor missing features in worktree compare to new-workdir

On Wed, 2017-06-14 at 08:31 -0400, Yichao Yu wrote: > 1. the branch name in new-workdir has the same behavior as checkout, > i.e. when it matches a remote branch name a local branch tracking that > remote branch will be created and checked out. worktree gives an error > in this case. This is very

Re: "git rm" seems to do recursive removal even without "-r"

On Sat, 2017-10-07 at 17:55 -0400, Robert P. J. Day wrote: > On Sat, 7 Oct 2017, Paul Smith wrote: > > On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote: > > > it's been a long week, so take this in the spirit in which it is > > > intended ... i think the "

Re: "git rm" seems to do recursive removal even without "-r"

On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote: >   it's been a long week, so take this in the spirit in which it is > intended ... i think the "git rm" command and its man page should be > printed out, run through a paper shredder, then set on fire. i can't > remember the last time i

Re: "git rm" seems to do recursive removal even without "-r"

On Tue, 2017-10-10 at 04:36 -0400, Robert P. J. Day wrote: >   ah, now *that* is a compelling rationale that justifies the > underlying weirdness. but it still doesn't explain the different > behaviour between: > >   $ git rm -n 'Makefile*' >   $ git rm -n '*Makefile' I explained that behavior

Re: [PATCH v4 4/4] worktree: make add dwim

On Sat, 2017-11-25 at 20:06 +, Thomas Gummerer wrote: > This part is getting done in 3/4, and is definitely going to work > without an additional flag, so this is (hopefully) soon going to work > just as you want :) Yay! Thanks!

Re: [PATCH v4 4/4] worktree: make add dwim

On Sat, 2017-11-25 at 17:50 +, Thomas Gummerer wrote: > This would be the output in the new version: > > $ git worktree add ../bla > Branch 'bla' set up to track remote branch 'bla' from 'origin'. > Preparing ../bla (identifier bla) > HEAD is now at 4aade43 bla > > vs.

Re: bash script to pull in branch B the changes from parent branch A

On Wed, 2017-11-22 at 00:19 +0800, Laetitia Pfaender wrote: > cd repo-in-branchB > git branch --set-upstream-to=origin/branchB > git pull > > git branch --set-upstream-to=origin/branchA > git pull > git branch --set- > upstream-to=origin/branchB > > It does exactly what I want but, as I have >

Git 2.18: RUNTIME_PREFIX... is it working?

I was excited to see the RUNTIME_PREFIX for POSIX systems patchset go by earlier this year. Although I didn't see any mention of it being included in the 2.18.0 release notes, it does appear that it was merged in for this release. Has anyone else tried to get it working? It doesn't appear to be

Re: [ANNOUNCE] Git v2.16.0-rc0

On Thu, 2017-12-28 at 20:30 -0800, Junio C Hamano wrote: > * The way "git worktree add" determines what branch to create from >where and checkout in the new worktree has been updated a bit. Does this include the enhancements published a few weeks ago to allow worktrees to be created directly

Re: [ANNOUNCE] Git v2.16.0-rc0

On Thu, 2018-01-04 at 20:18 +, Thomas Gummerer wrote: > On 12/29, Paul Smith wrote: > > On Thu, 2017-12-28 at 20:30 -0800, Junio C Hamano wrote: > > > * The way "git worktree add" determines what branch to create > > > from where and checkout in the new

Re: Can't squash merge with merge.ff set to false

On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote: > On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey > wrote: > > Not sure if this is intended or a bug, but with the following > > configuration: > > > > $ git config --global merge.ff false > > > > I am not able to

Re: "git branch" issue in 2.16.1

On Tue, 2018-02-06 at 11:49 -0800, Jason Racey wrote: > After upgrading git from 2.16.0 to 2.16.1 (via Homebrew - I’m on > macOS) I noticed that the “git branch” command appears to display the > branch listing in something similar to a vi editor - though not quite > the same. I don’t know the

Git "branch properties"-- thoughts?

Hi all. I'm wondering if anyone has any thoughts about the best, or even any, way to have "branch properties": some extra information which is attached to a branch (that is, the actual branch name not the commit it currently points to). My requirements are that the information needs to be pushed

Git 2.16.2: Build failure linking static libcurl / static SSL

I'm compiling Git with my own static libcurl and my own static LibreSSL. They live in two different locations. Building Curl with a pointer to my LibreSSL works fine, and compiling Git works fine: the correct -I options are added to the compile line when I configure with

Re: Bring together merge and rebase

On Tue, 2017-12-26 at 12:44 -0700, Carl Baldwin wrote: > > Sure, it could be opt in, be a new format etc. But you haven't > > explained why you think a feature like this would need to rely on > > an entirely new parent structure and side-DAG, as opposed to just > > the more minor changes I'm

Re: Help with "fatal: unable to read ...." error during GC?

On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote: > Let's narrow it down first and make sure we're dying where I expect. > Can > you try: > > GIT_TRACE=1 git gc > > and confirm the program running when the fatal error is produced? > > From what you've shown it's going to be git-repack, but

Re: Help with "fatal: unable to read ...." error during GC?

On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote: > If so, can you try running it under gdb and getting a stack trace? > Something like: > > gdb git > [and then inside gdb...] > set args pack-objects --all --reflog --indexed-objects foobreak die > run > bt > > That might give us

Re: Help with "fatal: unable to read ...." error during GC?

On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote: > If so, can you try running it under gdb and getting a stack trace? > Something like: > > gdb git > [and then inside gdb...] > set args pack-objects --all --reflog --indexed-objects foobreak die > run > bt > > That might give us

Help with "fatal: unable to read ...." error during GC?

I recently upgraded from Git 2.9.2 to 2.18.0 (note, I have no particular reason to believe this is related just passing info). I'm running on Linux (64bit Ubuntu 18.04.1 but I've compiled Git myself from source, I'm not using the distro version). I have a local repository I've been using for

Re: Help with "fatal: unable to read ...." error during GC?

On Wed, 2018-08-08 at 12:06 -0400, Jeff King wrote: > I'd have expected fsck to find it, too. However, looking at the code, > I'm not convinced that fsck is actually considering detached worktree > heads properly, either. Try: > > git rev-list --all --reflog --objects >/dev/null > > which I

Re: [ANNOUNCE] Git v2.19.0-rc0

On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote: > static inline int hashcmp(const unsigned char *sha1, const unsigned > char *sha2) > { > + assert(the_hash_algo->rawsz == 20); > return memcmp(sha1, sha2, the_hash_algo->rawsz); > } I'm not familiar with Git code, but for most

Re: git silently ignores include directive with single quotes

On Sat, 2018-09-08 at 13:13 -0700, Stas Bekman wrote: > I remind that the original problem came from a simple command: > > git config --local include.path '../.gitconfig' > > Which on linux removed the quotes and all was fine, and on windows > the same command kept the quotes and the user was

Re: Git 2.18: RUNTIME_PREFIX... is it working?

On Wed, 2018-07-04 at 13:22 +0200, Johannes Schindelin wrote: > > Basically what happens is that I run configure with > > --prefix=/my/install/path --with-gitconfig=etc/gitconfig > > --with-gitattributes=etc/gitattributes. > > > > Then I run make with RUNTIME_PREFIX=YesPlease. > > Ah. In Git for

RUNTIME_PREFIX references in gitconfig variable paths

One thing I wanted to do was provide a default ca-bundle.crt file along with my local build of Git. I need my installation to be relocatable and I'm using RUNTIME_PREFIX with Git 2.18.0 (on GNU/Linux). I can provide a system gitconfig file with a setting for http.sslCAInfo but the problem is I

Re: Git 2.18: RUNTIME_PREFIX... is it working?

On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote: > I forewent autoconf because I was concerned that the option was too > obscure and the configuration too nuanced to be worth adding via > flag, as RUNTIME_PREFIX requires some degree of path alignment and is > fairly special-case. If you

Re: RUNTIME_PREFIX references in gitconfig variable paths

On Wed, 2018-07-04 at 13:26 +0200, Johannes Schindelin wrote: > On Wed, 4 Jul 2018, Paul Smith wrote: > > > One thing I wanted to do was provide a default ca-bundle.crt file > > along with my local build of Git. I need my installation to be > > relocatable and I'm using