Jiang Xin:
Because I update the .po files with msgmerge, this update also
brings some format changes, so not panic. :) What I changed are:
Swedish (sv) looks fine, thanks!
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
>
> NOTE for Ralf: After I updated de.po, there are 3 fuzzies instead of one.
> I can only fix one of them.
>
I just send a pull-request to you. It seems I have forgotten one git.pot update.
Sorry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
Signed-off-by: Ralf Thielow
---
I already sent a pull request with this change due to
lack of time because the messages were fairly easy to
translate. If there's something wrong with these translations,
we need to fix it in a separate patch.
po/de.po | 4 +---
1 file changed, 1 insertion(+), 3 d
Hi,
Only two days left for Git 2.2.0 final according to Git calendar
(http://tinyurl.com/gitCal),
but there is a new update for our L10N team to respond.
The change is so small, I can handle it. git-diff shows:
-msgid "empty trailer token in trailer '%s'"
+msgid "empty trailer token in t
Hi,
Stefan Beller wrote:
> Sorry for the long delay.
> Thanks for the explanation and discussion.
>
> So do I understand it right, that you are not opposing
> the introduction of "everything should go through transactions"
> but rather the detail and abstraction level of the API?
For what it's w
Stefan Beller wrote:
> [Subject: [PATCH] refs.c: add a function to append a reflog entry to a fd]
Does this supersede the other patch with the same subject?
Please keep adding v in the subject --- when it's there, it makes
reading much easier.
>
Missing 'From:' line naming the original patch a
Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> This patch doesn't intend any functional changes. It is just
> a refactoring, which replaces a char** array by a stringlist
> in the function repack_without_refs.
> This is easier to read and maintain as it delivers the same
> functionality with le
Break out the code to create the string and writing it to the file
descriptor from log_ref_write and add it into a dedicated function
log_ref_write_fd. For now this is only used from log_ref_write,
but later on we will call this function from reflog transactions too,
which means that we will end up
Stefan Beller wrote:
> Compared to the last send of this patch[1], there was one change in the print
> function. Replaced sprintf by snprintf for security reasons.
I prefer the version that didn't change the code while we are
extracting it into a new function. A separate patch on top can switch
(administrivia: please don't top-post)
Stefan Beller wrote:
> On Wed, Nov 19, 2014 at 5:10 PM, Jonathan Nieder wrote:
>> I feel a bit ashamed to have my sign-off peppering all these patches
>> that I didn't have anything to do with except preparing to send them
>> to the list once or twice. I'd
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Compared to the last send of this patch[1], there was one change in the print
>> function. Replaced sprintf by snprintf for security reasons.
>
> Careful. I despise people who blindly think strlcpy() and
> snprintf() are good solutions for fo
On Thu, Nov 20, 2014 at 6:41 AM, Phil Pennock
wrote:
> On 2014-11-19 at 16:48 +0700, Duy Nguyen wrote:
>> On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
>> wrote:
>> > Expected to work as .gitignore in top-level of repo:
>> >
>> > *
>> > !**/*.asc
>> > !.gitignore
>> >
>>
>> gitignore
Stefan Beller writes:
> Compared to the last send of this patch[1], there was one change in the print
> function. Replaced sprintf by snprintf for security reasons.
Careful. I despise people who blindly think strlcpy() and
snprintf() are good solutions for for security. They are by
themselves
I am sorry for not having asked before.
As I picked up the patches, you had sign offs pretty much at any patch.
I'll remove them from future patches when sending to the list.
On Wed, Nov 19, 2014 at 5:10 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> From: Ronnie Sahlberg
>>
>> The ref_t
Stefan Beller wrote:
> refs.c | 22 ++
> refs.h | 2 +-
> 2 files changed, 3 insertions(+), 21 deletions(-)
Likewise:
Reviewed-by: Jonathan Nieder
but this shouldn't have had my sign-off.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> The ref_transaction_update function can already be used to create refs by
> passing null_sha1 as the old_sha1 parameter. Simplify by replacing
> transaction_create with a thin wrapper.
>
> Signed-off-by: Ronnie Sahlberg
> Signed-off-by: Jonathan N
Jeff King wrote:
> Signed-off-by: Ronnie Sahlberg
> Signed-off-by: Jeff King
> ---
> refs.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Jonathan Nieder
(modulo the author attribution nit you noticed)
--
To unsubscribe from this list: send the line "unsubsc
From: Ronnie Sahlberg
Break out the code to create the string and writing it to the file
descriptor from log_ref_write and add it into a dedicated function
log_ref_write_fd. For now this is only used from log_ref_write,
but later on we will call this function from reflog transactions too,
which m
On Thu, Nov 20, 2014 at 1:48 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>> index 09e82c3..0340c44 100644
>> --- a/Documentation/gitignore.txt
>> +++ b/Documentation/gitignore.txt
>> @@ -82,10 +82,9 @@ PATTE
On 2014-11-19 at 16:48 +0700, Duy Nguyen wrote:
> On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
> wrote:
> > Expected to work as .gitignore in top-level of repo:
> >
> > *
> > !**/*.asc
> > !.gitignore
> >
>
> gitignore man page has this "It is not possible to re-include a file
> if
Sorry for the long delay.
Thanks for the explanation and discussion.
So do I understand it right, that you are not opposing
the introduction of "everything should go through transactions"
but rather the detail and abstraction level of the API?
So starting from Michaels proposal in the first respo
Aleksey Vasenev writes:
>> To: git@vger.kernel.org
>> Cc: Junio C Hamano , Aleksey Vasenev
Sorry, but I am hardly qualified to review this one, especially
without any log message that explains what breaks and how it breaks
with the current code, which may lead the reader to understand how
the u
On Wed, Nov 19, 2014 at 02:34:12PM -0800, Junio C Hamano wrote:
> > Subject: lock_ref_sha1_basic: do not die on locking errors
>
> Will queue; thanks.
I just noticed that when I pasted it into the mail, I dropped the
From: Ronnie Sahlberg
header. Can you please make sure to credit Ronnie as
Jeff King writes:
> So we still have to keep the last_errno handling in error_return.
> Meaning that we need to drop patch 2 (even though the other cases don't
> need errno saved/restore, since the goto does it unconditionally, we
> still need to set last_errno). And therefore patch 1 is not help
On Tue, Nov 18, 2014 at 06:07:13PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Hmph. Should we just abandon my series in favor of taking Ronnie's
> > original patch, then? We can apply the "save/restore errno in error()"
> > patch independently if we like.
>
> I liked patches 1 and 2
From: Ronnie Sahlberg
This patch doesn't intend any functional changes. It is just
a refactoring, which replaces a char** array by a stringlist
in the function repack_without_refs.
This is easier to read and maintain as it delivers the same
functionality with less lines of code and less pointers.
From: Ronnie Sahlberg
This patch doesn't intend any functional changes. It is just
a refactoring, which replaces a char** array by a stringlist
in the function repack_without_refs.
This is easier to read and maintain as it delivers the same
functionality with less lines of code and less pointers.
Signed-off-by: Aleksey Vasenev
---
.../credential/wincred/git-credential-wincred.c| 25 +++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/contrib/credential/wincred/git-credential-wincred.c
b/contrib/credential/wincred/git-credential-wincred.c
index a1d38f
Jeff King writes:
> Typically I keep a very neat .gitignore file and just use "git add .",
> which _does_ ignore those files. The real problem here is that git
> cannot tell the difference between "the user explicitly asked for
> foo.aux, so we should complain" and "oops, foo.aux got caught in a
Jonathan Nieder writes:
> Jeff King wrote:
>
>> Hmph. Should we just abandon my series in favor of taking Ronnie's
>> original patch, then? We can apply the "save/restore errno in error()"
>> patch independently if we like.
>
> I liked patches 1 and 2 and the explanation from patch 4. Perhaps
>
From: Ronnie Sahlberg
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
The same as sent 2 days before as part of the ref-transactions-reflog series
http://thread.gmane.org/gmane.comp.version-control.git/259712
no changes since then.
refs.c
From: Ronnie Sahlberg
The ref_transaction_update function can already be used to create refs by
passing null_sha1 as the old_sha1 parameter. Simplify by replacing
transaction_create with a thin wrapper.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan Beller
Hi,
so I think the patch series ref-transactions-reflog[1] sent previously to the
list
is still too large for easy review and I want to break it up more.
So in this series we'll digest only 2 small patches, which do not seem to be
controversial (yet;) and seem to be useful no matter how the disc
Slavomir Vlcek writes:
> I solved this by adding an extra (second) synopsis line
> so it looks just like the 'usage_msg' in 'builtin/stripspace.c'.
>
> But perhaps it would be wiser to have something like
> "git stripspace [[-s | --strip-comments] | [-c | --comment-lines]] < input"
> instead (and
As we have "oops, what was already added to 'master' is not quite
right" fixes for a few topics, I'd feel uneasy to release 2.2 final
without a -rc3. I was hoping that we can tag the final end of this
week, but let's make a -rc3 tomorrow or Friday and then do the final
one mid next week just befor
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
> Junio C Hamano writes:
> > Jeff King writes:
> > If you are fetching from somebody else and then pushing into your
> > own publishing repository (i.e. fork of that upstream), why isn't
> > the sequence of event like this, instead?
> >
Junio C Hamano writes:
> Jeff King writes:
>
>> But here you do not have a pushurl defined in the first place. So I
>> guess this is really just a shortcut for swapping the two, like:
>>
>> git remote set-url --push gh $(git config remote.gh.url)
>> git remote set-url gh new-fetch-url
>
> It
Peter Wu writes:
> On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
> ...
>> Yes, the semantics the updated code gives feel very strange. I
>> wouldn't be able to write a three-line summary in the release notes
>> to advertise what good this new feature brings to users myself.
>
> Wh
Jeff King writes:
> But here you do not have a pushurl defined in the first place. So I
> guess this is really just a shortcut for swapping the two, like:
>
> git remote set-url --push gh $(git config remote.gh.url)
> git remote set-url gh new-fetch-url
It seems that this swapping is only ne
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
> Jeff King writes:
>
> > I dunno. I guess that is more convenient, but it seems like a lot of
> > code for a very marginal use case. But more importantly, I'm a little
> > worried that the presence of --fetch creates confusion about wh
On Wednesday 19 November 2014 15:17:21 Jeff King wrote:
> On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
> > git remote set-url --fetch new-fetch-url
> >
> > This is less verbose and is much more intuitive.
>
> I agree your suggestion is a nicer way to do this. I'm just not sure
>
Stefan Beller wrote:
> This patch doesn't intend any functional changes.
Yay. :)
> a refactoring, which replaces a char** array by a stringlist
> in the function repack_without_refs.
> This is easier to read and maintain as it delivers the same
> functionality with less lines of code and less po
On Wed, Nov 19, 2014 at 12:22:36PM -0800, Junio C Hamano wrote:
> With a separate local-tags hierarchy, the look-up part still has to
> be enhanced. After doing "git tag v2.0" and "git tag -l snapshot00",
> you would want to be able to say "git log snapshot00..v2.0" and have
> these found.
>
> I
Jeff King writes:
> I dunno. I guess that is more convenient, but it seems like a lot of
> code for a very marginal use case. But more importantly, I'm a little
> worried that the presence of --fetch creates confusion about what
> set-url without a --fetch or --push does. That is, it implies to m
Jeff King writes:
> On Wed, Nov 19, 2014 at 10:45:48AM -0800, Junio C Hamano wrote:
>
>> ... tags are meant to be used for globally shared
>> anchoring points and the whole machinery (e.g. "fetch" that
>> auto-follows tags, "clone" that gives refs/tags*:refs/tags/*
>> refspec) is geared towards s
On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
> > git remote set-url --push gh $(git config remote.gh.url)
> > git remote set-url gh new-fetch-url
>
> Indeed, and not having a push URL is not uncommon (that is, always the
> case when a new remote is added or just cloned). Compare
On Wednesday 19 November 2014 14:08:00 Jeff King wrote:
> On Wed, Nov 19, 2014 at 04:18:02PM +0100, Peter Wu wrote:
>
> > git remote set-url knew about the '--push' option to update just the
> > pushurl, but it does not have a similar option for "update fetch URL and
> > leave whatever was in plac
On Wed, Nov 19, 2014 at 03:52:33PM +0100, Michael J Gruber wrote:
> "git add foo bar" adds neither foo nor bar when bar is ignored, but dies
> to let the user recheck their command invocation. This becomes less
> helpful when "git add foo.*" is subject to shell expansion and some of
> the expanded
On Wed, Nov 19, 2014 at 04:18:02PM +0100, Peter Wu wrote:
> git remote set-url knew about the '--push' option to update just the
> pushurl, but it does not have a similar option for "update fetch URL and
> leave whatever was in place for the push URL".
Isn't that what:
git remote set-url foo n
Torsten Bögershausen writes:
> Some file systems do not support the executable bit:
> a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec
> b) The user executable bit is always 1, e.g. cifs mounted with
> -ofile_mode=0755
> c) There are system where user executable bit is 1 e
On Wed, Nov 19, 2014 at 10:45:48AM -0800, Junio C Hamano wrote:
> > My email boils down to two questions:
> >
> > (A) Has there been progress on implementing a proposal like in [2]?
>
> I do not think so, and also I do not agree that "mirror everybody
> else's ref hierarchy into separate namesp
Michael J Gruber writes:
> ... and most would
> expect "git add --ignore-errors" to ignore the "file is ignored" error
> as well and continue adding the remaining files.
Yeah, I think that makes sense (but please don't take it as the final
decision yet---I'd like to hear from others).
--
To unsu
From: Ronnie Sahlberg
This patch doesn't intend any functional changes. It is just
a refactoring, which replaces a char** array by a stringlist
in the function repack_without_refs.
This is easier to read and maintain as it delivers the same
functionality with less lines of code and less pointers.
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 09e82c3..0340c44 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -82,10 +82,9 @@ PATTERN FORMAT
>
> - An optional prefix "`!`" which negates the p
Brian Norris writes:
> --- TL;DR ---
You usually have TL;DR at the beginning to help people save time;
having it at the end forces the whole thing to be read and would not
help anybody. ;-)
> My email boils down to two questions:
>
> (A) Has there been progress on implementing a proposal like
On Tue, Nov 18, 2014 at 07:05:23PM -0800, Brian Norris wrote:
> When I fetch from a remote repository, the only ways to
> prevent fetching tags are:
>
> 1) git fetch --no-tags
>
> 2) git config remote..tagopt --no-tags; git fetch
Yes, there is no way to globally specify --no-tags. I don't
On Wed, Nov 19, 2014 at 10:14:17AM -0800, Junio C Hamano wrote:
> >> What the above doesn't explain is why the caller cares about errno.
> >> Are they going to print another message with strerror(errno)? Or are
> >> they going to consider some errors non-errors (like ENOENT when trying
> >> to un
Jeff King writes:
> On Tue, Nov 18, 2014 at 05:43:44PM -0800, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > It's common to use error() to return from a function, like:
>> >
>> >if (open(...) < 0)
>> >return error("open failed");
>> >
>> > Unfortunately this may clobber the
Stefan Beller writes:
> This patch doesn't intend any functional changes. It is just
> a refactoring, which replaces a char** array by a stringlist
> in the function repack_without_refs.
> This is easier to read and maintain as it delivers the same
> functionality with less lines of code less poi
Paul Smith writes:
> Allow new workdirs to be created in an empty directory (similar to "git
> clone"). Provide more error checking and clean up on failure.
>
> Signed-off-by: Paul Smith
> ---
>
> Getting rid of ls/wc was not as simple as I'd hoped, due to glob
> pathname expansion (can't rely
On Wed, 2014-11-19 at 16:26 +0100, Paolo Ciarrocchi wrote:
> On Tue, Nov 18, 2014 at 1:25 AM, David Turner
> wrote:
> >
> > My patches are not the world's most beautiful, but they do work.
>
> Out of curiosity: do you run the patches at twitter?
An increasing number of us do, yes.
--
To unsub
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for "update fetch URL and
leave whatever was in place for the push URL".
This patch adds support for a '--fetch' option which implements that use
case in a backwards compatible way:
On Tue, Nov 18, 2014 at 1:25 AM, David Turner wrote:
>
> My patches are not the world's most beautiful, but they do work.
Out of curiosity: do you run the patches at twitter?
Thanks.
-- Paolo
--
Paolo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
Some file systems do not support the executable bit:
a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec
b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755
c) There are system where user executable bit is 1 even if it should be 0
like b), but the
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies
to let the user recheck their command invocation. This becomes less
helpful when "git add foo.*" is subject to shell expansion and some of
the expanded files are ignored.
"git add --ignore-errors" is supposed to ignore errors
If we exclude a directory and have no knowledge in advance if there
will be any negative rules on that directory, then it makes no sense
to enter the directory and search for those negative rules. That
defeats the purpose of excluding in the first place.
However there are cases where we know in ad
On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
wrote:
> Expected to work as .gitignore in top-level of repo:
>
> *
> !**/*.asc
> !.gitignore
>
gitignore man page has this "It is not possible to re-include a file
if a parent directory of that file is excluded". In this case,
directory
67 matches
Mail list logo
