On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote:
$ git rev-parse --symbolic-full-name HEAD@{u}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @mybranch@{u}
@mybranch@{u}
fatal: ambiguous argument '@mybranch@{u}': unknown revision or path
not in the
This function checks a few different @{}-constructs. The
early part checks for and dispatches us to helpers for each
construct, but the code for handling @{upstream} is inline.
Let's factor this out into its own function. This makes
interpret_branch_name more readable, and will make it much
In the original version of this function, cp acted as a
pointer to many different things. Since the refactoring in
the last patch, it only marks the at-sign in the string.
Let's use a more descriptive variable name.
Signed-off-by: Jeff King p...@peff.net
---
Obviously can be squashed with the
interpret_branch_name gets passed a name buffer to parse,
along with a namelen parameter representing its length. If
namelen is zero, we fallback to the NUL-terminated
string-length of name.
However, it does not necessarily follow that if we have
gotten a non-zero namelen, it is the
get_sha1() cannot currently parse a valid object name like
HEAD:@{upstream} (assuming that such an oddly named file
exists in the HEAD commit). It takes two passes to parse the
string:
1. It first considers the whole thing as a ref, which
results in looking for the upstream of HEAD:.
2.
When we parse a string like foo@{upstream}, we look for
the first @-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see @foo@{upstream}. In this case, we check only the
first @, and ignore the second. As a result, we do not find
the
On Wed, Jan 15, 2014 at 01:56:52PM +0800, 乙酸鋰 wrote:
what are the possible causes of this?
After stash pop, refs/stash becomes 40 zeroes.
This is the only stash, so refs/stash should be deleted after pop.
However, it becomes 40 zeroes.
git 1.8.x
I can't reproduce the problem here. Running
On 15 Jan 2014, at 00:24, Pete Wyckoff p...@padd.com wrote:
p...@padd.com wrote on Mon, 13 Jan 2014 19:18 -0500:
dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100:
I am trying to clone a perforce repository via git and I am having the
following backtrace :
{14:20}~/projects/:master
On Tue, Jan 14, 2014 at 02:42:09PM -0500, Martin Langhoff wrote:
On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick mf...@codeaurora.org wrote:
Perhaps the receiving process is dying hard and leaving
stuff behind? Out-of-memory, out of disk space?
Yes, that's my guess as well. This server had
On Tue, Jan 14, 2014 at 04:41:03PM +0100, krz...@gmail.com wrote:
git can't execute hooks no partitions mounted with noexec - even if
those are just scripts with shebang line
Right. Git does not know that they are shell (or other) scripts; they
could be anything, and the advertised interface
[+cc Junio, as the bug blames to him]
On Fri, Jan 10, 2014 at 02:15:40PM +0100, Francis Moreau wrote:
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next
and
On 01/15/2014 10:49 AM, Jeff King wrote:
[+cc Junio, as the bug blames to him]
On Fri, Jan 10, 2014 at 02:15:40PM +0100, Francis Moreau wrote:
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick
Hi,
I am in the process of rewriting the core logic of git blame (the
current speed of which is quite an impediment to some workflows).
I currently have one question I don't see an answer to right away, and
that question arises in doing a reasonably robust traversal of commits
without
On Mon, Jan 06, 2014 at 07:19:43PM -0800, Junio C Hamano wrote:
Actually, I think the above recollection of mine was completely
bogus. The is there because we do allow things like HEAD (they
are the funny ones) as well as things inside refs/, and the latter
is the only thing we had a
On Wed, Jan 15, 2014 at 05:46:13AM -0500, Jeff King wrote:
This discussion stalled, but I finally got around to looking at it
today. I agree that we should leave aside more complex policy for now,
and start with bringing the fetch and fetch-pack filters into
harmony. That turns off
On Sun, Jan 12, 2014 at 06:03:39PM +0700, Nguyễn Thái Ngọc Duy wrote:
This patch establishes a connection between a new file watcher daemon
and git. Each index file may have at most one file watcher attached to
it. The file watcher maintains a UNIX socket at
$GIT_DIR/index.watcher. Any
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) = commitdate(parent)
c) commitdate(child) commitdate(parent)
a) none
From: Alexander Shopov a...@kambanaria.org
Signed-off-by: Alexander Shopov a...@kambanaria.org
---
po/glossary/bg.po | 287 ++
1 file changed, 287 insertions(+)
create mode 100644 po/glossary/bg.po
diff --git a/po/glossary/bg.po
From: Alexander Shopov a...@kambanaria.org
Following 3 patchess add:
1. Bulgarian translation of git-gui glossary
2. Bulgarian translation of git-gui po file
3. Additional terms for git-gui glossary in English
The terms in the 3rd patch are in alphabetic order after the existing terms
in order to
From: Alexander Shopov a...@kambanaria.org
Signed-off-by: Alexander Shopov a...@kambanaria.org
---
po/glossary/git-gui-glossary.txt | 29 +
1 file changed, 29 insertions(+)
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
index
When an object lookup fails, we re-read the objects/pack
directory to pick up any new packfiles that may have been
created since our last read. We also discard any pack
revindex structs we've allocated.
The discarding is a problem for the pack-bitmap code, which keeps
a pointer to the revindex
On Thu, Jan 9, 2014 at 10:05 PM, Mathieu Lemoine math...@mlemoine.name wrote:
Hello,
In https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt
is mentioned:
* Instead of typing four capital letters HEAD, you can say @ now,
e.g. git log @.
However, `git symbolic-ref @`
From: Alexander Shopov a...@kambanaria.org
Signed-off-by: Alexander Shopov a...@kambanaria.org
---
po/glossary/bg.po | 287 ++
1 file changed, 287 insertions(+)
create mode 100644 po/glossary/bg.po
diff --git a/po/glossary/bg.po
From: Alexander Shopov a...@kambanaria.org
This is the Bulgarian translation of gitk. Translation is synced
with git-gui so they have same terms and style.
Alexander Shopov (1):
gitk i18n: Added Bulgarian translation (304t)
po/bg.po | 1334
On Jan 14, 2014, at 21:36, Jason St. John wrote:
On Mon, Jan 13, 2014 at 12:55 PM, Junio C Hamano gits...@pobox.com
wrote:
Jason St. John jstj...@purdue.edu writes:
What AsciiDoc formatter (and version) do you use?
$ asciidoc --version
asciidoc 8.6.8
Checking with
Jeff King p...@peff.net writes:
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) = commitdate(parent)
c)
Jeff King p...@peff.net writes:
There are some parts of the code that will behave badly with clock skew.
For example, --since will stop traversing when we hit a certain point.
It requires a fixed number of too old commits before quitting, though,
in an attempt to bypass small runs of skewed
On Wed, 15 Jan 2014 12:40:29 +, David Kastrup wrote:
...
With a single root, depth helps a lot. When looking for a common
parent of a number of commits, you first shorten all ancestries to the
same size and then you can look for the point of convergence in
lockstep.
Hmm, how about
Hi,
If git-mv is provided absolute paths when moving symlinks, it tries to
dereference them and (attempts to) move the symlink target rather than the
symlink itself, this seems like a quite odd behaviour since it's inconsistent
with how git-mv works with symlinks if given relative paths, and I'm
Andreas Krey a.k...@gmx.de writes:
On Wed, 15 Jan 2014 12:40:29 +, David Kastrup wrote:
...
With a single root, depth helps a lot. When looking for a common
parent of a number of commits, you first shorten all ancestries to the
same size and then you can look for the point of
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King p...@peff.net wrote:
We see these occasionally at GitHub, too. I haven't yet figured out a
definite cause, though whatever it is, it's relatively rare.
Do you have a cleanup script to safely get rid of stale .keep and
.lock files? I wonder what other
On Wed, 15 Jan 2014 14:00:30 +, David Kastrup wrote:
Andreas Krey a.k...@gmx.de writes:
...
Hmm, how about traversing from all the start commits downwards
simultaneously, noting which start you say each commit from, and stopping
when you have a commit carrying all start labels?
It
On 01/14/2014 11:16 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
We used to use two separate rules for the normal ref resolution
dwimming and dwimming done to decide which remote ref to grab. The
third parameter to refname_match() selected which rules to use.
From: Ruben Kerkhof ru...@rubenkerkhof.com
I use gmail for sending patches.
If I have the following defined in my ~/.gitconfig:
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = ru...@rubenkerkhof.com
smtpserverport = 587
and try to send a
Martin Langhoff martin.langh...@gmail.com writes:
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King p...@peff.net wrote:
We see these occasionally at GitHub, too. I haven't yet figured out a
definite cause, though whatever it is, it's relatively rare.
Do you have a cleanup script to safely get rid
Igor Gnatenko i.gnatenko.br...@gmail.com writes:
From: Ruben Kerkhof ru...@rubenkerkhof.com
I use gmail for sending patches.
If I have the following defined in my ~/.gitconfig:
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = ru...@rubenkerkhof.com
Jeff King p...@peff.net writes:
[+cc Junio, as the bug blames to him]
...
I think what is happening is that we used to apply the SYMMETRIC_LEFT
flag directly to the commit. Now we apply it to the tag, and it does not
seem to get propagated. The patch below fixes it for me, but I have no
With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the git log family of commands no
longer directly places the object pointed by the tag in the pending
object array when it sees a tag
We have an SVN repository that has a structure for tags (likewise for
branches) like this:
tags/tag1
tags/tag2
tags/tag3/
tags/subdir/tag4
tags/subdir/tag5
The idea is that I want to have git-svn import everything inside subdir
as tags and everything else inside the root tags directory as tags,
Jeff King p...@peff.net writes:
On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote:
$ git rev-parse --symbolic-full-name HEAD@{u}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @mybranch@{u}
@mybranch@{u}
fatal: ambiguous argument '@mybranch@{u}': unknown
Ruben Kerkhof ru...@rubenkerkhof.com writes:
... because? Is it because the cert_path on your platform is
different from /etc/ssl/certs? What platform was this anyway?
This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64,
perl-IO-Socket-SSL-1.962-1.fc21.noarch
I see in the original
Junio C Hamano wrote:
Ruben Kerkhof ru...@rubenkerkhof.com writes:
As a last check, I set smtpsslcertpath = /etc/pki/tls/cert.pem in
~/.gitconfig and git-send-email works fine now.
Which would mean that the existing code, by blindly defaulting to
/etc/ssl/certs/ and misdiagnosing that the
On 15 jan. 2014, at 22:30, Junio C Hamano gits...@pobox.com wrote:
Ruben Kerkhof ru...@rubenkerkhof.com writes:
... because? Is it because the cert_path on your platform is
different from /etc/ssl/certs? What platform was this anyway?
This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64,
On Wed, Jan 15, 2014 at 11:57:39AM -0800, Junio C Hamano wrote:
Where do we pass down other flags from tags to commits? For
example, if we do this:
$ git log ^v1.8.5 master
we mark v1.8.5 tag as UNINTERESTING, and throw that tag (not commit
v1.8.5^0) into revs-pending.objects[].
On Wed, Jan 15, 2014 at 12:26:13PM -0800, Junio C Hamano wrote:
With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the git log family of commands no
longer directly places the object
Jeff King p...@peff.net writes:
Looks good to me. As per my previous mail, I _think_ you could squash
in:
diff --git a/revision.c b/revision.c
index f786b51..2db906c 100644
--- a/revision.c
+++ b/revision.c
@@ -316,13 +316,10 @@ static struct commit *handle_commit(struct rev_info
*revs,
Junio C Hamano gits...@pobox.com writes:
But I have a suspicion that my patch may break if any codepath looks
at the current flag on the object and decides ah, it already is
marked and punts.
It indeed looks like mark_tree_uninteresting() does have that
property. When an uninteresting tag
Signed-off-by: Philip Oakley philipoak...@iee.org
---
Documentation/Makefile | 1 +
Documentation/gituser-manual.txt | 34 ++
builtin/help.c | 1 +
3 files changed, 36 insertions(+)
create mode 100644 Documentation/gituser-manual.txt
The Git User Manual is formatted as a doc book, rather than as
a man page so isn't directly accessible via the 'hit help guide'
command.
This patch provides a simple man page with onward links to the true
User-Manual.
The man page is based directly on a very cut down version of the git(1)
page.
Add a `pull.ff` configuration option that is analogous
to the `merge.ff` option.
This allows us to control the fast-forward behavior for
pull-initiated merges only.
Signed-off-by: David Aguilar dav...@gmail.com
---
Documentation/config.txt | 10 ++
git-pull.sh | 15
Signed-off-by: David Aguilar dav...@gmail.com
---
git-pull.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-pull.sh b/git-pull.sh
index 7dbf6b1..68b2e40 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -4,7 +4,7 @@
#
# Fetch one or more remote refs and merge it/them into
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote:
As long as we can reliably determine that it is safe to do so
without risking races, automatically cleaning .lock files is a good
thing to do.
If the .lock file is a day old, it seems to me that it should be safe
to call
So this is my second try. The second one now gets rid of the call
to mark_blob_uninteresting() as Peff suggested, because the first
patch makes the function very well aware that it only should mark
the objects that are reachable from the object, and by definition
blobs do not reach anything.
With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the git log family of commands no
longer directly places the object pointed by the tag in the pending
object array when it sees a tag
git rev-list --objects ^A^{tree} B^{tree} ought to mean I want a
list of objects inside B's tree, but please exclude the objects that
appear inside A's tree.
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
Junio C Hamano wrote:
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree as uninteresting.
So the tree is marked
Kyle J. McKay mack...@gmail.com writes:
in the docbook-xsl sources. Debian includes a patch file
8530_manpages_lists_indentation_fix.dpatch in [1]:
...
And once I have applied that I suddenly get a correct git-config.1
file on System A.
...
--Kyle
[1]
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree
On Thu, Jan 16, 2014 at 6:50 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote:
As long as we can reliably determine that it is safe to do so
without risking races, automatically cleaning .lock files is a good
thing to
Here is the next iteration of cloning-update local branch setup. This
version is based on Francesco's fp/submodule-checkout-mode [1], and
moves back towards the weakly-bound v2 approach and away from the
tightly-bound v3 approach.
The first patch in this series extends that commit to consolidate
Signed-off-by: W. Trevor King wk...@tremily.us
---
git-submodule.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5e8776c..68dcbe1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -241,6 +241,12 @@ module_name()
#
# Clone a submodule
This avoids the current awkwardness of having either '' or 'checkout'
for checkout-mode updates, which makes testing for checkout-mode
updates (or non-checkout-mode updates) easier.
Signed-off-by: W. Trevor King wk...@tremily.us
---
git-submodule.sh | 27 +++
1 file
Test that cloning updates checkout the appropriate local branch for
their update-mode:
* Checkout-mode updates get detached HEADs
* Everyone else gets a local branch, matching the configured
submodule.name.branch and defaulting to master.
The 'initial-setup' tag makes it easy to reset the
The old documentation did not distinguish between cloning and
non-cloning updates and lacked clarity on which operations would lead
to detached HEADs, and which would not. The new documentation
addresses these issues while updating the docs to reflect the changes
introduced by this branch's
The previous code only checked out branches in cmd_add. This commit
moves the branch-checkout logic into module_clone, where it can be
shared by cmd_add and cmd_update. I also update the initial checkout
command to use 'reset' to preserve branches setup during module_clone.
With this change,
To preserve the local branch, for situations where we're not on a
detached HEAD.
Signed-off-by: W. Trevor King wk...@tremily.us
---
t/t7406-submodule-update.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index
I have a file in a git repo. It has changed during the last two
commits. I want to see the changes made in these two commits. The
following command should work:
git diff HEAD^^
but that doesn't get me the expected results. Read on for details.
Last commit: I changed some stuff towards the
Misha Penkov misha.pen...@gmail.com writes:
I have a file in a git repo. It has changed during the last two
commits. I want to see the changes made in these two commits. The
following command should work:
git diff HEAD^^
but that doesn't get me the expected results. Read on for
Am 1/16/2014 7:19, schrieb Misha Penkov:
I have a file in a git repo. It has changed during the last two
commits. I want to see the changes made in these two commits. The
following command should work:
git diff HEAD^^
but that doesn't get me the expected results. Read on for details.
Ah, I see. Thank you.
Michael
On 16 January 2014 15:55, Johannes Sixt j.s...@viscovery.net wrote:
Am 1/16/2014 7:19, schrieb Misha Penkov:
I have a file in a git repo. It has changed during the last two
commits. I want to see the changes made in these two commits. The
following command
Johannes Sixt j.s...@viscovery.net writes:
Am 1/16/2014 7:19, schrieb Misha Penkov:
I have a file in a git repo. It has changed during the last two
commits. I want to see the changes made in these two commits. The
following command should work:
git diff HEAD^^
Here, you revert the
71 matches
Mail list logo
