It's almost like the compiler is getting the initializer wrong. It's a
long shot, but I wonder if the presence of the bitfield could be
triggering a compiler bug (or there is a subtle C rule about bitfield
initializations that I do not know). Just for the sake of my sanity,
what does the
Jeff King p...@peff.net writes:
On Thu, Jan 31, 2013 at 07:27:04AM +, Jongman Heo wrote:
FYI, gdb backtrace and valgrind output attached below, Thanks.
Thanks, that's helpful.
#4 0x0812bda0 in string_list_insert (list=0xbfffe7c0,
string=0x821ec3c refs/remotes/origin/HEAD) at
On Thu, Jan 31, 2013 at 09:42:07AM +0100, Thomas Rast wrote:
int main(void)
{
struct foo f = { NULL, 0, 0, 0 };
printf(cmp is %lu\n, (unsigned long)f.cmp);
return 0;
}
I doubt that would help because that stack region would be 0 anyway due
to kernel initialization of new
On 01/31/2013 12:23 PM, Scott Yan wrote:
Sitaram:
It seems I must host my central repo on Gitolite first...
There is no must but yes it is a decent solution and can, in
principle, do the kind of checking you want if you set it up to do that.
Please note that I don't use that mode and, as my
On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
space/time trade-off.
Following the on-disk format experiment yesterday, I changed the
format to:
- a list a _short_ SHA-1 of cached commits
- a list of cache entries,
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany bracelet {snip} a is
{snip}
So, apparently git-daemon's http
When reporting the outcome of a push, a segfault occurs if HEAD does
not point somewhere. Check that HEAD points somewhere before trying
to strcmp it.
Signed-off-by: Fraser Tweedale fr...@frase.id.au
---
transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/transport.c
On Thu, Jan 31, 2013 at 1:46 PM, porpen+...@gmail.com wrote:
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany
I was not familiar with this behavior of 'install -d' that it tries to change
the mode of an existing directory, but GNU coreutils 8.12.197-032bb
certainly behaves as TJ reports.
As a possible alternative, what about
[ -d $(DESTDIR)$(main1dir) ] || $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
so
On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano gits...@pobox.com wrote:
JCH Jeff King p...@peff.net writes:
But it would probably make sense for send-email to support the existing
git-credential subsystem, so that it can take advantage of secure
system-specific storage. And that is where
Jeff Epler jep...@unpythonic.net writes:
I was not familiar with this behavior of 'install -d' that it tries to change
the mode of an existing directory, but GNU coreutils 8.12.197-032bb
certainly behaves as TJ reports.
As a possible alternative, what about
[ -d $(DESTDIR)$(main1dir) ]
TJ g...@iam.tj writes:
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN1)
Jeff King p...@peff.net writes:
That being said, we could be much more helpful. It seems like --contains
should imply listing mode, since it is nonsensical in other modes. The
second patch below adjusts that, and makes the command above do what you
expect.
[1/2]: docs: clarify git-branch
Fraser Tweedale fr...@frase.id.au writes:
When reporting the outcome of a push, a segfault occurs if HEAD does
not point somewhere. Check that HEAD points somewhere before trying
to strcmp it.
Signed-off-by: Fraser Tweedale fr...@frase.id.au
---
transport.c | 2 +-
1 file changed, 1
On Thursday 31 January 2013 01:46:11 Jeff King wrote:
Currently, a branch filter like `--contains`, `--merged`, or
`--no-merged` is ignored when we are not in listing mode.
For example:
git branch --contains=foo bar
will create the branch bar from the current HEAD, ignoring
the
Stephen Boyd sb...@codeaurora.org writes:
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
because they didn't indicate *which* pipe couldn't be
On Tue, Jan 29, 2013 at 1:19 PM, Jeff King p...@peff.net wrote:
On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote:
The point is not about space. Disk is cheap, and it is not making
it any worse than what happens to your target audience, that is a
fetch-only repository with only
On 31/01/13 15:51, Junio C Hamano wrote:
TJ g...@iam.tj writes:
+$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir)
+$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir)
+$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir)
+$(INSTALL)
Peter Wu lekenst...@gmail.com writes:
One note, the following command spits out master without complaining about
the
non-existing branch name:
git branch --contains id master non-existant branch name
(the order of branches doesn't affect the result.)
That is perfectly normal.
What
On Wed, Jan 30, 2013 at 7:56 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
From this:
Then it will be very natural for the extension data that store the
commit metainfo to name objects in the pack the .idx file describes
by the offset in the SHA-1 table.
I
On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@imag.fr wrote:
It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
from documentation (even though it's still supported) to make the
explanations
On Tue, Jan 29, 2013 at 1:14 AM, Jeff King p...@peff.net wrote:
This is the cleaned-up version of the commit caching patches I mentioned
here:
http://article.gmane.org/gmane.comp.version-control.git/212329
...
The short of it is that for an extra 31M of disk
space (~4%), I get a warm-cache
Hi,
The way we upload the Linux kernel to kernel.org involves creating a tar
archive, signing the archive, and then just uploading the signature.
The server then checks out the repo based on the tag, generates the tar
archive and checks the signature to make sure they match.
A few days ago I
Greg KH gre...@linuxfoundation.org writes:
The way we upload the Linux kernel to kernel.org involves creating a tar
archive, signing the archive, and then just uploading the signature.
The server then checks out the repo based on the tag, generates the tar
archive and checks the signature to
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@imag.fr wrote:
It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
from documentation (even
On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:
Greg KH gre...@linuxfoundation.org writes:
The way we upload the Linux kernel to kernel.org involves creating a tar
archive, signing the archive, and then just uploading the signature.
The server then checks out the repo
On 31/01/13 12:41 PM, Greg KH wrote:
Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up
doing lots of kernel releases while traveling), would be a horrible
change. I'd rather just keep using the same older version of git that
kernel.org is running instead.
Well, we do
On 01/31/13 08:24, Junio C Hamano wrote:
Stephen Boyd sb...@codeaurora.org writes:
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
because they
On 01/30/13 21:50, Jeff King wrote:
The strbuf_read above will read to EOF, so it should be equivalent (and
IMHO slightly more readable) to do:
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..5f142f6 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -130,8 +130,10 @@ int
Hey folks,
On 31 January 2013 08:22, Erik Faye-Lund kusmab...@gmail.com wrote:
This isn't a running instance of git-daemon, it's a web front-end for
the mailing list. It seems nabble allows image-attachments, and that's
what you're seeing; an attached image to a spam-email that was sent to
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges | grep key
on the linux kernel git repo. Eventually it will fail with
Stephen Boyd wrote:
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Yeah. Other error messages in this file are already translated, so
it's oddly inconsistent.
Assuming this passes tests with GETTEXT_POISON=YesPlease,
Reviewed-by:
Am 31.01.2013 18:28, schrieb Greg KH:
I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully). The diff of a hex dump
of the tar archives shows the following difference:
--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
As I mentioned recently, while discussing a cygwin specific patch
(see Version 1.8.1 does not compile on Cygwin 1.7.14 thread), the
MSVC build is broken for me.
The first 4 patches fix the MSVC build for me. The final patch is
not really related to fixing the build, but it removed some make
Commit 0f77dea9 (mingw: move poll out of sys-folder, 24-10-2011), along
with other commits in the 'ef/mingw-upload-archive' branch (see commit
7406aa20), effectively reintroduced the same problem addressed by commit
56fb3ddc (msvc: Fix compilation errors in compat/win32/sys/poll.c,
04-12-2010).
In particular, while linking git-daemon.exe, the linker complains
that the external symbols _inet_pton and _inet_ntop are unresolved.
Commit a666b472 (daemon: opt-out on features that require posix,
04-11-2010) addressed this problem for MinGW by configuring the
use of the internal 'compat'
In particular, remote-testsvn.c fails to compile with two
undeclared identifier errors relating to the 'UINT32_MAX'
and 'STDIN_FILENO' symbols.
In order to fix the compilation errors, we add appropriate
definitions for the UINT32_MAX and STDIN_FILENO constants
to an msvc compat header file.
In particular, while linking test-svn-fe.exe, the linker complains
that the external symbol _strtoull is unresolved. A call to this
function was added in commit ddcc8c5b (vcs-svn: skeleton of an svn
delta parser, 25-12-2010).
The NO_STRTOULL build variable attempts to provide support to old
Commit 2f769195 (MinGW: avoid collisions between tags and TAGS,
28-09-2010) enabled MinGW to use an ETAGS file in order to avoid
filename collisions on (Windows) case insensitive filesystems. In
addition, this prevents 'make' from issuing several warning messages.
When using the Makefile to
On Wed, Jan 30, 2013 at 9:37 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
Brandon Casey wrote:
Round 3.
Thanks for a pleasant read. My only remaining observations are
cosmetic, except for a portability
Hi Ramsay,
On Thu, 31 Jan 2013, Ramsay Jones wrote:
As I mentioned recently, while discussing a cygwin specific patch
(see Version 1.8.1 does not compile on Cygwin 1.7.14 thread), the
MSVC build is broken for me.
The first 4 patches fix the MSVC build for me. The final patch is
not really
Hi,
Junio C Hamano wrote:
Wow, that's a blast from the past.
I tend to agree that deprecating and removing are quite different,
but a simple revert of the change would not be good, either. We
still would want to _discourage_ its use.
Hm, I was about to try adding a line in that vein, like
Jonathan Nieder wrote:
Is the problem that deprecated is not precise enough? For example,
would it make sense to say deprecated synonym for `upstream`. Will
be dropped in git 2.1 or something like that?
Also, if we plan to remove support soon, we should start warning when
this setting is
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi Ramsay,
On Thu, 31 Jan 2013, Ramsay Jones wrote:
As I mentioned recently, while discussing a cygwin specific patch
(see Version 1.8.1 does not compile on Cygwin 1.7.14 thread), the
MSVC build is broken for me.
The first 4 patches
Hi Constantine,
Constantine A. Murenin wrote:
DragonFly BSD uses git as its SCM, with one single repository and
branch for both the kernel and the whole userland.
On 2011-11-26 (1322296064), someone did a commit that somehow touched
every single file in the repository, even though most of
On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
Jeff, is there a way for git-credential to currently support
authinfo/netrc parsing? I assume that's the right way, instead of using
Michal's proposal to parse internally?
I'd like to add that, plus support for the 'string' and
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Wow, that's a blast from the past.
I tend to agree that deprecating and removing are quite different,
but a simple revert of the change would not be good, either. We
still would want to _discourage_ its use.
Hm, I was
Junio C Hamano wrote:
That is why I tend to prefer how check-ref-format documentation
describes --print:
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
Jonathan Nieder jrnie...@gmail.com writes:
Jonathan Nieder wrote:
Is the problem that deprecated is not precise enough? For example,
would it make sense to say deprecated synonym for `upstream`. Will
be dropped in git 2.1 or something like that?
Also, if we plan to remove support soon,
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
That is why I tend to prefer how check-ref-format documentation
describes --print:
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposite direction), it should be unmistakingly clear that
`tracking`
Jonathan Nieder jrnie...@gmail.com writes:
How about the following?
* `nothing` - ...
* `matching` - ...
* `upstream` - ...
* `simple` - ...
* `current` - ...
For compatibility with ancient config files, the following synonym
is also supported. Don't use it.
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
That works because, as you mention, the usual way to look up an option
in manpages is to search for --print, including the two minus signs.
Unfortunately an analagous approach in gitconfig(5) would be seriously
broken, because
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
remote-helpers looks for gitremote-helpers
John Keeping j...@keeping.me.uk writes:
Would we want to do something to avoid breaking links to the existing
document as well?
That would be nice to add a new git-remote-helpers.txt saying document
has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposite direction), it
Matthieu Moy matthieu@grenoble-inp.fr writes:
John Keeping j...@keeping.me.uk writes:
Would we want to do something to avoid breaking links to the existing
document as well?
That would be nice to add a new git-remote-helpers.txt saying document
has moved, see
From: Jonathan Nieder jrnie...@gmail.com
Sent: Thursday, January 31, 2013 8:04 PM
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but
Jonathan Nieder jrnie...@gmail.com writes:
Am I really the only one that doesn't see the --print change as
hiding an option and sees burying tracking in the text as
qualitatively different?
Sorry, but I do not understand the question.
We are hiding/burying the --print option to make it clear
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
Am I really the only one that doesn't see the --print change as
hiding an option and sees burying tracking in the text as
qualitatively different?
Sorry, but I do not understand the question.
We are
How about doing it this way? I do not think anything that is
deprecated even deserves a separate section and do not use it!
heading.
-- 8 --
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means.
Instead of not mentioning
Junio C Hamano wrote:
How about doing it this way?
[...]
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1795,7 +1795,8 @@ push.default::
+
This is currently the default, but Git 2.0 will change the default
to `simple`.
-* `upstream` - push the current branch to
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
remote-helpers looks for gitremote-helpers
Before parsing a suspected smart-HTTP response verify the returned
Content-Type matches the standard. This protects a client from
attempting to process a payload that smells like a smart-HTTP
server response.
JGit has been doing this check on all responses since the dawn of
time. I mistakenly
John Keeping j...@keeping.me.uk writes:
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
On Thu, 31 Jan 2013 20:08:14 +, John Keeping j...@keeping.me.uk wrote:
This is the patch to rename it to gitremote-helpers.txt.
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have 'git-remote' but 'gitremote-helpers'.
--
To
On Thu, Jan 31, 2013 at 02:13:10PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic
On Thu, Jan 31, 2013 at 09:59:50PM +, John Keeping wrote:
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of
On Thu, Jan 31, 2013 at 08:24:21AM -0800, Junio C Hamano wrote:
Stephen Boyd sb...@codeaurora.org writes:
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error:
On Thu, Jan 31, 2013 at 1:59 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
Before parsing a suspected smart-HTTP response verify the returned
Content-Type matches the standard. This protects a client from
attempting to process a payload that smells like
On Thu, Jan 31, 2013 at 10:18:40AM -0800, Stephen Boyd wrote:
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges |
John Keeping j...@keeping.me.uk writes:
Yes. Should I change it to git-remote-helpers.html.in and then copy
it into place? That seems like the simplest answer and means that
*.html will continue to refer only to generated files.
I'd like to see if we can have a way to keep its look as the
Tomas Carnecky tomas.carne...@gmail.com writes:
On Thu, 31 Jan 2013 20:08:14 +, John Keeping j...@keeping.me.uk wrote:
This is the patch to rename it to gitremote-helpers.txt.
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have
Jeff King p...@peff.net writes:
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me.
It feels equally weird to say man gitremotehelpers (or in general
man git-thing or man gitconcept), to me. I gave up and switched
to git help
On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Yes. Should I change it to git-remote-helpers.html.in and then copy
it into place? That seems like the simplest answer and means that
*.html will continue to refer only to generated
Jeff King wrote:
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me. I know it technically follows our syntactic rules,
but having the lack of dash be significant between git and remote,
but then having a dash later makes it hard
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me. I know it technically follows our syntactic rules,
but having the lack of dash be significant between git and remote,
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Yes. I have thought for years that it should be git-remote-helpers,
that git help should be tweaked to look for that, and that the
existing gitrepository-layout and friends should be replaced with
redirects.
Because of the
John Keeping j...@keeping.me.uk writes:
On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Yes. Should I change it to git-remote-helpers.html.in and then copy
it into place? That seems like the simplest answer and means that
*.html
Jeff King p...@peff.net writes:
But it is not much code, and sometimes it is surprising what information
can be helpful when debugging, so like you, I am not opposed, just
doubtful.
Yes, exactly my feeling.
Perhaps I should just amend the 'stdin' and friends away without
asking Stephen to
On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote:
+If `--list` is given, or if there are no non-option arguments, existing
+branches are listed; the current branch will be highlighted with an
+asterisk. Option `-r` causes the remote-tracking branches to be listed,
+and option
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote:
+If `--list` is given, or if there are no non-option arguments, existing
+branches are listed; the current branch will be highlighted with an
+asterisk. Option `-r` causes the
Thomas Ackermann th.ac...@arcor.de writes:
Thomas, I do not want to see many rounds of entire rerolls of this
series on the list (nobody will look at the whole series multiple
times with fine toothed comb). I do not think you want to do that
either. Can you collect remaining fixups like
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Odd. https://www.gravatar.com/; also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks; will hold onto Andrej's patch until
Jonathan Nieder jrnie...@gmail.com writes:
[...]
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1795,7 +1795,8 @@ push.default::
+
This is currently the default, but Git 2.0 will change the default
to `simple`.
-* `upstream` - push the current branch to its
[snip]
Good point. Unfortunately, I can't get either yours or mine to fail,
neither with a recent version of gcc nor with gcc-4.1. But I can't
convince git to fail, either. The only gcc-4.1 I have is Debian's
4.1.3 release, which is not quite what the OP has.
Or perhaps something in
허종만 jongman@samsung.com writes:
But usually when I build upstream Linux kernel, I don't do make
clean after git pull.. I didn't expect that I needed make
clean for git build.
We don't expect anybody need make clean, either. There is
something wrong in the dependency.
--
To unsubscribe
Heiko Voigt hvo...@hvoigt.net writes:
Maybe Martin or Junio immediately see whats going wrong here? I would
need to further dig into the git-am code to find out how to fix it.
Thanks. I think the minimum fix is this, but there are some nits to
pick around this area as well.
diff --git
git rebase used to use format-patch --full-index to generate a
series of patches and let git am --rebase reconstruct a fake
preimage tree by reading the object names from the index lines.
With a230949 (am --rebasing: get patch body from commit, not from
mailbox, 2012-06-26), we switched to use
Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end. While doing so, it used git diff-tree but without
giving it the --full-index option.
The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor,
git am -3 uses this function to build a tree that records how the
preimage the patch was created from would have looked like. An
abbreviated object name on the index line is ordinarily sufficient
for us to figure out the object name the preimage tree would have
contained, but a change to a
On Thu, Jan 31, 2013 at 03:04:55PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me. I know it technically follows our syntactic rules,
but having the lack of dash be
On Thu, Jan 31, 2013 at 04:37:01PM -0800, Junio C Hamano wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote:
+If `--list` is given, or if there are no non-option arguments, existing
+branches are listed; the current branch
Jeff King p...@peff.net writes:
What was the original rationale for the gitfoo form? Was it just to
visually distinguish command manpages from non-command manpages? I can't
remember the origins now.
b27a23e (Documentation: convert tutorials to man pages, 2008-05-24)
turns tutorial.txt into
Jeff King p...@peff.net writes:
Thanks. No matter how many times I proofread a doc change, I always
manage to slip an error into the final version.
I think everybody shares that trait.
Hooray for many eyes.
Indeed.
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Jeff King p...@peff.net writes:
It seems a little weird to me that clang defines __GNUC__, but I
assume there are good reasons for it.
The thing is that gcc is as much a language dialect these days as it
is a compiler implementation, and many other compilers, including
clang, explicitly try to
The strong links of london sale
http://www.linksoflondonbraceletsweetie.co.uk/ /strong has forever
tried its best to bargain the customers a balance of present and sole
private mode couple necklaces for lovers in the world. All crop was packed
with people who like the flavor of life consistently.
Here I want to share you my happiness. Yesterday I have received my thomas
sabo uk which I ordered a few days ago. The one I bought is made with Neon
Yellow elastic with three lovely charms. So cute and fashionable these
Thomas Sabo Bracelets they are. By wearing these bracelets can make us
1 - 100 of 105 matches
Mail list logo