On Thu, 2019-06-13 at 09:51 +0200, Johannes Schindelin wrote:
> Hassles aside, you mentioned Linux and macOS. What about literally
> *all* the other platforms we support? Like AIX, NonStop, HP/UX, etc?
I assumed that we were discussing providing an _option_ of building
with shared libraries, rathe
On Tue, 2019-06-11 at 23:48 +, brian m. carlson wrote:
> Also, some people install Git into their home directories, and a
> shared library means that they'll have to use LD_LIBRARY_PATH (or
> equivalent) to run Git.
I don't have strong feeling about .so's although obviously less disk
space use
On Thu, 2019-01-24 at 14:51 +, Naum Derzhi wrote:
> Greetings,
>
> I have this problem: years ago one of our developers committed a
> large (Gigabytes) piece of binary data into our project repository.
> This should not have been done, but it happened. (Honest, it was not
> me). We never neede
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 te
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 e
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 a
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 a
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 w
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 kno
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 abou
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 pre
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
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
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 ca
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
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 --with-openssl=/path/to/l
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
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 techn
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 merge my topic branch into
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
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
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 pointi
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!
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. the
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
> ma
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 in
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 &
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 sa
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 architec
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 hav
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?
W
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 one
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 u
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 tre
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 s
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 i
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... th
On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith 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 to run without any problem.
> &
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 set
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 sense
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 prerequis
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
administrat
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 Git
On Wed, 2014-11-26 at 15:16 -0800, Junio C Hamano wrote:
> Paul Smith 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: can
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.
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.
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
---
Hopefully this doesn't contain unwanted stylistic changes. There's a
kind of gross thing about the behavior
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 f
On Thu, 2014-11-20 at 09:13 -0800, Junio C Hamano wrote:
> Paul Smith writes:
> > +# don't recreate a workdir over an existing directory, unless it's empty
> > +if test -d "$new_workdir"
> > then
> > - die "destination directory
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
---
contrib/workdir/git-new-workdir | 54 +++--
1 file changed, 36 insertions(+), 18
On Wed, 2014-11-19 at 09:32 -0800, Junio C Hamano wrote:
> Paul Smith 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
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 ht
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 ver
On Tue, 2014-11-18 at 12:15 -0800, Junio C Hamano wrote:
> Paul Smith 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 en
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
---
Getting rid of ls/wc was not as simple as I'd hoped, due to glob
pathname expansion (can't rely on nullglo
Junio C Hamano writes:
> Paul Smith 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.
I'll
>From 545c0d526eaa41f9306b567275a7d53799987482 Mon Sep 17 00:00:00 2001
From: Paul Smith
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-by: Pa
From: Paul Smith
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
---
I have an environment I want to use new-workdir for, where the directory
I need to use is pre-created for me and I&#
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 {} i
59 matches
Mail list logo
