On 15:27, Thu 05 Sep 13, Junio C Hamano wrote:
Now the long option name is --no-index, it makes me wonder if -i
is a good synonym for it, and the longer I stare at it, the more
certain I become convinced that it is a bad choice.
I had originally called it --ignore-index at which point -i made
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
encode_sha1ref()).
- Parent count: variable length encoding of the number of parents.
This is
Am 9/5/2013 23:43, schrieb Eyal Zinder:
I'm trying to setup a distributed development repository with a central
repository acting as the production copy. I'm doing so on a Windows
file share with no SSH / HTTP accessibility. Basically each developer
will have their own copy of the project,
Junio C Hamano gits...@pobox.com writes:
Isn't the right way to improve the situation to let the command line tools
know how the user wants to push things out and just have Git-GUI delegate
the choice to the underlying git push?
Thank you for all the constructive feedback. I realize that it
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com
---
Should be up to date with Nico's latest implementation and also cover
additions to the format that everybody
On Thu, 5 Sep 2013 14:43:52 -0700 (PDT)
Eyal Zinder ezin...@yahoo.com wrote:
[...]
The problem I faced later on was in parallel development, when
changes were made to a file in one repository, and at the same time
other changes made to the same file in another repository.. I
couldh't push
Hi,
Per Cederqvist alerted me to a change in v1.8.3.2 that broke his
build/test infrastructure. Specifically, before 41c21f2 (branch.c:
Validate tracking branches with refspecs instead of refs/remotes/*)
Git allowed a local branch to --track anything within refs/remotes/*,
and in 41c21f2, I
We're testing that trying to --track a ref that is not covered by any remote
refspec should fail. For that, we want to have refs/remotes/local/master
present, but we also want the remote.local.fetch refspec to NOT match
refs/remotes/local/master (so that the tracking setup will fail, as intended).
Make it easier for readers to find the actual config variables that
implement the upstream relationship.
Suggested-by: Per Cederqvist ced...@opera.com
Signed-off-by: Johan Herland jo...@herland.net
---
In a private email exchange, Per noted that it was hard for someone reading
the git-branch
From: Per Cederqvist ced...@opera.com
When creating an upstream relationship, we use the configured remotes and
their refspecs to determine the upstream configuration settings
branch.name.remote and branch.name.merge. However, if the matching
refspec does not have refs/heads/something on the
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index dee55e4..6c78fba 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@
Problem: It is not possible to push for Gerrit review as you will
always try to push to refs/heads/... on the remote.
Changes done:
Add an option to select Gerrit review and a corresponding entry
for a branch name. If this option is selected, push the changes to
refs/for/gerrit-branch/local
On Tue, 03 Sep 2013 08:33:39 +, Junio C Hamano wrote:
...
Reading the patch series from 2008 again, I do agree with J6t's
comment that it should be just a regular capability,
I've implemented it as a 'sym=refs/heads/foo' capability.
It actually makes the patch series a lot shorter; the only
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
Uli Heller uli.hel...@daemons-point.com writes:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see
On Fri, September 6, 2013 1:46 pm, Kyle J. McKay wrote:
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
Uli Heller uli.hel...@daemons-point.com writes:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug
On Sep 6, 2013, at 05:06, Uli Heller wrote:
I'm using Git built from master (57e4c1783). I see the same behavior
both with and without the SVN/Ra.pm patch (and using both bulk
updates
and skelta mode). Does the problem not happen on a git svn clone? I
can force serf back to version 1.2.1
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
I am Cc'ing Kyle McKay who apparently had some experience working
with git-svn with newer svn that can only use serf, hoping that we
can get an independent opinion/test just to be sure.
On Sep 3, 2013, at 00:35, Uli Heller wrote:
When using
On Fri, 06 Sep 2013 13:41:30 +, Andreas Krey wrote:
...
If I run the exact same commands in a shell script they succeed,
in t5601-clone.sh the clone step seems to fail, and I have no
clue where to look for a clue.
Oh, never mind. --verbose shows that the test is borked;
it tries a checkout
On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote:
On Sep 6, 2013, at 05:06, Uli Heller wrote:
I'm using Git built from master (57e4c1783). I see the same behavior
both with and without the SVN/Ra.pm patch (and using both bulk
updates
and skelta mode). Does the problem not happen on a
On Fri, 6 Sep 2013, Duy Nguyen wrote:
On Thu, Sep 5, 2013 at 11:52 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
Now the pack index v3 probably needs to be improved a little, again to
accommodate completion of thin packs.
On 2013-09-06 12:39, Tay Ray Chuan wrote:
First: recognize Mercurial's branches are entirely different beasts
from Git's. They just happen to be given a same sequence of
characters, b-r-a-n-c-h. The similarities end there!
Yeah, I'm trying to create a mental map between what Git means by
On Fri, 6 Sep 2013, Duy Nguyen wrote:
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com
---
Should be up to date with Nico's latest implementation and also
On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Duy Nguyen wrote:
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com
---
On Thu, 5 Sep 2013 21:27:14 -0500
Tim Chase g...@tim.thechases.com wrote:
[...]
Do any git users here have good understanding Mercurial branches
for the git user resources they've found helpful when working with
Mercurial? Preferably a for dummies resource with illustrations
comparison
On Wed, Sep 4, 2013 at 2:08 PM, William Swanson swanson...@gmail.com wrote:
On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It has been discussed many times in the past that 'index' is not an
appropriate description for what the high-level user does with
Jiang Xin worldhello@gmail.com writes:
2013/9/4 Junio C Hamano gits...@pobox.com:
* jx/branch-vv-always-compare-with-upstream (2013-08-26) 2 commits
- status: always show tracking branch even no change
- branch: report invalid tracking branch as gone
git branch -v -v (and git status)
Dave Williams d...@opensourcesolutions.co.uk writes:
On 15:27, Thu 05 Sep 13, Junio C Hamano wrote:
Now the long option name is --no-index, it makes me wonder if -i
is a good synonym for it, and the longer I stare at it, the more
certain I become convinced that it is a bad choice.
I had
From: Junio C Hamano gits...@pobox.com
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=target.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
Ok, here are some patches that make git actually
check out the current remote branch when cloning.
Up to now this failed when there were two branches that pointed to
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the HEAD ref isn't transmitted in all
Signed-off-by: Andreas Krey a.k...@gmx.de
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
From: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
---
On Fri, 6 Sep 2013, Duy Nguyen wrote:
On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Duy Nguyen wrote:
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
Jeff King p...@peff.net writes:
# and have 472 and 59 different commits each, respectively.
#
# Untracked files:
[...]
and have 472 and 59 different commits each, respectively.
Untracked files:
Indeed, I forgot the else branch in wt_status_print_tracking:
if
Uli Heller uli.hel...@daemons-point.com writes:
On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote:
...
In any case, I can now reproduce the problem (serf 1.3.1 still breaks
since it does not yet contain the fix and it is the most recent serf
release available).
And the Git/SVN/Ra.pm
From: Konstantin Khomoutov flatw...@users.sourceforge.net
To: Tim Chase g...@tim.thechases.com
On Thu, 5 Sep 2013 21:27:14 -0500
Tim Chase g...@tim.thechases.com wrote:
[...]
Do any git users here have good understanding Mercurial branches
for the git user resources they've found helpful when
Johan Herland jo...@herland.net writes:
However, in addition to requiring a matching remote/refspec, I also
(for reasons that are still unclear to me) added a requirement that
the resulting remote ref name (to be stored into branch.name.merge)
must start with refs/heads/ (see the last line of
On 6 September 2013 08:45, Ping Yin pkufra...@gmail.com wrote:
On Wed, Sep 4, 2013 at 2:08 PM, William Swanson swanson...@gmail.com wrote:
On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It has been discussed many times in the past that 'index' is not an
Jeff King wrote:
On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
I'm fine with any name actually (since it is enabled by default, people
don't need to know the name to benefit from the new output). Maybe
status.displayCommentPrefix was the best name after all.
FWIW, I had the
From: Andreas Krey a.k...@gmx.de
Ok, here are some patches that make git actually
check out the current remote branch when cloning.
Up to now this failed when there were two branches that pointed to
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the
mf...@codeaurora.org writes:
Object lookups should likely not get any slower than if
repack were not run, and the extra new pack might actually help
find some objects quicker.
In general, having an extra pack, only to keep objects that you know
are available in other packs, will make _all_
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
I'm fine with any name actually (since it is enabled by default, people
don't need to know the name to benefit from the new output). Maybe
status.displayCommentPrefix
Johan Herland jo...@herland.net writes:
Signed-off-by: Johan Herland jo...@herland.net
---
t/t2024-checkout-dwim.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index dee55e4..6c78fba 100755
---
The --for-status option was an undocumented option used only by
wt-status.c, which inserted a header and commented out the output. We can
achieve the same result within wt-status.c, without polluting the
submodule command-line options.
This will make it easier to disable the comments from
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/stripspace.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index e981dfb..1259ed7 100644
---
List of files in other sections (Changes to be committed, ...) end with
a blank line. It is not the case with the Untracked files and Ignored
files sections. The issue become particularly visible after the #-prefix
removal, as the last line (e.g. nothing added to commit but untracked
files
No behavior change, but two slight code reorganization: argv_array_push
doesn't accept NULL strings, and duplicates its argument hence
summary_limit must be written to before being inserted into argv.
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
Compared to v5:
* One test update I had forgotten. Now, the testsuite actually pass.
* Changed the config to status.displayCommentPrefix.
* Added the last patch, to add a missing blank line.
Matthieu Moy (6):
builtin/stripspace.c: fix broken indentation
wt-status: use argv_array API
Andreas Krey a.k...@gmx.de writes:
From: Junio C Hamano gits...@pobox.com
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=target.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by:
Historically, git status needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when git status is ran from the
command-line, and this may distract users from the real content.
Disable this prefix
Andreas Krey a.k...@gmx.de writes:
Signed-off-by: Andreas Krey a.k...@gmx.de
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref
On Friday, September 06, 2013 11:19:02 am Junio C Hamano
wrote:
mf...@codeaurora.org writes:
Object lookups should likely not get any slower than if
repack were not run, and the extra new pack might
actually help find some objects quicker.
In general, having an extra pack, only to keep
Matthieu Moy matthieu@grenoble-inp.fr writes:
Untracked files:
t/foo
test-obj-pool
test-string-pool
test-treap
test-url-normalize
nothing added to commit but untracked files present
The added blank line before nothing added
Matthieu Moy matthieu@imag.fr writes:
List of files in other sections (Changes to be committed, ...) end with
a blank line.
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line between each
element, so that they can have a
Philip Oakley philipoak...@iee.org writes:
Does this have any impact on the alleged bug in `git bundle --all`
(which can then be cloned from) where the current HEAD ref wasn't
included in the bundle? Or am I mis-remembering?
Not current HEAD ref, but git clone will fail to check out from
a
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
List of files in other sections (Changes to be committed, ...) end with
a blank line.
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line
Junio C Hamano gits...@pobox.com writes:
Actually, nothing added ... is not a part of status proper; it
will be clear if you run the command with comment prefix, whose
output may end like so:
# Untracked files:
# (use git add file... to include in what will be committed)
#
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
List of files in other sections (Changes to be committed, ...) end with
a blank line.
It is not like we want to add a blank line at the end of each
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
List of files in other sections (Changes to be committed, ...) end with
a blank line.
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line
On Mon, Sep 02, 2013 at 08:42:36PM +0100, Luke Diamand wrote:
I guess you could try changing the OOM score for git-fast-import.
change /proc/pid/oomadj.
I think a value of -31 would make it very unlikely to be killed.
On 29/08/13 23:46, Pete Wyckoff wrote:
I usually just do git p4 sync
On 2013-09-06 17:51, Konstantin Khomoutov wrote:
I found this guide [1] very useful back in the time I tried to grok
Mercurial.
1.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Indeed, after reading it, that's the most sense I've been able to make
of Mercurial's
On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
Andreas Krey a.k...@gmx.de writes:
...
+ if (symref) {
+ ref-symref = xcalloc(symref_len + 1, 1);
+ strncpy(ref-symref, symref, symref_len);
+ }
...
This looks utterly
Andreas Krey a.k...@gmx.de writes:
Can I assume that the only capability list is always on the
first ref sent (as it is now)?
The capability list _could_ be sent more than once, and the
receiving end is prepared to accept such a stream. Everything
learned from an older capability list needs
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Andreas Krey a.k...@gmx.de writes:
On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
Andreas Krey a.k...@gmx.de writes:
...
reason later, on-the-wire format should be prepared to support such
later enhancement. I think sending
symref=HEAD:refs/heads/master
Christian Couder chrisc...@tuxfamily.org writes:
+ obj_type = sha1_object_info(object, NULL);
+ repl_type = sha1_object_info(repl, NULL);
That we can do this is somewhat curious. If an object is replaced
with a different one, would it mean that this code snippet is
totally bogus?
On Fri, Sep 6, 2013 at 7:32 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index dee55e4..6c78fba 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -113,9 +113,9 @@
On Thu, 5 Sep 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
encode_sha1ref()).
- Parent count: variable length
Junio C Hamano gits...@pobox.com writes:
Christian Couder chrisc...@tuxfamily.org writes:
+obj_type = sha1_object_info(object, NULL);
+repl_type = sha1_object_info(repl, NULL);
That we can do this is somewhat curious
Note that this was a comment on the sha1_object_info() API,
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am not remembering correctly.
It just does @{upstream} by default, which tends to get messy if the
upstream has
On Fri, Sep 6, 2013 at 6:30 AM, Joergen Edelbo j...@napatech.com wrote:
Problem: It is not possible to push for Gerrit review as you will
always try to push to refs/heads/... on the remote.
Changes done:
Add an option to select Gerrit review and a corresponding entry
for a branch name. If
Sebastian Schuberth sschube...@gmail.com writes:
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
H, personally I'd actually want
On Fri, Sep 06, 2013 at 11:42:02AM -0700, Junio C Hamano wrote:
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line between each
element, so that they can have a bit of breathing room between them.
The output looks
Nicolas Pitre n...@fluxnic.net writes:
OK. If I understand correctly, the committer time stamp is more
important than the author's, right?
Yeah, it matters a lot more when doing timestamp based traversal
without the reachability bitmaps.
... may I suggest keeping the tree reference first.
Linux Mint has an implementation of the highlight command (unrelated
to the one from http://www.andre-simon.de) that works as a simple
filter. The script uses 'sed' to add terminal colour escape codes
around text matching a regular expression. When t9500-*.sh attempts
to run highlight --version,
On Fri, Sep 06, 2013 at 07:28:43PM +0200, Matthieu Moy wrote:
FWIW, I had the same thought as Junio. I much prefer something like
status.displayCommentPrefix for clarity and future-proofing.
Sounds fine, but I don't understand why we'd want this to be an option
with a future in the
On Sep 6, 2013, at 13:10, Sebastian Schuberth wrote:
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an
annotation.
It's not that hard to add -m to the command line:
git tag -a -m new-annotated-tag
if
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
Does this have any impact on the alleged bug in `git bundle --all`
(which can then be cloned from) where the current HEAD ref wasn't
included in the bundle? Or am I mis-remembering?
Not current HEAD ref, but
Junio C Hamano wrote:
Sebastian Schuberth sschube...@gmail.com writes:
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
H,
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office yesterday so I decided to use this very chance to know you. I
believe we should use every opportunity to know each other
On Fri, 6 Sep 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
OK. If I understand correctly, the committer time stamp is more
important than the author's, right?
Yeah, it matters a lot more when doing timestamp based traversal
without the reachability bitmaps.
On Fri, 6 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Should be up to date with Nico's latest implementation and also cover
additions to the format that everybody seems to agree on:
- new types for canonical trees and commits
-
On Fri, 6 Sep 2013, Nicolas Pitre wrote:
On Fri, 6 Sep 2013, Duy Nguyen wrote:
In your code you reject sha1ref starting with zero too
(sha1_file.c::get_base_delta and packv4-parse.c::decode_entries)
Yeah... because I wrote the minimum code to make it work with the
current encoder.
Dear Colleagues,
You are invited to upload your papers to our upcoming conferences
Paris, France, October 29-31, 2013. More details: http://www.wseas.org
Scientific Sponsors:
a) University of Zagreb, Croatia,
b) Music Academy Studio Musica, Italy,
c) Constanta Maritime University, Romania,
84 matches
Mail list logo
