W. Trevor King wk...@tremily.us 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
that the project s/he is interacting with may prefer rebase
On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
Am 26.06.2013 23:03, schrieb Junio C Hamano:
Fredrik Gustafsson iv...@iveqy.com writes:
On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
Used
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
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
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 fail
On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
W. Trevor King wk...@tremily.us 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
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
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
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
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
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 artag...@gmail.com
+ __git_complete_index_file
With or
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
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 integrator'
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 between the
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 'hidden' refs
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
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_status ()
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
On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
W. Trevor King wk...@tremily.us 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
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de 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).
$
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).
The
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
+++
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 expected
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
---
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:
Helped-by: SZEDER Gábor sze...@ira.uka.de
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 27 +++
1 file changed, 27 insertions(+)
diff --git a/contrib/completion/git-completion.bash
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
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
---
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,
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
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 artag...@gmail.com
---
Makefile | 3 ---
fixup-builtins | 16
2 files changed, 19 deletions(-)
delete mode
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
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 want
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 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 specify the
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 must
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de 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
SZEDER Gábor sze...@ira.uka.de 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
The configure option to disable threading is '--disable-pthreads',
not '--without-pthreads'.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index f3462d9..2f43393 100644
John Keeping j...@keeping.me.uk 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
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 probably
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net 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,
On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Stefano Lattarini stefano.lattar...@gmail.com writes:
The configure option to disable threading is '--disable-pthreads',
not '--without-pthreads'.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Thanks.
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Jens Lindstrom j...@opera.com 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
Petr Baudis pa...@ucw.cz writes:
Signed-off-by: Petr Baudis pa...@ucw.cz
---
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`.
Heiko Voigt hvo...@hvoigt.net 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
Jeff King p...@peff.net 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
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
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
Petr Baudis pa...@ucw.cz 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
Olivier de Broqueville olivier.debroquevi...@gmail.com 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
Jeff King p...@peff.net 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
On Thu, Jun 27, 2013 at 8:10 PM, Junio C Hamano gits...@pobox.com 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
On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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.
-
Hi Sebastian,
On Fri, 28 Jun 2013, Sebastian Schuberth wrote:
On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -97,7 +97,7 @@ do
if test $? -ne 0
then
echo
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano gits...@pobox.com wrote:
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 8:44 AM, Max Horn m...@quendi.de 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
Junio C Hamano gits...@pobox.com 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,
Sebastian Schuberth sschube...@gmail.com writes:
On Thu, Jun 27, 2013 at 8:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
John Szakmeister j...@szakmeister.net writes:
On Fri, Jun 28, 2013 at 1:13 PM, Junio C Hamano gits...@pobox.com 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
Am 28.06.2013 20:44, schrieb Junio C Hamano:
Heiko Voigt hvo...@hvoigt.net 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
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 .
./configure
Junio C Hamano gits...@pobox.com writes:
Petr Baudis pa...@ucw.cz 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)
Fredrik Gustafsson iv...@iveqy.com 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
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.
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
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:
John Keeping j...@keeping.me.uk 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
Jens Lehmann jens.lehm...@web.de writes:
Am 28.06.2013 20:44, schrieb Junio C Hamano:
Heiko Voigt hvo...@hvoigt.net 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
On Fri, Jun 28, 2013 at 03:51:41PM -0700, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
Am 28.06.2013 20:44, schrieb Junio C Hamano:
Heiko Voigt hvo...@hvoigt.net writes:
...
Hmm, but does it have a --depth option for revisions? Maybe we should
call it --clone-depth
On Fri, Jun 28, 2013 at 2:06 PM, Melton Low (devl) softw.d...@gmail.com 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
71 matches
Mail list logo
