On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge
On 4/21/2014 3:24 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Ilya Bobyr wrote:
test_expect_success 'setup'
mkdir -p .git/hooks
cat .git/hooks/update-branch -\\EOF
#!/bin/sh
Charles Bailey wrote:
On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
[...]
diff --git a/branch.c b/branch.c
index 660097b..c2058d1 100644
--- a/branch.c
+++ b/branch.c
@@ -4,6 +4,7 @@
#include refs.h
#include remote.h
#include commit.h
+#include run-command.h
struct tracking {
struct refspec
On 4/21/2014 1:49 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
This hook is invoked whenever a branch is updated, either when a branch
is created or updated with 'git branch', or when it's rebased with 'git
rebase'. It receives two parameters;
Ilya Bobyr wrote:
On 4/21/2014 3:24 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Ilya Bobyr wrote:
test_expect_success 'setup'
mkdir -p .git/hooks
cat .git/hooks/update-branch -\\EOF
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
Was the merge successful? [y/n]
Does this happen now even with merge tools for which we do trust the
exit code? If so, my original
On 4/21/2014 11:45 PM, Felipe Contreras wrote:
[...]
This is how it is suggested by t/README and how it is done in the other
test suites.
I can not see how your case is different, but I might be missing something.
Let's take a cursoy look at `git grep -l 'EOF' t`.
[...]
So the point is
Charles Bailey wrote:
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
Was the merge successful? [y/n]
Does this happen now even with merge tools for which we do trust the
Ilya Bobyr wrote:
On 4/21/2014 11:45 PM, Felipe Contreras wrote:
[...]
This is how it is suggested by t/README and how it is done in the other
test suites.
I can not see how your case is different, but I might be missing
something.
Let's take a cursoy look at `git grep -l 'EOF' t`.
Michael Haggerty mhag...@alum.mit.edu writes:
STRBUF_OWNS_MEMORY
The memory pointed to by buf is owned by this strbuf. If this
bit is not set, then the memory should never be freed, and
(among other things) strbuf_detach() must always call xstrcpy().
I just
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ (slightly), hindering interoperability.
I am afraid
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The problem is that between git rm and git mv, if we default git
cp to mean cherry-pick there could easily be user confusion.
I'm not sure that cherry-pick is used that often it really needs a two
character
On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote:
Charles Bailey wrote:
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
Was the merge successful? [y/n]
Charles Bailey wrote:
On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote:
Charles Bailey wrote:
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
It looks like the documentation for bitmaps is being included in the
1.9.2 release of Git for Windows but the functionality itself is not
present. For example, doc\git\html\git-config.html includes settings
like these:
pack.useBitmaps
When true, git will use pack bitmaps (if available) when
This patches add `--run` option to the test suites to allow one to run
individual tests out of the test suite. Like this:
./t-basic.sh --run='-4,7,9-12,15-'
Both spaces and commas are accepted as separators for the ranges (In
previous versions only spaces were accepted).
Two previous
Most arguments that could be provided to a test have short forms.
Unless documented, the only way to learn them is to read the code.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
t/README |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/README b/t/README
Allow better control of the set of tests that will be executed for a
single test suite. Mostly useful while debugging or developing as it
allows to focus on a specific test.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
t/README | 73 +++-
t/t-basic.sh | 356
We used to show (missing ) next to tests skipped because they are
specified in GIT_SKIP_TESTS. Use (GIT_SKIP_TESTS) instead.
Plus tests that check basic GIT_SKIP_TESTS functions.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
t/t-basic.sh | 63
Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ (slightly), hindering
Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
The problem is that between git rm and git mv, if we default git
cp to mean cherry-pick there could easily be user confusion.
I'm not sure that cherry-pick is used that often
On 04/21/2014 10:24 PM, Jeff King wrote:
On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
STRBUF_OWNS_MEMORY
The memory pointed to by buf is owned by this strbuf. If this
bit is not set, then the memory should never be freed, and
(among other things)
As part of my work to help get git-p4 close to bug-free before Git
2.0, I'm posting all bugs and patches to this mailing list. Please
direct me elsewhere if this is incorrect.
When trying to clone a particular directory from a depot, that
contains one or more branches that contain no commits for
Hi Pete,
I should have updated on this earlier, but I wished to refine my work
on this feature before submitting. With 2.0 looming I'll submit
what's there so far.
There is a patch viewable at this link:
https://github.com/Stealthii/git/commit/f7a2e611262fd977ac99e066872d3d0743b7df3c
For the
Am 17.04.2014 07:51, schrieb Nguyễn Thái Ngọc Duy:
This patch serves as a heads up about a feature I'm working on. I hope
that by posting it early, people could double check if I have made
some fundamental mistakes that completely ruin the idea. It's about
speeding up git status by caching
On Sun, Apr 20, 2014 at 9:46 PM, Jeff King p...@peff.net wrote:
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has changed. This is only enabled for
1-line changes.
See
Junio C Hamano gits...@pobox.com writes:
This is not wrong per-se, but I am not sure if translators would
understand that years and months ago may not be the longuest
variant for their language and they are asked to use 89 seconds
ago if the translation of that is longer than the translation
On Tue, Apr 22, 2014 at 4:56 PM, Karsten Blees karsten.bl...@gmail.com wrote:
Am 17.04.2014 07:51, schrieb Nguyễn Thái Ngọc Duy:
This patch serves as a heads up about a feature I'm working on. I hope
that by posting it early, people could double check if I have made
some fundamental mistakes
On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
So perhaps the rule should be updated to do something like:
- find candidate tags that can be used to describe --contains
the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
- among the candidate tags, cull the ones that
On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen pclo...@gmail.com wrote:
IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so hopefully
you did a dummy 'cache_name_exists(anything)' before starting the
measurement of the first run?
No I didn't. Thanks for pointing it out. I'll see
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
The whole point of the change is to *allow* strbuf to be used in
performance-critical stuff.
OK. It should not make the current use of strbuf any harder anyway.
In your proposal, would
On Apr 18, 2014, at 12:37, Junio C Hamano wrote:
An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
I have run into the following test failures with v2.0.0-rc0:
Test Summary Report
---
t9117-git-svn-init-clone.sh (Wstat: 256
On 4/22/2014 12:26 AM, Felipe Contreras wrote:
Marius Storm-Olsen wrote:
Turns out the osocas.2014.sgizmo.com survey subdomain gives an SSL
warning for the *.sgizmo.com certificate. *face palm*
Feel free to use
http://bit.ly/OSOCAS2014
instead, which will redirect to the non-subdomain
2014-04-22 18:01 GMT+08:00 David Kastrup d...@gnu.org:
Junio C Hamano gits...@pobox.com writes:
This is not wrong per-se, but I am not sure if translators would
understand that years and months ago may not be the longuest
variant for their language and they are asked to use 89 seconds
ago if
On Wed, Apr 16, 2014 at 7:19 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Erik Faye-Lund kusmab...@gmail.com writes:
So let's manually check for these in that case, and fall back to
the File::Spec-helper on other platforms (e.g Win32 with native
Perl)
2014-04-22 3:19 GMT+08:00 Junio C Hamano gits...@pobox.com:
Junio C Hamano gits...@pobox.com writes:
What I am wondering is if we can do something
like this:
...
Nah, that is a lot more stupid than just doing
In code:
blame_date_width = strtoul(_(4 years, 11 months ago),
Hi,
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation required to make
sure that the MSVC support of the msysGit project works.
Hi Marat,
On Tue, 22 Apr 2014, Marat Radchenko wrote:
Johannes says building mingw64 Git is dirt-easy.
Marat, please let's stop misquoting me, okay?
What I said was more along the lines that there had been some start of a
work on getting things to compile for 64-bit Windows, but that the test
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation required to make
sure that the MSVC
Changes since V3:
* rollback patch 2/2 to v2, but with a nicer comment for translators.
Jiang Xin (2):
bugfix: fix broken time_buf paddings for git-blame
blame: dynamic blame_date_width for different locales
builtin/blame.c | 30 ++
1 file changed, 22
Command `git blame --date relative` aligns the date field with a
fixed-width (defined by blame_date_width), and if time_str is shorter
than that, it adds spaces for padding. But there are two bugs in the
following codes:
time_len = strlen(time_str);
...
memset(time_buf +
When show date in relative date format for git-blame, the max display
width of datetime is set as the length of the string Thu Oct 19
16:00:04 2006 -0700 (30 characters long). But actually the max width
for C locale is only 22 (the length of string x years, xx months ago).
And for other locale,
Felipe Contreras felipe.contre...@gmail.com writes:
Ilya Bobyr wrote:
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
Also, most have names that start with either pre- or post-.
It seems reasonable for both pre-update-branch and
post-update-branch to exist.
I don't
On Tue, Apr 22, 2014 at 04:59:17PM +0700, Duy Nguyen wrote:
On Sun, Apr 20, 2014 at 9:46 PM, Jeff King p...@peff.net wrote:
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has
Johannes Schindelin wrote:
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation required to make
sure that the MSVC support of the msysGit
Hi Felipe,
On Tue, 22 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation
Duy Nguyen wrote:
On Sun, Apr 20, 2014 at 9:46 PM, Jeff King p...@peff.net wrote:
On Sun, Apr 20, 2014 at 04:58:28PM +0700, Duy Nguyen wrote:
- --color-words within unified diff format, using background color to
show what part of the line has changed. This is only enabled for
1-line
Marat Radchenko wrote:
On Mon, Apr 21, 2014 at 07:06:24PM -0500, Felipe Contreras wrote:
I managed to fix all the errors, some apply to newer mingw, regardless of
32 or
64, others are specific to 64-bit. It's all hacky and I haven't checked if
it
runs, but at least it compiles
Ilya Bobyr wrote:
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
[...]
diff --git a/branch.c b/branch.c
index 660097b..c2058d1 100644
--- a/branch.c
+++ b/branch.c
@@ -4,6 +4,7 @@
#include refs.h
#include remote.h
#include commit.h
+#include run-command.h
struct
Ilya Bobyr wrote:
On 4/21/2014 1:49 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
On 4/20/2014 7:23 PM, Felipe Contreras wrote:
This hook is invoked whenever a branch is updated, either when a branch
is created or updated with 'git branch', or when it's rebased with 'git
rebase'. It
Stephen Leake wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Ilya Bobyr wrote:
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
Also, most have names that start with either pre- or post-.
It seems reasonable for both pre-update-branch and
Dan Porter dpr...@gmail.com writes:
I should have updated on this earlier, but I wished to refine my work
on this feature before submitting. With 2.0 looming I'll submit
what's there so far.
I am not Pete, but...
The pre-release time is to find and fix regressions that may have
been
Erik Faye-Lund kusmab...@gmail.com writes:
Shouldn't the latter also be anchored at the beginning of the string
with a leading ^?
+}
+
+require File::Spec::Functions;
+return File::Spec::Functions::file_name_is_absolute($path);
We already use File::Spec qw(something else) at
On 4/22/2014 9:31 AM, Felipe Contreras wrote:
Stephen Leake wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Ilya Bobyr wrote:
On 4/21/2014 2:17 PM, Felipe Contreras wrote:
Ilya Bobyr wrote:
Also, most have names that start with either pre- or post-.
It seems reasonable for both
David Aguilar dav...@gmail.com writes:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge resolution tool (foo):
Every
David Aguilar dav...@gmail.com writes:
On Sun, Apr 20, 2014 at 07:24:20PM -0500, Felipe Contreras wrote:
It's similar to the default, except that the other windows are hidden.
This ensures that removed/added colors are still visible on the main
merge window, but the other windows not visible.
David Aguilar dav...@gmail.com writes:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge resolution tool (foo):
Every
Ilya Bobyr wrote:
On 4/22/2014 9:31 AM, Felipe Contreras wrote:
Stephen Leake wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Yes, there a reason for the existance of those hooks. Now tell me why
would
anybody use post-update-branch instead of pre-update-branch?
I have
Michael Haggerty mhag...@alum.mit.edu writes:
While we're at it, I think it would be prudent to ban '-' at the
beginning of reference name segments. For example, reference names like
refs/heads/--cmd=/sbin/halt
refs/tags/--exec=forkbomb(){forkbomb|forkbomb};forkbomb
are currently
Andrew Ardill andrew.ard...@gmail.com writes:
As a data point, I have seen people add .gitignore to their
.gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its canonical ignore list, but until that
time,
Jan Kara j...@suse.cz writes:
On Thu 17-04-14 10:04:52, Junio C Hamano wrote:
So perhaps the rule should be updated to do something like:
- find candidate tags that can be used to describe --contains
the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
- among the
Sebastian Schuberth sschube...@gmail.com writes:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are again likely to differ
On 2014-04-22 13:38, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
While we're at it, I think it would be prudent to ban '-' at the
beginning of reference name segments. For example, reference names like
refs/heads/--cmd=/sbin/halt
This change is based on the previous ref transaction patches.
This is sent as a separate patch series since it implements a lot more
non-trivial changes to the behaviour than the previous patches and thus can
use more detailed review.
Update fetch.c to use ref transactions when performing
In s_update_ref there are two calls that when they fail we return an error
based on the errno value. In particular we want to return a specific error
if ENOTDIR happened. Both these functions do have failure modes where they
may return an error without updating errno, in which case a previous and
Change s_update_ref to use a ref transaction for the ref update.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/fetch.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/builtin/fetch.c
Change store_updated_refs to use a single ref transaction for all refs that
are updated during the fetch. This makes the fetch more atomic when update
failures occur.
Since ref update failures will now no longer occur in the code path for
updating a single ref in s_update_ref, we no longer have
Thanks! I still haven't gotten around to looking at svn:mergeinfo
things, but this passes tests so I'm inclined to merge this unless
somebody disagrees.
--
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
Jakob Stoklund Olesen stokl...@2pi.dk wrote:
Subversion can put mergeinfo on any sub-directory to track cherry-picks.
Since cherry-picks are not represented explicitly in git, git-svn should
just ignore it.
Hi, was git-svn trying to track cherry-picks as merge before?
This changes behavior a
Am 22.04.2014 12:35, schrieb Duy Nguyen:
On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen pclo...@gmail.com wrote:
IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so
hopefully you did a dummy 'cache_name_exists(anything)' before starting
the measurement of the first run?
No I
Kyle J. McKay wrote:
The problem with --prefix= is this (from the Getopt::Long CHANGES file):
Changes in version 2.37
---
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
The system I ran the tests
Ronnie Sahlberg sahlb...@google.com writes:
diff --git a/refs.c b/refs.c
index 138ab70..9daf89e 100644
--- a/refs.c
+++ b/refs.c
@@ -3414,12 +3414,12 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
const char *msg, enum action_on_err onerr)
...
Am 22.04.2014 00:08, schrieb Ronald Weiss:
On 18. 4. 2014 14:09, Jens Lehmann wrote:
Am 13.04.2014 00:49, schrieb Ronald Weiss:
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but
Ronnie Sahlberg sahlb...@google.com writes:
@@ -3481,6 +3481,14 @@ cleanup:
unlock_ref(updates[i]-lock);
free(delnames);
ref_transaction_free(transaction);
+ if (ret) {
+ const char *str = Cannot commit transaction.;
+ switch
Junio C Hamano wrote:
Sebastian Schuberth sschube...@gmail.com writes:
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote:
If we don't standardize this now people will come up with their own
definitions [1] [2] (and many others if you just search GitHub) which
are
Ronnie Sahlberg sahlb...@google.com writes:
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref transaction API. There
are still three more places where write_ref_sha1() is called from outside
of refs.c but those all
Luis R. Rodriguez mcg...@do-not-panic.com writes:
From: Luis R. Rodriguez mcg...@suse.com
This saves us a few branches when RUN_SETUP is set up.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
Makes sense, especially because there is no sane reason to set both
bits on.
git.c | 2 +-
Richard Hansen rhan...@bbn.com writes:
and plan for transition to forbid them
everywhere in a next big version bump (it is too late for 2.0).
Would it be acceptable to have a config option to forbid these in a
non-major version bump?
Of course ;-) Because we try very hard to avoid a flag
Felipe Contreras felipe.contre...@gmail.com writes:
There's no point in this:
% git merge
fatal: No commit specified and merge.defaultToUpstream not set.
We know the most likely scenario is that the user wants to merge the
upstream, and if not, he can set merge.defaultToUpstream to false.
Kyle J. McKay mack...@gmail.com writes:
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
...
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches,
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to user-defined aliases,
My log graphs are pretty insane sometimes because we converted our
repo from SVN and haven't had a chance to delete all of the remote
branches. We still have quite a few (maybe 20).
When I do `git log`, I am shown about 10-15 vertical lines and the
branch I currently have checked out isn't even
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
[...]
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the form with argument attached
(--prefix=foo,
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
be low-priority compared to
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
This commit is also a prerequisite for the next one in series, which
adds the --ignore-submodules switch to git commit. That's why a new
argument is added to public function add_files_to_cache(), and it's
call
Allow ignoring submodules (or not) by command line switch, like diff
and status do.
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but didn't allow to override it from command line.
This patch depends on Jens Lehmann's patch commit -m: commit staged
submodules regardless
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
[...]
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probably biased in that you've used Git far
Junio C Hamano gits...@pobox.com writes:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
A few thinking points that are necessary to be worked out, even
before we start
Theodore Ts'o wrote:
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probably biased
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
The documentation says
--prefix=prefix
...
Before Git 2.0, the default prefix was (no prefix).
This meant that ...
which suggests that I can use --prefix= to mean no prefix.
Matthieu Moy matthieu@grenoble-inp.fr writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Why is not material for v2.0? Because you say so? Are you going to wait
another
ten years to introduce this to v3.0?
There's no need to wait for a 3.0 to introduce this. If these would
On 18. 4. 2014 14:28, Jens Lehmann wrote:
Am 13.04.2014 01:41, schrieb Ronald Weiss:
Second, there are some differences between adding standard ignored
files, and ignored submodules:
1) Already tracked files are never ignored, regardless of .gitignore.
However, tracked submodules should be
Felipe Contreras felipe.contre...@gmail.com writes:
Theodore Ts'o wrote:
This is especially true for commands which might not be used as often
-- e.g., rebase, and for commands where the meaning of git commit
without any argument is qualitatively different from what ci (for
checkin) means
On Tue, 22 Apr 2014, Theodore Ts'o wrote:
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are
I will look at this once i finish the next respin.
On Tue, Apr 22, 2014 at 12:34 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
This patch series changes most of the places where the ref functions for
locking and writing refs to instead use the new ref
On Tue, Apr 22, 2014 at 12:11 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
diff --git a/refs.c b/refs.c
index 138ab70..9daf89e 100644
--- a/refs.c
+++ b/refs.c
@@ -3414,12 +3414,12 @@ int ref_transaction_commit(struct ref_transaction
1 - 100 of 109 matches
Mail list logo
