On Fri, Jun 28, 2013 at 2:06 PM, Melton Low (devl) wrote:
> Hi,
>
> Did you do a "sudo make install" as the last step?
>
> As a general rule of thumb on OS X, don't update or otherwise do anything to
> stuff installed by Apple. You have to install the newer version from the
> Git repository to a
On Fri, Jun 28, 2013 at 03:51:41PM -0700, Junio C Hamano wrote:
> Jens Lehmann writes:
>
> > Am 28.06.2013 20:44, schrieb Junio C Hamano:
> >> Heiko Voigt writes:
> >> ...
> >>> Hmm, but does it have a --depth option for revisions? Maybe we should
> >>> call it --clone-depth or --rev-depth to m
Jens Lehmann writes:
> Am 28.06.2013 20:44, schrieb Junio C Hamano:
>> Heiko Voigt writes:
>> ...
>>> Hmm, but does it have a --depth option for revisions? Maybe we should
>>> call it --clone-depth or --rev-depth to make it clear? --depth and
>>> --max-depth would be completely orthogonal but t
John Keeping writes:
>> Here, "git pull . branch1" is merely saying "I want to integrate
>> the work on my current branch with that of branch1" without saying
>> how that integration wants to happen.
>
> The change that I think is important is that the "bring my branch
> up-to-date" operation sho
The latest maintenance release Git v1.8.3.2 is now available at the
usual places. It contains fixes that have already been applied to
the 'master' branch for 1.8.4.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4a6585dd81
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test "setup a submodule
tree" had to be modified. Also did some indent
Fredrik Gustafsson writes:
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index a4ffea0..b2d0f0e 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -31,8 +31,9 @@ test_expect_success 'setup a submodule tree' '
> git clone super re
Apparently due to a newly added test at the end of t7400 this patch doesn't
apply cleanly to neither pu, next nor master for me. But it addresses all
issues raised in the first round.
Am 28.06.2013 15:22, schrieb Fredrik Gustafsson:
> When a submodule is clone, clone it width the --depth flag. Thi
Junio C Hamano writes:
> Petr Baudis writes:
>
>> diff --git a/git-stash.sh b/git-stash.sh
>> index 1e541a2..3cb9b05 100755
>> --- a/git-stash.sh
>> +++ b/git-stash.sh
>> @@ -258,6 +262,12 @@ save_stash () {
>> say "$(gettext "No local changes to save")"
>> exit 0
>>
Hi,
Did you do a "sudo make install" as the last step?
As a general rule of thumb on OS X, don't update or otherwise do
anything to stuff installed by Apple. You have to install the newer
version from the Git repository to a different directory, eg /usr/local
or /usr/local/git .
./configur
Am 28.06.2013 20:44, schrieb Junio C Hamano:
> Heiko Voigt writes:
>
>> On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
>> ...
>>> Me too thinks adding "--depth" to "update" makes sense (and I don't
>>> think that this pretty generic name will become a problem later in
>>> case some
John Szakmeister writes:
> On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano wrote:
>>
>> An early part of nd/clone-connectivity-shortcut topic contains the
>> said commit, and I do not mind merging it to the maintenance track,
>> but I suspect that there is something else going on on your OS X
>>
Sebastian Schuberth writes:
> On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
> wrote:
>
>>> --- a/git-merge-octopus.sh
>>> +++ b/git-merge-octopus.sh
>>> @@ -97,7 +97,7 @@ do
>>> if test $? -ne 0
>>> then
>>> echo "Simple merge did not work, trying automatic merge
Junio C Hamano writes:
> I am perfectly fine with a change that allows a local clone to skip
> and not error out when such a "keep" marker cannot be copied, I do
> not know if it is a good idea to unconditionally skip and not even
> attempt to copy it.
That is, something like this, perhaps?
We
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano wrote:
> John Szakmeister writes:
>
>> On Fri, Jun 28, 2013 at 8:44 AM, Max Horn wrote:
>> [snip]
>
>>> I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1
>>> nor with current git maint. Command run inside /tmp, which is on
>>> a nor
Hi Sebastian,
On Fri, 28 Jun 2013, Sebastian Schuberth wrote:
> On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
> wrote:
>
> >> --- a/git-merge-octopus.sh
> >> +++ b/git-merge-octopus.sh
> >> @@ -97,7 +97,7 @@ do
> >> if test $? -ne 0
> >> then
> >> echo "Simple m
On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
wrote:
>> --- a/git-merge-octopus.sh
>> +++ b/git-merge-octopus.sh
>> @@ -97,7 +97,7 @@ do
>> if test $? -ne 0
>> then
>> echo "Simple merge did not work, trying automatic merge."
>> - git-merge-index -o gi
On Thu, Jun 27, 2013 at 8:10 PM, Junio C Hamano wrote:
>>> Now that I look at it more, I see that
>>> `git-mailinfo` was missed and there's a `git-apply` towards the
>>> bottom. So I'm not sure it's helping the consistency argument.
>>
>> Hmph, true.
>
> Having said that, I'd still prefer to se
Jeff King writes:
> Hmm. I would have thought --no-short would just set it to LONG. That is,
> we are no longer NONE at that point, as the user has told us something
> on the command line. So we are whatever --no-short is, which is LONG.
>
> But I guess that would wreck
>
> git status --no-shor
Olivier de Broqueville writes:
> Hello,
>
> I've learnt that Xcode installs git by default on the Mac. My current
> version of git is 1.7.12.4 and it's located in /usr/bin/git.
>
> I wanted to update git to the latest stable version available:
> 1.8.3.1. I proceeded with the instructions on:
> ht
Petr Baudis writes:
> diff --git a/git-stash.sh b/git-stash.sh
> index 1e541a2..3cb9b05 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -258,6 +262,12 @@ save_stash () {
> say "$(gettext "No local changes to save")"
> exit 0
> fi
> + if test -z "$untrac
Hello,
I've learnt that Xcode installs git by default on the Mac. My current
version of git is 1.7.12.4 and it's located in /usr/bin/git.
I wanted to update git to the latest stable version available:
1.8.3.1. I proceeded with the instructions on:
http://git-scm.com/downloads and typed:
git clon
On Fri, Jun 28, 2013 at 10:37:26AM -0700, Junio C Hamano wrote:
> > The final patch ended up folding that "-z" default logic into the
> > same function, so it probably is saner to remove UNSPECIFIED.
>
> Actually, the code needs to be able to differentiate between
>
> git status --no-short
Jeff King writes:
> So I think it is probably a good idea to remove it, but the
> justification is not "this is unused cruft", but more like:
>
> This script was added in 36e5e70 (Start deprecating "git-command" in
> favor of "git command", 2007-06-30) with the intent of aiding the
> transi
Heiko Voigt writes:
> On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
> ...
>> Me too thinks adding "--depth" to "update" makes sense (and I don't
>> think that this pretty generic name will become a problem later in
>> case someone wants to add a maximum recursion depth, as grep al
Petr Baudis writes:
> Signed-off-by: Petr Baudis
> ---
>
> Please Cc me, I'm currently not subscribed on the list.
Heh, long time no see.
> @@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch`
> mode.
> +
> The `--patch` option implies `--keep-index`. You can use
>
Jens Lindstrom writes:
Hmph. I am of two minds here.
> The pack-*.keep files are temporary, and serve no purpose in the
> clone.
They are not temporary, actually. A user can deliberatey create a
"keep" marker after packing with a good set of parameters, so that
the resulting pack will be kept
Stefano Lattarini writes:
> The configure option to disable threading is '--disable-pthreads',
> not '--without-pthreads'.
>
> Signed-off-by: Stefano Lattarini
> ---
Thanks.
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> i
On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> test_expect_success \
> >> 'merge-setup part 3' \
> >> -'git pull . branch1'
> >> +'git pull --merge . branch1'
> >
> > I think the "--merge" should be implied here because the suer has
> >
Junio C Hamano writes:
> Jeff King writes:
>
>> You lose the assertion that finalize_deferred_config has been called,
>> but I think the resulting code would be simpler, as it drops this
>> die("BUG") state entirely. Am I missing something?
>
> Probably not. Depending on "-z", NONE is sometimes
Jeff King wrote:
> This script was added in 36e5e70 (Start deprecating "git-command" in
> favor of "git command", 2007-06-30) with the intent of aiding the
> transition away from dashed forms. However, nobody is really working
> on that transition, and even if they did, this tool will proba
John Keeping writes:
>> test_expect_success \
>> 'merge-setup part 3' \
>> -'git pull . branch1'
>> +'git pull --merge . branch1'
>
> I think the "--merge" should be implied here because the suer has
> specified an explicit remote and branch.
The whole point of the topic is "It use
The configure option to disable threading is '--disable-pthreads',
not '--without-pthreads'.
Signed-off-by: Stefano Lattarini
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index f3462d9..2f43393 100644
--- a/configure.ac
+++ b/co
SZEDER Gábor writes:
> On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote:
>> The merged result is ok!
>
> Yeah, it look good, thanks.
Thanks, both, for double checking (and thank you for preparing the
pre-merged results).
--
To unsubscribe from this list: send the line "unsubscr
John Szakmeister writes:
> On Fri, Jun 28, 2013 at 8:44 AM, Max Horn wrote:
> [snip]
>> I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1
>> nor with current git maint. Command run inside /tmp, which is on
>> a normal HFS+ volume (using the default settings, i.e. the FS is
>> ca
On Fri, Jun 28, 2013 at 06:44:40PM +0200, Fredrik Gustafsson wrote:
> On Fri, Jun 28, 2013 at 12:31:53PM -0400, Jeff King wrote:
> > It's possible to have an "optional" argument by using the
> > PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the
> > user's perspective, as they
On Fri, Jun 28, 2013 at 12:31:53PM -0400, Jeff King wrote:
> It's possible to have an "optional" argument by using the
> PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the
> user's perspective, as they must use the "sticked" form:
>
> git format-patch -ooutdir ...
>
> to sp
On Fri, Jun 28, 2013 at 09:16:19PM +0530, Ramkumar Ramachandra wrote:
> The fixup-builtins script is only used by an unused remove-dashes target
> in the Makefile: remove that along with the script.
I am not sure of this justification. If you read the commit message from
36e5e70, which introduced
On Fri, Jun 28, 2013 at 06:05:00PM +0200, Fredrik Gustafsson wrote:
> I don't quite manage to figure out gits argv parsing and would need some
> help on the way.
>
> I want:
> git format-patch -o outdir HEAD~
>
> Work exactly the way it does now, setting output_directory to outdir.
> But I also
Hi,
I don't quite manage to figure out gits argv parsing and would need some
help on the way.
I want:
git format-patch -o outdir HEAD~
Work exactly the way it does now, setting output_directory to outdir.
But I also want
git format-patch -o HEAD~
to set output_directory with a NULL value so that
The fixup-builtins script is only used by an unused remove-dashes target
in the Makefile: remove that along with the script.
Signed-off-by: Ramkumar Ramachandra
---
Makefile | 3 ---
fixup-builtins | 16
2 files changed, 19 deletions(-)
delete mode 100755 fixup-builtins
I have been recently again bitten by git stash versus an uncommitted
file-to-directory change that happily threw away few gigabytes of my
data. This has been recently discussed in the past, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/202332/
and I implemented Junio's sugge
The pack-*.keep files are temporary, and serve no purpose in the
clone. They would probably also never be deleted from the clone if
copied, since the process that created them only expects to have to
delete them from the original repository.
Worse, though, they are created with access bits 0600,
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 14 ++
1 file changed, 14 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 278018f..f2959a7 100644
--- a/contrib/completion/git-completion
Helped-by: SZEDER Gábor
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 27 +++
1 file changed, 27 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b51c9e3..278018f 100644
-
git-completion.zsh looks in various "default" locations for
git-completion.bash. During development, the location
$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
is the most obvious and up-to-date version. Push it up on the list of
locations.
Signed-off-by: Ramkumar Ramachandra
---
Hi,
An older iteration of [2/4] was just reviewed by SZEDER on the list.
[1/4] and [3/4] have been sent out in the past, but haven't been
picked up. [4/4] is new.
Thanks.
Ramkumar Ramachandra (4):
completion: complete rebase --edit-todo
completion: add completer for status
completion: add
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 6c3bafe..b51c9e3 100644
--- a/contrib/completion/git-completion.bash
+++ b/
Excerpts from Junio C Hamano's message of Thu Jun 27 13:52:33 -0700 2013:
> Two issues here, which I'll locally amend (no need to resend):
Great! Thank you for your help and patience.
> cat >expected <<-EOF &&
> pick ...
> ...
> EOF
> test_cmp expe
On Fri, Jun 28, 2013 at 06:50:02PM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > diff --git a/contrib/completion/git-completion.bash
> > b/contrib/completion/git-completion.bash
> > index 912fb988..b68024c6 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/co
Ramkumar Ramachandra wrote:
>> + __git_complete_index_file "--with-tree=HEAD --cached --deleted"
>
> Might as well go all the way with "--cached --deleted --unmerged
> --others" no? What is the point of --with-tree=HEAD?
Ugh, --deleted doesn't work as advertised (terrible documentation).
T
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn wrote:
[snip]
> I am unable to reproduce this on Mac OS X 10.7.5 with git 1.8.3.1 nor with
> current git maint. Command run inside /tmp, which is on a normal HFS+ volume
> (using the default settings, i.e. the FS is case insensitive).
>
>
> $ git --versi
On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
> "W. Trevor King" writes:
> > I want the warning that they had not made the required config choice
> > between rebase/merge needed to handle a non-ff case, not the default
> > merge (or rebase) behavior. The warning gives them a chanc
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test "setup a submodule
tree" had to be modified. Also did some indent
SZEDER Gábor wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 912fb988..b68024c6 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1697,6 +1697,8 @@ _git_stage ()
>
> _git_statu
On 27.06.2013, at 12:17, John Szakmeister wrote:
> I wanted to look at some OpenWRT bits this morning and ran into an
> issue cloning the packages repository when setting up the package
> feed. The feeds script executes this under the hood:
>
> git clone --depth 1 git://nbd.name/packages.git
Am 28.06.2013 14:18, schrieb Fredrik Gustafsson:
> On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:
>> Hi there!
>>
>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
>> or a tag (from refs/tags/) ?
>>
>> Background: At $dayjob we're using some kind of 'hid
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:
> Hi there!
>
> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
> or a tag (from refs/tags/) ?
>
> Background: At $dayjob we're using some kind of 'hidden' refs (in
> refs/releases/)
> to communicate betwe
Am 28.06.2013 13:59, schrieb Stefan Näwe:
> Hi there!
>
> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
> or a tag (from refs/tags/) ?
>
> Background: At $dayjob we're using some kind of 'hidden' refs (in
> refs/releases/)
> to communicate between the 'branch inte
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the '
"W. Trevor King" writes:
> On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
>> "W. Trevor King" writes:
>>
>> > Or they may not even realize that they've just merged an unrelated
>> > branch at all, dragging in a thousand unrelated commits which they
>> > accidentally push to a cent
On Fri, Jun 28, 2013 at 12:56:01PM +0200, SZEDER Gábor wrote:
> On Fri, Jun 28, 2013 at 12:29:36PM +0200, SZEDER Gábor wrote:
> > On Mon, Jun 24, 2013 at 10:52:55PM +0530, Ramkumar Ramachandra wrote:
> > > Signed-off-by: Ramkumar Ramachandra
> > > + __git_complete_index_file
> >
> > With or witho
On Fri, Jun 28, 2013 at 12:29:36PM +0200, SZEDER Gábor wrote:
> On Mon, Jun 24, 2013 at 10:52:55PM +0530, Ramkumar Ramachandra wrote:
> > Signed-off-by: Ramkumar Ramachandra
> > + __git_complete_index_file
>
> With or without this change we can't ask for the status of a certain
> deleted file:
Hi,
On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote:
> This allows the user some finer grained control over how the update is
> done. The primary motivation for this was interoperability with stgit
> however being able to intercept the submodule update process may prove
> useful for
Hi,
On Mon, Jun 24, 2013 at 10:52:55PM +0530, Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra
> ---
> contrib/completion/git-completion.bash | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib
Am 28.06.2013 11:53, schrieb Chris Packham:
> This allows the user some finer grained control over how the update is
> done. The primary motivation for this was interoperability with stgit
> however being able to intercept the submodule update process may prove
> useful for integrating or extending
This allows the user some finer grained control over how the update is
done. The primary motivation for this was interoperability with stgit
however being able to intercept the submodule update process may prove
useful for integrating or extending other tools.
Signed-off-by: Chris Packham
--
Hi,
Hi,
On Thu, Jun 27, 2013 at 10:31:57PM -0300, Eduardo R. D'Avila wrote:
> The merged result is ok!
Yeah, it look good, thanks.
Gábor
--
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.kern
On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
> "W. Trevor King" writes:
> > On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> >> Because letting a trivial merge automatically handled by Git is so
> >> easy with "git pull", a person who is new to Git may not realize
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow. Add a safety valve to
Hi Junio, I don't think you've picked this up. Are you expecting a
re-roll or did it just get lost in the noise?
On Sat, Jun 22, 2013 at 12:25:17PM +0100, John Keeping wrote:
> git-completion.bash's parsing of the command name relies on everything
> preceding it starting with '-' unless it is the
Hello,
On the git-svn(1) man page, the third example in the "Basic Examples"
section discusses how one can speed up the initial clone of a
Subversion repository by cloning it from Git first and linking it to
Subversion afterwards. However, it seems this example is not correct. I
have had several p
72 matches
Mail list logo
