Johannes Sixt 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 change...
Ah, I see. Thank you.
Michael
On 16 January 2014 15:55, Johannes Sixt 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 should work:
>>
>>
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 det
Misha Penkov 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 details.
> As I mentio
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 en
To preserve the local branch, for situations where we're not on a
detached HEAD.
Signed-off-by: W. Trevor King
---
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 0825a92..5aa9591 1007
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 explic
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, fol
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..branch and defaulting to master.
The 'initial-setup' tag makes it easy to reset the superproj
Signed-off-by: W. Trevor King
---
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
#
+# $1 = submod
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
---
git-submodule.sh | 27 +++
1 file changed, 11 insertions
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
On Thu, Jan 16, 2014 at 6:50 AM, Martin Langhoff
wrote:
> On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano 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
Jonathan Nieder 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 as uninte
"Kyle J. McKay" 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]
> http://ftp.de.debian.org/debian/pool/
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 u
"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
u
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.
Juni
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 obj
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano 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 it stale.
Can
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
---
Documentation/config.txt | 10 ++
git-pull.sh | 15 +++
Signed-off-by: David Aguilar
---
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 the current HEAD.
Signed-off-by: Philip Oakley
---
Documentation/Makefile | 1 +
Documentation/gituser-manual.txt | 34 ++
builtin/help.c | 1 +
3 files changed, 36 insertions(+)
create mode 100644 Documentation/gituser-manual.txt
diff --git a/Documen
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 '
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.
This
Junio C Hamano 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 directly p
Jeff King 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,
>
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 obj
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.objec
On 15 jan. 2014, at 22:30, Junio C Hamano wrote:
> Ruben Kerkhof 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
Junio C Hamano wrote:
> Ruben Kerkhof 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 directory is mea
Ruben Kerkhof 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 discussion in your
Jeff King 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 re
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, s
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 obj
Jeff King 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
> idea if we
Igor Gnatenko writes:
> From: Ruben Kerkhof
>
> 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
Martin Langhoff writes:
> On Wed, Jan 15, 2014 at 4:12 AM, Jeff King 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
From: Ruben Kerkhof
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 patch, this fails with:
S
On 01/14/2014 11:16 PM, Junio C Hamano wrote:
> Michael Haggerty 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.
>>
>> When these
On Wed, 15 Jan 2014 14:00:30 +, David Kastrup wrote:
> Andreas Krey 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 means t
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King 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 stale bits me
Andreas Krey 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 convergence in
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 t
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 t
Jeff King 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 clocks.
Jeff King 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) commitdate(chi
On Jan 14, 2014, at 21:36, Jason St. John wrote:
On Mon, Jan 13, 2014 at 12:55 PM, Junio C Hamano
wrote:
"Jason St. John" writes:
What AsciiDoc formatter (and version) do you use?
$ asciidoc --version
asciidoc 8.6.8
Checking with www.methods.co.nz/asciidoc, I am behind by about 2
m
From: Alexander Shopov
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 ++
1 file c
From: Alexander Shopov
Signed-off-by: Alexander Shopov
---
po/glossary/bg.po | 287 ++
1 file changed, 287 insertions(+)
create mode 100644 po/glossary/bg.po
diff --git a/po/glossary/bg.po b/po/glossary/bg.po
new file mode 100644
index 0
On Thu, Jan 9, 2014 at 10:05 PM, Mathieu Lemoine 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 @` gives "fa
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 for
From: Alexander Shopov
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 make review easier.
From: Alexander Shopov
Signed-off-by: Alexander Shopov
---
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 9b31f69..4093046 100644
--- a/po/glossary/git-
From: Alexander Shopov
Signed-off-by: Alexander Shopov
---
po/glossary/bg.po | 287 ++
1 file changed, 287 insertions(+)
create mode 100644 po/glossary/bg.po
diff --git a/po/glossary/bg.po b/po/glossary/bg.po
new file mode 100644
index 0
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)
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 pro
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 for
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
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 determining
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 --onelin
[+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
>
>
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
On Tue, Jan 14, 2014 at 02:42:09PM -0500, Martin Langhoff wrote:
> On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick 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 gc misconfigu
On 15 Jan 2014, at 00:24, Pete Wyckoff 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/:maste
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. Ru
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
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:".
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 NUL-
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
---
Obviously can be squashed with the prior refactori
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
simple
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 th
71 matches
Mail list logo