John Keeping wrote:
> The following patch makes the revision cherry machinery ignore merges
> unconditionally. With it applied, there's not noticeable difference in
> speed between "git cherry" and "git log --cherry".
>
> -- >8 --
> diff --git a/revision.c b/revision.c
> index a67b615..19d0683 10
John Keeping wrote:
> On Sun, May 19, 2013 at 12:36:12PM -0700, Jonathan Nieder wrote:
>>Who is responsible for freeing
>> "path"? Would it make sense to use a strbuf here?
>>
>> strbuf_setlen(&buf, traverse_path_len(info, n));
>> make_traverse_pa
Junio C Hamano wrote:
> --- a/Documentation/git-diff-index.txt
> +++ b/Documentation/git-diff-index.txt
> @@ -3,7 +3,7 @@ git-diff-index(1)
>
> NAME
>
> -git-diff-index - Compares content and mode of blobs between the index and
> repository
> +git-diff-index - Compare a tree and the work
On Mon, May 20, 2013 at 1:01 AM, Junio C Hamano wrote:
> Subject: [PATCH] Documentation/diff-index: mention two modes of operation
>
> "diff-index" can be used to compare a tree with the tracked working
> tree files (when used without the --index option), or with the index
> (when used with the --
When you trying to add submodule, that already has submodule, it craches.
For example you could try: git clone --recursive
http://github.com/Exsul/al_server
Its happens because git dont create `modules` directory.
al_server/.git/modules
Workaround for it wont work to:
git submodule update --init
Albert Netymk writes:
> On Sun, May 19, 2013 at 9:46 AM, Junio C Hamano wrote:
>> Albert Netymk writes:
>>
>>> Hello,
>>>
>>> The man page of git-diff-index:
>>> http://git-scm.com/docs/git-diff-index
>>> states that
>>> `git-diff-index - Compares content and mode of blobs between the index
>>>
Jonathan Nieder writes:
>> @@ -64,6 +199,13 @@ static struct patch_id *add_commit(struct commit *commit,
>> unsigned char sha1[20];
>> int pos;
>>
>> +if (no_add) {
>> +if (collect_touched_paths(commit, ids, 1) < 0)
>> +return NULL;
>
> Ah, so this
Jonathan Nieder writes:
> Philip Oakley wrote:
>
>> Describe rebase in the description section.
>
> It already does that. :) I think you mean "start with a summary",
> which is a valuable improvement.
It indeed is a good idea to give the "high-level introduction" at
the very beginning, but I do
Nguyễn Thái Ngọc Duy writes:
> Originally I wanted to introduce --pretty with git-log's pretty syntax
> to for-each-ref, deprecating --format.
If you are going to unify the two mechanisms, I think the "--format"
option of "for-each-ref" needs to become a superset of what the
"--pretty" option o
Ramkumar Ramachandra writes:
> I suspect that the issue you're trying to address is:
>
> [remote "ram"]
> push = refs/heads/*:refs/heads/rr/*
>
> not dictating which refs to push when I say 'git push' (it'll push all
> the refs under refs/heads/*, not respecting push.default=current in my
> s
Am 19.05.2013 18:56, schrieb Ralf Thielow:
2013/5/16 Holger Hellmuth (IKS) :
[...]
+reset = neu setzen (maybe "umsetzen"?)
"zurücksetzen"
"reset" can be used with every existing commit. "zurücksetzen"
would imply that it have to be a recent commit, no?
It implies that it sets to s
On Sun, May 19, 2013 at 11:53 AM, Felipe Contreras
wrote:
> This script find people that might be interested in a patch, by going
s/find/finds/
> back through the history for each single hunk modified, and finding
> people that reviewed, acknowledge, signed, or authored the code the
> patch is m
From: "Jonathan Nieder"
Sent: Sunday, May 19, 2013 7:08 PM
Philip Oakley wrote:
Describe rebase in the description section.
It already does that. :) I think you mean "start with a summary",
which is a valuable improvement.
Yes.
Include a softer paraphrased version from the crytic, well
From: "Jonathan Nieder"
Sent: Sunday, May 19, 2013 6:39 PM
Hi,
Philip Oakley wrote:
The Git cli will generally accept dot '.' (period) as equivalent
to the current repository when appropriate. Tell the reader of this
'do what I mean' (dwim)mery action.
[...]
--- a/Documentation/gitcli.txt
+
On Sun, May 19, 2013 at 12:36:12PM -0700, Jonathan Nieder wrote:
> John Keeping wrote:
>
> > In this case, it is likely that only a small number of paths are touched
> > by the commits on the smaller side of the range and by storing these we
> > can ignore many commits on the other side before unp
On Sat, May 18, 2013 at 11:26 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Thanks Eric and Junio. I looked over the patches and they look good.
>
> Are you sure about that? It seemed to me that it was breaking
> everybody that is not on MacOS X --- did I misread the patch?
Gah, corre
On Sun, May 19, 2013 at 8:41 AM, Felipe Contreras
wrote:
> On Sun, May 19, 2013 at 10:13 AM, Ramkumar Ramachandra
> wrote:
>> Felipe Contreras wrote:
>>> How exactly is it not equivalent to len = len || 1?
>>
>> Here, I dug up an article for you on the issue:
>>
>> http://www.rubyinside.com/what-
Instead of accepting an array and using exactly two elements from the
array, take two single (struct object_array_entry *) arguments.
Signed-off-by: Michael Haggerty
---
builtin/diff.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin/diff.c b/builtin
At first glance the OBJ_COMMIT, OBJ_TREE, and OBJ_BLOB cases look like
they might be mutually exclusive. But the OBJ_COMMIT case doesn't end
the loop iteration with "continue" like the other two cases, but
rather falls through. So use if...else if...else construct to make it
more obvious that onl
The old version copied one entry to its destination position, then
deleted any matching entries from the tail of the array. This
required the tail of the array to be copied multiple times. It didn't
affect the complexity of the algorithm because the whole tail has to
be searched through anyway.
The condition under which gc_boundary() is called was previously
if (alloc <= nr)
. But by construction, nr can never exceed alloc, so the check looks
unnecessarily mysterious. In fact, the purpose of the check is to try
to avoid a realloc() call by shrinking the array if possible if it is
Signed-off-by: Michael Haggerty
---
submodule.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
index e728025..b837c04 100644
--- a/submodule.c
+++ b/submodule.c
@@ -846,7 +846,7 @@ static int find_first_merges(struct object_array *result,
const c
Add a function that allows unwanted entries in an object_array to be
removed. This encapsulation is a step towards giving object_array
ownership of its entries' name memory.
Use the new function to replace revision.c:gc_boundary().
Signed-off-by: Michael Haggerty
---
object.c | 16 ++
The lifetime of the refname was never documented, but some callers
used to assume that its lifetime was essentially permanent. The
commits leading up to this have disabused such callers of that notion.
The new status quo is that the API explicitly does *not* guarantee
that the refname string live
It's not a list, it's an array entry.
Signed-off-by: Michael Haggerty
---
builtin/diff.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index 72d99c0..7cac6de 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -338,9 +338,9 @@ int cmd
Change object_array and object_array_entry to copy the name before
storing it in the name field, and free it when an entry is deleted
from the array. This is useful because some of the name strings
passed to add_object_array() or add_object_array_with_mode() are
refnames whose lifetime is not defi
The source of this nonsense was
04d3975937 fsck: reduce stack footprint
, which wedged a pointer to parent into the object_array_entry's name
field. The parent pointer was passed to traverse_one_object(), even
though that function *didn't use it*.
The useless code has been deleted over time
No names are ever set for the object_array_entries in merges, so there
is no need to pretend to copy them to the result array.
Signed-off-by: Michael Haggerty
---
submodule.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
index b837c04..ad476ce 10
Signed-off-by: Michael Haggerty
---
revision.c | 20 ++--
revision.h | 32 +---
2 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/revision.c b/revision.c
index 25e424c..8ac88d6 100644
--- a/revision.c
+++ b/revision.c
@@ -70,7 +70,8 @@ s
Change cmd_diff() to use a (struct object_array) for holding the trees
that it accumulates, rather than rolling its own equivalent.
Signed-off-by: Michael Haggerty
---
builtin/diff.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/built
There is no logical reason for this test to be here. At the caller we
might be able to figure out its meaning.
Signed-off-by: Michael Haggerty
---
revision.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/revision.c b/revision.c
index 8ac88d6..
Instead of assuming that the memory pointed to by the name argument
will live forever, make a local copy of it before storing it in the
ref_cmdline_info.
Signed-off-by: Michael Haggerty
---
revision.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.
Do not retain references to refnames passed to the each_ref_fn
callback add_existing(), because their lifetime is not guaranteed.
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b
Do not retain a reference to the refname passed to the each_ref_fn
callback get_name(), because there is no guarantee of the lifetimes of
these names. Instead, make a local copy when needed.
Signed-off-by: Michael Haggerty
---
builtin/describe.c | 6 --
1 file changed, 4 insertions(+), 2 de
Prior to this patch series, the refs API said nothing about the
lifetime of the refname parameter passed to each_ref_fn callbacks by
the for_each_ref()-style iteration functions. De facto, the refnames
usually had long lives because they were pointers into the ref_cache
data structures, and those
On Sun, May 19, 2013 at 9:46 AM, Junio C Hamano wrote:
> Albert Netymk writes:
>
>> Hello,
>>
>> The man page of git-diff-index:
>> http://git-scm.com/docs/git-diff-index
>> states that
>> `git-diff-index - Compares content and mode of blobs between the index
>> and repository`.
>>
>> However, in
John Keeping wrote:
> In this case, it is likely that only a small number of paths are touched
> by the commits on the smaller side of the range and by storing these we
> can ignore many commits on the other side before unpacking blobs and
> diffing them.
I like this idea a lot.
> --- a/patch-id
Philip Oakley wrote:
> Describe rebase in the description section.
It already does that. :) I think you mean "start with a summary",
which is a valuable improvement.
> Include a softer paraphrased version from the crytic, well-loved,
> but sometimes parodied, Name description, and tell users th
Philip Oakley wrote:
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -734,6 +734,8 @@ branch..remote::
> overridden by `branch..pushremote`. If no remote is
> configured, or if you are not on any branch, it defaults to
> `origin` for fetching and `remote.p
Hi,
Philip Oakley wrote:
> The Git cli will generally accept dot '.' (period) as equivalent
> to the current repository when appropriate. Tell the reader of this
> 'do what I mean' (dwim)mery action.
[...]
> --- a/Documentation/gitcli.txt
> +++ b/Documentation/gitcli.txt
> @@ -59,6 +59,10 @@ work
2013/5/16 Holger Hellmuth (IKS) :
>
[...]
>> +reset = neu setzen (maybe "umsetzen"?)
>
>
> "zurücksetzen"
>
"reset" can be used with every existing commit. "zurücksetzen"
would imply that it have to be a recent commit, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
Hi,
here's an updated version of the glossary. Comments are appreciated.
Basic repository objects:
blob = Blob
tree = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt
submodule = Submodul
pack(noun) = Pack-Datei
pack(verb) = packen (ggf. Pack-Date
2013/5/16 Thomas Rast :
> Ralf Thielow writes:
>
>> Hi,
>>
>> I think the discussion might work better via ML than GitHub.
>> This is the full glossary of git's de.po as it would look
>> like with (hopefully) all the changes included that have been
>> discussed here. Still without any reasoning fo
2013/5/16 Holger Hellmuth (IKS) :
>
>> +bare repository= bloßes Repository
>
>
> Since "bloßes Rep." does not convey any sensible meaning to a german reader
> (at least it doesn't to me) it might as well be "bare". Also bare is used as
> parameter to commands
>
>
>> +remote tracking
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
patch is modifying.
It does this by running 'git blame' incrementally on each hunk, and then
On Sun, May 19, 2013 at 10:05 AM, Felipe Contreras
wrote:
> On Sun, May 19, 2013 at 9:40 AM, Ramkumar Ramachandra
> wrote:
>>> + '-L', '%u,+%u' % [start, len],
>>> + '--since', $since, from + '^',
>>> + '--', source]) do |p|
>>> + p.each do |line|
>
On Sun, May 19, 2013 at 10:17 AM, Ramkumar Ramachandra
wrote:
> Ramkumar Ramachandra wrote:
>> There's a non-optional space before the "" in your regex, which
>> is what I was pointing out.
>
> Er, scratch that. It's the space after the "Whatevered-by:"
It doesn't really matter. We can operate u
On Sun, May 19, 2013 at 10:13 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> How exactly is it not equivalent to len = len || 1?
>
> Here, I dug up an article for you on the issue:
>
> http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html
>
> Although it's
Ramkumar Ramachandra wrote:
> There's a non-optional space before the "" in your regex, which
> is what I was pointing out.
Er, scratch that. It's the space after the "Whatevered-by:"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
Felipe Contreras wrote:
>> Will $2 ever be nil (from fmt_person)? ie. Why are you checking for
>> the special case " <\S+?>$"?
>
> Yes, '' was valid in earlier versions of git.
There's a non-optional space before the "" in your regex, which
is what I was pointing out.
--
To unsubscribe from this
Felipe Contreras wrote:
> How exactly is it not equivalent to len = len || 1?
Here, I dug up an article for you on the issue:
http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html
Although it's fine in this case, I wouldn't recommend using ||=
because of the potential
On Sun, May 19, 2013 at 9:40 AM, Ramkumar Ramachandra
wrote:
> Okay, let's look at this part.
>
> Felipe Contreras wrote:
>> diff --git a/contrib/related/git-related b/contrib/related/git-related
>> new file mode 100755
>> index 000..4f31482
>> --- /dev/null
>> +++ b/contrib/related/git-relate
Okay, let's look at this part.
Felipe Contreras wrote:
> diff --git a/contrib/related/git-related b/contrib/related/git-related
> new file mode 100755
> index 000..4f31482
> --- /dev/null
> +++ b/contrib/related/git-related
> @@ -0,0 +1,124 @@
> +#!/usr/bin/env ruby
> +
> +# This script finds
On Sun, May 19, 2013 at 2:56 AM, Felipe Contreras
wrote:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
>
>> >> So when "the user" is running "git fetch" on "mywork" branch that
>> >> happens to be forked from a local "master",...
When using "git cherry" or "git log --cherry-pick" we often have a small
number of commits on one side and a large number on the other. In
revision.c::cherry_pick_list we store the patch IDs for the small side
before comparing the large side to this.
In this case, it is likely that only a small n
Duy Nguyen wrote:
> I don't think you can easily borrow parsing code from pretty-formats
> (but I may be wrong). Anyway new stuff with new syntax would look
> alien in for-each-ref format lines. Either we bring --pretty to
> for-each-ref, leaving all for-each-ref atoms behind in --format, or we
> s
On Mon, May 13, 2013 at 04:45:43PM +0200, Michael J Gruber wrote:
> Kevin Bracey venit, vidit, dixit 13.05.2013 16:26:
> > On 13/05/2013 01:22, Junio C Hamano wrote:
> >> Kevin Bracey writes:
> >>
> >>> git log --ancestry-path --left-right E...F --not $(git merge-base
> >>> --all E F)
> >>>
>
On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra
wrote:
> My itch is very simple.
>
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>
> % git pull # I want: pull from origin
Then do 'git pull origin', 'fc/remote/hg-next' has *nothing* to do
On Sun, May 19, 2013 at 7:08 PM, Ramkumar Ramachandra
wrote:
>> "branch -vv" shows [upstream: ahead x, behind y]. We need a syntax to
>> cover that too.
>
> Can't we construct that using [%(upstream:short): %(upstream:diff)]?
> It's nothing fundamental.
If there is no upstream, [] should not be s
My itch is very simple.
Felipe Contreras wrote:
> % git checkout fc/remote/hg-next
> % git rebase -i # rebase to master
% git pull # I want: pull from origin
> % git checkout fc/remote/hg-notes
> % git rebase -i # rebase to fc/remote/hg-next
% git pull # I want: pull from ram
> % git checkout
On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>> % git checkout fc/remote/hg-notes
>> % git rebase -i # rebase to fc/remote/hg-next
>> % git checkout fc/remote/hg-gitifyhg-compat
>> %
Duy Nguyen wrote:
> Hmm.. I missed that mail (or I wouldn't have worked on this already).
> Do you want to take over?
Oh, we can collaborate on one beautiful series :)
> "branch -vv" shows [upstream: ahead x, behind y]. We need a syntax to
> cover that too.
Can't we construct that using [%(upstr
On Fri, May 17, 2013 at 9:55 PM, Ramkumar Ramachandra
wrote:
> You can now do something like
>
> $ git for-each-ref --format='%C(red)%(refname:short)%C(reset)
> %C(blue)%(upstream:diff)%C(reset)' --count 5 --sort='-committerdate'
> refs/heads
>
> To get output that's much more customizable 'git br
On Sun, May 19, 2013 at 6:48 AM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> Exactly. I already explained why %(upstream) can't be used in 00/09.
>> "tracking" may not be perfect. Somebody might want
>> "tracking:upstream:short". It does not look quite nice.
>
> Which is why I suggested kee
On Sun, May 19, 2013 at 6:53 AM, Felipe Contreras
wrote:
> From: Amit Bakshi
>
> git clone hangs on windows, and file.write would return errno 22 inside
> of mercurial's windows.winstdout wrapper class. This patch sets stdout's
> mode to binary, fixing both issues.
Forgot:
[fc: cleaned up]
> Si
On Sun, May 19, 2013 at 6:54 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> You can't represent push.default = single either.
>
> Right. And I propose that we extend the refspec to be able to
> represent it, instead of having "single" sticking out like a sore
> thumb (and possibly i
On Sun, May 19, 2013 at 6:17 PM, Ramkumar Ramachandra
wrote:
>> [PATCH 3/9] for-each-ref: avoid printing each element directly to stdout
>
> Why did you do this? Atoms are designed to be independent of each
> other. I'll keep reading: might find out in a later patch.
Sorry for the lack of expla
From: Amit Bakshi
git clone hangs on windows, and file.write would return errno 22 inside
of mercurial's windows.winstdout wrapper class. This patch sets stdout's
mode to binary, fixing both issues.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 4
1 file chang
Felipe Contreras wrote:
> You can't represent push.default = single either.
Right. And I propose that we extend the refspec to be able to
represent it, instead of having "single" sticking out like a sore
thumb (and possibly introducing more sore thumbs like this in the
future).
--
To unsubscribe
On Sun, May 19, 2013 at 6:11 PM, Ramkumar Ramachandra
wrote:
> Nguyễn Thái Ngọc Duy wrote:
>> The purpose of this series is to make "for-each-ref --format" powerful
>> enough to display what "branch -v" and "branch -vv" do so that we
>> could get rid of those display code and use for-each-ref code
The dot repository convention is not well know to users and its
documenation is hidden as a note in an ancilliary config variable's
documenation.
Document the dot repository 'do what I mean' convention in the
config variable it is used in, and in the cli (command line interface)
documenation page
The Git cli will generally accept dot '.' (period) as equivalent
to the current repository when appropriate. Tell the reader of this
'do what I mean' (dwim)mery action.
Signed-off-by: Philip Oakley
---
Documentation/gitcli.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation
branch..remote can be set to '.' (period) as a dot repository
as part of the remote name dwimmery. Tell the reader.
Signed-off-by: Philip Oakley
---
Documentation/config.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53fc5..f
Describe rebase in the description section.
Include a softer paraphrased version from the crytic, well-loved,
but sometimes parodied, Name description, and tell users that merge
commits are excluded by default.
Signed-off-by: Philip Oakley
---
http://article.gmane.org/gmane.comp.version-contro
Give details of the implied priority in the description section.
Signed-off-by: Philip Oakley
---
wording based on:
http://article.gmane.org/gmane.comp.version-control.git/222581
http://article.gmane.org/gmane.comp.version-control.git/223816
http://article.gmane.org/gmane.comp.version-control.git
Recent discussions have shown that rebase isn't as well understood as
as perhaps it should be for the basic user.
Add a softer introductory paragraph to the man page description, and
in the second patch, add a second paragraph explaining the build up of
the command so that users have a historical
Felipe Contreras wrote:
> % git checkout fc/remote/hg-next
> % git rebase -i # rebase to master
> % git checkout fc/remote/hg-notes
> % git rebase -i # rebase to fc/remote/hg-next
> % git checkout fc/remote/hg-gitifyhg-compat
> % git rebase -i # rebase to fc/remote/hg-notes
So it is rebase, but re
Duy Nguyen wrote:
> Exactly. I already explained why %(upstream) can't be used in 00/09.
> "tracking" may not be perfect. Somebody might want
> "tracking:upstream:short". It does not look quite nice.
Which is why I suggested keeping upstream, upstream:short, and
introducing upstream:diff and upstr
On Sun, May 19, 2013 at 6:44 AM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> If somebody implements the "push.default = single" (see the original
>> message you are responding to), then the change might be smaller.
>
> I think this is a bad hack covering up an underlying problem: it is
Junio C Hamano wrote:
> If somebody implements the "push.default = single" (see the original
> message you are responding to), then the change might be smaller.
I think this is a bad hack covering up an underlying problem: it is
ugly, confusing, and inextensible in my opinion. I think of
push.def
On Sun, May 19, 2013 at 6:38 PM, Felipe Contreras
wrote:
> On Sun, May 19, 2013 at 6:18 AM, Ramkumar Ramachandra
> wrote:
>> Nguyễn Thái Ngọc Duy wrote:
>>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>>> index 498d703..b10d48a 100644
>>> --- a/builtin/for-each-ref.c
>>> +++ b/bu
On Sun, May 19, 2013 at 6:32 PM, Ramkumar Ramachandra
wrote:
> I don't think [7/9] and [8/9] belong in this series. Let's see how
> you've used it in :aligned.
>
> Nguyễn Thái Ngọc Duy wrote:
>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>> index 1390da8..3240ca0 100644
>> --- a
On Sun, May 19, 2013 at 5:27 AM, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/for-each-ref.c | 14 ++
> quote.c| 44 ++--
> quote.h| 6 +++---
> 3 files changed, 35 inserti
On Sun, May 19, 2013 at 5:27 AM, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> quote.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
No functional changes I suppose.
--
Felipe Contreras
--
To unsubscribe from this list: send the line
On Sun, May 19, 2013 at 6:18 AM, Ramkumar Ramachandra
wrote:
> Nguyễn Thái Ngọc Duy wrote:
>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>> index 498d703..b10d48a 100644
>> --- a/builtin/for-each-ref.c
>> +++ b/builtin/for-each-ref.c
>> @@ -76,6 +76,8 @@ static struct {
>>
On Sun, May 19, 2013 at 6:11 AM, Ramkumar Ramachandra
wrote:
> Yes, I think this is the direction we should be taking. Poorly
> thought-out stuff like -v and -vv should be deprecated.
Of course not. They are useful and user-friendly.
The only question is what should be the format by default.
I don't think [7/9] and [8/9] belong in this series. Let's see how
you've used it in :aligned.
Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index 1390da8..3240ca0 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -1012,8 +101
Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index b10d48a..db5c211 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -78,6 +81,7 @@ static struct {
> { "current" },
> { "tracking" },
> { "tracking:upstr
On Mon, Jan 28, 2013 at 4:13 PM, Amit Bakshi wrote:
> git clone hangs on windows (msysgit/cygwin), and
> file.write would return errno 22 inside of mercurial's
> windows.winstdout wrapper class. This patch sets
> stdout's mode to binary, fixing both issues.
> ---
> contrib/remote-helpers/git-remo
Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index 498d703..b10d48a 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -76,6 +76,8 @@ static struct {
> { "symref" },
> { "flag" },
> { "current" },
> +
> [PATCH 3/9] for-each-ref: avoid printing each element directly to stdout
Why did you do this? Atoms are designed to be independent of each
other. I'll keep reading: might find out in a later patch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to ma
Nguyễn Thái Ngọc Duy wrote:
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index 08d4eb1..498d703 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -75,6 +75,7 @@ static struct {
> { "upstream" },
> { "symref" },
> { "flag" },
> +
Nguyễn Thái Ngọc Duy wrote:
> The purpose of this series is to make "for-each-ref --format" powerful
> enough to display what "branch -v" and "branch -vv" do so that we
> could get rid of those display code and use for-each-ref code instead.
Damn, you beat me to it. I just introduced color, and w
On 18/05/2013 23:37, Peter Lauri wrote:
Great, I have gotten the concept now :)
My workaround for my problem is to rename the file to default and
then all will work out well :) Copy the file then and locally modify
it, but it will be in .gitignore so not tracked :)
Over in the #git IRC cha
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 1390da8..3240ca0 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index a9d189c..1390da8 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/fo
By the time show_ref() is called, atom values for all refs are
ready. This can be taken advantage of later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 4 ++--
builtin/for-each-ref.c | 18 ++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0836890..7d084da 100644
--- a/builtin/branch.c
+++ b/builtin/branch.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
branch.h | 11 +++
builtin/branch.c | 12 ++--
builtin/for-each-ref.c | 34 +-
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/branch.h b/branch.h
index 64173ab..076babf 1
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 08d4eb1..498d703 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -75,6 +75,7 @@ static struc
1 - 100 of 118 matches
Mail list logo
