Jeff King writes:
> If you want to keep refactoring this, I don't mind, but I kind of feel
> like we are going down a rabbit hole for very little gain.
Right, and right. The rewrite to move _ln to "\n" was wrong, and
this is too much hassle for too little gain. If we were to do
something, I ag
On Tue, Jul 09, 2013 at 10:52:55PM -0700, Junio C Hamano wrote:
> > The patch to do it is below, but I actually think an explicit blank-line
> > function like:
> >
> > status_print_empty_line(s, color);
> >
> > would be more obvious to a reader.
>
> I noticed that all but one can be dealt with
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:35:25PM -0700, Junio C Hamano wrote:
>
>> > You can "fix" it with -Wno-zero-format-length, so the hassle is not
>> > huge.
>>
>> Yes, or just do func(..., "%s", "") perhaps? That also sound iffy.
>
> I imagine that is the method intended by upstre
On Tue, Jul 09, 2013 at 10:35:25PM -0700, Junio C Hamano wrote:
> > You can "fix" it with -Wno-zero-format-length, so the hassle is not
> > huge.
>
> Yes, or just do func(..., "%s", "") perhaps? That also sound iffy.
I imagine that is the method intended by upstream (though who
knows...the who
Jeff King writes:
> On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > These functions could benefit from the added compile-time
>> > safety of having the compiler check printf arguments.
>> >
>> > Unfortunately, we also sometimes pass an empty format
On Tue, Jul 09, 2013 at 10:26:04PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > These functions could benefit from the added compile-time
> > safety of having the compiler check printf arguments.
> >
> > Unfortunately, we also sometimes pass an empty format string,
> > which will cause
On Wed, Jul 10, 2013 at 3:10 AM, Thomas Gummerer wrote:
>> If you happen to know that certain entries match the given pathspec,
>> you could help the caller avoid match_pathspec'ing again by set a bit
>> in ce_flags.
>
> I currently don't know which entries do match the pathspec from just
> readin
Jeff King writes:
> These functions could benefit from the added compile-time
> safety of having the compiler check printf arguments.
>
> Unfortunately, we also sometimes pass an empty format string,
> which will cause false positives with -Wformat-zero-length.
> In this case, that warning is wro
I get this error message when trying to create a shared ssh key in Mac osx Lion
scp .ssh/id_rsa.pub cvatt...@cook.cs.uno.edu:~/
ssh_exchange_identification: Connection closed by remote host
lost connection
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
On Tue, Jul 09, 2013 at 04:09:35PM -0700, Junio C Hamano wrote:
> * jk/argv-pushf-sentinel (2013-07-09) 1 commit
> - argv-array: add sentinel attribute to argv_array_pushl
>
> Will merge to 'next'.
If you have not pushed it out already, I just posted a re-roll which
covers many other places, t
These functions could benefit from the added compile-time
safety of having the compiler check printf arguments.
Unfortunately, we also sometimes pass an empty format string,
which will cause false positives with -Wformat-zero-length.
In this case, that warning is wrong because our function is
not
This attribute can help gcc notice when callers forget to
add a NULL sentinel to the end of the function. This is our
first use of the sentinel attribute, but we shouldn't need
to #ifdef for other compilers, as __attribute__ is already a
no-op on non-gcc-compatible compilers.
Suggested-by: Bert We
For most of our functions that take printf-like formats, we
use gcc's __attribute__((format)) to get compiler warnings
when the functions are misused. Let's give a few more
functions the same protection.
In most cases, the annotations do not uncover any actual
bugs; the only code change needed is
On Tue, Jul 09, 2013 at 10:27:29PM +, Matt Kraai wrote:
> > Nice catch. We cannot use variadic macros, because we support pre-C99
> > compilers that do not have them. But the sentinel attribute is a good
> > idea. Here's a patch.
>
> This attribute could also be used for
> builtin/revert.c:ve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Of course! Thanks, now it completely makes sense.
On 07/09/2013 03:41 PM, Jeff King wrote:
> On Tue, Jul 09, 2013 at 02:28:32PM -0400, Phillip Susi wrote:
>
>> When I try to look at a color diff of a file using dos newlines,
>> the output gets an od
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are in the middle of 6th week (http://tinyurl.com/gitCal) now in
the 11-week releace cycle for 1.8.4, and quite a few topics have
graduated t
Junio C Hamano writes:
> I _think_ I am OK if we introduced "--allow-no-ff" that means the
> current "--force" (i.e. "rewinding is OK"), that does not defeat the
> "--lockref" safety. That is the intended application (you know that
> push does not fast-forward because you rebased, but you also w
Jeff King writes:
> On Tue, Jul 09, 2013 at 08:05:19AM +0200, Bert Wesarg wrote:
> > > + argv_array_pushl(&args, "send-pack", "--stateless-rpc",
"--helper-status");
> >
> > missing NULL sentinel. GCC has the 'sentinel' [1] attribute to catch
> > such errors. Or use macro magic:
> >
> > voi
Johannes Sixt writes:
> No. --force means "I know what I am doing, no safety needed, thank you".
I sympathize the desire to keep a big red button to override
everything, but it is still not clear how these two independent
safety should work together and should possibly seletively be
overriden.
On 13-07-09 04:37 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Am 09.07.2013 21:53, schrieb Junio C Hamano:
>>> +--lockref::
>>> +--lockref=::
>>> +--lockref=:::
>>> ...
>>> +This is meant to make `--force` safer to use.
>>
>> This is a contradiction. "--force" means "I mean it, dude",
From: "Junio C Hamano"
Sent: Wednesday, July 03, 2013 7:08 PM
[catching up on old emails]
Ed Hutchins writes:
I'm not trying to change the way git does things (which works
perfectly
well), I'm asking for some extra information to be added to the
commit
so that analysis of the ancestry graph c
Am 09.07.2013 22:37, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 09.07.2013 21:53, schrieb Junio C Hamano:
>>> +--lockref::
>>> +--lockref=::
>>> +--lockref=:::
>>> ...
>>> +This is meant to make `--force` safer to use.
>>
>> This is a contradiction. "--force" means "I mean it, dude",
On 07/09/2013 08:37 PM, John Szakmeister wrote:
You might want to consider giggle. I've not used it, but it's more
BzrExplorer-like, IIRC.
No no no, git-cola much similar to Bazaar Explorer. Giggle is so far way
from Bazaar Explorer like
--
Best Regards,
Muhammad Bashir Al-Noimi
--
To unsubs
On 07/09/2013 07:38 PM, Fredrik Gustafsson wrote:
git-cola is about six years old and you're using a two year old release.
You miss 1/3 of all development that has been done on git-cola. I
suggest you update to a newer version. Too bad that ubuntu shipped such
old version.
Thanks for mentioning
Michael Haggerty writes:
>
> The name "--lockref" is OK, but for me it's less a question of
> "locking", because as far as the user is concerned the push is an atomic
> operation so there is no sense of a "lock" that is being held for a
> finite period of time.
Yeah, I think this is more like "
Aaron Schrab writes:
> How does this behave if --force is not used?
Both the usual "must fast-forward" safety and the "ref should not
have moved" safety apply.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Johannes Sixt writes:
> Am 09.07.2013 21:53, schrieb Junio C Hamano:
>> +--lockref::
>> +--lockref=::
>> +--lockref=:::
>> ...
>> +This is meant to make `--force` safer to use.
>
> This is a contradiction. "--force" means "I mean it, dude", and not "I
> mean it sometimes". It would make sense if
On 07/09/2013 09:53 PM, Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> Documentation/git-push.txt | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index f7dfe48..e7c8bd6 100644
> --- a/Do
At 12:53 -0700 09 Jul 2013, Junio C Hamano wrote:
+This is meant to make `--force` safer to use. Imagine that you have
+to rebase what you have already published. You will have to
+`--force` the push to replace the history you originally published
+with the rebased history. If somebody else b
Michael Haggerty writes:
> It would be more general to support "follow the second match to /A/"
> *independent* of whether the first match is also followed. I think your
> proposal only allows the second to be followed if the first is also
> followed. Therefore it seems to me that your wish is
Am 09.07.2013 21:53, schrieb Junio C Hamano:
> +--lockref::
> +--lockref=::
> +--lockref=:::
> ...
> +This is meant to make `--force` safer to use.
This is a contradiction. "--force" means "I mean it, dude", and not "I
mean it sometimes". It would make sense if this sentence were "This is
meant to
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>>> The reader often needs to rewind the read-pointer partially while
>>> walking the index (e.g. next_cache_entry() in unpack-trees.c and how
>>> the o->cache_bottom position is used throughout the subsystem). I
>>> am not sure if this singly-
Duy Nguyen writes:
> On Tue, Jul 9, 2013 at 3:54 AM, Thomas Gummerer wrote:
>> As promised, a draft for a documentation for the index api as it is in
>> this series.
>
> First of all, it may be a good idea to acknowledge
> index_state->cache[] as part of the API for now. Not hiding it
> simplifi
Michael Haggerty writes:
> On 07/09/2013 02:08 PM, Thomas Rast wrote:
>> Michael Haggerty writes:
>>
>>> Since you've already implemented a way to merge into the index (even an
>>> alternative index) without touching the working copy, I'll just cross my
>>> fingers and hope for the appearance o
On 07/09/2013 09:31 PM, Junio C Hamano wrote:
> Thomas Rast writes:
>
>> If you define it that way, the output of
>>
>> git blame -L 4,6; git blame -L /A/,+20
>>
>> is significantly different from
>>
>> git blame -L 4,6 -L /A/,+20
>>
>> Not just in the presentation or any possible coalescing,
This plugs the push_cas_option data collected by the command line
option parser to the transport system with a new function
apply_push_cas(), which is called after match_push_refs() has
already been called. At this point, we know which remote we are
talking to, and what remote refs we are going to
Update "git push" and "git send-pack" to parse this commnd line
option.
The intended sematics is:
* "--lockref" alone, without specifying the details, will protect
_all_ remote refs that are going to be updated by requiring their
current value to be the same as the remote-tracking branch w
The command line parser of "git push" for "--tags", "--delete", and
"--thin" options still used outdated OPT_BOOLEAN. Because these
options do not give escalating levels when given multiple times,
they should use OPT_BOOL.
Signed-off-by: Junio C Hamano
---
builtin/push.c | 6 +++---
1 file chan
Signed-off-by: Junio C Hamano
---
Documentation/git-push.txt | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index f7dfe48..e7c8bd6 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -
This teaches the deepest part of the callchain for "git push" (and
"git send-pack") to optionally allow "the old value of the ref must
be this, otherwise fail this push" we discussed earlier.
Nobody sets the new "expect_old_sha1" and "expect_old_no_trackback"
bitfields yet, so this is still a no-o
Prepare two repositories, src and dst, the latter of which is a
clone of the former (with tracking branches), and push from the
latter into the former, using --lockref=name (using tracking ref for
"name" when updating "name"), --lockref=name:value, --lockref=name:
(i.e. check creation), and --lockr
The definition of "struct ref" in "cache.h", a header file so
central to the system, always confused me. This structure is not
about the local ref used by sha1-name API to name local objects.
It is what refspecs are expanded into, after finding out what refs
the other side has, to define what ref
When you have to replace an already published branch with its
rebased version, you would have to --force, but then you risk losing
work, if any, that was pushed by somebody else while you are working
on rebasing, as your earlier decision that replacing the old one
with its rebase is OK was based on
On Tue, Jul 09, 2013 at 02:28:32PM -0400, Phillip Susi wrote:
> When I try to look at a color diff of a file using dos newlines, the
> output gets an odd sequence of ansi escapes and a stray carriage
> return showing up only on the + lines, but not the -. The normal
> looking - lines look like th
On 07/09/2013 02:08 PM, Thomas Rast wrote:
> Michael Haggerty writes:
>
>> Since you've already implemented a way to merge into the index (even an
>> alternative index) without touching the working copy, I'll just cross my
>> fingers and hope for the appearance of an option that makes merge leave
Thomas Rast writes:
> If you define it that way, the output of
>
> git blame -L 4,6; git blame -L /A/,+20
>
> is significantly different from
>
> git blame -L 4,6 -L /A/,+20
>
> Not just in the presentation or any possible coalescing, but in the
> meaning of the ranges.
>
> Do you really want
On Tue, Jul 09, 2013 at 01:49:21PM +0200, Thomas Rast wrote:
> Rather, it's very strange that 'git config --file foo' tries to look at
> any config file other than 'foo'. In a git repo:
>
> $ strace git config --file fooconfig test.var 2>&1 | grep 'open.*config'
> open("/home/thomas/.gitconf
Thomas Rast wrote:
> If you define it that way, the output of
>
> git blame -L 4,6; git blame -L /A/,+20
>
> is significantly different from
>
> git blame -L 4,6 -L /A/,+20
>
> Not just in the presentation or any possible coalescing, but in the
> meaning of the ranges.
I can see both meanings
Junio C Hamano writes:
> Eric Sunshine writes:
>
>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>>> Junio C Hamano writes:
>>>
(2) In the ranges "-L ,/B/ -L /C/,", the
beginning of the second range is found by choosing C that comes
_after_ the end of the previo
On Tue, Jul 9, 2013 at 2:55 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>>> Junio C Hamano writes:
>>>
(2) In the ranges "-L ,/B/ -L /C/,", the
beginning of the second range is found by choosing C that comes
Thomas Rast writes:
> Junio C Hamano writes:
>
>> (2) In the ranges "-L ,/B/ -L /C/,", the
>> beginning of the second range is found by choosing C that comes
>> _after_ the end of the previous range (/B/ may choose either
>> the second or the 4th line, and the only C that comes a
Eric Sunshine writes:
> On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
>> Junio C Hamano writes:
>>
>>> (2) In the ranges "-L ,/B/ -L /C/,", the
>>> beginning of the second range is found by choosing C that comes
>>> _after_ the end of the previous range (/B/ may choose either
>>
On Tue, Jul 09, 2013 at 09:00:20AM -0700, Junio C Hamano wrote:
> >>> + return cmd_name_rev(args.argc, args.argv, prefix);
> >>
> >> This leaks the memory allocated by "args". The original did, too, and it
> >> is probably not that big a deal (we exit right after anyway). The fix
> >> woul
On Tue, Jul 9, 2013 at 10:39 AM, Matthieu Moy wrote:
> Muhammad Bashir Al-Noimi writes:
>
>> I'm bzr user and I want to migrate to git. Generally I use bzr through
>> Bazaar Explorer which is very easy & neat GUI utility for managing bzr
>> repositories. May you please guide me to most easy way t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I try to look at a color diff of a file using dos newlines, the
output gets an odd sequence of ansi escapes and a stray carriage
return showing up only on the + lines, but not the -. The normal
looking - lines look like this:
\r\n ( from previou
On Tue, Jul 9, 2013 at 1:42 PM, Thomas Rast wrote:
> Junio C Hamano writes:
>
>> (2) In the ranges "-L ,/B/ -L /C/,", the
>> beginning of the second range is found by choosing C that comes
>> _after_ the end of the previous range (/B/ may choose either
>> the second or the 4th lin
Junio C Hamano writes:
> (2) In the ranges "-L ,/B/ -L /C/,", the
> beginning of the second range is found by choosing C that comes
> _after_ the end of the previous range (/B/ may choose either
> the second or the 4th line, and the only C that comes after
> either of them is
On Tue, Jul 09, 2013 at 07:26:57PM +0200, Muhammad Bashir Al-Noimi wrote:
> On Tue, Jul 9, 2013 at 7:02 PM, Fredrik Gustafsson wrote:
> > You don't need the terminal to create a new repository. When starting
> > git-cola from a non-git directory you get a menu where you can open an
> > existing gi
On Tue, Jul 9, 2013 at 7:02 PM, Fredrik Gustafsson wrote:
> You don't need the terminal to create a new repository. When starting
> git-cola from a non-git directory you get a menu where you can open an
> existing git-repository, clone an existing git-repository or create a new one
I'm using git-
On Tue, Jul 9, 2013 at 12:39 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> As implemented by this patch, the behavior of git-blame with multiple
>> -L's is consistent with that of git-log with multiple -L's. The
>> implemented behavior feels intuitive to me, but I can see how the
>> beha
---
gitweb/static/gitweb.css | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index a869be1..3b4d833 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -68,12 +68,13 @@ div.page_path {
}
div.page_foot
Eric Sunshine writes:
> As implemented by this patch, the behavior of git-blame with multiple
> -L's is consistent with that of git-log with multiple -L's. The
> implemented behavior feels intuitive to me, but I can see how the
> behavior you suggest could feel intuitive to others.
>
> If I re-do
On Tue, Jul 09, 2013 at 04:50:20PM +0200, Muhammad Bashir Al-Noimi wrote:
> I tried to use git-cola and found it complicated and not user friendly
> (maybe because I came from Bazaar Explorer) I noticed that it needs
> terminal to be able to work (ex. it can't create new repository). I
> can't even
The rss_logo CSS style has a fixed width which is too narrow for
the string "OPML". Replace the fixed width with horizontal padding
so the text fits with nice margins.
---
For before/after examples, see http://dotat.at/cgi/git (overflow)
and https://git.csx.cam.ac.uk/x/ucs/ (padded).
gitweb/stat
Nguyễn Thái Ngọc Duy writes:
> I attempted to make index_state->cache[] a "const struct cache_entry **"
> to find out how existing entries in index are modified and where. The
> question I have is what do we do if we really need to keep track of on-disk
> changes in the index. The result is
>
>
Junio C Hamano writes:
> Jeff King writes:
>
>> On Sun, Jul 07, 2013 at 03:33:43PM -0700, Junio C Hamano wrote:
>>
>>> + argv_array_init(&args);
>>> + argv_array_push(&args, "name-rev");
>>> + argv_array_push(&args, "--name-only");
>>> + argv_array_push(&a
Thanks René~
I'll use "git archive" command to create the tarball.
Rick
-Original Message-
From: René Scharfe [mailto:rene.scha...@lsrfire.ath.cx]
Sent: Monday, July 08, 2013 8:54 PM
To: Rick Liu
Cc: git@vger.kernel.org
Subject: Re: standarize mtime when git checkout
Am 08.07.2013 23:39
On Tue, Jul 9, 2013 at 3:54 AM, Thomas Gummerer wrote:
> As promised, a draft for a documentation for the index api as it is in
> this series.
First of all, it may be a good idea to acknowledge
index_state->cache[] as part of the API for now. Not hiding it
simplifies a few things (no need for new
The function mkstemps() isn't available in all libc implementations. In
glibc it first became available in 2.11, so platforms such as RHEL 5 &
Slackware 13 lack it. This is likely true of many non-LINUX platforms
as well.
This fixes breakage that was introduced with a0fdac29 "Create temporary
file
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name
[Added Cc:Thomas Rast]
On Sun, Jul 7, 2013 at 5:58 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> git-blame accepts only zero or one -L option. Clients requiring blame
>> information for multiple disjoint ranges are therefore forced either to
>> invoke git-blame multiple times, once for
Jeff King writes:
> On Sun, Jul 07, 2013 at 03:33:43PM -0700, Junio C Hamano wrote:
>
>> +argv_array_init(&args);
>> +argv_array_push(&args, "name-rev");
>> +argv_array_push(&args, "--name-only");
>> +argv_array_push(&args, "--no-undefined");
>> [..
On Tue, Jul 9, 2013 at 4:39 PM, Matthieu Moy wrote:
> But there are nice GUIs for Git too. The "official" one is git gui,
> distributed with Git. I do not like the visual aspect a lot, but it has
> a very good coverage of Git's functionalities. Otherwise, have a look at
>
>
> https://git.wiki.k
Muhammad Bashir Al-Noimi writes:
> I'm bzr user and I want to migrate to git. Generally I use bzr through
> Bazaar Explorer which is very easy & neat GUI utility for managing bzr
> repositories. May you please guide me to most easy way to migrate to
> Git?
(I think it's a mistake to stick to GUI
Hi,
If you are on Windows or OS X, you can try SourceTree from Atlassian
(free). It is really nice to work with.
Cheers,
Matthieu
2013/7/9 Muhammad Bashir Al-Noimi :
> Howdy?
>
> I'm bzr user and I want to migrate to git. Generally I use bzr through
> Bazaar Explorer which is very easy & neat G
Howdy?
I'm bzr user and I want to migrate to git. Generally I use bzr through
Bazaar Explorer which is very easy & neat GUI utility for managing bzr
repositories. May you please guide me to most easy way to migrate to
Git?
P.S.
* I'm very comfortable with bzr (it has awesome GUI utility) but I
d
Hi Junio,
> Doing it "correctly" (in the shorter term) would involve:
>
> - adding a capability on the sending side "fixed-off-by-one-depth"
>to the protocol, and teaching the sending side to advertise the
>capability;
>
> - teaching the requestor that got --depth=N from the end use
Junio C Hamano wrote:
> $ git describe $(git rev-parse v1.8.3)
> v1.8.3
> $ git describe --contains $(git rev-parse v1.8.3)
> v1.8.3^0
This is a correct observation, and I've already submitted the correct
fix: "name-rev: strip trailing ^0 in when --name-only".
> $ git describe
> -Original Message-
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: 9. heinäkuuta 2013 15:01
> To: Sarajärvi Tony
> Cc: git@vger.kernel.org
> Subject: Re: Git --file doesn't override $HOME in version 1.8.1.2
>
> Sarajärvi Tony writes:
>
> > Using Ubuntu 13.04 with Git 1.8.1.
Michael Haggerty writes:
> Since you've already implemented a way to merge into the index (even an
> alternative index) without touching the working copy, I'll just cross my
> fingers and hope for the appearance of an option that makes merge leave
> HEAD, MERGE_HEAD, etc. untouched.
The most ann
Sarajärvi Tony writes:
> Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
>
> In Puppet we launch Git with the command: '/usr/bin/git config --file
> /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration System"'
Hmph. What does this even mean?
git co
Sarajärvi Tony writes:
> Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
>
> In Puppet we launch Git with the command: '/usr/bin/git config --file
> /home/qt/.gitconfig --get "user.name" "Qt Continuous Integration
> System"'
> However, puppet logs: "fatal: unable to ac
Jeff King writes:
> Although I am still not clear on why it would not be up to the caller of
> git-describe in the first place to decide which they wanted.
Thanks for a dose of sanity.
Even though the part of the miniseries that makes sure that "X (Y)"
output from "name-rev" always satisfies th
Unicode clause D14 defines all characters U+nFFFE and U+n (where
0 <= n <= 10h) as well as the range U+FDD0..U+FDEF as non-characters,
reserved for internal use only. Disallow these characters in commit
messages as they are normally not recommended for interchange.
Signed-off-by: Peter Kreft
Using Ubuntu 13.04 with Git 1.8.1.2 I stumbled upon a problem using Puppet.
In Puppet we launch Git with the command: '/usr/bin/git config --file
/home/qt/.gitconfig --get "user.name" "Qt Continuous Integration System"'
However, puppet logs: "fatal: unable to access '/root/.config/git/config':
P
On 30.06.13 19:28, Ramsay Jones wrote:
> Ramsay Jones wrote:
>> Michael Haggerty wrote:
>>> On 06/27/2013 12:35 AM, Jeff King wrote:
>> [ ... ]
I think Michael's assessment above is missing one thing.
>>> Peff is absolutely right; for some unknown reason I was thinking of the
>>> consistency c
From: Nguyễn Thái Ngọc Duy
Before anything is printed, for-each-ref sorts all refs first. As
part of the sorting, populate_value() is called to fill the values in
for all atoms/placeholders per entry. By the time sort_refs() is done,
pretty much all data is already retrieved.
This works fine wh
From: Nguyễn Thái Ngọc Duy
Pretty format accepts either ' ', '+' or '-' after '%' and before the
placeholder name to modify certain behaviors. Teach verify_format()
about this so that it finds atom "upstream" in, for example,
'% (upstream)'. This is important because verify_format populates
used_
This helper function is intended to be used by callers implementing
--pretty themselves; it parses pretty.* configuration variables
recursively and hands the user-defined format back to the caller. No
builtins are supported, as CMT_FMT_* are really only useful when
displaying commits. Callers mig
Use get_pretty_userformat() to interpret the --pretty string. This
means that you can now reference a format specified in a pretty.*
configuration variable as an argument to 'git for-each-ref --pretty='.
There are two caveats:
1. A leading "format:" or "tformat:" is automatically stripped and
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by the contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)%(upstream:tracksho
From: Nguyễn Thái Ngọc Duy
Pretty placeholders %>(N) and %<(N) require a user provided width N,
which makes sense because the commit chain could be really long and the
user only needs to look at a few at the top, going to the end just to
calculate the best width wastes CPU cycles.
for-each-ref i
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend the format with
%(HEAD) to do exactly the same thing.
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)
to di
From: Nguyễn Thái Ngọc Duy
for-each-ref.c:print_value() currently prints values to stdout
immediately using {sq|perl|python|tcl}_quote_print, giving us no
opportunity to do any further processing. In preparation for getting
print_value() to accept an additional strbuf argument to write to,
conve
From: Nguyễn Thái Ngọc Duy
Currently, the entire callchain starting from show_ref() parses and
prints immediately. This inflexibility limits our ability to extend the
parser. So, convert the entire callchain to accept a strbuf argument to
write to. Also introduce a show_refs() helper that call
Remove sq_quote_print() since it has no callers. A nicer alternative
sq_quote_buf() exists: its callers aren't forced to print immediately.
For historical context, sq_quote_print() was first introduced in
575ba9d6 (GIT_TRACE: show which built-in/external commands are executed,
2006-06-25) for the
From: Nguyễn Thái Ngọc Duy
--format is very limited in its capabilities. Introduce --pretty, which
extends the existing --format with pretty-formats. In --pretty:
- Existing --format %(atom) is available. They also accept some pretty
magic. For example, you can use "% (atom)" to only disp
From: Nguyễn Thái Ngọc Duy
The struct pretty_print_context contains the context in which the
placeholders in format_commit_one() should be parsed. Although
format_commit_one() primarily acts as a parser, there is no way for a
caller to plug in custom callbacks. Now, callers can:
1. Parse a cus
To make sure that a pretty_ctx->format substitution doesn't result in an
infinite recursion, change the prototype of format_commit_one() to
accept one last argument: no_recurse. So, a single substitution by
format() must yield a result that can be parsed by format_commit_one()
without the help of
Currently, there is exactly one caller of sq_quote_print(), namely
cmd_tar_tree(). In the interest of removing sq_quote_print() and
simplification, replace it with an equivalent call to sq_quote_argv().
No functional changes intended.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thá
1 - 100 of 110 matches
Mail list logo
