On 10/24/2013 11:11 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> ...
>> Signed-off-by: Michael Haggerty
>
> Everything in the proposed log message made sense to me.
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index d4d93c9..83c1700 100644
>> --- a/Docu
On Sat, Oct 26, 2013 at 09:09:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> Jeff, how about this?
>
> It's similar to your last suggestion (i.e. relaxing the magic mask
> about literal magic). In addition, it forces literal magic
> unconditionally in this case, which I think is the right thing
On Fri, Oct 25, 2013 at 08:26:29PM -0400, Jeff King wrote:
> On Fri, Oct 25, 2013 at 04:06:19PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > diff --git a/pack-bitmap.c b/pack-bitmap.c
> > > new file mode 100644
> > > index 000..73c52fd
> > > --- /dev/null
> > > +++ b/pack-
On 10/24/2013 10:51 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> diff --git a/Documentation/fetch-options.txt
>> b/Documentation/fetch-options.txt
>> index ba1fe49..0e6d2ac 100644
>> --- a/Documentation/fetch-options.txt
>> +++ b/Documentation/fetch-options.txt
>> @@ -61,11 +61,9 @@ en
Thanks for taking care of this! Maybe John or I can finally get the
changes to rebase done after this.
A few comments below. Sorry I didn't find time to review the earlier revisions.
On Fri, Oct 25, 2013 at 2:38 PM, Junio C Hamano wrote:
> +
> +where `origin/master` used to point at commits B3,
In git 1.7.0.4, what's the correct way to preview what a "git pull"
would do, without actually doing it? Unlike most git subcommands,
pull seems not to understand --dry-run:
$ git pull --dry-run
sed: can't read {pathname suppressed}/.git/FETCH_HEAD: No such file or directory
You asked to pull fro
Milton Soares Filho writes:
> On 25 October 2013 15:13, Junio C Hamano wrote:
>> Milton Soares Filho writes:
>>
>>> git log --graph --oneline
>>> * a1
>>> * a2
>>> x a3
>>> * b1
>>> * b2
>>> x b3
>>
>> I agree that the problem you are trying to solve is a good thing t
Normally parse_pathspec() is used on command line arguments where it
can do fancy thing like parsing magic on each argument or adding magic
for all pathspecs based on --*-pathspecs options.
There's another use of parse_pathspec(), where pathspec is needed, but
the input is known to be pure paths.
Normally parse_pathspec() is used on command line arguments where it
can do fancy thing like parsing magic on each argument or adding magic
for all pathspecs based on --*-pathspecs options.
There's another use of parse_pathspec(), where pathspec is needed, but
the input is known to be pure paths.
On Fri, Oct 25, 2013 at 04:06:19PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > diff --git a/pack-bitmap.c b/pack-bitmap.c
> > new file mode 100644
> > index 000..73c52fd
> > --- /dev/null
> > +++ b/pack-bitmap.c
> > @@ -0,0 +1,965 @@
> > +#include
> > +
> > +#include "cache.h"
>
No, the .git/hooks directory in your clone is created from your local
templates, installed with your Git distribution, not the remote hooks.
On Linux distributions, these templates are often in someplace like
/usr/share/git-core/templates (for normal packages), and on Windows
with msysgit they are
[git-scm.com/community doesn't say whether the address for bug reports
allows posting by non-list members, so hopefully this makes it through
the moderation process]
I'm building git 1.8.4.1 on x86_64-pc-solaris2.11 (OpenIndiana 151a8,
one of the opensource distributions that came out of the Ope
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Jeff King writes:
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> new file mode 100644
> index 000..73c52fd
> --- /dev/null
> +++ b/pack-bitmap.c
> @@ -0,0 +1,965 @@
> +#include
> +
> +#include "cache.h"
You among all people already know why this is bad, no?
I'll remove the first two lines
Nicolas Vigier writes:
> On Fri, 25 Oct 2013, Junio C Hamano wrote:
>
>> Nicolas Vigier writes:
>>
>> > Add the --sticked-long option to output the options in their long form
>> > if available, and with their arguments sticked.
>>
>> Hmph, doesn't verb "stick" conjugate to "(present) stick (pa
On Fri, 25 Oct 2013, Junio C Hamano wrote:
> Nicolas Vigier writes:
>
> > Add the --sticked-long option to output the options in their long form
> > if available, and with their arguments sticked.
>
> Hmph, doesn't verb "stick" conjugate to "(present) stick (past) stuck
> (pp) stuck"?
Ah, yes
But when someone do a "clone" he don't have .git/hooks directory
downloaded to his local computer ? I thought so ...
2013/10/26 Junio C Hamano :
> Olivier Revollat writes:
>
>> I was wondering : What if I had a "malicious" GIT repository who can
>> "inject" code via git hooks mechanism : someone
Olivier Revollat writes:
> I was wondering : What if I had a "malicious" GIT repository who can
> "inject" code via git hooks mechanism : someone clone my repo and
> some malicious code is executed when a certain GIT hook is triggered
> (for example on commit ("prepare-commit-msg' hook))
In tha
I was wondering : What if I had a "malicious" GIT repository who can
"inject" code via git hooks mechanism : someone clone my repo and
some malicious code is executed when a certain GIT hook is triggered
(for example on commit ("prepare-commit-msg' hook)) ? What if I email
/etc/passwd for exemple
Nicolas Vigier writes:
> Add the --sticked-long option to output the options in their long form
> if available, and with their arguments sticked.
Hmph, doesn't verb "stick" conjugate to "(present) stick (past) stuck
(pp) stuck"?
--
To unsubscribe from this list: send the line "unsubscribe git" i
On Fri, Oct 25, 2013 at 5:38 PM, Junio C Hamano wrote:
> diff --git a/Documentation/git-merge-base.txt
> b/Documentation/git-merge-base.txt
> index 87842e3..b383766 100644
> --- a/Documentation/git-merge-base.txt
> +++ b/Documentation/git-merge-base.txt
> @@ -137,6 +143,31 @@ In modern git, you c
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example
On Fri, Oct 25, 2013 at 03:17:06AM -0400, Jeff King wrote:
> I think that makes sense. Would you also want to suppress the probe
> request in that case? It serves the same purpose, but would cause you to
> do an extra auth for no reason (which potentially means user input,
> which is annoying).
I
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
Hist
On 25 October 2013 15:13, Junio C Hamano wrote:
> Milton Soares Filho writes:
>
>> git log --graph --oneline
>> * a1
>> * a2
>> x a3
>> * b1
>> * b2
>> x b3
>
> I agree that the problem you are trying to solve is a good thing to
> tackle, and I also agree that marking
Add the --sticked-long option to output the options in their long form
if available, and with their arguments sticked.
Contrary to the default form (non sticked arguments and short options),
this can be parsed unambiguously when using options with optional
arguments :
- in the non sticked form,
Milton Soares Filho writes:
> git log --graph --oneline
> * a1
> * a2
> x a3
> * b1
> * b2
> x b3
I agree that the problem you are trying to solve is a good thing to
tackle, and I also agree that marking a root commit differently from
other commits is one way to solve
Johannes Sixt writes:
>> +for count in 1 2 3 4 5
>> +do
>> +git merge-base --reflog base $(cat derived$count) >actual &&
>> +test_cmp expect$count actual || break
>> +done &&
>
> This does not work as intended because the exit code of 'break' is always
> zero.
Jeff King writes:
> 3. Teach add--interactive to recognize the empty tree sha1 as an
> "unstage" path.
>
> I kind of like (3). At first glance, it is wrong; we will also treat
> "git reset -p $(git hash-object -t tree /dev/null)" as if "HEAD" had
> been passed. But if you are explicitly pa
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
Hist
Hello,
Basically doing: git describe --abbrev=0 gives the closest tag
from
I would expect adding "--contains" option would give the closest tag
containing but it seems that --abbrev=0 has no more effect in
that case:
$ git describe --tags --contains --abbrev=0
7f285fa78d4b81b8458f05e77fb6b462
On 10/24/2013 10:51 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Previously, fetch's "--tags" option was considered equivalent to
>> specifying the refspec "refs/tags/*:refs/tags/*" on the command line;
>> in particular, it caused the remote..refspec configuration to be
>> ignored.
>
On Thu, Oct 24, 2013 at 6:04 PM, Jeff King wrote:
> For bitmaps to be used, the following must be true:
>
> 1. We must be packing to stdout (as a normal `pack-objects` from
> `upload-pack` would do).
>
> 2. There must be a .bitmap index containing at least one of the
> "have" objects
On Thu, Oct 24, 2013 at 6:06 PM, Jeff King wrote:
> Note that most of the time we spend for --count invocations is on
> generating the pack revindex. It may be worth storing a revidx (either
> in a separate file, as part of the .idx, or as an optional section in
> the .bitmap file).
This was disc
On Thu, Oct 24, 2013 at 6:03 PM, Jeff King wrote:
> If `prepare_bitmap_walk` runs successfully, the resulting bitmap is
> stored and the equivalent of a `traverse_commit_list` call can be
> performed by using `traverse_bitmap_commit_list`; the bitmap version
> of this call yields the objects strai
On Fri, Oct 25, 2013 at 3:21 AM, Jeff King wrote:
> [+cc spearce; sorry, I really should have cc'd the whole series to you
> in the first place]
>
> On Fri, Oct 25, 2013 at 08:16:18AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > + - A header appears at the beginning:
>> > +
>> > +
Jeff King peff.net> writes:
> On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:
>
> > however I can't find a way to have the repository's configuration
> > saved and transmited with the repository in a way similar to how
> > .gitignore is transmitted...
> > [...]
> Two, the config i
Dear account owner
Your mailbox has exceeded the set storage limit which is 20GB.
You are currently running on 19.8GB due to hidden files and folder on
your mailbox.
Your email account would be blocked from sending and receiving emails
if your email account is not verified with in 48hrs.
You are
(Jonathan, sorry if you got this multiple times, it seems I forgot to Cc list)
On Mon, Oct 21, 2013 at 8:40 PM, Jonathan Nieder wrote:
> Should the git-diff(1) manpage get a note about this setting as
> well (perhaps in a new CONFIGURATION section)?
I'll add a reference to the documentation for
We offer Funds/ money to all in need at very low interest rate 3% no collateral
involved we will be able to give you any amount ranging from $ 5,000-$
5,000,000 interest rate negotiable, with repayment allowed from 1-20 years if
interested contact us now via email (misglorialoanf...@gmail.com)
-
On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:
> however I can't find a way to have the repository's configuration
> saved and transmited with the repository in a way similar to how
> .gitignore is transmitted...
> [...]
> Knowing how mature git is I can only assume that this has a
Am 10/25/2013 10:09, schrieb John Keeping:
> On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
>> You could put the loops into a function from which you 'return', but that
>> is obscure in this case. The first iteration was better, IMO.
>
> Wouldn't it be simpler to just return from t
On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
> Am 10/25/2013 0:21, schrieb Junio C Hamano:
> > +test_expect_success 'using reflog to find the fork point' '
> > + git reset --hard &&
> > + git checkout -b base $E &&
> > +
> > + for count in 1 2 3 4 5
> > + do
> > +
On Thu, Oct 17, 2013 at 08:47:05AM -0700, Junio C Hamano wrote:
> > In general, I don't think we know enough about patterns of recovery
> > corruption to say which commands would definitely be worth implementing.
> > Part of the reason I wrote this up is to document this one case. But
> > this is
On Fri, Oct 25, 2013 at 9:10 AM, Jeff King wrote:
> On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
>> 1. Split the input on the first '/' into $remote/$branch, and use the
>> preceding part ($remote) as a potential remote name, and the following
>> part ($branch) as a potential br
On Mon, Oct 21, 2013 at 07:06:29PM +0200, arnaud brejeon wrote:
> I dont know if you plan to keep GIT_ASKPASS as is, but this
> environment variable is not mentioned on git svn documentation and I
> guess just a few people know about it. Moreover, the name is
> misleading as it handles all the pro
On Wed, Oct 23, 2013 at 10:56:32PM +, brian m. carlson wrote:
> On Tue, Oct 22, 2013 at 08:21:48PM -0700, Shawn Pearce wrote:
> > From my perspective, it is OK to defaulting to use 100-continue if the
> > server supports Negotiate. If the user is stuck behind a broken proxy
> > and can't authe
Am 10/25/2013 0:21, schrieb Junio C Hamano:
> +test_expect_success 'using reflog to find the fork point' '
> + git reset --hard &&
> + git checkout -b base $E &&
> +
> + for count in 1 2 3 4 5
> + do
> + git commit --allow-empty -m "Base commit #$count" &&
> +
Hello everybody
I am looking into the git configuration mechanism and there seem to
be a "hole" in use cases I'm trying to figure out...
git configurations can be saved at various places
* /etc/gitconfig : system-wide configuration
* ~/.gitconfig : user-wide configuration
* .git/config : repos
On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
> Actually, I don't think there's much refspec stuff to be done here.
> When running "git diff $remote/$branch", there are 3 possible
> outcomes:
>
> - $remote is not a valid remote name, the user probably meant
> something different
On Fri, Oct 25, 2013 at 8:14 AM, Jeff King wrote:
> On Fri, Oct 25, 2013 at 02:14:07AM -0400, Jeff King wrote:
>> > Could this error message be improved for interactive commands by
>> > first checking to see whether or not the path starts with a remote,
>> > then recommend that the remote be p
51 matches
Mail list logo
