Jeff King p...@peff.net writes:
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed git push) to a different remote (or
a different branch on the remote). It may sometimes be
useful to be able to quickly refer to that
Jeff King p...@peff.net writes:
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
+if (flags DO_FOR_EACH_NO_RECURSE) {
+struct ref_dir *subdir = get_ref_dir(entry);
+sort_ref_dir(subdir);
+
Michael Haggerty mhag...@alum.mit.edu writes:
It's not only racy WRT other processes. If the current git process
would create a new reference, it wouldn't be reflected in the cache.
It's true that the main ref_cache doesn't invalidate itself
automatically either when a new reference is
Øystein Walle oys...@gmail.com writes:
But it's seems the spaces trigger some other way of interpreting the
selector. In my git.git, git rev-parse HEAD{0} gives me the same result
as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different.
The integer to specify the nth reflog entry (or nth
Tom Miller jacker...@gmail.com writes:
After reading this and trying different things with the code. I believe
it would make sense to continue to anonymize the url for output to the
terminal.
Yes. That is what the anonymize bit is all about.
I also chose to continue to strip the trailing
Andy Lutomirski l...@amacapital.net writes:
It's possible, in principle, to shove enough metadata into the output
of 'git archive' to allow anyone to verify (without cloning the repo)
to verify that the archive is a correct copy of a given commit. Would
this be considered a useful feature?
Jeff King p...@peff.net writes:
Or is @{p} already taken by something and my memory is not
functioning well?
It is my brain that was not functioning well. I somehow thought well,
@{u} is already taken, so we must use @{pu}. Which of course makes no
sense, unless you are middle-endian. :)
Philip Oakley philipoak...@iee.org writes:
From: Jeff King p...@peff.net
Sent: Wednesday, January 08, 2014 9:37 AM
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed git push) to a different remote (or
a different
Johannes Sixt j...@kdbg.org writes:
The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
relies on that rename(src, dst/) fails if directory dst does not
exist (note the trailing slash). This does not work as expected on Windows:
This rename() call is successful. Insert
Andy Lutomirski l...@amacapital.net writes:
You only need the object name of the top-level tree. After untar
the archive into an empty directory, make it a new repository and
git add . git write-tree---the result should match the
top-level tree the archive was supposed to contain.
Hmm. I
Michael Haggerty mhag...@alum.mit.edu writes:
To replace %.*s with %s, all we have to do is use snprintf()
to interpolate %s into the pattern.
Cute ;-). Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
It may be overdue to refresh the suggested set of top 20 commands,
as things have vastly changed over the past 8 years. Perhaps we
should do
Michael Haggerty mhag...@alum.mit.edu writes:
As for removing the third argument of refname_match(): although all
callers pass it ref_ref_parse_rules, that array is sometimes passed to
the function via the alias ref_fetch_rules. So I suppose somebody
wanted to leave the way open to make
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring that the 'git help
What's cooking in git.git (Jan 2014, #02; Fri, 10)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Quite a few topics have graduated to
Jonathan Nieder jrnie...@gmail.com writes:
There is no guarantee that strbuf_read_file must error out for
directories. On some operating systems (e.g., Debian GNU/kFreeBSD
wheezy), reading a directory gives its raw content:
$ head -c5 / | cat -A
^AM-|^_^@^L$
As a result,
Jeff King p...@peff.net writes:
... but the
failing test is actually somewhat broken in 'next' already.
Hmph, in what way? I haven't seen t5531 breakage on 'next', with or
without your series...
fixes it, and should be done regardless of the other series.
t/t5531-deep-submodule-push.sh |
Matthieu Moy matthieu@grenoble-inp.fr writes:
Ryan Biesemeyer r...@yaauie.com writes:
+ test_when_finished git merge --abort
+ (
+git checkout -B other HEAD@{1}
Weird indentation (space/tab mix).
Also I do not quite see why the body has to be in a subshell.
--
To
Ryan Biesemeyer r...@yaauie.com writes:
When merging, make the prepare-commit-msg hook have access to the merge
state in order to make decisions about the commit message it is preparing.
What information is currently not available, and if available how
would that help the hook to formulate a
Ryan Biesemeyer r...@yaauie.com writes:
+ write_script $HOOK -EOF
+ if [ -s $(git rev-parse --git-dir)/MERGE_HEAD ]; then
+ exit 0
+ else
+ exit 1
+ fi
+ EOF
The script can be a one-liner
write_scirpt $HOOK -\EOF
test -s $(git
Francesco Pretto cez...@gmail.com writes:
Thanks for the comments, my replies below. Before, a couple of general
questions:
- I'm also writing some tests, should I commit them together with the
feature patch?
- to determine the attached/detached state I did this:
head_detached=
if test
Thomas Ackermann th.ac...@arcor.de writes:
- Add to Documentation/Makefile
- Start every TODO with a new line
- Fix indentation error
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/Makefile| 1 +
Documentation/technical/http-protocol.txt | 3 +--
Jeff King p...@peff.net writes:
It does not matter for actually pushing, because to do a non-default
push, you must always specify a remote. But @{publish} will ask the
question even if I am on 'side' now, what would happen if I were to
default-push on 'master'?.
In a similar wording to
Jonathan Nieder jrnie...@gmail.com writes:
* More typical usage is to clone from a bare repository (A.git), which
wouldn't have this problem. But I think your case is worth
supporting, too.
I think the relative URL among nested submodules was specifically
designed for hosting
W. Trevor King wk...@tremily.us writes:
Additional metadata, the initial checkout, and syncing down
---
However, folks who do local submodule development will care about
which submodule commit is responsible for that tree, because
Bernhard R. Link brl...@debian.org writes:
Allows to disable the git blame optimization of assuming that if there is a
parent of a merge commit that has the exactly same file content, then
only this parent is to be looked at.
This optimization, while being faster in the usual case, means
Bernhard R. Link brl+...@mail.brlink.eu writes:
* Junio C Hamano gits...@pobox.com [140113 23:31]:
I read the updated documentation three times but it still does not
answer any of my questions I had in $gmane/239888, the most
important part of which was:
Yeah, the cherry-picked one
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
While the result is more consistent and more predictable in the case
of merged cherry picks, it is also slower in every case.
Consistent and predictable, perhaps, but I am not sure exact would
be a good word
to print_object_or_die
cat-file: handle --batch format with missing type/size
Revert prompt: clean up strbuf usage
Johannes Sixt (1):
mv: let 'git mv file no-such-dir/' error out on Windows, too
Junio C Hamano (1):
Git 1.8.5.3
Kyle J. McKay (1):
gc: notice gc processes run by other
mechanism to remove this part from
git pull documentation, while keeping it for git merge.
Reported-by: Ivan Zakharyaschev
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-pull.txt | 4 ++--
Documentation/merge-options.txt | 9 ++---
2 files changed, 8 insertions(+), 5
Junio C Hamano gits...@pobox.com writes:
The pick the one that exactly matches if exists can be thought of
an easy hack to hide the problems that come from this arbitrary
choice. ...
Instead, pass the whole blame to the one that exactly matches hack
keeps larger blocks of text unsplit
Torsten Bögershausen tbo...@web.de writes:
Subject: Documentaiotn: exclude irrelevant options from git pull
^^
(Small nit ??)
;-).
They are now a small two patch series, with typofix for the above.
--
To unsubscribe from this list: send the line unsubscribe git in
the
to fix this.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* To be applied on top of 409b8d82 (Documentation/git-pull: put
verbosity options before merge/fetch ones, 2010-02-24)
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
.
Reported-by: Ivan Zakharyaschev
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* Merge the result of applying 1/2 on top of 409b8d8 to 66fa1b2,
and then apply this.
Documentation/merge-options.txt | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation
private to
refs.c, and remove ref_fetch_rules entirely.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
See
http://article.gmane.org/gmane.comp.version-control.git/240305
in which Junio made the suggestion and wrote most
Keith Derrick keith.derr...@lge.com writes:
I couldn't find a duplicate in the JIRA instance.
Don't worry, we do not use any JIRA instance ;-)
According to the documentation of check-ref-format, a branch name such
as @mybranch is valid.
Correct.
Yet 'git check-ref-format --branch
Jeff King p...@peff.net writes:
Is that what --branch does? I have never used it, but the manpage
seems to suggest it is about _parsing_ (which, IMHO, means it probably
should have been an option to rev-parse, but that is another issue
altogether).
Ahh, of course you are right. I never use
Martin Langhoff martin.langh...@gmail.com writes:
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King p...@peff.net wrote:
We see these occasionally at GitHub, too. I haven't yet figured out a
definite cause, though whatever it is, it's relatively rare.
Do you have a cleanup script to safely get rid
Igor Gnatenko i.gnatenko.br...@gmail.com writes:
From: Ruben Kerkhof ru...@rubenkerkhof.com
I use gmail for sending patches.
If I have the following defined in my ~/.gitconfig:
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = ru...@rubenkerkhof.com
Jeff King p...@peff.net writes:
[+cc Junio, as the bug blames to him]
...
I think what is happening is that we used to apply the SYMMETRIC_LEFT
flag directly to the commit. Now we apply it to the tag, and it does not
seem to get propagated. The patch below fixes it for me, but I have no
-off-by: Junio C Hamano gits...@pobox.com
---
* Comes directly on top of the faulty commit, so that we could
backport it to 1.8.4.x series.
revision.c | 2 +-
t/t6000-rev-list-misc.sh | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/revision.c b
Jeff King p...@peff.net writes:
On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote:
$ git rev-parse --symbolic-full-name HEAD@{u}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @mybranch@{u}
@mybranch@{u}
fatal: ambiguous argument '@mybranch@{u}': unknown
Ruben Kerkhof ru...@rubenkerkhof.com writes:
... because? Is it because the cert_path on your platform is
different from /etc/ssl/certs? What platform was this anyway?
This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64,
perl-IO-Socket-SSL-1.962-1.fc21.noarch
I see in the original
Jeff King p...@peff.net writes:
Looks good to me. As per my previous mail, I _think_ you could squash
in:
diff --git a/revision.c b/revision.c
index f786b51..2db906c 100644
--- a/revision.c
+++ b/revision.c
@@ -316,13 +316,10 @@ static struct commit *handle_commit(struct rev_info
*revs,
Junio C Hamano gits...@pobox.com writes:
But I have a suspicion that my patch may break if any codepath looks
at the current flag on the object and decides ah, it already is
marked and punts.
It indeed looks like mark_tree_uninteresting() does have that
property. When an uninteresting tag
.
Junio C Hamano (2):
revision: mark contents of an uninteresting tree uninteresting
revision: propagate flag bits from tags to pointees
revision.c | 29 +
t/t6000-rev-list-misc.sh | 17 +
2 files changed, 34 insertions(+), 12 deletions
-off-by: Junio C Hamano gits...@pobox.com
---
revision.c | 8 ++--
t/t6000-rev-list-misc.sh | 11 +++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/revision.c b/revision.c
index 28449c5..aec0333 100644
--- a/revision.c
+++ b/revision.c
@@ -273,6 +273,7
-object.parsed at the end of mark_tree_contents_uninteresting()
can be removed when this fix is merged to the codebase after
6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05).
Signed-off-by: Junio C Hamano gits...@pobox.com
---
revision.c | 25
Kyle J. McKay mack...@gmail.com writes:
in the docbook-xsl sources. Debian includes a patch file
8530_manpages_lists_indentation_fix.dpatch in [1]:
...
And once I have applied that I suddenly get a correct git-config.1
file on System A.
...
--Kyle
[1]
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree
W. Trevor King wk...@tremily.us writes:
This avoids the current awkwardness of having either '' or 'checkout'
for checkout-mode updates, which makes testing for checkout-mode
updates (or non-checkout-mode updates) easier.
Signed-off-by: W. Trevor King wk...@tremily.us
---
git-submodule.sh
W. Trevor King wk...@tremily.us writes:
The previous code only checked out branches in cmd_add. This commit
moves the branch-checkout logic into module_clone, where it can be
shared by cmd_add and cmd_update. I also update the initial checkout
command to use 'reset' to preserve branches
W. Trevor King wk...@tremily.us writes:
To preserve the local branch, for situations where we're not on a
detached HEAD.
Signed-off-by: W. Trevor King wk...@tremily.us
---
This should be a part of some other change that actually changes how
this git submodule update checks out the
W. Trevor King wk...@tremily.us writes:
@@ -817,11 +831,15 @@ cmd_update()
displaypath=$(relative_path $prefix$sm_path)
- if test $update_module = none
- then
+ case $update_module in
+ none)
echo
W. Trevor King wk...@tremily.us writes:
The old documentation did not distinguish between cloning and
non-cloning updates and lacked clarity on which operations would lead
to detached HEADs, and which would not. The new documentation
addresses these issues while updating the docs to reflect
W. Trevor King wk...@tremily.us writes:
On Thu, Jan 16, 2014 at 11:22:52AM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
To preserve the local branch, for situations where we're not on a
detached HEAD.
Signed-off-by: W. Trevor King wk...@tremily.us
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I am planning to tag 1.9-rc0 preview release from the tip of
'master' soonish. Hopefully a few fix-up topics still in flight and
also updates
W. Trevor King wk...@tremily.us writes:
A naïve expectation from a casual reader of the above would be The
superproject's tree ought to point at the same commit as the tip of
the branch used in the submodule (modulo mirroring delays and
somesuch),
What is the branch used in the submodule?
Alexander Berntsen alexan...@plaimi.net writes:
Signed-off-by: Alexander Berntsen alexan...@plaimi.net
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -240,3 +240,5 @@
*.pdb
/show_bug.cgi?id=1043194
Tested-by: Igor Gnatenko i.gnatenko.br...@gmail.com
Signed-off-by: Ruben Kerkhof ru...@rubenkerkhof.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-send-email.perl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send
Kyle J. McKay mack...@gmail.com writes:
On my OS X platform depending on which version of OpenSSL I'm using,
the OPENSSLDIR path would be one of these:
/System/Library/OpenSSL
/opt/local/etc/openssl
And neither of those uses a certs directory, they both use a
cert.pem bundle instead:
Jeff King p...@peff.net writes:
diff_filespec has a 2-bit dirty_submodule field and
defines two flags as macros. Originally these were right
next to each other, but a new field was accidentally added
in between in commit 4682d85.
Interesting.
- 4682d852 (diff-index.c: git diff has no need
Jeff King p...@peff.net writes:
But while looking at it, I noticed a bunch of cleanups for
diff_filespec. With the patches below, sizeof(struct diff_filespec) on
my 64-bit machine goes from 96 bytes down to 80. Compiling with -m32
goes from 64 bytes down to 52.
The first few patches have
Jeff King p...@peff.net writes:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out fatal: No such
ref: '' if git pull --rebase is run on branches without an upstream.
This is already fixed in bb3f458 (rebase: fix
Jonathan Nieder jrnie...@gmail.com writes:
Hi,
Erik Faye-Lund wrote:
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -367,7 +367,7 @@ static void squash_message(struct commit *commit, struct
commit_list *remotehead
sha1_to_hex(commit-object.sha1));
Kyle J. McKay mack...@gmail.com writes:
On Jan 16, 2014, at 20:21, Jeff King wrote:
When we run the pager, we always set LESS=R to tell the
pager to pass through ANSI colors. On modern versions of
FreeBSD, the system more can do the same trick.
[snip]
diff --git a/pager.c b/pager.c
index
Jeff King p...@peff.net writes:
diff --git a/pager.c b/pager.c
index 90d237e..2303164 100644
--- a/pager.c
+++ b/pager.c
@@ -87,6 +87,10 @@ void setup_pager(void)
argv_array_push(env, LESS=FRSX);
if (!getenv(LV))
argv_array_push(env, LV=-c);
+#ifdef
Roman Kagan rka...@mail.ru writes:
2013/12/31 Roman Kagan rka...@mail.ru:
2013/12/30 Junio C Hamano gits...@pobox.com:
Roman Kagan rka...@mail.ru writes:
I'd like to note that it's IMO worth including in the 'maint' branch
as it's a crasher. Especially so since the real fix has been merged
Yuri y...@rawbw.com writes:
I think that in a rare case of error this extra-printout wouldn't
hurt.
If the error is rare, extra verbiage does not hurt were a valid
attitude, error is rare, non-zero exit is enough would be equally
valid ;-)
Also that statement contradicts with the rationale
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
diff --git a/pager.c b/pager.c
index 90d237e..2303164 100644
--- a/pager.c
+++ b/pager.c
@@ -87,6 +87,10 @@ void setup_pager(void)
argv_array_push(env, LESS=FRSX);
if (!getenv(LV
John Keeping j...@keeping.me.uk writes:
Perhaps something like this is needed?
...
Either that or 2/dev/null like in the original, yes.
Ah, that makes sense. I see you already followed-up with a patch,
so I'll pick it up.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Shouldn't this use write_in_full() to avoid a silently truncated result? (*)
Meaning this? If so, I think it makes sense.
[...]
-if (xwrite(fd, out.buf, out.len) 0
Junio C Hamano gits...@pobox.com writes:
Perhaps we can start it like this. Then pager.c can iterate over
the PAGER_ENV string, parse out LESS=, LV=, etc., and do its thing.
We would also need to muck with git-sh-setup.sh but that file is
already preprocessed in the Makefile, so we should
Jeff King p...@peff.net writes:
I'm happy with it either way. I almost just pulled the macro
definitions, including DIFF_FILE_VALID, out of the struct definition
completely. I see the value in having the flags near their bitfield, but
it makes the definition a bit harder to read.
Yeah, my
Sebastian Schuberth sschube...@gmail.com writes:
On Sun, Jan 19, 2014 at 12:40 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
This patch applies on top of v3 of mh/safe-create-leading-directories.
The only logical change from Sebastian's patch is that this version
restores the original
Jeff King p...@peff.net writes:
...
does complicate the point of my series, which was to add more intimate
logic about how we handle LESS.
...
return !x || strchr(x, 'R');
}
[...]
}
but we are still hard-coding a lot of intelligence about less here.
I am not
Michael Haggerty mhag...@alum.mit.edu writes:
On 01/09/2014 09:11 PM, Junio C Hamano wrote:
Andy Lutomirski l...@amacapital.net writes:
It's possible, in principle, to shove enough metadata into the output
of 'git archive' to allow anyone to verify (without cloning the repo)
to verify
Jeff King p...@peff.net writes:
Perhaps instead of just dumping it into a macro, we could actually parse
it at compile time into C code, and store the result as a header file.
Then that header file becomes the proper dependency, and this run-time
error:
+while (*pager_env) {
+
Sebastian Schuberth sschube...@gmail.com writes:
On Thu, Jan 2, 2014 at 10:08 PM, Junio C Hamano gits...@pobox.com wrote:
Seems like the path to clone to is taken as-is from argv in
cmd_clone(). So maybe another solution would be to replace all
backslashes with forward slashes already
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed under GPLv2
b) significant contributions
Cosmin Apreutesei cosmin.apreute...@gmail.com writes:
I would like to be able to tell my users that they can simply do:
git clone --git-dir=_/git/module1/.git module1-url
git clone --git-dir=_/git/module2/.git module2-url
which will overlay the files from both modules into the current
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
If the git version number consists of less than three period
separated numbers, then the windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION = 1.9.rc0
windres -O coff \
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/majordomo-info.html
Junio C Hamano gits...@pobox.com writes:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
If the git version number consists of less than three period
separated numbers, then the windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION
David Kastrup d...@gnu.org writes:
---
Thanks. At some point during its development I must have thought
that having it as a dual-linked list may make it easier when we have
to split a block into pieces, but it seems that split_overlap() does
not need to look at this information.
Needs
libraries
remove #!interpreter line from shell libraries
stop installing git-tar-tree link
pager: set LV=-c alongside LESS=FRSX
diff test: reading a directory as a file need not error out
Junio C Hamano (28):
revision: introduce --exclude=glob to tame wildcards
Christian Couder chrisc...@tuxfamily.org writes:
This patch parses the trailer command line arguments
and put the result into an arg_tok doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 77
Jeff King p...@peff.net writes:
This tradeoff probably makes sense in the context of
pack-objects, where we have set revs-edge_hint to have the
traversal feed us the set of boundary objects. For a
regular rev-list, though, it is probably not a good
tradeoff. It is true that it makes our
Junio C Hamano gits...@pobox.com writes:
+static struct trailer_item *create_trailer_item(const char *string)
+{
+struct strbuf tok = STRBUF_INIT;
+struct strbuf val = STRBUF_INIT;
+struct trailer_item *new;
+
+parse_trailer(tok, val, string);
+
+int tok_alnum_len
Siddharth Agarwal s...@fb.com writes:
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
Thanks, Siddharth.
It seems that we have a hand-crafted parser
Junio C Hamano gits...@pobox.com writes:
Siddharth Agarwal s...@fb.com writes:
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
Thanks, Siddharth
Philip Oakley philipoak...@iee.org writes:
Determining which is the current release note is possibly more
problematic, which should be when making the documentation.
Hmmm Why?
You are already aware of the stale-notes section, no? Isn't the top
one the latest?
--
To unsubscribe from this
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by now after seeing
https://sourceware.org/ml/binutils/2012-07/msg00199.html
Ah, nice find!
I will test your patch (below) and let you know soon, but it
Pete Wyckoff p...@padd.com writes:
Most of this is work on tests for git p4.
Patch 03 is a regression fix, found and narrowed down thanks to
much work by Damien Gérard. But it is obscure enough that I'm
not proposing it for a maintenance release.
There are a couple other behavior fixes,
Philip Oakley philipoak...@iee.org writes:
I already have a local patch that creates a stalenote.txt file, and
includes that in a release-notes(7) man page, but it still leaves
the actual release notes in a separate plain text file, linked from
the man page, rather than being right at hand,
Javier Domingo Cansino javier...@gmail.com writes:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Aside from the obvious we won't be able to use something that is no
longer offered? They are
Michael Haggerty mhag...@alum.mit.edu writes:
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
$ make doc
$ grep -nIE -e '^\.SH DOCUMENTATION|AUTHOR' Documentation/*.[0-9]
Documentation/git-column.1:80:.SH
Michael Haggerty mhag...@alum.mit.edu writes:
Add cross-references between the manpages for git-for-each-ref(1) and
git-show-ref(1).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
There is a lot of overlap between the functionality of these two
commands.
Two differences I most
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's
Johannes Sixt j.s...@viscovery.net writes:
[Cc Pat, who added git.rc]
Am 1/22/2014 0:48, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by now after seeing
https://sourceware.org
101 - 200 of 27729 matches
Mail list logo
