On Tue, May 21, 2013 at 3:18 PM, Chico Sokol wrote:
> Ok, we discovered that the commit object actually contains the tree
> object's sha1, by reading its contents with python zlib library.
>
> So the bug must be with our java code (we're building a java lib).
>
> Is there any non-standard issue in
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey wrote:
> On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
>> Ok, we discovered that the commit object actually contains the tree
>> object's sha1, by reading its contents with python zlib library.
>>
>> So the bug must be with our java code (we'r
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol wrote:
> It was git who created that object.
>
> We're trying to build a improved java library focused in our needs
> (jgit has a really confusing api focused in solving egit needs).
JGit code... is confusing because its fast. We spent a lot of time
tr
On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
> Ok, we discovered that the commit object actually contains the tree
> object's sha1, by reading its contents with python zlib library.
>
> So the bug must be with our java code (we're building a java lib).
That's interesting. We ran in a si
I applied this one and the "guilt: skip empty line after..." patch.
Jeff.
On Tue, May 21, 2013 at 11:13:31PM -0400, Theodore Ts'o wrote:
> If the date field has a space in it, such as:
>
>Date: Tue, 14 May 2013 18:37:15 +0200
>
> previously guilt would go belly up:
>
>+ export GIT_AUTH
On Tue, May 21, 2013 at 10:55:57PM -0400, Theodore Ts'o wrote:
> To make it harder to accidentally do "git push" with a guilt patch
> applied, "guilt push" changes branch from e.g. "master" to
> "guilt/master" starting with commit 67d3af63f422. This is a feature
> which I use for ext4 development;
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
/usr/local/bin/guilt: 571: export: 14: bad variable name
Fix this.
Signed-off-by: "Theodore Ts'o"
---
guil
On Tue, May 21, 2013 at 3:54 PM, Thomas Gummerer wrote:
> Currently the __git_ps1 git prompt gives the following error with a
> repository converted by git-svn, when used with zsh:
>
>__git_ps1_show_upstream:19: bad pattern: svn_remote[
>
> This was introduced by 6d158cba (bash complet
On Tue, May 21, 2013 at 7:47 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano wrote:
>>
>>> This sounds like a good thing to do. Perhaps the refspec mapping
>>> can be handled the same way as a backend feature so that you do not
>>> have
On Tue, May 21, 2013 at 7:50 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
I still haven't received a response: which makes more sense?
a)
% git checkout svn-ext
>>
To make it harder to accidentally do "git push" with a guilt patch
applied, "guilt push" changes branch from e.g. "master" to
"guilt/master" starting with commit 67d3af63f422. This is a feature
which I use for ext4 development; I actually *do* want to be able to
push patches to the dev branch, whi
Commit 2cc8d353d7ecb broke manually written patch descriptions of the
form:
> Frobnozzle: this is a patch subject
>
> From: Fred McNurk
>
> This is the patch description
Commit 8f88f953580a0 partially fixed things by filtering out the From:
field, but it did not filter out th
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin
Signed-off-by: Ju
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git a/t/t7301-clean-in
Add new section "Interactive mode" for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin
Helped-by: Eric Sunshine
Signed-off-by: Junio C Hamano
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2 deletions(-)
d
Add a new action for interactive git-clean: ask each. It's just like
the "rm -i" command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
builtin/clean.c | 36
1 file
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and retur
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, press
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive." for command `git-add--interactive`.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
Documentatio
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 4
builtin/clean.c | 49 +++
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press "y" to start cleaning, and press "n" if you want to abort.
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
Documentati
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
quote_path_relative(). Remove unused parameters and change the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin
Signed-off
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletion
Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to retur
Add subcommand "relative_path" in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin
---
t/t0060-path-utils.sh | 26 ++
test-path-utils.c | 25 +
2 files changed, 51 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t006
2013/5/22 Junio C Hamano :
> Jiang Xin writes:
>
>> diff --git a/test-path-utils.c b/test-path-utils.c
>> index 0092cb..18267 100644
>> --- a/test-path-utils.c
>> +++ b/test-path-utils.c
>> @@ -1,6 +1,19 @@
>> #include "cache.h"
>> #include "string-list.h"
>>
>> +#define PARSE_ARGV_STRING(var, i
Felipe Contreras writes:
> On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> I still haven't received a response: which makes more sense?
>>>
>>> a)
>>>
>>> % git checkout svn-ext
>>> % git fetch
>>> From .
>>>* branch
Felipe Contreras writes:
> On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano wrote:
>
>> This sounds like a good thing to do. Perhaps the refspec mapping
>> can be handled the same way as a backend feature so that you do not
>> have to unconditionally disable it in the other patch.
>
> With my p
On Tue, May 21, 2013 at 07:29:38PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 7:20 PM, SZEDER Gábor wrote:
> > On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
> >> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> >> > On Tue, May 21, 2013 at 06:04:35PM -0500,
On Tue, May 21, 2013 at 7:20 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
>> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
>> > On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
>> >> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gáb
On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> I still haven't received a response: which makes more sense?
>>
>> a)
>>
>> % git checkout svn-ext
>> % git fetch
>> From .
>>* branchmaster -> FETCH_HEAD
>> # oo
On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> > On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
> >> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
> >>
> >> > On Tue, May 21, 2013 at 10:54:27PM +
On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
>> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
>>
>> > On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
>> >> Currently the __git_ps1 git prompt gives
On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
>
> > On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
> >> Currently the __git_ps1 git prompt gives the following error with a
> >> repository converted by git
Chico Sokol wrote:
> We're trying to build a improved java library focused in our needs
> (jgit has a really confusing api focused in solving egit needs).
JGit is also open to contributions, including contributions that
add less confusing API calls. :) See
http://wiki.eclipse.org/JGit/User_Gui
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final version of 1.8.3 is expected to be tagged late this week.
I have kept many late topics outside 'next' during the -rc period
primarily
Felipe Contreras writes:
> I still haven't received a response: which makes more sense?
>
> a)
>
> % git checkout svn-ext
> % git fetch
> From .
>* branchmaster -> FETCH_HEAD
> # oops
> % git fetch git-svn
> % git log ..FETCH_HEAD
>
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
>> Currently the __git_ps1 git prompt gives the following error with a
>> repository converted by git-svn, when used with zsh:
>>
>> __git_ps1_show_upstream:19: bad pat
On Tue, May 21, 2013 at 5:33 PM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Tuesday, May 21, 2013 10:21 PM
>
>> On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano
>> wrote:
>>>
>>> "Philip Oakley" writes:
>>
>>
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
wrote:
>
>
Hi,
On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
> Currently the __git_ps1 git prompt gives the following error with a
> repository converted by git-svn, when used with zsh:
>
> __git_ps1_show_upstream:19: bad pattern: svn_remote[
>
> This was introduced by 6d158cba
On Tue, May 21, 2013 at 12:19 PM, Torsten Bögershausen wrote:
> On 2013-05-21 00.52, Junio C Hamano wrote:
>> Thanks, will replace da/darwin with this round.
> (May be late response, not sure if this is the right email thread.
> I eventually managed to compile under 10.6, what we have on pu)
>
> O
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs). But
we're about to get into their code to discover how to decompress git
objects.
--
Chico Sokol
On Tue, May 21, 2013 at 7:22
From: "Felipe Contreras"
Sent: Tuesday, May 21, 2013 10:21 PM
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano
wrote:
"Philip Oakley" writes:
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
wrote:
Another trick is to use "git push":
git push . $production_sha1:refs/heads/master
Chico Sokol writes:
> Ok, we discovered that the commit object actually contains the tree
> object's sha1, by reading its contents with python zlib library.
>
> So the bug must be with our java code (we're building a java lib).
Why aren't you using jgit?
--
To unsubscribe from this list: send th
Chico Sokol writes:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following output:
Who wrote this commit
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any non-standard issue in git's zlib compression? We're
decompressing its contents with
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol wrote:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol wrote:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol 1369140112 -0300
comm
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano wrote:
> "Philip Oakley" writes:
>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
>> wrote:
>>> Another trick is to use "git push":
>>> git push . $production_sha1:refs/heads/master
>
> It all falls out naturally from the "Git is distri
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Certain remote-helpers (the ones with 'export') would try to push
>> regardless.
>>
>> Obviously this is not what the user wants.
>>
>> Also, add a check for the 'dry-run' option, so remote-helpers can
>> impl
On Tue, May 21, 2013 at 11:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>> I won't
>> bother rationalizing if this makes sense for 'master'
>
> As this is a change to an old code/behaviour that was with us with
> many released versions, it hardly is for 'master' during -rc period.
Pr
Junio C Hamano wrote:
> In general, when a command is working in your repository with a
> working tree, we do not make any such promise that it keeps
> operationg normally when you pull the rug under its feet from
> another terminal ("git checkout maint" running at the same time "git
> pull" would
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
This was introduced by 6d158cba (bash completion: Support "divergence
from upstream" messages in __git_ps1), whe
Jiang Xin writes:
> diff --git a/test-path-utils.c b/test-path-utils.c
> index 0092cb..18267 100644
> --- a/test-path-utils.c
> +++ b/test-path-utils.c
> @@ -1,6 +1,19 @@
> #include "cache.h"
> #include "string-list.h"
>
> +#define PARSE_ARGV_STRING(var, input) do { \
> + if (!strcmp(inpu
Ramkumar Ramachandra writes:
> "@{u}". What am I missing?
You draw the arrow the other way around, that is what made the text
confusing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Is there? I do not think "volatile" is particularly a good
>> description for this, but showing what is pushed as a concrete
>> branch name feels like a good improvement to me, at least in
>> principle.
>
> Okay. I used "volatile", because
Junio C Hamano wrote:
>> interpret_branch_name -> interpret_branch_name (recursion)
>> -> get_sha1_basic -> get_sha1 [context] (end-user data)
>> -> substitute_branch_name -> dwim (end-user data)
>> -> strbuf_branchname (callers pass a
Ramkumar Ramachandra writes:
> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> So did you or did you not audit the codepath?
>>
>> No; I was explaining why I didn't in the first place. Going through it now.
>
> So, this is what I have:
>
> interpret_branch_name -> interpret_branch_name
Ramkumar Ramachandra writes:
> We're at 1.8.3; isn't it a little early to be thinking of 2.0? Is it
> conflicting with jc/push-2.0-default-to-simple in pu? I should
> re-send after this topic graduates to master in 2.0?
I implicitly asked you not to ask as I do not even have to worry
about con
Junio C Hamano wrote:
> Is there? I do not think "volatile" is particularly a good
> description for this, but showing what is pushed as a concrete
> branch name feels like a good improvement to me, at least in
> principle.
Okay. I used "volatile", because push does not lock HEAD when the
operat
Torsten Bögershausen wrote:
> One minor nit, or 2:
> imap-send.c: In function ‘cram’:
> imap-send.c:913: warning: statement with no effect
>
> This fixes it:
>
> diff --git a/imap-send.c b/imap-send.c
> index 8ea180f..11577c9 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -35,7 +35,7 @@ typed
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> So did you or did you not audit the codepath?
>
> No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name -> interpret_branch_name (recursion)
-> get_sh
On 2013-05-21 00.52, Junio C Hamano wrote:
> Thanks, will replace da/darwin with this round.
(May be late response, not sure if this is the right email thread.
I eventually managed to compile under 10.6, what we have on pu)
One minor nit, or 2:
imap-send.c: In function ‘cram’:
imap-send.c:913: war
Ramkumar Ramachandra writes:
> There's still a lot to think about.
Is there? I do not think "volatile" is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
I haven't picked them up, and I w
Johan Herland writes:
> On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano wrote:
> ...
>> That "backing out" can be made more intelligently than just dying
>> with "compare and swap failed--please retry" message, e.g. you at
>> that point notice what you started with, what the other party did
>> w
Setting push.default to current adds the refspec "HEAD" for the
transport layer to handle. If "HEAD" doesn't resolve to a branch (and
since no refspec rhs is specified), the push fails after some time with
a cryptic error message:
$ git push
error: unable to push to unqualified destination: H
Since a push does not lock the "HEAD" ref, there is no guarantee that it
will remain the same for the entire operation of the push. Practically,
this means that with push.default set to current:
# on branch push-current-head
$ git push
# on another terminal
$ git checkout master
# retur
With push.default set to upstream or simple, and a detached HEAD, git
push prints the following error:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:
This error is not unique to upstrea
There's still a lot to think about.
[3/3] is the big itch: [1/2] and [2/2] are just setup patches.
Ramkumar Ramachandra (3):
push: factor out the detached HEAD error message
push: fail early with detached HEAD and current
push: don't push the volatile HEAD with current
builtin/push.c | 20
Junio C Hamano wrote:
> People have _already_ seen and lived with these issues in released
> versions. Changing it may or may not be getting it back to the
> state to that of an even older release, but at that point the
> differences do not matter. It is a "fix", too late for the kind of
> regres
Junio C Hamano wrote:
> More importantly, doesn't "real_ref" have the name of the branch?
>
> Suppose the user said "git show @{1}" instead of "git show
> master@{1}" while on 'master'.
My stupidity, sorry.
> It could be argued that it may look nicer to say "your current
> branch does not
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> So did you or did you not audit the codepath?
>
> No; I was explaining why I didn't in the first place. Going through it now.
I did not mean "You must do so or we should discard the patch". I
just wanted to make sure the log messages say
Junio C Hamano wrote:
> So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Does a failure in interpret-branch-name that issue these error
>> messages always followed by die() in the caller? I know you looked
>> at the cases you noticed as an end-user (like the above "git show @{u}"
>> example), but if some codepat
Ramkumar Ramachandra writes:
> So, is it
> because that version was too long ago that we don't consider it a
> regression (do we backport fixes)?
The "regression fixes" pre-release -rc period is for is to make sure
to avoid unwanted/unintended behaviour changes between releases.
People have _al
Junio C Hamano wrote:
> Does a failure in interpret-branch-name that issue these error
> messages always followed by die() in the caller? I know you looked
> at the cases you noticed as an end-user (like the above "git show @{u}"
> example), but if some codepaths did this:
>
> if (interpre
On 21/05/2013 19:52, Junio C Hamano wrote:
Ramkumar Ramachandra writes:
The empty string '' looks ugly and inconsistent with the output of
@{}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't "real_ref" have the name of the bra
Junio C Hamano wrote:
> Fixes to something that are broken the same way between 'master' and
> older release versions are the same as enhancements (which you can
> view as "fix to lack of feature"). They are not regression fixes
> and not for 1.8.3 at this point in the cycle, deep into -rc.
If we
Michael Haggerty writes:
> 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
> ---
I do not think this change is justified, *unless* the caller later
in the series gains a better heuristics than
Michael Haggerty writes:
> 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 sh
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> revision.c | 20 ++--
> revision.h | 32 +---
> 2 files changed, 35 insertions(+), 17 deletions(-)
Looks obviously good for *.c file, but I am on the fence for *.h
one, as the reason
Michael Haggerty writes:
> Change cmd_diff() to use a (struct object_array) for holding the trees
> that it accumulates, rather than rolling its own equivalent.
>
A significant detail missing here is that this lifts the hardcoded
100 tree limit in combined diff but that does not matter in
practi
Michael Haggerty writes:
> 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(-
Nguyễn Thái Ngọc Duy writes:
> This series introduces:
>
> - %(current), which either shows "*" if the ref is pointed by HEAD
>or a space. Junio called it %(headness). I don't like that.
>I don't like %(current) either but we have to start somewhere.
>Name suggestion? %(marker)??
"
Will apply for 1.8.3.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Felipe Contreras writes:
> Certain remote-helpers (the ones with 'export') would try to push
> regardless.
>
> Obviously this is not what the user wants.
>
> Also, add a check for the 'dry-run' option, so remote-helpers can
> implement it.
This sounds like a good thing to do. Perhaps the refspe
Ramkumar Ramachandra writes:
> Currently, when we try to resolve @{} or @{} when the reflog
> for the current branch doesn't go back far enough, we get errors like:
>
> $ git show @{1}
> fatal: Log for '' only has 7 entries.
>
> $ git show @{1.days.ago}
> warning: Log for '' only
Ramkumar Ramachandra writes:
> Currently, when no (valid) upstream is configured for a branch, we get
> an error like:
>
> $ git show @{u}
> error: No upstream configured for branch 'upstream-error'
> error: No upstream configured for branch 'upstream-error'
> fatal: ambiguous argument '@
Ramkumar Ramachandra writes:
> Seeing other patches on the list, I decided that I should do something
> for 1.8.3 as well
Fixes to something that are broken the same way between 'master' and
older release versions are the same as enhancements (which you can
view as "fix to lack of feature"). Th
Ramkumar Ramachandra writes:
> [+CC: Matthieu Moy]
>
> Mathieu Liénard--Mayor wrote:
>> -Cleaner error message when "git rm" fails with multiple files
>
> Should be fairly straightforward to implement. Just collect the
> errors and print them out at once.
>
>> -Add configuration options for some
Felipe Contreras writes:
> Otherwise with certain remote helpers (the ones that support 'export'),
> the users will be pushing to the wrong branch:
>
> git push topic:master
>
> Will push the topic branch, as if the user typed:
>
> git push topic
>
> Signed-off-by: Felipe Contreras
> ---
>
>
Felipe Contreras writes:
> On Mon, May 20, 2013 at 7:33 PM, Felipe Contreras
> wrote:
>> zsh completion wrapper doesn't reimplement __gitcompadd(). Although it
>> should be trivial to do that, let's use __gitcomp_nl() which achieves
>> exactly the same thing, specially since the suffix ($4) has
"Philip Oakley" writes:
> From: "Junio C Hamano"
> Sent: Monday, May 20, 2013 11:22 PM
>> "Philip Oakley" writes:
>>
>>> So we can have a branch whose remote is '.'
>>> _and_ a remote whose URL is '.'
>>
>> Yes, and they are two separate concepts.
> Thank you of the confirmation.
>
>>
>> "git f
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> * mm/color-auto-default (2013-05-15) 2 commits
>> - make color.ui default to 'auto'
>> - config: refactor management of color.ui's default value
>>
>> Flip the default for color.ui to 'auto', which is what many
>> tutorials recommend new use
Thomas Rast writes:
> Junio C Hamano writes:
>
>> * tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
>> - test-lib: support running tests under valgrind in parallel
>> - test-lib: allow prefixing a custom string before "ok N" etc.
>> - test-lib: valgrind for only tests matching a pattern
>
Johan Herland writes:
> On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano wrote:
>> * jh/shorten-refname (2013-05-07) 4 commits
>> - t1514: refname shortening is done after dereferencing symbolic refs
>> - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to
>> origin
>> - t15
Thomas Rast writes:
> Junio C Hamano writes:
>
>> In addition to your topic, it may be a good idea to notice this at
>> the Porcelain level (e.g. "checkout -b" and "branch", but not at the
>> "update-ref" level) and warn or even die if a Porcelain tries to
>> create a branch with such a name.
>
1 - 100 of 113 matches
Mail list logo
