Re: What's cooking in git.git (May 2013, #04; Wed, 15)

2013-05-21 Thread Thomas Rast
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. But if we're going there and d

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

2013-05-21 Thread Thomas Rast
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 > - test-lib: verbose mode fo

Re: Contributing to git: cleaner git -rm & add configuration options

2013-05-21 Thread Ramkumar Ramachandra
[+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 commonly used command-line options I'd rea

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Philip Oakley
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 fetch" while on "mywork" branch with this: [bra

Re: [PATCH] contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash

2013-05-21 Thread John Keeping
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote: > Dmitry Marakasov writes: > > > Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: > > it's required for systems which don't use bash by default (for example, > > FreeBSD), while there seem to be no bashisms in th

Re: Workflow Help

2013-05-21 Thread John Keeping
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote: > I am looking at formulating and then documenting our vcs workflow > using Git at work. I have an idea of how I want things to work, but am > a little hazy on some of the details. > > Our basic workflow will be based around: > http://

[PATCH 0/2] Fix invalid revision error messages for 1.8.3

2013-05-21 Thread Ramkumar Ramachandra
Hi, Seeing other patches on the list, I decided that I should do something for 1.8.3 as well (as opposed to constantly writing new features). So here's my contribution. The first error message has annoyed me endlessly, and I took this opportunity to fix it. Interested people can sprinkle in som

[PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Ramkumar Ramachandra
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 '@{u}': unknown revision or path not in the wo

[PATCH 2/2] sha1_name: fix error message for @{}, @{}

2013-05-21 Thread Ramkumar Ramachandra
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 goes back to Tue, 21 May 2013 14:14:45 +0530.

activate color.ui by default (Re: What's cooking in git.git (May 2013, #05; Mon, 20))

2013-05-21 Thread Matthieu Moy
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 users to do. > > I think this is r

Re: your mail

2013-05-21 Thread Magnus Bäck
On Friday, May 17, 2013 at 14:02 EDT, ASHISH VERMA wrote: > Hi, i am using git to push my code from eclipse to heroku , but > recently iam getting error like:: > > master:master rejected:non fast forward > > and i am not able to resolve it .I tried a git pull but that says - > conflicts

Re: Workflow Help

2013-05-21 Thread Magnus Bäck
On Monday, May 20, 2013 at 20:59 EDT, "Quilkey, Tony" wrote: > I am looking at formulating and then documenting our vcs workflow > using Git at work. I have an idea of how I want things to work, but am > a little hazy on some of the details. > > Our basic workflow will be based around: > ht

Re: Workflow Help

2013-05-21 Thread Andreas Ericsson
On 2013-05-21 02:59, Quilkey, Tony wrote: Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successfu

Re: What's cooking in git.git (May 2013, #04; Wed, 15)

2013-05-21 Thread Junio C Hamano
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. >

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

2013-05-21 Thread Junio C Hamano
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

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

2013-05-21 Thread Junio C Hamano
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 >

Re: activate color.ui by default (Re: What's cooking in git.git (May 2013, #05; Mon, 20))

2013-05-21 Thread Junio C Hamano
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Junio C Hamano
"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

Re: [PATCH] completion: trivial fix for zsh

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH] transport-helper: barf when user tries old:new

2013-05-21 Thread Junio C Hamano
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 > --- > >

Re: Contributing to git: cleaner git -rm & add configuration options

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Junio C Hamano
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 '@

Re: [PATCH 2/2] sha1_name: fix error message for @{}, @{}

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH v2] transport-helper: check if the dry-run is supported

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 0/2] remote-hg: fix configuration notes

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH/WIP 0/9] for-each-ref format improvements

2013-05-21 Thread Junio C Hamano
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)?? "

Re: [PATCH 04/17] builtin_diff_tree(): make it obvious that function wants two entries

2013-05-21 Thread Junio C Hamano
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(-

Re: [PATCH 05/17] cmd_diff(): use an object_array for holding trees

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 08/17] revision: split some overly-long lines

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 10/17] get_revision_internal(): make check less mysterious

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 09/17] gc_boundary(): move the check "alloc <= nr" to caller

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 2/2] sha1_name: fix error message for @{}, @{}

2013-05-21 Thread Kevin Bracey
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Ramkumar Ramachandra
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://

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 2/2] sha1_name: fix error message for @{}, @{}

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 0/2] Fix invalid revision error messages for 1.8.3

2013-05-21 Thread Ramkumar Ramachandra
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

[PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Ramkumar Ramachandra
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

[PATCH 1/3] push: factor out the detached HEAD error message

2013-05-21 Thread Ramkumar Ramachandra
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

[PATCH 2/3] push: fail early with detached HEAD and current

2013-05-21 Thread Ramkumar Ramachandra
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

[PATCH 3/3] push: don't push the volatile HEAD with current

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 00/17] Remove assumptions about refname lifetimes

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto

2013-05-21 Thread Torsten Bögershausen
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto

2013-05-21 Thread Jonathan Nieder
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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

2013-05-21 Thread Junio C Hamano
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

Re: [PATCH v12 01/15] test: add test cases for relative_path

2013-05-21 Thread 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, input) do { \ > + if (!strcmp(inpu

[PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread Thomas Gummerer
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

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2013-05-21 Thread Ramkumar Ramachandra
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

Re: [PATCH] transport-helper: barf when user tries old:new

2013-05-21 Thread Felipe Contreras
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

Re: [PATCH v2] transport-helper: check if the dry-run is supported

2013-05-21 Thread Felipe Contreras
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Felipe Contreras
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

Reading commit objects

2013-05-21 Thread Chico Sokol
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

Re: Reading commit objects

2013-05-21 Thread Felipe Contreras
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

Re: Reading commit objects

2013-05-21 Thread John Szakmeister
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

Re: Reading commit objects

2013-05-21 Thread Chico Sokol
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

Re: Reading commit objects

2013-05-21 Thread Junio C Hamano
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

Re: Reading commit objects

2013-05-21 Thread Junio C Hamano
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Philip Oakley
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

Re: Reading commit objects

2013-05-21 Thread Chico Sokol
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

Re: [PATCH v8 0/3] Begin replacing OpenSSL with CommonCrypto

2013-05-21 Thread David Aguilar
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread SZEDER Gábor
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Felipe Contreras
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: > >

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread Felipe Contreras
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Junio C Hamano
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 >

What's cooking in git.git (May 2013, #06; Tue, 21)

2013-05-21 Thread Junio C Hamano
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

Re: Reading commit objects

2013-05-21 Thread Jonathan Nieder
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread SZEDER Gábor
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread Felipe Contreras
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread SZEDER Gábor
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 +

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Felipe Contreras
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread Felipe Contreras
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

Re: [PATCH] prompt: fix show upstream with svn and zsh

2013-05-21 Thread SZEDER Gábor
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,

Re: [PATCH v2] transport-helper: check if the dry-run is supported

2013-05-21 Thread Junio C Hamano
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

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

2013-05-21 Thread Junio C Hamano
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

[PATCH v13 00/15] interactive git-clean

2013-05-21 Thread Jiang Xin
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

[PATCH v13 01/15] test: add test cases for relative_path

2013-05-21 Thread Jiang Xin
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

[PATCH v13 02/15] path.c: refactor relative_path(), not only strip prefix

2013-05-21 Thread Jiang Xin
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

[PATCH v13 03/15] quote.c: remove path_relative, use relative_path instead

2013-05-21 Thread Jiang Xin
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

[PATCH v13 04/15] Refactor quote_path_relative, remove unused params

2013-05-21 Thread Jiang Xin
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

[PATCH v13 07/15] git-clean: add support for -i/--interactive

2013-05-21 Thread Jiang Xin
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

[PATCH v13 06/15] git-clean: refactor git-clean into two phases

2013-05-21 Thread Jiang Xin
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

[PATCH v13 08/15] git-clean: show items of del_list in columns

2013-05-21 Thread Jiang Xin
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 +++

[PATCH v13 09/15] git-clean: add colors to interactive git-clean

2013-05-21 Thread Jiang Xin
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

[PATCH v13 10/15] git-clean: use a git-add-interactive compatible UI

2013-05-21 Thread Jiang Xin
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

[PATCH v13 11/15] git-clean: add filter by pattern interactive action

2013-05-21 Thread Jiang Xin
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

[PATCH v13 12/15] git-clean: add select by numbers interactive action

2013-05-21 Thread Jiang Xin
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

[PATCH v13 14/15] git-clean: add documentation for interactive git-clean

2013-05-21 Thread Jiang Xin
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

[PATCH v13 13/15] git-clean: add ask each interactive action

2013-05-21 Thread Jiang Xin
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

[PATCH v13 15/15] test: add t7301 for git-clean--interactive

2013-05-21 Thread Jiang Xin
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

  1   2   >