* Re: log: option "--follow" not the default for a single file?
From: Ralf Thielow @ 2011-11-30 18:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net>
> pathspec. That may happen to match a single file in the current> revision, but to git it is actually a prefix-limiting pattern, and
Is it possible to detect the case of a single file in the current
revisionand use "--follow" by default for exactly that?
^ permalink raw reply
* Re: log: option "--follow" not the default for a single file?
From: Junio C Hamano @ 2011-11-30 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Ralf Thielow, git
In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 2. It can be slower than a regular traversal, since we have to do
> rename detection whenever we see a deletion. In practice I don't
> think it is much slower, though (mainly because files don't get
> moved all that much).
There is no difference between a regular traversal and a follow traversal
while the path is still there. When a path disappear during a regular
traversal, most likely the remaining traversal will yield nothing but the
user has already seen what is there to see. If a follow traversal was in
use, the user has seen the same as the regular traversal up to that point,
we spend a bit of time in rename detection, and then we start showing the
result of the traversal using an updated pathspec. I doubt that "slowness"
is an issue here.
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Carlos Martín Nieto @ 2011-11-30 18:22 UTC (permalink / raw)
To: John Twilley; +Cc: git
In-Reply-To: <CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4175 bytes --]
On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:
> Today someone asked me if there was a way to run git against a
> directory other than the current directory. I looked at the output of
> --help and ran this:
>
> $ git --work-tree blah status
>
> I got the following output:
>
> fatal: Not a git repository (or any parent up to mount parent /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>
> I mistakenly thought the error message meant that blah was not a git
> repository. What it meant was that there was no .git in the current
> directory or any parent directory up to /home.
Yes, git looks at the current directory and .git/ to see if there's a
git repository there. This is what happens unless you tell git to look
for it somewhere else.
>
> This command worked as expected:
>
> $ git --work-tree blah --git-dir blah/.git status
>
> The documentation is somewhat fuzzy about what constitutes a git
> repository. The gittutorial describes the git repository as .git when
> talking about "git init" while the Git User's Manual describes the git
> repository as the working tree and the special top-level directory
> named .git when talking about "git clone".
A git repository is what's under .git/ (or in foo.git/ for bare
repos). Non-bare repositories have a working tree associated with
them, which by default lives just above the repository, because it'd
be silly to have it somewhere else by default. Often you can think of
both as the repository, as they're both. When you tell git to look for
the worktree somewhere else, you're only overriding that particular
variable, as git expects to be run from the repository (or just above,
in the worktree).
>
> It's clear (to me at least) that --work-tree should be used to
> identify the root of the working tree when not inside the working
> tree. I expected that the git directory would be automatically set to
> .git in the root of the working tree, as that would match the
> documentation. Instead, the current directory and its parents were
> checked -- which could provide dangerously misleading information to
> the user.
What part of the documentation exactly? --work-tree tells git to look
for the working tree somewhere else. This option exists in order to
support a multiple-workdir workflow.
>
> I think that one of two things should be done: either the --git-dir
> default should be changed when the --work-tree option is set, or the
> error message cited above should be changed to explicitly identify the
> directory being tested as a potential git repository. I personally
Git does tell you explicitly, but only when you specify a gitdir (via
GIT_DIR or --git-dir), otherwise it looks at the current directory.
> believe the first option is superior because it fulfills the
> expectations of average users (folks who read git's documentation
> instead of its source code) while permitting flexibility to those who
It's not likely that it will get changed because that would break
backwards-compatability in a very big way. If your concern is for
"average user", she shouldn't be using that option, but changing to
that directory instead. If you want your working tree to be ./foo/ and
your gitdir to be ./foo/.git, why don't you just cd to ./foo/?
> wish to refer to the current directory or some other directory for
> their --git-dir value. If the current behavior is somehow not a bug
> but instead a critical and significant feature which if changed would
> cause more harm than good, please consider the second option.
You get two different messages depending on how git is looking for the
repository. The message you mentioned gets printed when git tries to
find it automatically. A "fatal: Not a git repository: '/tmp'" gets
printed if you've told git to look for it in a specific place. The
information is already there, though I guess you do have to know about
the difference. Adding the current directory to the "default" message
probably wouldn't hurt, as it's unlikely that a script is parsing
that, and might be useful.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Junio C Hamano @ 2011-11-30 18:05 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jeff King, Bill Zaumen, git, gitster, spearce, torvalds
In-Reply-To: <CACsJy8A6kGmn0h0xdxfTC4krXgc8hzO1fHTdqfk0YnASGN5K0w@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> What I'm thinking is whether it's possible to decouple two sha-1 roles
> in git, as object identifier and digest, separately.
Why it would be a good thing? If you have a collided identifier, somebody
has to choose which blob a particular tree wants to have at the path, and
because the tree would not record anything but the identifier, you cannot.
> ...
> The day sha-1 is broken, a project can generate new digests from its
> old good repo and enforce developers to use new digests for
> verification instead of sha-1. sha-1 is still used by git as
> identifier after that day.
And an old blob that is identified with a SHA-1 now has a new blob that
has different contents but happens to have the same SHA-1. How does Git
decide which blob to use when a particular object is named by the SHA-1?
^ permalink raw reply
* BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: John Twilley @ 2011-11-30 17:43 UTC (permalink / raw)
To: git
Today someone asked me if there was a way to run git against a
directory other than the current directory. I looked at the output of
--help and ran this:
$ git --work-tree blah status
I got the following output:
fatal: Not a git repository (or any parent up to mount parent /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
I mistakenly thought the error message meant that blah was not a git
repository. What it meant was that there was no .git in the current
directory or any parent directory up to /home.
This command worked as expected:
$ git --work-tree blah --git-dir blah/.git status
The documentation is somewhat fuzzy about what constitutes a git
repository. The gittutorial describes the git repository as .git when
talking about "git init" while the Git User's Manual describes the git
repository as the working tree and the special top-level directory
named .git when talking about "git clone".
It's clear (to me at least) that --work-tree should be used to
identify the root of the working tree when not inside the working
tree. I expected that the git directory would be automatically set to
.git in the root of the working tree, as that would match the
documentation. Instead, the current directory and its parents were
checked -- which could provide dangerously misleading information to
the user.
I think that one of two things should be done: either the --git-dir
default should be changed when the --work-tree option is set, or the
error message cited above should be changed to explicitly identify the
directory being tested as a potential git repository. I personally
believe the first option is superior because it fulfills the
expectations of average users (folks who read git's documentation
instead of its source code) while permitting flexibility to those who
wish to refer to the current directory or some other directory for
their --git-dir value. If the current behavior is somehow not a bug
but instead a critical and significant feature which if changed would
cause more harm than good, please consider the second option.
Jack.
--
mathuin at gmail dot com
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Thomas Rast @ 2011-11-30 16:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier wrote:
> When a revision is specified on the commandline we explicitly output
> a 'reset' command for it if it was not handled already. This allows
> for example the remote-helper protocol to use fast-export to create
> branches that point to a commit that has already been exported.
>
> Initial-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
My apologies if this is redundant, I'm not up to speed on progress
here. But a crash in t9350.19 caught my eye:
checking known breakage:
(
cd limit-by-paths &&
git fast-export master~2..master~1 > output &&
test_cmp output expected
)
==23766== Invalid read of size 1
==23766== at 0x4FD21E: prefixcmp (strbuf.c:9)
==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563)
==23766== by 0x42C274: cmd_fast_export (fast-export.c:732)
==23766== by 0x4051F1: run_builtin (git.c:308)
==23766== by 0x40538B: handle_internal_command (git.c:466)
==23766== by 0x4054A5: run_argv (git.c:512)
==23766== by 0x40562C: main (git.c:585)
==23766== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23766==
{
<insert_a_suppression_name_here>
Memcheck:Addr1
fun:prefixcmp
fun:handle_tags_and_duplicates
fun:cmd_fast_export
fun:run_builtin
fun:handle_internal_command
fun:run_argv
fun:main
}
==23766==
==23766== Process terminating with default action of signal 11 (SIGSEGV)
==23766== Access not within mapped region at address 0x0
==23766== at 0x4FD21E: prefixcmp (strbuf.c:9)
==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563)
==23766== by 0x42C274: cmd_fast_export (fast-export.c:732)
==23766== by 0x4051F1: run_builtin (git.c:308)
==23766== by 0x40538B: handle_internal_command (git.c:466)
==23766== by 0x4054A5: run_argv (git.c:512)
==23766== by 0x40562C: main (git.c:585)
The crash is hidden by the fact that the test is test_expect_failure.
It bisects to this commit. Perhaps we should distinguish between
test_expect_failure and test_expect_crash?...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-30 15:52 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <1322668371-21218-1-git-send-email-andrew.kw.w@gmail.com>
"commit --amend" could fail in cases like the user empties the commit
message, or pre-commit failed. When it fails, rebase should be
interrupted and alert the user, rather than ignoring the error and
continue on rebasing. This also gives users a way to gracefully
interrupt a "reword" if they decided they actually want to do an "edit",
or even "rebase --abort".
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
---
git-rebase--interactive.sh | 36 +++++++++++++++++++++++-------------
1 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 804001b..5812222 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -143,6 +143,21 @@ die_with_patch () {
die "$2"
}
+exit_with_patch () {
+ echo "$1" > "$state_dir"/stopped-sha
+ make_patch $1
+ git rev-parse --verify HEAD > "$amend"
+ warn "You can amend the commit now, with"
+ warn
+ warn " git commit --amend"
+ warn
+ warn "Once you are satisfied with your changes, run"
+ warn
+ warn " git rebase --continue"
+ warn
+ exit $2
+}
+
die_abort () {
rm -rf "$state_dir"
die "$1"
@@ -408,7 +423,13 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- git commit --amend --no-post-rewrite
+ git commit --amend --no-post-rewrite || {
+ warn "Could not amend commit after successfully picking $sha1... $rest"
+ warn "This is most likely due to an empty commit message, or the pre-commit hook"
+ warn "failed. If the pre-commit hook failed, you may need to resolve the issue before"
+ warn "you are able to reword the commit."
+ exit_with_patch $sha1 1
+ }
record_in_rewritten $sha1
;;
edit|e)
@@ -417,19 +438,8 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- echo "$sha1" > "$state_dir"/stopped-sha
- make_patch $sha1
- git rev-parse --verify HEAD > "$amend"
warn "Stopped at $sha1... $rest"
- warn "You can amend the commit now, with"
- warn
- warn " git commit --amend"
- warn
- warn "Once you are satisfied with your changes, run"
- warn
- warn " git rebase --continue"
- warn
- exit 0
+ exit_with_patch $sha1 0
;;
squash|s|fixup|f)
case "$command" in
--
1.7.8.rc3.32.gb0399.dirty
^ permalink raw reply related
* Re: [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-30 15:52 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <7vk46isncq.fsf@alter.siamese.dyndns.org>
On 11-11-29 3:08 PM, Junio C Hamano wrote:
> Is there anything we should be saying more than "fatal: Cannot amend" to
> help users when this new "die" triggers?
Ah, yes, that would be helpful.
The situation is actually very similar to an "edit", where a pick is successful
but requires user intervention. So I'm planning to refactor the behavior and
message from "edit" into a function called "exit_with_patch". Then call the
function from "reword" as well. Though it bothers me a bit that I have to pass
in an exit code as well, since we want the exit status for "reword" to indicate
a failure, but "edit" needs to indicate a success. Is this acceptable? Or
should I just not bother with refactoring?
Andrew Wong (1):
rebase -i: interrupt rebase when "commit --amend" failed during
"reword"
git-rebase--interactive.sh | 36 +++++++++++++++++++++++-------------
1 files changed, 23 insertions(+), 13 deletions(-)
--
1.7.8.rc3.32.gb0399.dirty
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Vitor Antunes @ 2011-11-30 14:55 UTC (permalink / raw)
To: git
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
Luke Diamand <luke <at> diamand.org> writes:
> In adding the test case for labels I also found and fixed a few other
> small bugs in the label handling:
>
> - labels missing a description or "EOT" in their text cause problems;
> - labels without an owner cause problems.
>
> I also noticed, but did not fix, that you can't have more than one label
> per commit (the others are silently dropped) and the documentation for
> branch import could be improved. I've added a (failing) test case for
> the multiple label problem.
Hi Luke,
Seeing that you have some experience using labels, could I kindly ask you to
include some description of it in git-p4.txt?
Thanks,
Vitor
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Nguyen Thai Ngoc Duy @ 2011-11-30 13:35 UTC (permalink / raw)
To: Jeff King; +Cc: Bill Zaumen, git, gitster, spearce, torvalds
In-Reply-To: <20111129205905.GA1793@sigill.intra.peff.net>
On Wed, Nov 30, 2011 at 3:59 AM, Jeff King <peff@peff.net> wrote:
> If you wanted to say "make a digest of all of the sub-objects pointed to
> by the tag", then yes, that does work (security-wise). But it's
> expensive to calculate. Instead, you want to use a "digest of digests"
> as much as possible. Which is what git already does, of course; you hash
> the tree object, which contains hashes of the blob sha1s. Git's
> conceptual model is fine. The only problem is that sha1 is potentially
> going to lose its security properties, weakening the links in the chain.
> So as much as possible, we want to insert additional links at the exact
> same places, but using a stronger algorithm.
What I'm thinking is whether it's possible to decouple two sha-1 roles
in git, as object identifier and digest, separately. Each sha-1
identifies an object and an extra set of digests on the "same" object.
Object database is extended to store all these new digests and mapping
between sha-1 and them. When we need to verify an object, given an
sha-1, we rehash that object and check the result digest with the ones
linked to the sha-1.
These new digests would be "digest of digests" just like how we use
sha-1. In fact this new digest set could be just sha-1. We just don't
hash trees/commits/tags as-is when computing these new digests. When a
tree object is hashed, for example, a new tree object with new digests
will be created for hashing (we keep sha-1 <-> new digest mapping on
disk). Think of duplicating an entire DAG with new digests as links
instead of sha-1, then we keep digests and drop the DAG.
The day sha-1 is broken, a project can generate new digests from its
old good repo and enforce developers to use new digests for
verification instead of sha-1. sha-1 is still used by git as
identifier after that day.
Computing these digests is expensive, but for local, day-to-day use,
we only need sha-1 as identifier (correct me if I'm wrong here), so we
can delay compute/store these new digests until we absolutely need
them (e.g. push/fetch). There is also an interesting case, assume
these digests are strong enough, we could replace sha-1 as identifier
in git with a cheaper hash. A new hash must fit in 160-bit space that
sha-1 takes and should have good distribution, of course. Projects
with a lot of data may like it that way.
--
Duy
^ permalink raw reply
* Status after 'git clone --no-checkout' ?
From: norbert.nemec @ 2011-11-30 13:02 UTC (permalink / raw)
To: git
Hi there,
what exactly is the status after 'git clone --no-checkout'? Is there any
straightforward way how one could end up in this state starting from a
regularly checked out repository?
A somewhat related question:
'git checkout' without any further options serves to move from the
aforementioned special state to a regular checked out state. Otherwise
it never seems to do anything. Are there any other situations where 'git
checkout' on its own would have any effect?
Thanks for any insight on this!
Norbert Nemec
^ permalink raw reply
* Re: two branches: keep one difference but merge others forth and back
From: Tor Arntsen @ 2011-11-30 12:37 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jats5v$r7c$1@dough.gmane.org>
On Sun, Nov 27, 2011 at 18:31, Gelonida N <gelonida@gmail.com> wrote:
> Hi,
>
>
> Is this possible.
>
>
> I'd like to have two branches.
>
> If possible I would be able to merge forth and back between both of them.
>
> However I would like, that certain differences will be kept between both
> branches.
>
> Is there any way to tell git to permanently ignoring certain commits
> from merging?
Instead of merging, you could use rebasing. So you have one
development branch where you do all the changes, and then another
branch where the only commit there is that special difference (as in
your /usr/bin/bash example). From then on you only develop/maintain
the original branch, and then you rebase the 'special' branch on top
of the development branch. Then you get all the updates, plus your
special change applied on top each time.
Likewise, if you have two variants (say, one /bin/bash, another
/usr/bin/bash, and then one with /usr/local/bin/bash) then create two
branches and rebase them on top of the third branch (the development
branch) every time you wish to deploy new updates.
-Tor
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-30 11:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111130070111.GE5317@sigill.intra.peff.net>
On Wed, Nov 30, 2011 at 9:01 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 22, 2011 at 01:47:36AM +0200, Felipe Contreras wrote:
>
>> > I didn't mean "you didn't define a mirror in your config". I meant "your
>> > question is not well-defined, because you haven't defined the term
>> > 'mirror'". IOW, I can't answer your question without knowing exactly
>> > what you meant.
>>
>> I wasn't the one that brought the mirror up, you did:
>
> Yes, because that is the most related concept in current git. But I
> thought you were asking from the perspective of a clueless user, and I
> don't know what that clueless user meant by "mirror".
I don't think common users know, or should care about, what a "mirror" is.
> Anyway, I don't think it's important.
Me neither.
> I read over your whole message, and I feel like our discussion isn't
> really moving towards an actual goal. Junio and I both mentioned that in
> the long-term, features like this should be part of "push", not
> "remote". Do you want to try revising your patch in that direction?
Yes, I can try that for 'git push', but my worry is about 'git fetch'.
To me it's really clear that what I am trying to achieve is more
complicated than a simple push/fetch.
You still haven't replied to my solution to synchronize the local
branches, which to first do a 'git fetch' so we have the remote
branches tracked locally, and go through each one of them and do
something to the local ones. This solution works, is simple, and
allows all kinds of options, but IMO it's not part of 'git fetch'.
> That will give us something concrete to talk about (and hopefully
> apply).
Yes, but that's basically 'git push --prune', which I think is the
only thing we have agreed. But what about the rest?
I feel you are trying to ignore the fact that 'refs/heads/*' is not
user-friendly, neither is BRANCHES, or :, and 'git fetch' would be
even more cumbersome.
The user-friendliness of git is one of the biggest complains people
have, and while it makes sense to keep certain operations under
push/fetch, there's only so much pureness we can have before things
become too complicated for the users. The fact of the matter is that
these particular remote synchronization operations are much easier to
picture mentally in a group like 'git remote sync'. That not only
works for all the cases, including 'git fetch', but it's
non-intrusive, and most importantly: user-friendly.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCHv2 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-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 | 45 +++++++++++++++++++++++--------------------
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 02f0f54..d97f927 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -553,6 +553,27 @@ class Command:
def __init__(self):
self.usage = "usage: %prog [options]"
self.needsGit = True
+ 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
+
class P4UserMap:
def __init__(self):
@@ -694,7 +715,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:
@@ -802,25 +822,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 = ""
@@ -1506,7 +1507,9 @@ class P4Sync(Command, P4UserMap):
owner = labelDetails["Owner"]
tagger = ""
- if author in self.users:
+ if not owner:
+ tagger = "%s <a@b> %s %s" % (self.p4UserId(), epoch, self.tz)
+ elif author in self.users:
tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv2 4/4] git-p4: add test for p4 labels
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-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.
Add failure test case for multiple labels.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 114 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 114 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..a46763f
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,114 @@
+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 ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ 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 some label corner cases:
+#
+# - two tags on the same file; both should be available
+# - a tag that is only on one file; the other file should
+# not be checked out on the tag.
+
+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/f1 &&
+ p4 tag -l tag_f1_2 main/f1 &&
+
+ p4 labels ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ git tag | grep -q tag_f1_1 &&
+ git tag | grep -q tag_f1_2 &&
+
+ cd main &&
+
+ git checkout tag_tag_f1_1 &&
+ test -f f1 &&
+
+ git checkout tag_tag_f1_1 &&
+ test -f f1 &&
+
+ ! test -f f2
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv2 2/4] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-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 bcac6ec..02f0f54 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1511,9 +1511,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
* [PATCHv2 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-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/t9801-git-p4-branch.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index b975d67..bcac6ec 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -793,7 +793,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':
@@ -1528,7 +1528,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`
@@ -1570,7 +1570,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(" ")
@@ -1708,7 +1708,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/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index a25f18d..bd08dff 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -226,6 +226,54 @@ test_expect_success 'git-p4 clone simple branches' '
)
'
+# 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
* [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
This is a small set of patches to git-p4 to fix a couple of issues with
branches and labels.
This is the second version of this patch series; the first one vanished
without trace :-)
Firstly, I've added the fixes needed so that branches and labels can
contain shell metacharacters (missed from the previous series). Added
a test case for this.
In adding the test case for labels I also found and fixed a few other
small bugs in the label handling:
- labels missing a description or "EOT" in their text cause problems;
- labels without an owner cause problems.
I also noticed, but did not fix, that you can't have more than one label
per commit (the others are silently dropped) and the documentation for
branch import could be improved. I've added a (failing) test case for
the multiple label problem.
Luke Diamand (4):
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
contrib/fast-import/git-p4 | 61 +++++++++++++-----------
t/t9801-git-p4-branch.sh | 48 ++++++++++++++++++
t/t9804-git-p4-label.sh | 114 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 195 insertions(+), 28 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* Re: [HELP] Adding git awareness to the darning patch management system.
From: Tay Ray Chuan @ 2011-11-30 9:04 UTC (permalink / raw)
To: Peter Williams; +Cc: git
In-Reply-To: <4ED59232.3000807@users.sourceforge.net>
On Wed, Nov 30, 2011 at 10:17 AM, Peter Williams
<peter_ono@users.sourceforge.net> wrote:
> I'm the author of the darning patch management system
> <http://darning.sourceforge.net/> and would like some help adding git
> awareness to the system. At this stage of the development, "awareness" is
> fairly simple concept with two broad aims:
That link says it "combines the strengths of quilt and mq and
eliminates their weaknesses", but I don't see any info on why this is
the case with your program; it would be great it if you could provide
a quick start guide (probably easier to show this with some commands
in the CLI rather than GUI screenshots).
Have a look at StGit's tutorial
http://www.procode.org/stgit/doc/tutorial.html (very similar to quilt
and mq too) to see what I mean.
--
Cheers,
Ray Chuan
^ permalink raw reply
* I Await Your Response
From: Robert Bingham @ 2011-11-30 16:40 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 68 bytes --]
Hello,
kindly read through the mesasge attached and promptly reply
[-- Attachment #2: Message From Bingham Robert.rtf --]
[-- Type: application/octet-stream, Size: 3340 bytes --]
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Jens Lehmann @ 2011-11-30 8:31 UTC (permalink / raw)
To: Max Krasnyansky; +Cc: git
In-Reply-To: <4ED57EED.4040705@qualcomm.com>
Am 30.11.2011 01:55, schrieb Max Krasnyansky:
> Does anyone have a pointer to a thread/discussion that explains why git submodules are not auto
> updated when the superproject is updated (merge, reset, etc) by default?
This is because in current git a submodules work tree gets only updated
when running "git submodule update". A default auto update wouldn't be
backwards compatible (and some users really like it the way it is now).
I'm working on a patch series to teach Git to optionally update the
submodules work trees on checkout, reset merge and so on, but I'm not
there yet.
> Assuming a simple and default setup where submodule update policy is set to "checkout".
> It seems that the default and sane behavior should be to update (checkout) corresponding submodule
> commit to track the superproject.
I agree, but we should decide about a sane default when the feature is
there. In the first version it will be off by default, so people can make
up their minds about breaking backwards compatibility.
> I can't seem to find convincing explanation why it's not the case :). Having to manually update
> submodules after pull or reset has been error prone and confusing for the devs I work with.
Yes, we even had some mis-merges because of that.
> I'm thinking about adding a config option that would enable automatic submodule update but wanted
> to see if there is some fundamental reason why it would not be accepted.
I think adding something like an "submodule.autoupdate" config makes lots
of sense, but IMO it should affect all work tree updating porcelain commands,
not just merge.
^ permalink raw reply
* Re: [HELP] Adding git awareness to the darning patch management system.
From: Jeff King @ 2011-11-30 7:22 UTC (permalink / raw)
To: Peter Williams; +Cc: git
In-Reply-To: <4ED59232.3000807@users.sourceforge.net>
On Wed, Nov 30, 2011 at 12:17:22PM +1000, Peter Williams wrote:
> 1. presenting the file tree of the sources being patched in a way
> that makes sense to the user including the current status of files
> from the point of view of the underlying SCM (in this case, git), and
I'm not exactly sure what this means.
> 2. detecting files with uncommitted changes (from the SCM's point of
> view) when the user adds them to a patch (or pushes a patch that
> contains them) so that they may be alerted to the fact and offered
> the choice of absorbing the uncommitted changes into the patch (or
> not).
For this, you probably want "git diff-files --name-only", which will
show files with differences in the working tree. Keep in mind that git
has an "index" or "staging area", which means that you have three states
of content for a given path:
1. the state of the prior commit (i.e., HEAD)
2. the state that is marked to be committed when "git commit" is run
(i.e., the index)
3. the state in the working tree
You can compare the first two with "git diff-index", and the latter two
with "git diff-files". You can also use "git status --porcelain" to get
a machine-readable output that shows how the three states match up, with
one line per file.
> I've already implemented this interface for Mercurial (with which I
> am familiar) and looked at doing the same with git but had difficulty
> discovering the definitive mechanisms for obtaining the necessary
> data. So I'm soliciting your help in overcoming these problems.
I hope the above helps you some. If not, just ask. It might be easier to
understand what you are looking for if you can give concrete examples.
-Peff
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Jeff King @ 2011-11-30 7:15 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4EC12E8B.3050909@workspacewhiz.com>
On Mon, Nov 14, 2011 at 08:06:51AM -0700, Joshua Jensen wrote:
> __This is a genuine data loss problem in Git.__
>
> I'm confused at the lack of response to this. I first posted about
> the issue **2-1/2 weeks ago**, and there have been no responses Does
> no one care?
Still not much response.
I think the keywords "submodule" and "fast-export" in the subject line
hit a lot of people's do-not-care filters.
I read your original two messages. It does seem like a simple ordering
problem from your description. I suspect you would get more response to
actually post your patch with a commit message explaining the problem,
and an accompanying test. And then at the very least, one outcome could
be Junio picking up the patch. :)
I think you have all of those components spread across your messages,
and just need to polish them and put them in one place.
Regarding your patch itself, your explanation make sense to me and the
goal of your patch looks reasonable. Bearing in mind that I know
virtually nothing about the innards fast-import/fast-export.
But for the patch text itself:
> @@ -161,6 +161,14 @@ static int depth_first(const void *a_, const void *b_)
> name_a = a->one ? a->one->path : a->two->path;
> name_b = b->one ? b->one->path : b->two->path;
> + /*
> + * Move 'D'elete entries first.
> + */
> + if (a->status == 'D')
> + return -1;
> + else if (b->status == 'D')
> + return 1;
> +
> len_a = strlen(name_a);
> len_b = strlen(name_b);
> len = (len_a < len_b) ? len_a : len_b;
If you have multiple deleted entries, doesn't this leave them in a
random order at the beginning of the list? Does that matter? If they are
both 'D', should they be compared as usual? I.e.:
if (a->status != b->status) {
if (a->status == 'D')
return -1;
if (b->status == 'D')
return 1;
}
/* and now we do the rest of the function as usual... */
-Peff
^ permalink raw reply
* [HELP] Adding git awareness to the darning patch management system.
From: Peter Williams @ 2011-11-30 2:17 UTC (permalink / raw)
To: git
I'm the author of the darning patch management system
<http://darning.sourceforge.net/> and would like some help adding git
awareness to the system. At this stage of the development, "awareness"
is fairly simple concept with two broad aims:
1. presenting the file tree of the sources being patched in a way that
makes sense to the user including the current status of files from the
point of view of the underlying SCM (in this case, git), and
2. detecting files with uncommitted changes (from the SCM's point of
view) when the user adds them to a patch (or pushes a patch that
contains them) so that they may be alerted to the fact and offered the
choice of absorbing the uncommitted changes into the patch (or not).
I've already implemented this interface for Mercurial (with which I am
familiar) and looked at doing the same with git but had difficulty
discovering the definitive mechanisms for obtaining the necessary data.
So I'm soliciting your help in overcoming these problems.
Darning's source is managed by Mercurial and can be perused at:
<http://darning.hg.sourceforge.net/hgweb/darning/darning>
The interface to be implemented is defined in the file
darning/scm_ifce.py and the implementation for Mercurial is in the file
scm_ifce_hg.py.
Any help or pointers would be appreciated.
Thanks
Peter
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-30 7:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3StLjb9KgBkRrG4nPqJD_ZjeSyFUwuP4A3b+mJKBgHWQ@mail.gmail.com>
On Tue, Nov 22, 2011 at 01:47:36AM +0200, Felipe Contreras wrote:
> > I didn't mean "you didn't define a mirror in your config". I meant "your
> > question is not well-defined, because you haven't defined the term
> > 'mirror'". IOW, I can't answer your question without knowing exactly
> > what you meant.
>
> I wasn't the one that brought the mirror up, you did:
Yes, because that is the most related concept in current git. But I
thought you were asking from the perspective of a clueless user, and I
don't know what that clueless user meant by "mirror".
Anyway, I don't think it's important.
I read over your whole message, and I feel like our discussion isn't
really moving towards an actual goal. Junio and I both mentioned that in
the long-term, features like this should be part of "push", not
"remote". Do you want to try revising your patch in that direction?
That will give us something concrete to talk about (and hopefully
apply).
-Peff
^ 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