Hi,
Jason St. John wrote:
git-log.txt: grammatical fixes under --log-size option
Thanks.
[...]
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -56,10 +56,10 @@ Note that this affects all diff-based output types, e.g.
those
produced by --stat etc.
--log-size::
-
Jason St. John wrote:
I broke this off into a separate patch in case the release notes are
essentially fixed in history and typos, misspellings, etc. don't get
corrected.
Yeah, I'd prefer not to retroactively fix release notes for cases
like this.
Thanks,
Jonathan
--
To unsubscribe from this
Running make clean after a successful make install should not
result in a broken mediawiki remote helper.
Reported-by: Thorsten Glaser t.gla...@tarent.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for the very pleasant mediawiki remote helper.
contrib/mw-to-git/Makefile | 1
Junio C Hamano wrote:
Is everybody happy with this version?
Looks good to me.
Thanks,
Jonathan
--
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 http://vger.kernel.org/majordomo-info.html
John Keeping wrote:
On Mon, Nov 11, 2013 at 10:25:51AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git repo-config, git tar-tree, git lost-found and git
peek-remote have all been deprecated since at least Git 1.5.4.
[...]
Probably good material to discuss during the
Matthieu Moy wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Running make clean after a successful make install should not
result in a broken mediawiki remote helper.
Acked-by: Matthieu Moy matthieu@imag.fr
Thanks for looking it over. Here are a few more makefile tweaks on
top
On some machines, the most usable 'install' tool is named
'ginstall'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/mw-to-git/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index ee78fda
file \
'/usr/share/perl/5.18.1/Git/Mediawiki.pm': No such file or directory
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/mw-to-git/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index c5547f9
Quote DESTDIR and INSTLIBDIR for the shell in the same way as is done in
the toplevel Makefile to avoid confusion in case they contain shell
metacharacters.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/mw-to-git/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions
-to-left languages. Something
to solve another day.
The rest looks good.
If the commit message is clarified,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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 http
Hi,
Andrew Ardill wrote:
On 15 November 2013 01:51, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
But there was an announcement that an experimental JIRA instance has
been set up for Git [1]. I'm not sure what its current status is, but
you could look at it.
So!
The
A small pair of patches, for your enjoyment.
Thoughts?
Jonathan Nieder (2):
Makefile: rebuild perl scripts when perl paths change
Makefile: add PERLLIB_EXTRA variable that adds to default perl path
Makefile | 16 ++--
1 file changed, 14 insertions(+), 2 deletions
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Makefile | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index af847f8..e5e7868 100644
--- a/Makefile
+++ b/Makefile
@@ -1792,7 +1792,8 @@ perl/PM.stamp: FORCE
perl/perl.mak: GIT-CFLAGS
, as a convenience for packagers.
Requested-by: Dave Borowitz dborow...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading.
Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e5e7868..67f1754 100644
--- a/Makefile
Andreas Stricker wrote:
svn, Version 1.7.10 (r1485443)
I tried to reproduce the problem with git version 1.8.4.2 and
Subversion version 1.8.4 (r1534716) with a fresh and pristine
subversion repo and a git-svn clone of it: I didn't manage to
reproduce the rename issue. Then I switched
Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
* git branch -v -v (and git status) did not distinguish among a
- branch that does not build on any other branch, a branch that is in
- sync with the branch it builds on, and a branch that is configured
- to build on
Marc Branchaud wrote:
* git branch -v -v (and git status) did not distinguish among a
branch that is not based on any upstream branch, a branch that is in
sync with its upstream branch, and a branch that is configured with an
upstream branch that no longer exists.
Ooh, this is much
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Change since v1:
- add GIT-PERL-DEFINES to .gitignore so it doesn't clutter up
git status output
.gitignore | 1 +
Makefile | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index
this shouldn't slow anything
down. Thanks.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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 http://vger.kernel.org/majordomo-info.html
Hi,
Jim Garrison wrote:
The master reference TOC page at http://git-scm.com/docs links to
all the associated command reference pages, except it seems to be
missing a link for gitrevisions(7)
(http://git-scm.com/docs/gitrevisions.html).
I've never submitted a patch and thought I would learn
Hi,
Jason St. John wrote:
Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
listing blocks
I'd leave out the above two description lines, since they're redundant
next to the patch text.
Without these blank lines, AsciiDoc thinks the opening - is a
section
Jason St. John wrote:
On Tue, Nov 19, 2013 at 7:31 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jason St. John wrote:
Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
listing blocks
I'd leave out the above two description lines, since they're redundant
next
Heiko Voigt wrote:
After that we can discuss whether add should add submodules that are
tracked but not shown. How about commit -a ? Should it also ignore the
change? I am undecided here. There does not seem to be any good
decision. From the users point of view we should probably not add it
Jeff King wrote:
sha1_file.c| 74
-
Yay!
t/t1013-loose-object-format.sh | 66 --
Hmm, not all of these tests are about the experimental format. Do
we really want to remove them all?
Thanks,
Jeff King wrote:
On Fri, Nov 22, 2013 at 04:24:05PM -0800, Jonathan Nieder wrote:
t/t1013-loose-object-format.sh | 66 --
Hmm, not all of these tests are about the experimental format. Do
we really want to remove them all?
I think so. They were not all
Duy Nguyen wrote:
Do you think it's ok to revert the workaround if we detect
the running glibc is fixed (or if it does not run glibc at all)? I
think we could use gnu_get_libc_version() to detect it.
That would be wonderful.
Thanks,
Jonathan
--
To unsubscribe from this list: send
Thomas Rast wrote:
This shuts up compiler warnings about unused functions.
If that is the only goal, I think it would be cleaner to use
#define MAYBE_UNUSED __attribute__((__unused__))
static MAYBE_UNUSED void init_ ...
like was done in the vcs-svn/ directory until cba3546
Thomas Rast wrote:
The clear_$slabname() function was only documented by source code so
far. Write something about it.
Good idea.
[...]
--- a/commit-slab.h
+++ b/commit-slab.h
@@ -24,6 +24,10 @@
* to each commit. 'stride' specifies how big each array is. The slab
* that id
Thomas Rast wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Thomas Rast wrote:
This shuts up compiler warnings about unused functions.
If that is the only goal, I think it would be cleaner to use
#define MAYBE_UNUSED __attribute__((__unused__))
static MAYBE_UNUSED void init_
for a couple of years. Thanks to list denizens for the
improvements last time I brought it up[1]. Hopefully this version is
more sensible.
Anyway, hopefully it can provide some amusement.
Thanks,
Jonathan Nieder (9):
mark Windows build scripts executable
mark perl test scripts executable
mark
These scripts are not run directly as part of a normal build, so no
one noticed that they did not have the +x bit. Mark them executable
to make it more obvious that they can be run directly (when debugging,
for example).
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/Git-SVN
-by: Olivier Berger olivier.ber...@it-sudparis.eu
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
contrib/hooks/post-receive-email | 1 -
contrib/hooks/pre-auto-gc-battery | 1 -
contrib/hooks/setgitperms.perl| 0
contrib/hooks/update-paranoid | 0
4 files changed, 2 deletions(-)
mode
.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Following up on
http://thread.gmane.org/gmane.comp.version-control.git/52580
contrib/p4import/README | 1 -
contrib/p4import/git-p4import.py | 365 --
contrib/p4import/git-p4import.txt | 167
The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
po/po2msg.sh | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change
The Makefile only runs po/po2msg.sh using tclsh, but because the
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
The Windows git-gui wrapper is usable in-place for the same reason.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
po/po2msg.sh
On Windows the convention is to rely on filename extensions to decide
whether a file is executable so Windows users are probably not relying
on the executable bit of these scripts, but on other platforms it can
be useful documentation.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
compat
This way, test authors don't need to remember to source
lib-prereq-FILEMODE.sh before using the FILEMODE prereq to guard tests
that rely on the executable bit being honored when checking out files.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/lib-prereq-FILEMODE.sh | 11
with '.sh'. For documentation,
add a brief description of how the files are meant to be used in
place of the shebang line.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/gitweb-lib.sh | 3 ++-
t/lib-bash.sh | 7 +++
t/lib-cvs.sh | 2 +-
t/lib-diff
input used in tests
(t/t4034/perl/{pre,post}).
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading.
contrib/completion/git-completion.bash | 2 --
contrib/completion/git-completion.tcsh | 2 --
git-mergetool--lib.sh | 3 +--
git-parse-remote.sh
Heikki Hokkanen wrote:
If running git config on each prompt seems too expensive, do you have
any better ideas?
Perhaps a GIT_PS1_NOT_FOR_THESE_REPOS=repo1:repo2:repo3 setting would
work.
__git_ps1 would do the one 'git rev-parse --git-dir --...' to find the
repo corresponding to the cwd and
Hi,
Thanks for tackling this. This review will be kind of nitpicky, as a
way to save time when reviewing future patches.
Andrés G. Aragoneses wrote:
From 4f3b24379090b7b69046903fba494f3191577b20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9s=20G=2E=20Aragoneses?= kno...@gmail.com
Junio C Hamano wrote:
I have a feeling that the
current not copy to fix it to a stable value, but look into
.gitmodules as a fallback was not a designed behaviour for the
other properties, but was done by accident and/or laziness.
It was designed.
with '.sh'. For documentation,
add a brief description of how the files are meant to be used in
place of the shebang line.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Eric Sunshine wrote:
On Mon, Nov 25, 2013 at 4:03 PM, Jonathan Nieder jrnie...@gmail.com wrote:
+++ b/t/lib-bash.sh
(cc-ing the msysgit@ group, which maintains Git for Windows)
Hi,
Tom Byrer wrote:
Seems that grep.exe is too outdated for some scripts:
https://github.com/creationix/nvm/issues/75#issuecomment-13735767
Updating to a newer grep distro fixes the problem:
and fix 'make install'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi,
John Keeping wrote:
builtin/tar-tree.c | 62 -
Here's a quick fixup on top. Thoughts?
Thanks,
Jonathan
Makefile| 3 +--
builtin/{tar
Junio C Hamano wrote:
Karsten Blees karsten.bl...@gmail.com writes:
If we don't want to support this, though, I think it would be more
approrpiate to issue a warning if GIT_DIR points to a worktree
location.
But how do tell what is and isn't a worktree location? Having the
path in the
Hi,
Ralf Thielow wrote:
I've fetched from the current git.git on GitHub minutes ago and got a
segfault. I could reproduce it with the Git version of the current next
branch
(1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with
version 1.8.5.
Yep, I can reproduce
Nguyễn Thái Ngọc Duy wrote:
Mark strings like [up to date] passed to print_ref_status() for
translation with N_() instead of _() so they can remain untranslated
in porcelain mode.
Makes sense.
[...]
--- a/builtin/push.c
+++ b/builtin/push.c
Perhaps it would make sense to send these as a
Jeff King wrote:
I don't know if it is worth all that much effort, though. I suppose it
could get us more exposure to the httpd tests, but I do not know if it
would be a good idea to turn them on by default anyway. They touch
global machine resources (like ports) that can cause conflicts or
Muzaffer Tolga Ozses wrote:
I am cloning over http
I am guessing you are using the dumb (plain static file transfer)
HTTP protocol. With that protocol the server doesn't do anything
other than shuttle out files, so it doesn't need to do its own
progress reporting.
Perhaps the client should do
Jeff King wrote:
Patch 3 is the revised version of this patch which notices ambiguity.
However, I'm having second thoughts on it. I think it's the right thing
to do if you want to help people build something like git log
themselves. But it does mean that we are breaking somebody who does:
that
most callers would simply not be affected by this.
Thanks for a pleasant patch.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
Jeff King wrote:
As an aside, this is one of those places where C's string functions do
gross things with const.
Yes, yuck.
The fundamental grossness is that argv is semantically char **
(assuming this doesn't segfault) but passed around as const char **.
I wonder why we don't use the same
that
someone overflows an int with a very long -nnn... commandline).
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
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 http://vger.kernel.org
Hi,
Stefanus Du Toit wrote:
The git-subtree manpage is currently missing from the git-manpages
tarballs at https://code.google.com/p/git-core/.
For example,
https://code.google.com/p/git-core/downloads/detail?name=git-manpages-1.8.5.1.tar.gz
does not include it.
A side effect of this is
Hi,
brian m. carlson wrote:
Oftentimes people will make the same change in two branches, revert the change
in one branch, and then be surprised when a merge reinstitutes that change
when
the branches are merged.
Life is even more complicated: if the merge-base chosen happens to be
a
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
but it's especially annoying if there is a broken
index file.
Is this
Jens Lehmann wrote:
Am 09.12.2013 16:16, schrieb Jonathan Nieder:
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
Hmm, but this will disable
Junio C Hamano wrote:
So maybe we are doing a favor by
calling out the problem; if they want a rev, they should be using
--verify (or --).
I tend to agree with the reasoning in the last sentence. Let's cook
it for a while and see what happens.
Isn't
Jonathan Nieder wrote:
Isn't this essentially breaking a contract
To clarify, if there were some strong motivation --- e.g. if this
were resolving some security problem --- then I would be all for
breaking compatibility in this way. What's confusing to me is that I
just don't see
Karsten Blees wrote:
GCC supports __packed__ as of 2.3 (1992), so any other compilers
that copied the __attribute__ feature probably won't complain.
Alas, it looks like HP C doesn't support __packed__ (not that I
care much about HP C):
Hi,
Dominik Vogt wrote:
Now,
when I switch to one of the other branches, said file is not
identical anymore and stamped with the _current_ time during
checkout. Although branch b and c have not changed at all, they
will now be
Junio C Hamano wrote:
I do not share the with --verify is better hence no problem
reasoning. My not so much worth worrying about comes solely from
a hunch that nobody has HEAD~3..HEAD in their working directory,
That's what makes it a problem. This change makes it very easy to
make a
Karsten Blees wrote:
(Besides, __attribute__((aligned)) / __declspec(align) can only
_increase_ the alignment, so aligned(1) would have no effect).
Good catch.
Googling some more, I believe the most protable way to achieve this
via 'compiler settings' is
#pragma pack(push)
#pragma
John Keeping wrote:
Since commit d96855f (merge-base: teach --fork-point mode, 2013-10-23)
we can replace a shell loop in git-pull with a single call to
git-merge-base. So let's do so.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-pull.sh | 10 +-
1 file changed, 1
(pruning cc list)
Hi,
Thomas Gummerer wrote:
Currently the --no-index option is parsed in diff_no_index(). Move the
detection if a no-index diff should be executed to builtin/diff.c
No functional change intended, I assume?
[...]
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -283,14
Thomas Gummerer wrote:
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -295,7 +295,9 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
break;
}
- prefix = setup_git_directory_gently(nongit);
+ if (!no_index)
+ prefix =
Hi,
avinash r wrote:
I followed the installation instructions at
git-scm.com, but somehow the sub-command svn (git svn) is not being
installed.
[...]
Here is how i'm compiling:
$ make all
$ sudo make install
What is the content of config.mak? Is there a file named
Dominik Vogt wrote:
How does git-new-workdir cope with
rebasing (e.g. you have the same branch checked out in two working
trees and rebase -i it in one of them)?
Generally you don't have the same branch checked out in two working
trees. I tend to use git checkout
Duy Nguyen wrote:
I wonder if we could promote multiple worktree from a hack to a
supported feature. What I have in mind is when you clone
--separate-worktree it would create a .git file that describes
separate worktree:
gitbasedir: /path/to/the/original/.git
name: foo
HEAD, index and
Stefan Zager wrote:
This is probably a naive question, but: there are quite a lot of static
variables in the git code where it's really unnecessary. Is that just a
historical artifact, or is there some reason to prefer them?
Sometimes it's for convenience. Other times it's to work around
Jonathan Nieder wrote:
Stefan Zager wrote:
This is probably a naive question, but: there are quite a lot of static
variables in the git code where it's really unnecessary. Is that just a
historical artifact, or is there some reason to prefer them?
Sometimes it's for convenience.
See
Joey Hess wrote:
[2] A particularly annoying one is that git branch -d cannot be used
to remove a branch that is directly pointing to a corrupted commit!
It's generally considered okay for everyday commands like git branch -d
not to cope well with corrupted repositories, but we try to keep
-by: Jonathan Nieder jrnie...@gmail.com
--
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 http://vger.kernel.org/majordomo-info.html
commit message changes or the
check that data-type is initialized,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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 http://vger.kernel.org/majordomo
Jeff King wrote:
Updated patch is below.
Thanks! v2 of both patches looks good.
--
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 http://vger.kernel.org/majordomo-info.html
Jens Lehmann wrote:
Am 12.12.2013 02:16, schrieb Junio C Hamano:
I think the solution we want is to copy only minimum to the config
(and that minimum may turn out to be nothing), and to default
keys that are only absolutely safe to .gitmodules file.
I agree and will prepare a patch for
Junio C Hamano wrote:
- Do we want to record where the working tree directory is in
$GIT_SUPER_DIR/repos/id somewhere? Would it help to have such
a record?
That could be nice for the purpose of garbage collecting them. I fear
that for users it is too tempting to remove a worktree
Hi,
Thomas Gummerer wrote:
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
Thanks, and sorry for the slow follow-up.
[...]
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -16,6 +16,9 @@
[...]
@@ -283,14 +286,57 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
*
Thomas Gummerer wrote:
Also add a test to guard against future breakages, and a performance
test to show the improvements.
Very nice.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line
Hi,
Karsten Blees wrote:
test-hashmap.c | 340
Here come two small tweaks on top (meant for squashing in or applying
to the series, whichever is more convenient).
Thanks,
Jonathan Nieder (2):
Add test-hashmap to .gitignore
Drop
Prevent the test-hashmap program from being accidentally tracked
with git add or cluttering git status output.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..dc600f9 100644
it is already
included by git-compat-util.h.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
test-hashmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/test-hashmap.c b/test-hashmap.c
index 7e86f88..f5183fb 100644
--- a/test-hashmap.c
+++ b/test-hashmap.c
@@ -1,6 +1,5
somehow.
Hopefully this will discourage readers from depending on the old or
the new calculation.
Reported-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-pack-objects.txt | 3 +--
1 file changed
Jakub Narebski wrote:
It is a bit strange that markfile has explicitly SHA-1 (:markid SHA-1),
instead of generic reference to commit, in the case of CVS it would be
commitid (what to do for older repositories, though?), in case of Bazaar
its revision id (GUID), etc.
Usually importers use at
Adam Spiers wrote:
Hmm, another related option would be to add a new test case which
tests that git log behaves in the way the man page says it does, in
this case.
Yes, please! If you have a rough patch in that direction, that
would be welcome.
Thanks,
Jonathan
--
To unsubscribe from this
the colon in the translated string, to make it easier to
remember to keep the non-breaking space before it.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
[1] http://bugs.debian.org/725777
diff --git i/wt-status.c w/wt-status.c
index 4e55810..7b0e5b8 100644
--- i/wt-status.c
+++ w/wt-status.c
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
This includes the colon in the translated string, to make it easier to
remember to keep the non-breaking space before it.
Hmph, recent 3651e45c (wt-status: take the alignment burden off
translators, 2013-11-05) seems to have
Hi,
Samuel Bronson wrote:
Markus Heidelberg wrote:
In the buildroot project (it consists of Makefiles) there a lots of
those workarounds. There was a patch on the list to replace all
$(strip $(subst ,,$(FOO))) with $(call strip_dquotes, $(FOO)), but
$(call) is not allowed in git for
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
Heh. :)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Ronnie Sahlberg wrote:
Please pull my ref-transactions branch.
I'm at bd5736cb (2014-05-21 13:46) now.
On Wed, May 21, 2014 at 3:00 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
@@ -3308,6 +3308,12 @@ struct ref_update {
const char
Ronnie Sahlberg wrote:
Change prune_ref to delete the ref using a ref transaction. To do this we also
need to add a new flag REF_ISPRUNING that will tell the transaction that we
do not want to delete this ref from the packed refs.
Interesting. Since the flag is per ref update, it even would
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
[...]
@@ -2515,24 +2510,18 @@ static int delete_ref_loose(struct ref_lock *lock,
int flag, struct strbuf *err)
int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
{
- struct ref_lock *lock;
- int ret =
Ronnie Sahlberg wrote:
Change the reference transactions so that we pass the reflog message
through to the create/delete/update function instead of the commit message.
Nice.
[...]
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -673,7 +673,6 @@ static int store_updated_refs(const char
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Ronnie Sahlberg wrote:
This means that most loose refs will no longer be present after the rename
Is this to handle the git branch -m foo/bar foo case or for some other
purpose?
[...]
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -289,7 +289,7 @@ test_expect_success 'renaming a symref
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
@@ -2044,6 +2044,9 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
int missing = 0;
int attempts_remaining = 3;
+ if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL))
+ return NULL;
Ronnie Sahlberg wrote:
On Wed, May 21, 2014 at 6:42 PM, Jonathan Nieder jrnie...@gmail.com wrote:
$ git rev-parse HEAD .git/refs/heads/foo..bar
$ git branch -m foo..bar something-saner
fatal: Invalid branch name: 'foo..bar'
git branch -m has an explicit codepath
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Hi,
Ronnie Sahlberg wrote:
Add a new flag REF_ISPACKONLY that we can use in ref_transaction_delete.
This flag indicates that the ref does not exist as a loose ref andf only as
a packed ref. If this is the case we then change the commit code so that
we skip taking out a lock file and we skip
1301 - 1400 of 2895 matches
Mail list logo
