On 09/12/13 19:51, Johannes Sixt wrote:
Am 12/9/2013 3:23, schrieb Brett Randall:
* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).
Why would you want that? To fixup the previous commit, just use
This aims to support code-review workflows of teams that prefer rebase
over merge, when committing a new peer-reviewed feature.
* Developer starts with commit OM, commits A.
* During testing, the developer may make further changes, either
through --amend or new commits, but either way, all work
Thomas Gummerer t.gumme...@gmail.com writes:
Hi,
previous rounds (without api) are at $gmane/202752, $gmane/202923,
$gmane/203088 and $gmane/203517, the previous rounds with api were at
$gmane/229732, $gmane/230210 and $gmane/232488. Thanks to Duy for
reviewing the the last round and
Hi list,
I was just playing with the new features of 'git mv' in 1.8.5 and
realized that both rm
and mv don't change the .git/config file. Is that on purpuse?
Also after mv you need to run 'submodule update' and I think this should be
documented somewhere.
Thanks..
--
George 'papanikge'
Me and some colleagues work on gcc in lots of different branches.
For each branch there is a separate build directory for each
branch, e.g. build-a, build-b and build-c. Let's assume that all
branches are identical at the moment. If a file in branch a is
changed that triggers a complete rebuild
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks, but it's especially annoying if there is a broken
index file.
Avoid calling the unnecessary gitmodules_config() when the --no-index
Am 08.12.2013 11:20, schrieb Thomas Rast:
Karsten Blees karsten.bl...@gmail.com writes:
Am 07.12.2013 23:23, schrieb Thomas Rast:
Karsten Blees karsten.bl...@gmail.com writes:
Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
memory on 64-bit systems. This is
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
but it's especially annoying if there is a broken
index file.
Is this
Am 09.12.2013 16:16, schrieb Jonathan Nieder:
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
Hmm, but this will disable the submodule
Karsten Blees karsten.bl...@gmail.com writes:
Am 07.12.2013 00:52, schrieb Junio C Hamano:
* kb/doc-exclude-directory-semantics (2013-11-07) 1 commit
- gitignore.txt: clarify recursive nature of excluded directories
Originally merged to 'next' on 2013-11-13
Kicked back to 'pu' to
Karsten Blees karsten.bl...@gmail.com writes:
* kb/fast-hashmap (2013-11-18) 14 commits
(merged to 'next' on 2013-12-06 at f90be3d)
Damn, a day too late :-) I found these two glitches today...is a
fixup patch OK or should I do a reroll (or separate patch on top)?
A separate patch on top
John Szakmeister j...@szakmeister.net writes:
Signed-off-by: John Szakmeister j...@szakmeister.net
---
The gnome-keyring credential backend had a number of coding style
violations. I believe this fixes all of them.
.../gnome-keyring/git-credential-gnome-keyring.c | 55
Jeff King p...@peff.net writes:
Is it better for rev-parse to be more careful, and to behave more like
the rest of git? Or is better to be historically compatible?
One thing to note is that git rev-parse HEAD is slightly broken there
already. Because git rev-parse $some_branch may do very
Jens Lehmann wrote:
Am 09.12.2013 16:16, schrieb Jonathan Nieder:
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
Hmm, but this will disable
Junio C Hamano wrote:
So maybe we are doing a favor by
calling out the problem; if they want a rev, they should be using
--verify (or --).
I tend to agree with the reasoning in the last sentence. Let's cook
it for a while and see what happens.
Isn't
Jonathan Nieder jrnie...@gmail.com writes:
Thomas Gummerer wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks,
Makes sense.
but it's especially
Jonathan Nieder wrote:
Isn't this essentially breaking a contract
To clarify, if there were some strong motivation --- e.g. if this
were resolving some security problem --- then I would be all for
breaking compatibility in this way. What's confusing to me is that I
just don't see the
Samuel Bronson naes...@gmail.com writes:
If somebody has diff.orderfile configuration that points at a custom
ordering, and wants to send out a patch (or show a diff) with the
standard order, how would the overriding command line look like?
Would it be git diff -O/dev/null?
It looks like
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
I've got this with Vietnamese translation
$ git status
HEAD được tách rời từorigin/master
One does not need to understand Vietnamese to see that a space is
missing before origin/master...
Not really. Only if one guesses (or knows)
The old log-line looked like this:
+ 9d498b0...8598732 master - master (forced update)
And the new one like this:
9d498b0..8598732 master - master
- Loosen the grep pattern by not demanding (forced update)
- Improve the grep pattern and check the new SHA id
Signed-off-by: Torsten
Karsten Blees wrote:
GCC supports __packed__ as of 2.3 (1992), so any other compilers
that copied the __attribute__ feature probably won't complain.
Alas, it looks like HP C doesn't support __packed__ (not that I
care much about HP C):
John Keeping j...@keeping.me.uk writes:
Last time this came up [1], there was some discussion about moving the
added block of code to affect upstreams given on the command line as
well as when the upstream is discovered from the config. Having tried
that, it has some more fallout on the test
Johannes Sixt j.s...@viscovery.net writes:
Am 12/9/2013 3:23, schrieb Brett Randall:
* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).
Why would you want that? To fixup the previous commit, just
Thomas Gummerer t.gumme...@gmail.com writes:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks, but it's especially annoying if there is a broken
index file.
Avoid calling the
Dominik Vogt v...@linux.vnet.ibm.com writes:
Me and some colleagues work on gcc in lots of different branches.
For each branch there is a separate build directory for each
branch, e.g. build-a, build-b and build-c. Let's assume that all
branches are identical at the moment. If a file in
On Mon, Dec 09, 2013 at 12:11:50PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Last time this came up [1], there was some discussion about moving the
added block of code to affect upstreams given on the command line as
well as when the upstream is discovered from
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). This results in worse performance when
the index is not actually needed. This patch avoids calling
gitmodules_config() when the --no-index option is given. The times for
executing git diff
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
So maybe we are doing a favor by
calling out the problem; if they want a rev, they should be using
--verify (or --).
I tend to agree with the reasoning in the last sentence. Let's cook
it
Hi,
Dominik Vogt wrote:
Now,
when I switch to one of the other branches, said file is not
identical anymore and stamped with the _current_ time during
checkout. Although branch b and c have not changed at all, they
will now be
On 2013-12-09 21.40, Thomas Gummerer wrote:
+test_expect_success 'git diff --no-index with broken index' '
+ cd repo
+ echo broken .git/index
+ git diff --no-index a ../non/git/a
^^
I'm confused: Does this work with the trailing ?
This submodule configuration cache allows us to lazily read .gitmodules
configurations by commit into a runtime cache which can then be used to
easily lookup values from it. Currently only the values for path or name
are stored but it can be extended for any value needed.
This cache can be used
Junio C Hamano wrote:
I do not share the with --verify is better hence no problem
reasoning. My not so much worth worrying about comes solely from
a hunch that nobody has HEAD~3..HEAD in their working directory,
That's what makes it a problem. This change makes it very easy to
make a
On Mon, Dec 9, 2013 at 3:40 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). This results in worse performance when
the index is not actually needed. This patch avoids calling
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
But it does not have to stay that way. In order to move things
forward in that direction, this new configuration has to be
Will re-queue these 6 for now. Thanks.
--
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
Jonathan Nieder jrnie...@gmail.com writes:
But if we cook it for a while, I suspect that we will find more and
more breakages of expectations in the existing scripts in and out of
the tree;
Alas, probably no, because nobody has HEAD~3..HEAD in their working
directory. That's exactly the
Junio C Hamano gits...@pobox.com writes:
A refspec consists of one or more elements, each of which has
right and left hand side separated by a colon, i.e. RHS:LHS, and
1) is determined by the RHS
2-a) is determined by the LHS
2-b) is determined by the correspondence between RHS-to-LHS.
[Sorry for not seeing this before sending out v2.]
Junio C Hamano gits...@pobox.com writes:
Thomas Gummerer t.gumme...@gmail.com writes:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance
Eric Sunshine sunsh...@sunshineco.com writes:
On Mon, Dec 9, 2013 at 3:40 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). This results in worse performance when
the index is not actually
Felipe Contreras felipe.contre...@gmail.com writes:
Commit 66713ef (pull: allow pull to preserve merges when rebasing)
didn't include an update so 'git remote status' parses
branch.name.rebase=preserve
correctly, let's do that.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Thanks, will queue.
--
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
Felipe Contreras felipe.contre...@gmail.com writes:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
abspath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/abspath.c b/abspath.c
index e390994..8b3385a 100644
--- a/abspath.c
+++ b/abspath.c
@@ -143,7
Felipe Contreras felipe.contre...@gmail.com writes:
There's no mention of the 'origin' default, or the fact that the
upstream tracking branch remote is used.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-fetch.txt | 3 +++
1 file changed, 3 insertions(+)
On Fri, Dec 6, 2013 at 5:07 PM, Jeff King p...@peff.net wrote:
When rev-parse looks at whether an argument like foo..bar
or foobar^@ is a difference or parent-shorthand, it
internally munges the arguments so that it can pass the
individual rev arguments to get_sha1. However, we do not
On Thu, Dec 05, 2013 at 09:51:31PM +0100, Jens Lehmann wrote:
Am 05.12.2013 00:19, schrieb Heiko Voigt:
On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
This series tries to achieve the following goals for the
submodule.name.ignore=all configuration or the
On Fri, Dec 06, 2013 at 03:10:31PM -0800, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
diff --git a/builtin/add.c b/builtin/add.c
index 2d0d2ef..d6cab7f 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -550,6 +569,7 @@ int cmd_add(int argc, const char **argv, const char
Torsten Bögershausen tbo...@web.de writes:
The old log-line looked like this:
+ 9d498b0...8598732 master - master (forced update)
And the new one like this:
9d498b0..8598732 master - master
- Loosen the grep pattern by not demanding (forced update)
Hmm, what is the reason for the
Jens Lehmann jens.lehm...@web.de writes:
I didn't check each site in detail, but I suspect each ignore option
was added on purpose to fix a problem. That means we still need all
(at least when diffing rev-index). Unfortunately that area is not
covered well in our tests, I only got breakage
On Sat, Dec 07, 2013 at 06:03:22PM +0100, Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
* jk/pack-bitmap (2013-11-18) 22 commits
[...]
Peff can decide if he wants to reroll with my nits or not; either way
I'm all for moving it forward and aiming for one of the next releases.
On Fri, Dec 06, 2013 at 03:48:46PM +, Charlie Dyson wrote:
gitmodules(5) states that submodule.$name.update should be defined in
.gitmodules. However in cmd_update() in git-submodule.sh, git config
is used with -f .gitmodules. Consequently this flag is only
respected in .git/config
On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann jens.lehm...@web.de wrote:
Right you are, we need tutorials for the most prominent use cases.
In the meantime, are there any hints? Emails on this list showing a
current smart
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream}'. That is also what
'git pull [--rebase]' defaults to, so it only makes sense that
'git rebase' defaults to the same thing.
but that isn't
Am 09.12.2013 21:08, schrieb Jonathan Nieder:
Karsten Blees wrote:
GCC supports __packed__ as of 2.3 (1992), so any other compilers
that copied the __attribute__ feature probably won't complain.
Alas, it looks like HP C doesn't support __packed__ (not that I
care much about HP C):
I had not previously noticed commit --fixup, so that is something
useful I have learned from this thread, thanks.
The workflow here can be summarized as I have an initial commit and
subsequent, review-generated commits, that I'd like to share on a
review-branch with proper commit-log comments,
Heiko Voigt hvo...@hvoigt.net writes:
This submodule configuration cache allows us to lazily read .gitmodules
configurations by commit into a runtime cache which can then be used to
easily lookup values from it. Currently only the values for path or name
are stored but it can be extended for
Heiko Voigt hvo...@hvoigt.net writes:
This notion has changed in a way that only the url (by that the name)
should be copied on init. The default for everything else should come
from .gitmodules or gits own default.
I think you need to be a bit careful here. I do not think
everything should
Karsten Blees wrote:
(Besides, __attribute__((aligned)) / __declspec(align) can only
_increase_ the alignment, so aligned(1) would have no effect).
Good catch.
Googling some more, I believe the most protable way to achieve this
via 'compiler settings' is
#pragma pack(push)
#pragma
Heiko Voigt hvo...@hvoigt.net writes:
On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann jens.lehm...@web.de wrote:
Right you are, we need tutorials for the most prominent use cases.
In the meantime, are there any hints? Emails on
John Keeping wrote:
Since commit d96855f (merge-base: teach --fork-point mode, 2013-10-23)
we can replace a shell loop in git-pull with a single call to
git-merge-base. So let's do so.
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-pull.sh | 10 +-
1 file changed, 1
Hi
I came across this issue the other day while trying to optimise a fetch to a
repo with release branches named release-X.X.X. I wanted to just fetch just
those branches but because of the trailing slash rule I couldn't. The following
StackOverflow post has details of the issue:
On 5 Dec 2013, at 11:52, Junio C Hamano gits...@pobox.com wrote:
Nick Townsend nick.towns...@mac.com writes:
Interplay between paths specified in three ways now tested:
* After a : in the tree-ish,
* As a pathspec in the command,
* By virtue of the current working directory
Note that
61 matches
Mail list logo
