Hi, everyone,
since ad8261d (rebase: use reflog to find common base with upstream)
a rebase without arguments says fatal: Not a valid object name: '',
caused by trying to determine the fork point with an empty $switch_to.
I don't really see what the appropriate fix would be. :-(
Andreas
--
On Thu, 09 Jan 2014 15:56:21 +, John Keeping wrote:
...
I think the correct fix is to change the $switch_to in the call to
git merge-base --fork-point to ${switch_to:-HEAD}, but I'm not at a
machine where I can test that or work up a patch at the moment...
Thanks, looks plausible and
On Wed, 15 Jan 2014 12:40:29 +, David Kastrup wrote:
...
With a single root, depth helps a lot. When looking for a common
parent of a number of commits, you first shorten all ancestries to the
same size and then you can look for the point of convergence in
lockstep.
Hmm, how about
On Wed, 15 Jan 2014 14:00:30 +, David Kastrup wrote:
Andreas Krey a.k...@gmx.de writes:
...
Hmm, how about traversing from all the start commits downwards
simultaneously, noting which start you say each commit from, and stopping
when you have a commit carrying all start labels
Hi,
I noticed that, when a git repack fails due to insufficient
disk space, the newly created partial pack file isn't unlinked
(which doesn't help at all in that situation).
(Will venture a look myself when time permits.)
Andreas
--
Totally trivial. Famous last words.
From: Linus Torvalds
On Mon, 10 Mar 2014 19:39:00 +, Shawn Pearce wrote:
Yes, this was my real concern. Eclipse users using EGit expect EGit to
be compatible with git-core at the filesystem level so they can do
something in EGit then switch to a shell and bang out a command, or
run a script provided by their
On Wed, 09 Apr 2014 20:50:57 +, Mahmoud Asshole wrote:
...
This was raised previously[1], but none of the responses are convincing.
Please go directly to the special hell of debugging timezone-related stuff
in customer data, for which this extra bit of information is heaven-sent.
Do not
On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote:
...
Anyway, if you disagree change one of your frequently used passwords to a
chapter of The Lord of the Rings for a day. Let's see if you still think that.
Proving that one extreme isn't the optimum doesn't prove the other is.
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote:
...
But these days there's hardly any risk to using a detached HEAD. Plus
nowadays I think it's commonly accepted that using topic branches is a git
best practice. The notion of doing work on a generically-named branch like
maint
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does.
That still doesn't
On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
...
What the gibbins? I don't even use git pull.
I do, but I watch for the fast-forward message
and undo as appropriate.
I use git fetch, and then, depending on my needs, I rebase or merge.
I wouldn't mind that, but I have a century of
On Fri, 17 Oct 2014 13:25:42 +, Ciro Santilli wrote:
...
The problem is that the `/usr/bin` breaks interpreter version manager
systems like RVM, rbenv, virtualenv, etc. since people will write
hooks like:
#!/usr/bin/env ruby
and the `/usr/bin` ruby will get run instead of the
Hi, dear listers,
I'm wondering if there is (or will be) a way of doing almost
git clone --reference localrepo host:canonrep
Basically, I don't want the implications of --reference but still the
performance advantages of reusing local objects/pack files. I probably
have to go and first do a
On Tue, 03 Sep 2013 12:46:52 +, Andreas Krey wrote:
...
I have a strange behaviour from a bare repo I inherited;
when I clone from that one (ssh) the branch checked out
is *not* the one referenced in HEAD in the remote repo,
I now have a sample repo that reproduces this behaviour.
Unpack
On Tue, 03 Sep 2013 13:48:31 +, Andreas Krey wrote:
...
I now have a sample repo that reproduces this behaviour.
Unpack tar file, clone, see clone having 'wrong' branch
checked out, apparently independent of the transport:
Ouch, it looks like 'git clone' doesn't actually know
the 'current
On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote:
...
happen to have the HEAD *commit* as their tip.
Yes, it picks the first of those:
http://thread.gmane.org/gmane.comp.version-control.git/168144
Thanks for the pointer.
And pity, the patches didn't make it that time either...
On Tue, 03 Sep 2013 08:33:39 +, Junio C Hamano wrote:
...
Reading the patch series from 2008 again, I do agree with J6t's
comment that it should be just a regular capability,
I've implemented it as a 'sym=refs/heads/foo' capability.
It actually makes the patch series a lot shorter; the only
On Fri, 06 Sep 2013 13:41:30 +, Andreas Krey wrote:
...
If I run the exact same commands in a shell script they succeed,
in t5601-clone.sh the clone step seems to fail, and I have no
clue where to look for a clue.
Oh, never mind. --verbose shows that the test is borked;
it tries a checkout
From: Junio C Hamano gits...@pobox.com
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=target.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
upload
Ok, here are some patches that make git actually
check out the current remote branch when cloning.
Up to now this failed when there were two branches that pointed to
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the HEAD ref isn't transmitted in all
Signed-off-by: Andreas Krey a.k...@gmx.de
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
From: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601
On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
Andreas Krey a.k...@gmx.de writes:
...
+ if (symref) {
+ ref-symref = xcalloc(symref_len + 1, 1);
+ strncpy(ref-symref, symref, symref_len);
+ }
...
This looks utterly
On Mon, 09 Sep 2013 07:44:04 +, Junio C Hamano wrote:
...
I'd rather not go this route. Allowing refs/heads/master and local
branches that forked from it in refs/heads/master/{a,b,c,...} could
be a potentially useful future enhancement,
Want! We're currently going the route of naming the
On Mon, 09 Sep 2013 22:48:42 +, Niels Basjes wrote:
...
However I can imagine that a malicious opensource coder can create a
github repo and try to hack the computer of a contributer via those
scripts. So having such scripts is a 'bad idea'.
Given that half the repos out there are cloned
On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
That's interesting. We ran in a
On Thu, 23 May 2013 13:25:55 +, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
I have largedir I want to get rid of, but there is a directory
I want to save, largedir/precious, in it, so I do
cp -R largedir/precious precious
and then run 'rm -rf largedir' in
On Wed, 22 May 2013 11:07:07 +, Junio C Hamano wrote:
...
If you have a four-commit segment in your commit ancestry graph
I never had yet. :-(
(time flows from left to right; turn your head 90-degrees to the
right if you want a gitk representation):
---A--X
\/
/\
On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
...
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
I'd actually only like it that way when pulling from
the tracking branch, not for any
On Thu, 23 May 2013 06:34:38 +, Felipe Contreras wrote:
...
I don't understand; gitk already shows the first parent starting from
the bottom, and the merge commits arrive from the right side. What am
I missing?
That this isn't (consistently) the case in complicated situations.
I'll need to
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
...
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
And at that time you don't know it's
On Thu, 23 May 2013 07:45:34 +, Junio C Hamano wrote:
...
Even with 'mv', between the time the main in mv starts and the
process finally issues rename(2) on the directory, you can start
running what competes and interferes with it in another terminal,
so it does not fundamentally change
On Thu, 23 May 2013 12:01:43 +, Brett Trotter wrote:
In my work, we have a lot of autogenerated files that need to exist so
a script will replace their contents, but tracking the contents
creates a lot of unnecessary conflicts. I would love to see an option
for a different tracking method
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost completely meaningless. I could just
do my
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
Instead of having a nice these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully history that explains how these commits were
related and these commits are
On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote:
Am 24.05.2013 15:42, schrieb Andreas Krey:
...
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
In which case parent switching in the commit
On Tue, 21 May 2013 22:56:21 +, Shawn Pearce wrote:
...
This was with JGit? A stack trace and JGit version (so we can
correlate line numbers) would be a much more useful bug report than
nothing at all.
I now have a full test case (involving a generated repo just shy of 1GB)
that will
On Wed, 05 Jun 2013 13:19:18 +, Ian Kumlien wrote:
...
Well, I have no idea of how to control HOME in xinetd - access to the
machine is limited and x doesn't give that much access (nothing really
important is actually stored in /root)
Make xinetd execute '/usr/bin/env HOME=/home/yourstruly
On Wed, 12 Jun 2013 13:28:05 +, Felipe Contreras wrote:
...
And you are
doing that with the express purpose of annoying.
Where did 'assume good faith' go to today?
Andreas
--
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
Some people run inetds that collect stderr of the spawned programs.
Give them 'git-daemon --inetd --no-syslog' to keep error output
on stderr.
Signed-off-by: Andreas Krey a.k...@gmx.de
---
Documentation/git-daemon.txt | 4
daemon.c | 14 +++---
2 files changed
On Sat, 22 Jun 2013 23:21:03 +, Junio C Hamano wrote:
...
Are there examples of other daemon programs outside Git that have
this particular support to help such inetd implementations?
Unfortunately I only know one server that exclusively uses this
interface, and isn't even capable of
On Mon, 05 Nov 2012 21:29:48 +, Andreas Krey wrote:
...
But still I'd like to know if there is a cleaner solution,
esp. with respect to the index.
Actually, it seems
commit -m 'index'
commit -a -m 'worktree'
...push
git reset HEAD^
git reset --soft HEAD^
might do the index trick
Hi all,
I have a workflow for which I can't quite find the git tooling.
Essentially what I want is like 'git commit -a', except that I
want the resulting commit on a branch I name instead of the current
one, and I want my current index not being modified. At the moment
I emulate that via
git
On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
...
We both know that the CVS history omits important data, and that the
history is mutable, etc. So there are lots of hypothetical histories
that do not contradict CVS. But some things are recorded unambiguously
in the CVS history,
On Thu, 24 Oct 2013 02:57:15 +, Karsten Blees wrote:
...
The latter. I don't know about 'broader', but I'll try to summarize _my_
world view:
(1) Audience matters
For actual users, we need an accurate model that supports a variety of use
cases without falling apart. IMO, a working
On Mon, 18 Nov 2013 18:11:54 +, Matthieu Moy wrote:
...
I was wondering whether others had similar (or not) experience.
Similar. When I used eclipse I didn't even try to use the plugins
and just stayed on the command line. (Well, almost, but back then
jgit couldn't deal with submodules which
On Thu, 12 Dec 2013 08:42:25 +, Martin Langhoff wrote:
...
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs repo
- run cvs to git import at time T1, pointed to G, and the import tool
will only add the new commits found in cvs between T and T1.
I'm pretty
Hi all,
we're running into a problem with the rename detection; we're
at num_src=27320 and num_create=46731, which means that 'matrix'
would still be enumerable in int32, but... well, I don't yet know
where exactly it refuses to perform rename detection. I've tried to
set needed_rename_limit to
Hi all,
there seems to be a regression in the behaviour of 'git show_ref'
(note the underscore). In v2.0.3-711-g586f414 it starts to say:
$ ./git show_ref
error: invalid key: pager.show_ref
git: 'show_ref' is not a git command. See 'git --help'.
and somewhere (probably two commits,
On Fri, 16 Jan 2015 14:29:17 +, Andreas Krey wrote:
...
=== /tmp/tmp-ws-20150116-11355-v7zfcc
searching to describe HEAD
lightweight4 r2.4/bl-0
lightweight4 r2.4/bl-1
traversed 5 commits
r2.4/bl-0-4-g689e350
Apparently, this comes because two of the commit have
Hi all again,
today another expectation crumbled.
I expected the algo of 'git describe' to be deterministic,
but it happens to return different tags in structurally
identical repositories. These are generated on each run
of a test (and obviously have different dates and thus
commit IDs), and
To follow up on myself, this is the output of 'git describe --debug
--tags' and 'git log --oneline --decor --parents' for each of the
two repos.
The one irritating thing is that in two of them the inital commit is
not the bottommost in the log output.
To make my expectation more concrete: I
On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote:
...
You don't need the -f here. Just git repack -ad should be enough
(and the -f probably makes it _way_ slower).
Indeed, factor four.
However, my expectation is that a repack -ad will remove all the
old pack files, as what is in there is
On Thu, 15 Jan 2015 18:05:46 +, Bryan Turner wrote:
...
No, Stash will only do that in a repository which has been forked. In
any non-forked repository, Stash does not interact with garbage
collection in any way. Auto GC is left enabled, and all pruning
settings are left at their defaults.
On Thu, 15 Jan 2015 12:23:00 +, Bryan Turner wrote:
...
Guess in the dark: ls -l .git/objects/pack
Do you see any .keep files?
Lots of. :-(
I'm one of the Stash developers and just noticed this thread. If the
repository in question has been forked via Stash there likely _will_
be
On Wed, 14 Jan 2015 15:39:46 +, Andreas Krey wrote:
...
This is not the case. :-( (Done only with 1.8.2 due to
lack of compilers for this box.)
Neither for current git (copied repo to other machine)
There is one new pack file of a plausible size (25G),
and 65G worth of old packfiles
On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote:
On Wed, Jan 14, 2015 at 12:51:30PM +0100, Andreas Krey wrote:
I have a repo here that is 130G, but when I clone --mirror it, the result
is only 25G big. Because of the --mirror I don't think that I missed
any refs that keep objects
Hi everybody,
I have a repo here that is 130G, but when I clone --mirror it, the result
is only 25G big. Because of the --mirror I don't think that I missed
any refs that keep objects only in the source repo.
I already tried 'git repack -fad' and 'git gc' to shrink the original repo,
but it
get_ref_cache used a linear list, which obviously is O(n^2).
Use a fixed bucket hash which just takes a factor of 10
(~ 317^2) out of the n^2 - which is enough.
Signed-off-by: Andreas Krey a.k...@gmx.de
---
This brings 'git clean -ndx' times down from 17 minutes
to 11 seconds on one of our
On Mon, 16 Mar 2015 10:23:05 +, Junio C Hamano wrote:
Andreas Krey a.k...@gmx.de writes:
...
say a lot of ignored directories, but do you mean directories in
the working tree (which I suppose do not have much to do with the
submodule_ref_caches[])?
Apparently, they do.
I am guessing
On Wed, 22 Apr 2015 08:36:00 +, David Rodríguez wrote:
...
* User is relying on a custom path to select their Ruby version. For
example, let's say the first folder in path is ~/.rubies/2.2.2/bin.
* User runs /usr/bin/git commit and a pre-commit hook is triggered.
* The pre-commit hook
On Tue, 21 Apr 2015 18:37:29 +, David Rodríguez wrote:
...
This causes issues with Ruby git hooks, because Ruby version managers
rely on custom settings in PATH to select the Ruby executable,
Even if git wouldn't modify PATH this is still a broken way to do that.
What ruby to execute a
On Wed, 15 Apr 2015 21:25:44 +, Dennis Kaarsemaker wrote:
...
It does not and cannot work. The way mosh works, is that it uses ssh to
log in and launch a mosh-server daemon. This daemon and the mosh client
then communicate via a custom UDP protocol. The SSH connection is closed
after the
On Tue, 17 Mar 2015 01:48:00 +, Jeff King wrote:
> On Mon, Mar 16, 2015 at 10:35:18PM -0700, Junio C Hamano wrote:
>
> > > It looks like we don't even really care about the value of HEAD. We just
> > > want to know "is it a git directory?". I think in other places (like
> > > "git add"), we
Hi all,
we also ran into the maximum rename limit
in the rename detection. (Yes, we get a lot
of rename candidates when cherry-picking
between two specific releases.)
The code talks about limiting the size
of the rename matrix, but as far as I
can see, the matrix itself never exists
as such, and
On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote:
> > Can't we handle this in resolve_gitlink_ref itself? As I understand it,
> > it should resolve a ref (here "HEAD") when path points to a submodule.
> > When there isn't one it should return -1, so:
>
> I'm not sure. I think part of the
On Fri, 13 Nov 2015 19:01:18 +, Jeff King wrote:
...
> 2. But for a little more work, pushing the is_git_directory() check
> out to the call-sites gives us probably saner semantics overall.
Oops, now I get it[1]: You mean replacing resolve_gitlink_ref usages
with is_git_directory,
Hi all,
I have a bit of an annoying behaviour in git gc;
there is a repo I regularly do a fetch in, and
this kicks off a gc/prune every time. I remember
there being a heuristic with being that many files
in .git/objects/17 as the gc trigger.
Which is unfortunate if the gc does not actually
On Tue, 03 Nov 2015 16:01:24 +, Duy Nguyen wrote:
> > I have a bit of an annoying behaviour in git gc;
> > there is a repo I regularly do a fetch in, and
> > this kicks off a gc/prune every time. I remember
> > there being a heuristic with being that many files
> > in .git/objects/17 as
On Sat, 04 Apr 2015 15:55:07 +, Jeff King wrote:
...
> I think this is the same issue that was discussed here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/265560/focus&5585
>
> There is some discussion of a possible fix in that thread. I was hoping
> that Andreas was going
Hi all,
our workflow is pretty rebase-free for diverse reasons yet.
One obstacle now appearing is that rebases simply take
very long - once you might want to do a rebase there are
several hundred commits on the remote branch, and our tree
isn't small either.
This produces rebase times in the
On Fri, 04 Dec 2015 15:31:03 +, John Keeping wrote:
...
> I'm pretty sure that you're right and the cherry-pick analysis is where
> the time is spent.
But I'm pretty surprised as to the amount of CPU time that goes there.
I'm now rebasing a single commit with a single blank line added,
and
On Sat, 05 Dec 2015 02:37:44 +, Jeff King wrote:
...
> Hrm. Weird. You'd think it would break with the existing code if I do
> this, then:
>
...
> - (cd a/b/c; git init) &&
> + (cd a/b/c; git init && git commit --allow-empty -m foo) &&
> git config
On Fri, 04 Dec 2015 18:09:33 +, demerphq wrote:
...
> I bet you have a lot of refs; tags, or branches.
We do, but removing them doesn't noticably change the times
(12k refs vs. 120, mostly tags). I'm just running the
second series, the first (with many refs) ended
with rebasing over 3000
Hi Jeff,
thanks for the reply!
On Tue, 24 Nov 2015 18:33:28 +, Jeff King wrote:
...
> I didn't dig in the archive, but I think we discussed the "just show
> progress for destinations" before. The problem you run into is that the
> items aren't a good indication of the amount of work. You
Hi all,
when I have an ignored file in my workspace, is git
then also assumed not to remove it in the course
of a merge?
Shouldn't it then say that the file is ignored,
as it does not show up in the untracked section
of git status?
Regards, Andreas
PS: Test script (will remove anything named
On Tue, 14 Jun 2016 10:06:16 +, Junio C Hamano wrote:
...
>
> IIRC, untracked files are kept during merge and across checking out
> another branch. Files that are deliberately marked as ignored by
> listing them to .gitignore mechanism are considered expendable, and
> they will be removed as
Hi all,
I'm looking for pointers to review tools that work with git (obviously),
and can deal sensibly with bigger reviews. Things we need:
- Ability to split (set of) commits into multiple reviews,
so parts of changes can be reviewed by the respective owners
(or assign different reviewers
On Thu, 16 Jun 2016 11:55:56 +, Richard Ipsum wrote:
...
> Have you considered Gerrit[1] already?
> It would seem to handle the cases you're interested in.
Possible, but only after a lot of user education.
We don't currently rewrite commits for review comments, and
neither can we get (all)
Hi all,
I have a single workspace where executing merges
occasionally leads to a left-over .git/index.lock file
that prevents me from adding resolved conflicted files.
I'm running a sped-up integration/feature branch process,
and the merges and conflict resolution are automated.
But the
On Fri, 22 Jan 2016 17:26:50 +, Jeff King wrote:
...
> Here it is. I think this is the right fix, based on the previous attempt
> by Andreas and my comments. Sorry for stealing your topic,
This seems to keep happening with things I try to patch. :-)
> but I hope
> the perf numbers in the
On Mon, 15 Feb 2016 18:06:33 +, Lars Schneider wrote:
> Hi Andreas,
>
> I am looking into a similar issue with SourceTree on Windows right now.
> However, in my case it only happens when I switch branches.
Semi-bingo. That is actually a difference between the workspace this
happens in and
Hi all,
I observed a strange an unexpected behaviour in 'git shortlog'.
When in git.git:
$ git shortlog -sn | wc
14414493 31477
but with input redirected:
$ git shortlog -sn
Date: Fri, 22 Jan 2010 07:29:21 -0800
-off-by: Andreas Krey <a.k...@gmx.de>
---
Ok, I've removed the clever message, as Junio suggested.
I don't know what else to do to make it acceptable. :-)
We're going to deploy it internally anyway, but I think
it belongs in git.git as well (aka 'Can I has "will queue"?').
D
Hi all,
We're occasionally seeing a lot of
error: cannot lock ref 'stash-refs/pull-requests/18978/to': Unable to create
'/opt/apps//repositories/68/stash-refs/pull-requests/18978/to.lock': File
exists.
from the server side with fetches as well as pushes. (Bitbucket server.)
What I
That behavior is now documented, and we don't
need a reward afterwards.
Signed-off-by: Andreas Krey <a.k...@gmx.de>
---
> Sorry for making you send an extra round; let's queue the original,
> and if you still are interested, have the "Clever" removal as its
> own patch
On Fri, 02 Dec 2016 23:32:55 +, Jeff King wrote:
> On Fri, Dec 02, 2016 at 11:15:13PM +0100, Andreas Krey wrote:
>
> > --only is implied when paths are present, and required
> > them unless --amend. But with --allow-empty it should
> > be allowed as well - it i
On Mon, 05 Dec 2016 12:36:19 +, Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes:
> > On Sat, Dec 03, 2016 at 07:59:49AM +0100, Andreas Krey wrote:
...
> >> Tool: git commit --allow-empty -m 'FIX: A-123'
> >
> > OK. I think "tool"
--only is implied when paths are present, and required
them unless --amend. But with --allow-empty it should
be allowed as well - it is the only way to create an
empty commit in the presence of staged changes.
Signed-off-by: Andreas Krey <a.k...@gmx.de>
---
I stumbled over this omission
On Fri, 16 Dec 2016 09:20:07 +, Junio C Hamano wrote:
...
> > error: cannot lock ref 'stash-refs/pull-requests/18978/to': Unable to
> > create
> > '/opt/apps//repositories/68/stash-refs/pull-requests/18978/to.lock':
> > File exists.
...
> I think (and I think you also think) these
On Fri, 16 Dec 2016 15:34:22 +, Bryan Turner wrote:
...
> Bitbucket Server developer here.
Social media rock. :-)
> If you'd like to investigate more in depth, I'd encourage you to
> create a ticket on support.atlassian.com so we can work with you.
That is going to be postponed until we
On Tue, 21 Mar 2017 13:00:05 +, Jeff King wrote:
...
> > I have an slightly unusual usecase for cherry-pick:
> > I want to modify the commit message that is used in the process,
> > e.g. do an d/^PROP:/ on it, but unfortunately -m does something
> > else here.
> >
...
>
> There's
On Tue, 21 Mar 2017 13:33:35 +, Jeff King wrote:
...
> Probably "format-patch | sed | am -3" is your best bet if you want to
> modify the patches in transit _and_ have the user just use normal git
> tools.
Except that 'git am' doesn't have --no-commit like cherry-pick does. :-(
It's always
Hi all,
I have an slightly unusual usecase for cherry-pick:
I want to modify the commit message that is used in the process,
e.g. do an d/^PROP:/ on it, but unfortunately -m does something
else here.
And there is no --message here for good reason, as cherry-pick
can pick multiple commits and so
On Thu, 06 Jul 2017 10:01:05 +, Bryan Turner wrote:
> Do you know what version of Bitbucket Server is in use?
We're on the newest 4.x.
...
> - Run "git config gc.auto 0" in
Going that route.
...
> I also want to add that Bitbucket Server 5.x includes totally
> rewritten GC handling.
Hi everyone,
how is 'git reflog expire' triggered? We're occasionally seeing a lot
of the running in parallel on a single of our repos (atlassian bitbucket),
and this usually means that the machine is not very responsive for
twenty minutes, the repo being as big as it is.
The server is still on
On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote:
> On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
...
> I seem to recall that using --stale-fix is also extremely expensive,
> too. What do the command line arguments for the slow commands look like?
The prob
On Tue, 04 Jul 2017 11:43:33 +, Ævar Arnfjörð Bjarmason wrote:
...
> You can set gc.auto=0 in the repo to disable auto-gc, and play with
> e.g. the reflog expire values, see the git-gc manpage.
>
> But then you need to run your own gc, which is not a bad idea anyway
> with a dedicated git
Hi everybody,
I got something that looks like a regression somewhere since 2.11.
This script
set -xe
rm -rf repo
git init repo
cd repo
git commit -m nix --allow-empty
git branch -m master/master
git rev-parse HEAD
git branch
git status
causes .git/HEAD to still contain 'ref:
On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote:
> Hi Andreas,
>
> Andreas Krey wrote:
>
> > I observed (again) an annoying behavior of 'git repack':
>
> Do you have context for this 'again'? E.g. was this discussed
> previously on-list?
I think I posted
1 - 100 of 111 matches
Mail list logo