On 09/14/2014 08:27 AM, Michael Haggerty wrote:
> On 09/13/2014 09:41 AM, Johannes Sixt wrote:
>> Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
>>> It's bad manners. Especially since, if unlink_or_warn() failed, the
>>> memory wasn't restored to its original contents.
>>
>> I do not see how the
On 09/13/2014 09:41 AM, Johannes Sixt wrote:
> Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
>> It's bad manners. Especially since, if unlink_or_warn() failed, the
>> memory wasn't restored to its original contents.
>
> I do not see how the old code did not restore the file name. Except for
>
glibc has deprecated the use of _BSD_SOURCE define
warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
To make it easier to maintain a cross platform source code, that
warning can be suppressed by _DEFAULT_SOURCE.
Define both _BSD_SOURCE, _DEFAULT_SOURCE and cleanup the
On Sat, Sep 13, 2014 at 7:00 PM, Perry Hutchison wrote:
> David Aguilar wrote:
>> Add a #ifndef guard to ensure that common-cmds.h can only
>> be included by help.c.
>
> This strikes me as a very peculiar, and sub-optimal, way of
> achieving the purpose. If these definitions are intended to
> be
David Aguilar wrote:
> Add a #ifndef guard to ensure that common-cmds.h can only
> be included by help.c.
This strikes me as a very peculiar, and sub-optimal, way of
achieving the purpose. If these definitions are intended to
be private to help.c, why not put them there and eliminate
common-cmds
On Sat, Sep 13, 2014 at 09:01:20PM -0400, Jeff King wrote:
> [1] We do use the mbox format in git, and AFAIK do not do any
> From-quoting of this nature. I haven't tested, but I suspect that
> certain format-patch output would be corrupted when reading back via
> "git am", let alone o
Add a #ifndef guard to ensure that common-cmds.h can only
be included by help.c.
Suggested-by: Junio C Hamano
Signed-off-by: David Aguilar
---
generate-cmdlist.sh | 4
help.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/generate-cmdlist.sh b/generate-
On Sat, Sep 13, 2014 at 05:55:49PM -0700, Junio C Hamano wrote:
> On Sat, Sep 13, 2014 at 5:47 PM, Jeff King wrote:
> >
> > On Sat, Sep 13, 2014 at 10:57:14PM +, brian m. carlson wrote:
> >
> > > I wonder if git send-email should do what mutt does in this case, which
> > > is use quoted-print
Add dependent headers so that including a header does not
require including additional headers.
Move the unicode interval types to unicode_width.h so that we
can include them from utf8.h.
This makes it so that "gcc -c $header" succeeds for each header.
Helped-by: René Scharfe
Signed-off-by: Dav
This allows us to ensure that each header can be included
individually without needing to include other headers first.
Implicitly include git-compat-util.h during the check since
the implementation files will have already included it.
Helped-by: Jonathan Nieder
Helped-by: Junio C Hamano
Helped-
On Sat, Sep 13, 2014 at 5:47 PM, Jeff King wrote:
>
> On Sat, Sep 13, 2014 at 10:57:14PM +, brian m. carlson wrote:
>
> > I wonder if git send-email should do what mutt does in this case, which
> > is use quoted-printable encoding and encode the first F as =46 (as well
> > as any equals signs
On Sat, Sep 13, 2014 at 10:57:14PM +, brian m. carlson wrote:
> On Sat, Sep 13, 2014 at 05:25:05PM -0400, Jeff King wrote:
> > Thanks both of you for following up. I did confirm that git-send-email
> > does not add such quoting. From your findings above, I'd agree that it's
> > the list-archiv
On Sat, Sep 13, 2014 at 05:25:05PM -0400, Jeff King wrote:
> Thanks both of you for following up. I did confirm that git-send-email
> does not add such quoting. From your findings above, I'd agree that it's
> the list-archive software munging it, and they are buggy IMHO (they
> should de-quote on d
On Fri, Sep 12, 2014 at 12:05:48PM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Use `git rev-parse --verify --quiet` instead of redirecting
> > stderr to /dev/null.
> >
> > Signed-off-by: David Aguilar
> > ---
>
> Has this patch ever been tested? t3903 seems to break with this at
When a reflog is deleted, e.g. when "git stash" clears its stashes,
"git rev-parse --verify --quiet" dies:
fatal: Log for refs/stash is empty.
The reason is that the get_sha1() code path does not allow us
to suppress this message.
Pass the flags bitfield through the get_sha1_with_context
[-cc driver-devel list, as this is getting into git patches]
On Sun, Sep 14, 2014 at 12:09:08AM +0300, Dan Carpenter wrote:
> > > FYI it was 'git send-email' v2.1.0 that sent the mail, and I don't have
> > > the offending character in any versions of the mail I can see.
> [...]
> Piper mail has '
On Sat, Sep 13, 2014 at 11:57:51PM +0300, Dan Carpenter wrote:
> On Sat, Sep 13, 2014 at 09:47:45PM +0100, Mark Einon wrote:
> > On Sat, Sep 13, 2014 at 04:36:45PM -0400, Jeff King wrote:
> > > I don't think we can make this 100% foolproof without knowing which mbox
> > > variant the writer used. B
On Sat, Sep 13, 2014 at 11:57:51PM +0300, Dan Carpenter wrote:
> On Sat, Sep 13, 2014 at 09:47:45PM +0100, Mark Einon wrote:
> > On Sat, Sep 13, 2014 at 04:36:45PM -0400, Jeff King wrote:
> > > I don't think we can make this 100% foolproof without knowing which mbox
> > > variant the writer used. B
On Sat, Sep 13, 2014 at 04:36:45PM -0400, Jeff King wrote:
> I don't think we can make this 100% foolproof without knowing which mbox
> variant the writer used. But dropping the line is probably the worst
> possible thing, as it does not match _any_ variants. :)
Hi,
FYI it was 'git send-email' v2
On Sat, Sep 13, 2014 at 09:47:45PM +0100, Mark Einon wrote:
> On Sat, Sep 13, 2014 at 04:36:45PM -0400, Jeff King wrote:
> > I don't think we can make this 100% foolproof without knowing which mbox
> > variant the writer used. But dropping the line is probably the worst
> > possible thing, as it do
On Sat, Sep 13, 2014 at 08:45:56AM -0700, Greg KH wrote:
> On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote:
> > On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
> > > >From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
> > > multicast_pkts_xmtd, broadcast_pkts_rcv
We allocate pack information in a static global list but
never clean it up. This leaks memory, and means that calling
update_server_info twice will generate a buggy file (it will
have duplicate entries).
Signed-off-by: Jeff King
---
server-info.c | 9 +
1 file changed, 9 insertions(+)
d
Since "git update-server-info" may be called automatically
as part of a push or a "gc --auto", we should be robust
against two processes trying to update it simultaneously.
However, we currently use a fixed tempfile, which means that
two simultaneous writers may step on each other's toes and
end up
We form all of our directories in a strbuf, but never release it.
Signed-off-by: Jeff King
---
builtin/prune-packed.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index 6879468..d430731 100644
--- a/builtin/prune-packed.c
+++ b/builtin/prune
On Sat, Sep 13, 2014 at 09:28:01AM +0200, René Scharfe wrote:
> Call the functions behind git prune-packed and git update-server-info
> directly instead of using run_command(). This is shorter, easier and
> quicker.
It can also introduce bugs, since a lot of git code assumes it is
running in a s
On Sat, Sep 13, 2014 at 08:45:56AM -0700, Greg KH wrote:
> On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote:
> > On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
> > > >From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
> > > multicast_pkts_xmtd, broadcast_pkts_rcvd
On Fri, Sep 12, 2014 at 04:21:09PM +0200, Michael Haggerty wrote:
> > But I still wonder how hard it would be to just remove lock_file structs
> > from the global list when they are committed or rolled back.
> [...]
>
> To make that change, we would have to remove entries from the list of
> lock_f
Junio C Hamano writes:
> I noticed that with this series merged to the version I use daily,
> detaching HEAD (i.e. "git checkout HEAD^0") breaks my HEAD reflog,
> which made me redo the integration ejecting the series out of 'pu'.
>
> Not happy, as my workflow relies fairly heavily on detached HE
On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote:
> On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
> > >From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
> > multicast_pkts_xmtd, broadcast_pkts_rcvd and broadcast_pkts_xmtd
>
> For some reason something adds a '>
On 09/12/2014 09:10 PM, Rom Walton wrote:
> I found this:
> http://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
>
> That might help in the future.
This helped :
git reset --hard 9e860d0451
git pull
git clean -f
git gc
git p
Signed-off-by: Ian Liu Rodrigues
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 9f984a9..496af55 100644
--- a/Makefile
+++ b/Makefile
@@ -14,11 +14,11 @@ all::
# Define INLINE to a suitable substitute (such as '__inline' or '') if g
Am 12.09.2014 um 15:58 schrieb Edward Z. Yang:
tl;dr You can't git-new-workdir checkouts which use core.worktree. This
is unfortunate because 'git submodule init' uses core.worktree by
default, which means you can't recursively git-new-workdir without a
hack.
In the beginning, the Developer cre
Am 11.09.2014 um 22:33 schrieb Cole:
Thanks for the feedback, really appreciate it, and will try to reformat
the patches as you have asked.
Thanks!
When you say you would like the patches split, do you mean into two
separate threads, or just different patches part of the same thread?
I thin
Am 12.09.2014 um 07:21 schrieb Fredrik Gustafsson:
On Thu, Sep 11, 2014 at 10:33:51PM +0200, Cole wrote:
Also if there is anything else you are currently looking at regarding
submodules or thinking about, I would be glad to hear about it or to try
look at it while I am working on these changes.
Am 12.09.2014 um 15:03 schrieb Edward Z. Yang:
Hello Jens,
Excerpts from Jens Lehmann's message of 2014-09-11 15:29:28 -0400:
Git does know what's going on, just fails to display it properly
in the diff, as the output of ls-files shows:
$git ls-files -u
16 6a6e215138b7f343fba67ba
On Thursday 04 September 2014 20:37:52 Nguyễn Thái Ngọc Duy wrote:
> This patch fixes two problems with using :(glob) (or even "*.c"
> without ":(glob)").
>
> The first one is we forgot to turn on the 'recursive' flag in struct
> pathspec. Without that, tree_entry_interesting() will not mark
> pot
On Wednesday 03 September 2014 13:21:06 Duy Nguyen wrote:
> On Wed, Sep 3, 2014 at 5:17 AM, Peter Wu wrote:
> > Hi,
> >
> > The `git archive` seems to accept a pathspec judging from the error message
> > (git
> > version 2.1.0):
> >
> > git archive HEAD -- :x
> > fatal: pathspec 'x' did n
On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
> >From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
> multicast_pkts_xmtd, broadcast_pkts_rcvd and broadcast_pkts_xmtd
For some reason something adds a '>' to the start of lines which start
with 'From'. I don't know what it is
Hi Junio,
On Fri, 12 Sep 2014, Junio C Hamano wrote:
> Thanks. I think this is ready for 'next' and then down to 'master'
> for the next release.
Thank you!
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
On 13.09.2014 09:28, René Scharfe wrote:
> Call the functions behind git prune-packed and git update-server-info
> directly instead of using run_command(). This is shorter, easier and
> quicker.
>
> Signed-off-by: Rene Scharfe
Thanks for cleaning up the literal rewrite of the shell script
and m
# gits...@pobox.com / 2014-09-12 10:31:30 -0700:
> Roman Neuhauser writes:
> > git-diff-tree without --root is absolutely silent for the root commit,
> > and i see no bad effects of --root on non-root commits. are there any
> > hidden gotchas? IOW, why is the --root behavior not the default?
>
Am 13.09.2014 um 00:48 schrieb Junio C Hamano:
> The pre-receive and post-receive hooks were designed to be an
> improvement over old style update and post-update hooks that used to
> take the update information on the command line and were limited by
> the command line length limit. They take the
Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
> It's bad manners. Especially since, if unlink_or_warn() failed, the
> memory wasn't restored to its original contents.
I do not see how the old code did not restore the file name. Except for
this nit, the patch looks good.
>
> So make our own c
Call the functions behind git prune-packed and git update-server-info
directly instead of using run_command(). This is shorter, easier and
quicker.
Signed-off-by: Rene Scharfe
---
builtin/repack.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/built
44 matches
Mail list logo
