* [ANNOUNCE] Git 1.7.7.6
From: Junio C Hamano @ 2012-01-19 1:14 UTC (permalink / raw)
To: git
An maintenance release Git 1.7.7.6 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
483dc95de0e26f0154fb23444589266b59848cfe git-1.7.7.6.tar.gz
8bcbd0a53fd3b937a9991aa096220a1a0eb2f771 git-htmldocs-1.7.7.6.tar.gz
0fd7452c88d0b3ccb08d9b2b91b552680b0209e0 git-manpages-1.7.7.6.tar.gz
Also the following public repositories all have a copy of the v1.7.7.6
tag and the maint-1.7.7 branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.7.6 Release Notes
==========================
Fixes since v1.7.7.5
--------------------
* The code to look up attributes for paths reused entries from a wrong
directory when two paths in question are in adjacent directories and
the name of the one directory is a prefix of the other.
* A wildcard that matches deeper hierarchy given to the "diff-index" command,
e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
matching files even when there is no change.
* When producing a "thin pack" (primarily used in bundles and smart
HTTP transfers) out of a fully packed repository, we unnecessarily
avoided sending recent objects as a delta against objects we know
the other side has.
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.7.5 are as follows:
Clemens Buchacher (1):
Documentation: read-tree --prefix works with existing subtrees
Jack Nagel (1):
Add MYMETA.json to perl/.gitignore
Jeff King (4):
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Jens Lehmann (1):
docs: describe behavior of relative submodule URLs
Junio C Hamano (8):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Git 1.7.7.6
Nguyễn Thái Ngọc Duy (2):
t2203: fix wrong commit command
diff-index: enable recursive pathspec matching in unpack_trees
Thomas Rast (1):
Documentation: rerere.enabled is the primary way to configure rerere
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.4
From: Junio C Hamano @ 2012-01-19 1:15 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.7.8.4 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
add7b05f26216181d1b148dde298432132552b0f git-1.7.8.4.tar.gz
ac2b89d8d4418c7633ee2344e89eb7dfcb81522a git-htmldocs-1.7.8.4.tar.gz
4372c423a0d2f7df33b5b39727a81f0a7b40669d git-manpages-1.7.8.4.tar.gz
Also the following public repositories all have a copy of the v1.7.8.4
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.8.4 Release Notes
==========================
Fixes since v1.7.8.3
--------------------
* The code to look up attributes for paths reused entries from a wrong
directory when two paths in question are in adjacent directories and
the name of the one directory is a prefix of the other.
* A wildcard that matches deeper hierarchy given to the "diff-index" command,
e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
matching files even when there is no change.
* When producing a "thin pack" (primarily used in bundles and smart
HTTP transfers) out of a fully packed repository, we unnecessarily
avoided sending recent objects as a delta against objects we know
the other side has.
* "git send-email" did not properly treat sendemail.multiedit as a
boolean (e.g. setting it to "false" did not turn it off).
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.8.3 are as follows:
Jeff King (5):
send-email: multiedit is a boolean config option
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Junio C Hamano (11):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Prepare for 1.7.8.4
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.8.4
Git 1.7.7.6
Git 1.7.8.4
Nguyễn Thái Ngọc Duy (2):
t2203: fix wrong commit command
diff-index: enable recursive pathspec matching in unpack_trees
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9.rc2
From: Junio C Hamano @ 2012-01-19 1:16 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.9.rc2 is available for testing.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4eeaaf8a73006f797e6c23455097684664bf256e git-1.7.9.rc2.tar.gz
22aad76c146abe04e8f9bd89b2fbf4b575f434ce git-htmldocs-1.7.9.rc2.tar.gz
8565f64f6227fcfba3f768dabdcd9d6037f08842 git-manpages-1.7.9.rc2.tar.gz
Also the following public repositories all have a copy of the v1.7.9.rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.9 Release Notes (draft)
========================
Updates since v1.7.8
--------------------
* gitk updates accumulated since early 2011.
* git-gui updated to 0.16.0.
* git-p4 (in contrib/) updates.
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
locale is appropriately set. Distributors can drop in new PO files
in po/ to add new translations.
* The code to handle username/password for HTTP transaction used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
* The prompted input in the terminal use our own getpass() replacement
when possible. HTTP transactions used to ask username without echoing
back what was typed, but with this change you will see it as you type.
* The internal of "revert/cherry-pick" has been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
* "git rev-parse FETCH_HEAD" after "git fetch" without specifying
what to fetch from the command line will now show the commit that
would be merged if the command were "git pull".
* "git add" learned to stream large files directly into a packfile
instead of writing them into individual loose object files.
* "git checkout -B <current branch> <elsewhere>" is a more intuitive
way to spell "git reset --keep <elsewhere>".
* "git checkout" and "git merge" learned "--no-overwrite-ignore" option
to tell Git that untracked and ignored files are not expendable.
* "git commit --amend" learned "--no-edit" option to say that the
user is amending the tree being recorded, without updating the
commit log message.
* "git commit" and "git reset" re-learned the optimization to prime
the cache-tree information in the index, which makes it faster to
write a tree object out after the index entries are updated.
* "git commit" detects and rejects an attempt to stuff NUL byte in
the commit log message.
* "git commit" learned "-S" to GPG-sign the commit; this can be shown
with the "--show-signature" option to "git log".
* fsck and prune are relatively lengthy operations that still go
silent while making the end-user wait. They learned to give progress
output like other slow operations.
* The set of built-in function-header patterns for various languages
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
show information from the reflog entries when warlking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
instead of the tip of a topic branch. The GPG signature from the
signed tag is recorded in the resulting merge commit for later
auditing.
* "git log" learned "--show-signature" option to show the signed tag
that was merged that is embedded in the merge commit. It also can
show the signature made on the commit with "git commit -S".
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.
* "git fmt-merge-msg" learned to take the branch description into
account when preparing a merge summary that "git merge" records
when merging a local branch.
* "git request-pull" has been updated to convey more information
useful for integrators to decide if a topic is worth merging and
what is pulled is indeed what the requestor asked to pull,
including:
- the tip of the branch being requested to be merged;
- the branch description describing what the topic is about;
- the contents of the annotated tag, when requesting to pull a tag.
* "git pull" learned to notice 'pull.rebase' configuration variable,
which serves as a global fallback for setting 'branch.<name>.rebase'
configuration variable per branch.
* "git tag" learned "--cleanup" option to control how the whitespaces
and empty lines in tag message are cleaned up.
* "gitweb" learned to show side-by-side diff.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.8
------------------
Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).
----------------------------------------------------------------
Changes since v1.7.9-rc1 are as follows:
Jakub Narebski (2):
gitweb: Fix file links in "grep" search
gitweb: Harden "grep" search against filenames with ':'
Jeff King (3):
unix-socket: handle long socket pathnames
credential-cache: report more daemon connection errors
credential-cache: ignore "connection refused" errors
Jonathan Nieder (1):
unix-socket: do not let close() or chdir() clobber errno during cleanup
Junio C Hamano (4):
pulling signed tag: add howto document
Git 1.7.7.6
Git 1.7.8.4
Git 1.7.9-rc2
Michael Haggerty (2):
git-show-ref: fix escaping in asciidoc source
git-show-ref doc: typeset regexp in fixed width font
Nguyễn Thái Ngọc Duy (3):
Document limited recursion pathspec matching with wildcards
diff-index: enable recursive pathspec matching in unpack_trees
diff-index: enable recursive pathspec matching in unpack_trees
Thomas Rast (1):
word-diff: ignore '\ No newline at eof' marker
^ permalink raw reply
* Re: Cannot push a commit
From: Jeff King @ 2012-01-19 2:09 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git
In-Reply-To: <4F170E7E.9000804@fechner.net>
On Wed, Jan 18, 2012 at 07:25:02PM +0100, Matthias Fechner wrote:
> Am 17.01.2012 08:35, schrieb Matthias Fechner:
> > So the problem has something to do with windows as client. I will do
> > some additional test this evening.
> >
> > Where can we continue to search?
> [...]
> Then I opened the git bash and inserted:
> export GIT_SSH=plink.exe
> git push
> [...]
Thanks for following up on this. It does seem like openssh is dropping
your connection in a half-duplex way, though we don't know why. A bug in
openssh sounds like a reasonable candidate...
> The currently installed version is OpenSSH_4.6p1, OpenSSL 0.9.8e 23
> Feb 2007. Maybe an updated openssh version in the git bin folder will
> solve the problem?
Especially given how old your version is. Certainly I would try with a
more recent version. If it clears up the problem, I'm willing to assume
it's an openssh bug that's been fixed. If it doesn't, then it may be an
open openssh bug, or perhaps there is some problem in the way we're
invoking it on Windows. We can investigate that path if need be.
-Peff
^ permalink raw reply
* [BUG] Git bisect not finding the right commit
From: Andreas J. Koenig @ 2012-01-19 3:29 UTC (permalink / raw)
To: git
My git versions
---------------
1.7.9.rc2 and 1.7.8.3 and 1.7.2.5
The example output below was produced with 1.7.8.3 as provided by debian
"git/unstable uptodate 1:1.7.8.3-1"
The result looks the same on all three versions. I did not do a
byte-by-byte comparison, but the outcome is the same.
The repository
--------------
http://perl5.git.perl.org/perl.git
Problem description
-------------------
After v5.15.5-20-gfd76d40 a merge happened and v5.15.4-110-g27b29ec
through v5.15.4-169-g3582575 were inserted. The code was developed
before v5.15.5 but merged after v5.15.5.
- A -> B -> C - D ->
\ /
- E - F -
A v5.15.5
B v5.15.5-20-gfd76d40
C v5.15.5-81-gcfe287a
D v5.15.5-159-ga71d67b
E v5.15.4-110-g27b29ec
F v5.15.4-169-g3582575
The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A
and B. Bisect did not find it, it returned me E instead. Here the wrong
bisect output:
% git bisect start v5.15.5-159-ga71d67b v5.15.5
Already on 'blead'
Bisecting: 77 revisions left to test after this (roughly 6 steps)
[cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead
% git describe
v5.15.5-81-gcfe287a
% git bisect bad
Bisecting: 40 revisions left to test after this (roughly 5 steps)
[baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html
% git describe
v5.15.4-149-gbaf7658
% git bisect bad
Bisecting: 19 revisions left to test after this (roughly 4 steps)
[fbf24e084f7e43d3caa066f3520b4c32ebbb2e3a] Start modifying test cases to suit new Pod::Html
% git describe
v5.15.4-129-gfbf24e0
% git bisect bad
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[9949917516c8bca1036187e3e878ed8869558a65] Finish skeleton version of Pod::Html
% git describe
v5.15.4-119-g9949917
% git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[953c3c52c300d440cb8e0811a812e78c12d45695] Remove spurious code after start of parser switch
% git describe
v5.15.4-114-g953c3c5
% git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[2618a74b5307cde59d3b3111031637fbe4bfe0cf] Remove cache feature for simplicity
% git describe
v5.15.4-111-g2618a74
% git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[27b29ec338b08496d21538c0db7377d446529f8b] Remove deprecated --netscape flag
% git describe
v5.15.4-110-g27b29ec
% git bisect bad
27b29ec338b08496d21538c0db7377d446529f8b is the first bad commit
commit 27b29ec338b08496d21538c0db7377d446529f8b
Author: Marc Green <marcgreen@cpan.org>
Date: Mon May 16 23:46:07 2011 -0400
deprecated --netscape flag
:040000 040000 6759c516ef91450c73a01c5695051f31b787171e 080d58438a5c00aaaa6464f4c3a42c2ffd5f7ee0 M ext
% git version
git version 1.7.8.3
What I expected
---------------
The above result is wrong, git should have found v5.15.5-13-gff0cf12.
Git seemingly did not consider the revisions between v5.15.5 and
v5.15.5-20-gfd76d40.
Let me know if you need further informations. (I'm not subscribed to the
mailing list.)
Thanks && Regards,
--
andreas
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Johannes Sixt @ 2012-01-19 7:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Alex Riesen,
Git Mailing List
In-Reply-To: <7vfwfclf4v.fsf@alter.siamese.dyndns.org>
Am 1/19/2012 1:17, schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
>> ...
>>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>>> whether it works, or not.
>>
>> That's not what NO_GETTEXT means, and not what it *should* mean. It
>> means that your output won't be translated, but we might still make
>> use of a locally installed library to provide the gettext() and
>> eval_gettext() functions.
>
> You are right.
Sorry to disagree: We have, e.g., NO_MMAP, and I can set it to request
that some alternative is used, even if I have a working mmap(). The option
name "NO_GETTEXT" is in exactly the same spirit.
> In the current approach we take for shell scripts, we cannot have "No i18n
> whatsoever and messages are emit with printf and echo". We always have to
> go through gettext/eval_gettext even though they may be an implementation
> that does not do i18n at all.
Just like we go through _() in C code, even though there may be an
implementation that does not do i18n at all, right?
gettext/eval_gettext annotations are the shell equivalent of _()
annotations in C code, aren't they? Neither go away just by defining
NO_GETTEXT. It is just a quality-of-implementation issue that those
annotations have as little overhead as possible if NO_GETTEXT is defined.
In C, it is easy, in shell code it may be more involved.
-- Hannes
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: Nguyen Thai Ngoc Duy @ 2012-01-19 7:31 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Pete Harlan, Git Mailing List, Shawn Bohrer
In-Reply-To: <20120119002904.GA14107@burratino>
2012/1/19 Jonathan Nieder <jrnieder@gmail.com>:
> Pete Harlan wrote:
>
>> When a directory contains nothing but an ignored subdirectory, that
>> subdirectory does not get removed by "git clean -Xdf".
>>
>> For example, in a new directory:
>>
>> # git init
>> Initialized empty Git repository in /tmp/foo/.git/
>> # echo a/ >.gitignore
>> # git add .gitignore
>> # git commit -m "Initial commit"
>> [master (root-commit) c3af24c] Initial commit
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>> create mode 100644 .gitignore
>> # mkdir -p foo/a
>> # touch foo/a/junk.o
>> # git status
>> # On branch master
>> nothing to commit (working directory clean)
>> # git clean -Xdn # <--- DOES NOT MENTION foo/a
-X is to remove ignored files _only_ (DIR_SHOW_IGNORED flag). And
"foo" is not ignored according to .gitignore, so it cuts short there
and never gets to "foo/a". -x works. May be intentional, may be not
(we hit a corner case). I don't know. Commit message b991625 might
help:
dir.c: Omit non-excluded directories with dir->show_ignored
This makes "git-ls-files --others --directory --ignored" behave
as documented and consequently also fixes "git-clean -d -X".
Previously, git-clean would remove non-excluded directories
even when using the -X option.
--
Duy
^ permalink raw reply
* Re: [BUG] Git bisect not finding the right commit
From: Junio C Hamano @ 2012-01-19 8:20 UTC (permalink / raw)
To: Andreas J. Koenig; +Cc: git
In-Reply-To: <87r4yw8j4i.fsf@franz.ak.mind.de>
andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:
> A v5.15.5
> B v5.15.5-20-gfd76d40
> C v5.15.5-81-gcfe287a
> D v5.15.5-159-ga71d67b
> E v5.15.4-110-g27b29ec
> F v5.15.4-169-g3582575
>
> The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A
> and B. Bisect did not find it, it returned me E instead. Here the wrong
> bisect output:
Just for the sake of simplicity, I'll call ff0cf12 "Q" (the Questionable
one).
> % git bisect start v5.15.5-159-ga71d67b v5.15.5
You start by telling Git that D is bad and A is good.
I can see that D does contain Q (i.e. "git log D..Q" gives nothing), which
you should read as "D is _contaminated_ by the breakage Q introduced", so
D is indeed bad.
On the other hand, A does _not_ contain Q (i.e. "git log A..Q" gives
output), which you should read as "A is _not_ contaminated by the breakage
Q introduced", so A is indeed good.
So far so good...
> Already on 'blead'
> Bisecting: 77 revisions left to test after this (roughly 6 steps)
> [cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead
> % git describe
> v5.15.5-81-gcfe287a
This is your "C", and "git log C..Q" does not give anything. C is
contaminated by Q, hence it is bad.
> % git bisect bad
> Bisecting: 40 revisions left to test after this (roughly 5 steps)
> [baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html
> % git describe
> v5.15.4-149-gbaf7658
Here, baf7658 does not contain Q, so you are supposed to answer it is
GOOD.
> % git bisect bad
But you answered that it is BAD.
Why?
What caused you to say "bad" here to a commit that could not possibly have
inherited the breakage Q introduced?
One plausible explanation is that whatever symptom you are seeing in Perl
at version Q that you call "bad" may not be caused by a single root cause,
and a similar (or the same) symptom somehow appears at this version that
is _NOT_ contaminated by Q.
Another plausible scenario is that the symptom you are chasing may not be
reliably reproducible.
"bisection" by nature is an optimization technique applicable only when
you are chasing a reliably reproducible symptom that is caused by a single
cause, a breakage that existed in a single old version that is inherited
to all its descendants, and the "bad" symptom did not appear in any
version that does not inherit the breakage from that single problematic
commit. If you have a history A--B--C--D--E, in which B breaks something,
C fixes its breakage and then D reintroduces another breakage that shows
the same symptom, you can not optimize the search for a problem using
bisect. You need to check each and every version.
Of course, people sometimes simply get confused and mistakenly say BAD
when they wanted to say GOOD. That may be a simpler explanation of what
happened to your bisection.
Anyway, the remainder of your bisect sequence is GiGo, so I'll snip them
and will not quote.
^ permalink raw reply
* Re: [BUG] Git bisect not finding the right commit
From: Johannes Sixt @ 2012-01-19 8:23 UTC (permalink / raw)
To: Andreas J. Koenig; +Cc: git
In-Reply-To: <87r4yw8j4i.fsf@franz.ak.mind.de>
Am 1/19/2012 4:29, schrieb Andreas J. Koenig:
> - A -> B -> C - D ->
> \ /
> - E - F -
>
> A v5.15.5
> B v5.15.5-20-gfd76d40
> C v5.15.5-81-gcfe287a
> D v5.15.5-159-ga71d67b
> E v5.15.4-110-g27b29ec
> F v5.15.4-169-g3582575
I haven't looked at the actual history, but given the names of the commits
as produced by git-describe, I doubt that your history graph sketched
above is correct. Doesn't it look more like this:
A -- B -- C -- D --
/ /
-- X -- E -- F
where X is v5.15.4?
To find a commit between A and B, you must declare F as "good".
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-19 9:12 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20120117223949.GA811@padd.com>
On 17/01/12 22:39, Pete Wyckoff wrote:
> luke@diamand.org wrote on Mon, 16 Jan 2012 23:14 +0000:
>> Don't use shell expansion when detecting branches, as it will
>> fail if the branch name contains a shell metachar. Similarly
>> for labels.
>>
>> Add additional test for branches with shell metachars.
>
> Nice. There will be a fixup on a command in Vitor's series,
> depending on which goes first. He'll have a couple of
> un-listified read_pipe{,_lines} that we should treat similarly.
>
>> @@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
>> def getLabels(self):
>> self.labels = {}
>>
>> - l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
>> + l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
>> if len(l)> 0 and not self.silent:
>> print "Finding files belonging to labels in %s" % `self.depotPaths`
>
> I suspect the command "p4" "labels" "//depot/foo/... //depot/bar/..."
> might confuse p4, but haven't tested. Maybe tuck each one in its
> own argument?
>
> ["labels"] + ["%s..." % p for p in self.depotPaths]
Yes, you're right. I'll resubmit. I suspect the previous code was
actually broken as well as you end up with the "..." only on the last depot.
>
> What happened to your failing test? It's fun to keep the broken
> ones around to inspire others to fix them.
I'll send that one through as well. I actually had a fix, but it needs
to be reworked now. I'm reluctant to try to do much more on this though
unless someone can tell me how the --detect-labels code can ever really
work.
i.e. if you do:
p4 submit
git-p4 rebase --detect-labels
p4 tag LABEL_A
git-p4 rebase --detect-labels
At this point, LABEL_A won't show up in git until the _next_ p4 commit.
It's slowly working it's way towards the top of my todo list though!
Regards!
Luke
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
On Thu, Jan 19, 2012 at 00:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
>>
>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>> whether it works, or not.
>
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
I would never guess all that by its name: NO_GETTEXT. I wanted to
say: there is no gettext in this installation, don't even try it.
> This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
> and you want to change *everywhere* because you have some completely
> broken Cygwin install.
Just as I said.
> How did you even get that install? Is it a known issue? Some ancient
> now-fixed bug?
It is very likely. Or probably just a one installation problem: the
problem is not consistently everywhere here. Some installations
work (if slow).
> What version of Cygwin / gettext etc.
No idea. The person or persons who did this to me have no idea either.
> Now I'm not saying that we shouldn't fix this, I just don't think that
> this is the right way to go about it.
And I agree.
> But in summary: We shouldn't be *always* using fallback functions
> whether they're the C stuff in compat/* or the gettext fallbacks in
> git-sh-i18n.sh just because there's some version out there of the
> system-supplied functions that's broken.
>
> It makes sense to prefer the system functions by default in both
> cases, but when the OS one can be broken or lacking we can just add
> probes or Makefile options like we do for fnmatch() with the
> NO_FNMATCH_CASEFOLD switch.
Yes, and I personally shall welcome a chance to insult the local IT
by suggesting BROKEN_SH_GETTEXT. Not that they get the point...
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git Mailing List, Junio C Hamano, Ævar Arnfjörð
In-Reply-To: <20120119001225.GA13975@burratino>
On Thu, Jan 19, 2012 at 01:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> I like the unindenting. Alas, I get
>
> 1: test: type: unexpected operator
>
> I suspect this should just say "elif type gettext.sh >/dev/null 2>&1".
Indeed. Copy-paste error. I wonder why I didn't notice it...
Yes, ran the tests, both with and without NO_GETTEXT.
> The rest looks good. Thanks for writing it.
Was Junios idea, I just liked it.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, Git Mailing List
In-Reply-To: <7vfwfclf4v.fsf@alter.siamese.dyndns.org>
On Thu, Jan 19, 2012 at 01:17, Junio C Hamano <gitster@pobox.com> wrote:
> So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
> in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
> that correct?
I think yes.
> If that is the case, should we do something like
>
> LANG=C LC_ALL=C
> export LANG LC_ALL
>
> in our shell scripts, when building for NO_GETTEXT target?
Just for the record: gettext here stays broken with LANG and LC_ALL set to C.
But the locale-dependent formatting in C functions will change. Wont be a
problem here, though. The named formatting is broken, too: strftime, for
instance, always formats in C locale.
^ permalink raw reply
* [PATCHv4 0/5] git-p4: small fixes to branches and labels
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
This is the fourth version of some small fixes to git-p4 branch and
label handling, incorporating a fix from Pete Wyckoff and an
additional failing test.
This change does not fix the other problems with git-p4 labels:
- two p4 labels on the same changelist will fall over
- labels must match exactly the list of files imported
- you can't import a label without a p4 commit
Luke Diamand (5):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
git-p4: label import fails with multiple labels at the same
changelist
contrib/fast-import/git-p4 | 79 ++++++++++++++-----------
t/t9803-git-p4-shell-metachars.sh | 48 ++++++++++++++++
t/t9804-git-p4-label.sh | 113 +++++++++++++++++++++++++++++++++++++
3 files changed, 205 insertions(+), 35 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* [PATCHv4 1/5] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++---
t/t9803-git-p4-shell-metachars.sh | 48 +++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 5aacea8..163e95a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -799,7 +799,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1769,7 +1769,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels"] + ["%s..." % p for p in self.depotPaths])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1811,7 +1811,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1949,7 +1949,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9803-git-p4-shell-metachars.sh b/t/t9803-git-p4-shell-metachars.sh
index db04375..db67020 100755
--- a/t/t9803-git-p4-shell-metachars.sh
+++ b/t/t9803-git-p4-shell-metachars.sh
@@ -57,6 +57,54 @@ test_expect_success 'deleting with shell metachars' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 2/5] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 163e95a..5b59bc8 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1752,9 +1752,11 @@ class P4Sync(Command, P4UserMap):
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
self.gitStream.write("tagger %s\n" % tagger)
- self.gitStream.write("data <<EOT\n")
- self.gitStream.write(labelDetails["Description"])
- self.gitStream.write("EOT\n\n")
+
+ description = labelDetails["Description"]
+ self.gitStream.write("data %d\n" % len(description))
+ self.gitStream.write(description)
+ self.gitStream.write("\n")
else:
if not self.silent:
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 3/5] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 63 ++++++++++++++++++++++++-------------------
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 5b59bc8..58551b9 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -563,6 +563,26 @@ class Command:
class P4UserMap:
def __init__(self):
self.userMapFromPerforceServer = False
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
def getUserCacheFilename(self):
home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
@@ -700,7 +720,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -808,25 +827,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1675,6 +1675,12 @@ class P4Sync(Command, P4UserMap):
if self.stream_file.has_key('depotFile'):
self.streamOneP4File(self.stream_file, self.stream_contents)
+ def make_email(self, userid):
+ if userid in self.users:
+ return self.users[userid]
+ else:
+ return "%s <a@b>" % userid
+
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
@@ -1698,10 +1704,7 @@ class P4Sync(Command, P4UserMap):
committer = ""
if author not in self.users:
self.getUserMapFromPerforceServer()
- if author in self.users:
- committer = "%s %s %s" % (self.users[author], epoch, self.tz)
- else:
- committer = "%s <a@b> %s %s" % (author, epoch, self.tz)
+ committer = "%s %s %s" % (self.make_email(author), epoch, self.tz)
self.gitStream.write("committer %s\n" % committer)
@@ -1746,11 +1749,15 @@ class P4Sync(Command, P4UserMap):
self.gitStream.write("from %s\n" % branch)
owner = labelDetails["Owner"]
- tagger = ""
- if author in self.users:
- tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
+
+ # Try to use the owner of the p4 label, or failing that,
+ # the current p4 user id.
+ if owner:
+ email = self.make_email(owner)
else:
- tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
+ email = self.make_email(self.p4UserId())
+ tagger = "%s %s %s" % (email, epoch, self.tz)
+
self.gitStream.write("tagger %s\n" % tagger)
description = labelDetails["Description"]
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 4/5] git-p4: add test for p4 labels
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Add basic test of p4 label import. Checks label import and
import with shell metachars; labels with different length
descriptions.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 72 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
new file mode 100755
index 0000000..5fa2bcf
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,72 @@
+test_description='git-p4 p4 label tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+# Basic p4 label tests.
+#
+# Note: can't have more than one label per commit - others
+# are silently discarded.
+#
+test_expect_success 'basic p4 labels' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ echo f3 >main/file_with_\$metachar &&
+ p4 add main/file_with_\$metachar &&
+ p4 submit -d "file with metachar" &&
+
+ p4 tag -l tag_f1_only main/f1 &&
+ p4 tag -l tag_with\$_shell_char main/... &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ p4 label -i <<-EOF &&
+ Label: long_label
+ Description:
+ A Label first line
+ A Label second line
+ View: //depot/...
+ EOF
+
+ p4 tag -l long_label ... &&
+
+ p4 labels ... &&
+
+ "$GITP4" clone --dest="$git" --detect-labels //depot@all &&
+ cd "$git" &&
+
+ git tag &&
+ git tag >taglist &&
+ test_line_count = 3 taglist &&
+
+ cd main &&
+ git checkout tag_tag_f1_only &&
+ ! test -f f2 &&
+ git checkout tag_tag_with\$_shell_char &&
+ test -f f1 && test -f f2 && test -f file_with_\$metachar &&
+
+ git show tag_long_label | grep -q "A Label second line"
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 5/5] git-p4: label import fails with multiple labels at the same changelist
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
git-p4 has an array of changelists with one label per changelist.
But you can have multiple labels on a single changelist and so this
code fails.
Add a test case demonstrating the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
index 5fa2bcf..80d01ea 100755
--- a/t/t9804-git-p4-label.sh
+++ b/t/t9804-git-p4-label.sh
@@ -65,6 +65,47 @@ test_expect_success 'basic p4 labels' '
)
'
+# Test some label corner cases:
+#
+# - two tags on the same file; both should be available
+# - a tag that is only on one file; this kind of tag
+# cannot be imported (at least not easily).
+
+test_expect_failure 'two labels on the same changelist' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ p4 edit main/f1 main/f2 &&
+ echo "hello world" >main/f1 &&
+ echo "not in the tag" >main/f2 &&
+ p4 submit -d "main/f[12]: testing two labels" &&
+
+ p4 tag -l tag_f1_1 main/... &&
+ p4 tag -l tag_f1_2 main/... &&
+
+ p4 labels ... &&
+
+ "$GITP4" clone --dest="$git" --detect-labels //depot@all &&
+ cd "$git" &&
+
+ git tag | grep tag_f1 &&
+ git tag | grep -q tag_f1_1 &&
+ git tag | grep -q tag_f1_2 &&
+
+ cd main &&
+
+ git checkout tag_tag_f1_1 &&
+ ls &&
+ test -f f1 &&
+
+ git checkout tag_tag_f1_2 &&
+ ls &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* Re: Unexpected "clean -Xd" behavior
From: Jonathan Nieder @ 2012-01-19 10:03 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Pete Harlan, Git Mailing List, Shawn Bohrer
In-Reply-To: <CACsJy8AE+rwmOVUZez5GRXRHJsTy+W8ekzr59NTd7_C+gB0Byw@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> -X is to remove ignored files _only_ (DIR_SHOW_IGNORED flag). And
> "foo" is not ignored according to .gitignore, so it cuts short there
> and never gets to "foo/a". -x works.
Makes sense.
I guess the internal logic is that "git clean -fdX" cleans up files
that "git clean -fd" would miss, and this is not such a file ("git
clean -fd" removes it). But as Pete mentioned, in this edge case the
behavior renders "git clean -fdX" less effective than expected at its
primary task as poor man's "make clean".
I'd be happy to see a patch that moves to a different set of semantics
or an addition to t/t7300-clean.sh and BUGS section in
Documentation/git-clean.txt explaining the current limitations, if
someone wants to work on that.
Thanks, both.
Jonathan
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Thomas Rast @ 2012-01-19 10:24 UTC (permalink / raw)
To: Yves Goergen
Cc: Holger Hellmuth, Jeff King, Carlos Martín Nieto, git,
Erik Faye-Lund
In-Reply-To: <4F15B65A.8070009@unclassified.de>
Glad that you could fix your repository.
Yves Goergen <nospam.list@unclassified.de> writes:
> Just like that stupid autocrlf that causes more issues than it solves. I
> regularly see files with all lines changed and the diff says that both
> files only differ in line endings. But I have no sure observation on
> whether that value was set or unset in those cases. I'll have to look
> after that, too.
Just please remember what I tried to teach you in this thread: copy and
paste actual command invocations and outputs, and let us do the
interpretation. With CRLF problems, it may in addition help to pipe
through a utility that shows the presence or absence of \r, such as 'cat
-v'.
> These two config settings are not cloned with the repository, are they?
Neither config nor hooks are cloned.
> Also, TortoiseGit already sets ignorecase = true. So maybe the Visual
> Studio provider does the init on its own and is missing that. Or I have
> at some time cloned the repository and the setting wasn't copied over.
git-clone also autodetects the setting as part of initializing the
clone. (Copying over the repository from a case-sensitive medium using
a case-sensitive OS would of course leave it unset.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Interactive rebase with submodules
From: John Keeping @ 2012-01-19 10:48 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4F172DBB.4080303@web.de>
On 18/01/12 20:38, Jens Lehmann wrote:
> Am 18.01.2012 12:21, schrieb John Keeping:
>> On 17/01/12 21:29, Jens Lehmann wrote:
>>> Am 17.01.2012 19:47, schrieb John Keeping:
>>>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>>>
>>> The irony is that you would have to update submodules (or at least
>>> their HEAD and use "--ignore-submodules=dirty") while running rebase
>>> to make that work in all cases ;-)
>>
>> I don't this this is the case, since diff-tree is being invoked with --cached won't it ignore changes in the work tree anyway?
>
> Right, thanks for nudging me with the clue bat ...
>
> I missed the "--cached" option and did not question if the code does
> what the commit message of 6848d58c6 (where the --ignore-submodules
> option was introduced) said:
>
> Ignore dirty submodule states during rebase and stash
>
> When rebasing or stashing, chances are that you do not care about
> dirty submodules, since they are not updated by those actions anyway.
> So ignore the submodules' states.
>
> Note: the submodule states -- as committed in the superproject --
> will still be stashed and rebased, it is _just_ the state of the
> submodule in the working tree which is ignored.
>
> I think this logic misses the case when only submodule changes are left
> in a commit.
Yes, this is precisely the case that doesn't work as I expect.
>>> But just updating the HEAD would be dangerous as you would have to be
>>> very careful to restore the submodules HEAD after the rebase, or the
>>> submodule's work tree will be out of sync.
>>
>> Just updating HEAD in the submodule without touching its work tree doesn't seem like a good idea. I think it will cause a lot more confusion when running `git status` which will show unexpected modified content for the submodule.
>
> Yes, we agree here.
>
>> Since I did not expect rebase to perform a submodule update, I was not surprised to see unstaged submodule changes when rebasing, but I did expect rebase to commit anything I had added to the index.
>
> Right.
>
> I'll have to add some tests for that case, but I doubt I'll manage that
> today. Until I can provide a complete patch, this diff should fix your
> problem (no, I did not test if that change is enough to fix the problem,
> but at least it does not break the test suite ;-):
>
> ---------------8<--------------
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 5812222..4546749 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -672,7 +672,7 @@ rearrange_squash () {
> case "$action" in
> continue)
> # do we have anything to commit?
> - if git diff-index --cached --quiet --ignore-submodules HEAD --
> + if git diff-index --cached --quiet HEAD --
> then
> : Nothing to commit -- skip this
> else
This patch does indeed fix the problem I was seeing.
Thanks,
--
John
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Dieter Plaetinck @ 2012-01-19 10:52 UTC (permalink / raw)
To: Junio C Hamano, Jens Lehmann; +Cc: git
In-Reply-To: <7vobu0liwj.fsf@alter.siamese.dyndns.org>
On Wed, 18 Jan 2012 14:56:12 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Dieter Plaetinck <dieter@plaetinck.be> writes:
>
> > There is no need to restrict use of --ignore-missing to dry runs,
> > it can be useful to ignore missing files during normal operation as
> > well.
> >
> > Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
>
> Sorry, but for this kind of change, we would want to see a
> justification that is much better than that. The default around here
> is not to change an established behaviour without a good reason.
Hello Junio, thanks for your quick and elaborate response.
> Have you dug into the list archive to see _why_ we decided not to
> allow this option in the real run in the first place?
Actually I did, before submitting this patch.
From what I could find, the original patch [1] only cared about having this
feature available in dry run, and came with this "only in dry run" restriction,
merely because it was the only use case considered.
I couldn't find any evidence of this restriction actually being needed nor
any discussion of this matter. I added Jens to this mail, as he wrote
the original patch.
> You would need
> to find "By letting the command ignore missing paths, the user can
> get into X and Y situations and we would want to avoid it. We however
> need to give users a way to see if there is something missing, hence
> we add it when we are under dry-run option." and refute that previous
> justification, arguing why X and Y is something we should _not_ be
> worrying about, to make a good case for this change.
Yes, ignoring missing files can lead to files not actually being added, if they are missing.
But that's why this is an optional flag to needs to explicitly passed.
The flag is clear about what it does, so if users enable it, I don't see the problem?
> If somebody is writing a script using "git add" (which is not
> recommended to begin with), it is tempting to say 'git add
> $list_of_possible_files' in such a script when the script _knows_
> that the list it is giving to "git add" may contain a path that does
> not exist, and wants to ignore missing ones.
>
> But then the script could easily filter what does not exist before
> compiling such a list, so that is not a very strong reason to advocate
> it.
The use case is as follows:
I'm working on a tool [2] which runs in the background, and automatically synchronizes file/directory trees,
by using inotify events, and synchronizing changes in the working tree to the
index automatically, committing automatically and push/pulling automatically.
Basically for when you want to version a tree with git, but without needing to manually
commit all the time. (useful for a directory with notes as text files, for example)
the problem is, you can have a constant stream of inotify events (if files are being
edited/deleted/(re)created all the time), and at the point where my tool decides to automatically commit the changes it just saw,
more changes (deletes, renames, readding a file that was just deleted, ..) can happen around the same time.
So basically, if this tool needs to check which files still/no-longer exist before calling git-add,
that's vulnerable to race conditions.
The only real solution against race conditions is to deal with (ignore) missing files right at the point where git
adds them to the index.
But if "git add" is not the right way, please let me know the alternative.
From what I can find "git add --all --ignore-missing <file>" (with my patch for allowing ignore-missing without dry run) would be the most appropriate,
this would never accidentially modify the working tree (as "git rm" for a deleted file could, if the file gets readded at the same point
where we call git), and it would gracefully handle changes we didn't see yet (such as new/modified files disappearing again)
thanks again for the feedback,
Dieter
[1] http://kerneltrap.org/mailarchive/git/2010/7/9/34077
[2] https://gitorious.org/search?q=dvcs-autosync
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Thomas Rast @ 2012-01-19 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobu0liwj.fsf@alter.siamese.dyndns.org>
[dropped Dieter as this really goes off on an internal tangent]
Junio C Hamano <gitster@pobox.com> writes:
> If somebody is writing a script using "git add" (which is not recommended
> to begin with)
Can we still stick to that stance? Our tests are increasingly using
'git add' instead of 'git update-index --add':
$ git grep 'git[ -]add' t/ | wc -l
1540
$ git grep 'git[ -]update-index --add' t/ | wc -l
269
$ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l
251
$ git grep 'git[ -]add' v1.6.0 t/ | wc -l
705
So while git(1) still says git-add is porcelain (and thus not to be used
for scripting), it has mostly superseded 'git update-index --add' in new
script usage even within git.git. I suspect the same goes for things
like git-rm, git-commit, etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-19 13:21 UTC (permalink / raw)
To: git
Hello,
I first posted that message on the group for msysgit [1].
====
I'm using mysgit 1.7.8 on XP.
I think the stash name completion has a problem.
I don't know if it's a problem from my system, mysgit or git.
Here are the steps to reproduce (you need to have at least 2 stashed commits).
'+ tab =>' means using the tab to autocomplete the current command. Left part is
before completion, right tab is after completion.
$ git stash list
stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
lot de 10.000 contrats
stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
$ git stash drop '+ tab =>' $ git stash drop stash@{
$ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
I don't know if it's relevant, but I also have 'git flow' and 'git flow
completion' installed, and as said in a previous thread, 'git flow completion'
isn't working with alias [2].
====
Regards,
Mathieu CLAVEL
[1] https://groups.google.com/d/topic/msysgit/AgGY7wl8IJQ/discussion
[2] https://groups.google.com/d/msg/msysgit/UnBHlY9eAK0/JfdH7q2hcsAJ
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox