Junio C Hamano writes:
> Ramkumar Ramachandra writes:
> ...
>> -G::
>> -Look for differences whose added or removed line matches
>> -the given .
>> +Grep through the patch text of commits for added/removed lines
>> +that match . `--pickaxe-regex` is implied in this
>> +mode
Felipe Contreras writes:
> On Sat, May 18, 2013 at 6:46 AM, Felipe Contreras
> wrote:
>
>> contrib/related/git-related | 124
>>
>> 1 file changed, 124 insertions(+)
>> create mode 100755 contrib/related/git-related
>
> I tried everything and I don
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 fact this command compares between files on disk and
> repository b
Peter Lauri writes:
> 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 :)
I think it is not even an workaround
Felipe Contreras writes:
> Sorry Amit, I assumed this patch made it to the list, but I just
> realized it didn't; it doesn't allow HTML, and mails and silently
> dropped (I hate that).
>
> So I'm sending it so the list can see it:
>
> It seems OK for me, but I would like to try it, and so far I h
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>
> >>> This is irrelevant, it's an implementation detail of 'git pull'. *THE
> >>> USER* is not running 'git fetch .'
> >>
> >> To those who fear runni
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",...
> >> we still need to have FETCH_HEAD updated to point at what we
Junio C Hamano wrote:
> Kevin Bracey writes:
> > And it would be ideal if the initial base and push tracking
> > information could be set up automatically on the first "git checkout
> > -b"/"git branch" and "git push".
>
> I think checkout and branch is already covered with -t. There may
> even
Junio C Hamano wrote:
> David Aguilar writes:
>
> > On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano wrote:
> >
> >> So it is a right thing to do in that sense.
> >>
> >> I however am having this nagging feeling that I may be missing
> >> something subtle here. Comments from others are very much
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Sat, May 18, 2013 at 6:46 AM, Felipe Contreras
> > wrote:
> >
> >> contrib/related/git-related | 124
> >>
> >> 1 file changed, 124 insertions(+)
> >> create mode 100755 contrib/related/git-
This is a re-roll of David Aguilar's patch series [1] which eliminates some
of the OpenSSL deprecation warnings on Mac OS X.
Changes since v7:
- Avoid double-negation (#ifndef NO_APPLE_COMMON_CRYPTO)
- Don't break imap-send.c for platforms other than Apple
[1]: http://thread.gmane.org/gmane.comp.
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
Introduce boilerplate which controls whether Apple'
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build diagnostics such as:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using Apple's Common
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability. Silence the warnings by using Apple's
CommonCrypto HMAC replacement functions.
[es: reworded commit message; check APPLE_COMMON_CRYPTO instead of
abusing COMMON_DIGEST_FOR_OPENSSL]
S
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.
The benefits are clear: share more code, branch can also borrow
--sort and --format from f
Signed-off-by: Nguyễn Thái Ngọc Duy
---
quote.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/quote.c b/quote.c
index 911229f..c67f5d3 100644
--- a/quote.c
+++ b/quote.c
@@ -44,19 +44,10 @@ void sq_quote_buf(struct strbuf *dst, const char *src)
void sq
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 insertions(+), 29 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 48 +---
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 14151b4..08d4eb1 100644
--- a/builtin/for-each-ref.c
+++ b/b
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
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/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
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 | 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
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
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
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" },
> +
> [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 498d703..b10d48a 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -76,6 +76,8 @@ static struct {
> { "symref" },
> { "flag" },
> { "current" },
> +
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 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
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
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.
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 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 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 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 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
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: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
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
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
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
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
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
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
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
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
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
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
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
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
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: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: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 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
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 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
>> %
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 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
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 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)
> >>>
>
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
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
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",...
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 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
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
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
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
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
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: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|
>
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
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
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
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 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,
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
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
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
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
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
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
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
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
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.
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..
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
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
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
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
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
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
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
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
1 - 100 of 118 matches
Mail list logo
