* Re: [PATCH] git-svn: teach find-rev to find near matches
From: Eric Wong @ 2013-01-18 0:49 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130117221933.GK4574@serenity.lan>
John Keeping <john@keeping.me.uk> wrote:
> When a single SVN repository is split into multiple Git repositories
> many SVN revisions will exist in only one of the Git repositories
> created. For some projects the only way to build a working artifact is
> to check out corresponding versions of various repositories, with no
> indication of what those are in the Git world - in the SVN world the
> revision numbers are sufficient.
>
> By adding "--before" to "git-svn find-rev" we can say "tell me what this
> repository looked like when that other repository looked like this":
>
> git svn find-rev --before \
> r$(git --git-dir=/over/there.git svn find-rev HEAD)
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
Thanks.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I've pushed this out to git://bogomips.org/git-svn along with a few
other things I seem to have forgotten about :x
John Keeping (1):
git-svn: teach find-rev to find near matches
Jonathan Nieder (2):
Git::SVN::Editor::T: pass $deletions to ->A and ->D
git svn: do not overescape URLs (fallback case)
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Jeff King @ 2013-01-18 1:06 UTC (permalink / raw)
To: Chris Rorvick
Cc: Junio C Hamano, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <CAEUsAPYAL6TD_nzu-YumRK_b-kFy7mNz1VivmSxGeuFYVxVL4g@mail.gmail.com>
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote:
> I was referring to your concern about rejecting based on type. A push
> causing a reference to move (for example) from a commit to a blob is
> rejected as "already exists" with this patch. You emphatically state
> this is not OK and your solution is to revert back to behavior that
> advises a merge.
>
> Clearly the bug regarding an 'old' unknown to the client should be
> fixed. This is a obvious test case I should have covered and it's
> unfortunate it made it into master. But I don't understand why
> is_forwardable() was misguided (maybe poorly named) nor why
> ref_newer() is a better place to solve the issues it was addressing.
I think that a type-based rule that relies on knowing the type of the
other side will always have to guess in some cases, because we do not
necessarily have that information. However, if instead of the rule being
"blobs on the remote side cannot be replaced", if it becomes "the old
value on the remote side must be referenced by what we replace it with",
that _is_ something we can calculate reliably on the sending side. And
that is logically an extension of the fast-forward rule, which is why I
suggested placing it with ref_newer (but the latter should probably be
extended to not suggest merging if we _know_ it is a non-commit object).
-Peff
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Chris Rorvick @ 2013-01-18 3:18 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <20130118010638.GA29453@sigill.intra.peff.net>
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King <peff@peff.net> wrote:
> However, if instead of the rule being
> "blobs on the remote side cannot be replaced", if it becomes "the old
> value on the remote side must be referenced by what we replace it with",
> that _is_ something we can calculate reliably on the sending side.
Interesting. I would have thought knowing reachability implied having
the old object in the sending repository.
> And
> that is logically an extension of the fast-forward rule, which is why I
> suggested placing it with ref_newer (but the latter should probably be
> extended to not suggest merging if we _know_ it is a non-commit object).
Sounds great, especially if it is not dependent on the sender actually
having the old object. Until this is implemented, though, I don't
understand what was wrong with doing the checks in the
is_forwardable() helper function (of course after fixing the
regression/bug.)
Chris
^ permalink raw reply
* Re: [PATCH v2 8/8] git-remote-testpy: call print as a function
From: Sverre Rabbelier @ 2013-01-18 3:48 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <88502ee7b090454352b46d496741029817b27482.1358448207.git.john@keeping.me.uk>
Looks harmless enough.
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping <john@keeping.me.uk> wrote:
> This is harmless in Python 2, which sees the parentheses as redundant
> grouping, but is required for Python 3. Since this is the only change
> required to make this script just run under Python 3 without needing
> 2to3 it seems worthwhile.
>
> The case of an empty print must be handled specially because in that
> case Python 2 will interpret '()' as an empty tuple and print it as
> '()'; inserting an empty string fixes this.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> git-remote-testpy.py | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> index bc5e3cf..ccdb2dc 100644
> --- a/git-remote-testpy.py
> +++ b/git-remote-testpy.py
> @@ -87,9 +87,9 @@ def do_capabilities(repo, args):
> """Prints the supported capabilities.
> """
>
> - print "import"
> - print "export"
> - print "refspec refs/heads/*:%s*" % repo.prefix
> + print("import")
> + print("export")
> + print("refspec refs/heads/*:%s*" % repo.prefix)
>
> dirname = repo.get_base_path(repo.gitdir)
>
> @@ -98,11 +98,11 @@ def do_capabilities(repo, args):
>
> path = os.path.join(dirname, 'git.marks')
>
> - print "*export-marks %s" % path
> + print("*export-marks %s" % path)
> if os.path.exists(path):
> - print "*import-marks %s" % path
> + print("*import-marks %s" % path)
>
> - print # end capabilities
> + print('') # end capabilities
>
>
> def do_list(repo, args):
> @@ -115,16 +115,16 @@ def do_list(repo, args):
>
> for ref in repo.revs:
> debug("? refs/heads/%s", ref)
> - print "? refs/heads/%s" % ref
> + print("? refs/heads/%s" % ref)
>
> if repo.head:
> debug("@refs/heads/%s HEAD" % repo.head)
> - print "@refs/heads/%s HEAD" % repo.head
> + print("@refs/heads/%s HEAD" % repo.head)
> else:
> debug("@refs/heads/master HEAD")
> - print "@refs/heads/master HEAD"
> + print("@refs/heads/master HEAD")
>
> - print # end list
> + print('') # end list
>
>
> def update_local_repo(repo):
> @@ -164,7 +164,7 @@ def do_import(repo, args):
> ref = line[7:].strip()
> refs.append(ref)
>
> - print "feature done"
> + print("feature done")
>
> if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
> die('Told to fail')
> @@ -172,7 +172,7 @@ def do_import(repo, args):
> repo = update_local_repo(repo)
> repo.exporter.export_repo(repo.gitdir, refs)
>
> - print "done"
> + print("done")
>
>
> def do_export(repo, args):
> @@ -192,8 +192,8 @@ def do_export(repo, args):
> repo.non_local.push(repo.gitdir)
>
> for ref in changed:
> - print "ok %s" % ref
> - print
> + print("ok %s" % ref)
> + print('')
>
>
> COMMANDS = {
> --
> 1.8.1.1.260.g99b33f4.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 7/8] git-remote-testpy: don't do unbuffered text I/O
From: Sverre Rabbelier @ 2013-01-18 3:50 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <6bc90f3afc86d53eb6e4b4d6b87f6afd20023769.1358448207.git.john@keeping.me.uk>
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping <john@keeping.me.uk> wrote:
> - sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
> + sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
It is not immediately obvious why you would open stdin in rb mode,
please add a comment.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* bug: git-svn seg fault during 'git svn fetch' due to perl < 5.10
From: Durham Goode @ 2013-01-18 4:14 UTC (permalink / raw)
To: git@vger.kernel.org
In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a
seg fault. It's caused by git-svn trying to parse a large yaml file
(introduced in
https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540
) which encounters a perl regex stack overflow bug that was present in
perl < 5.10 (https://bugzilla.redhat.com/show_bug.cgi?id=192400).
We'll find a work around, but it'd be nice if there was a config setting
to let us choose not to use the yaml format.
Let me know if there's a better place to report this.
-Durham
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Junio C Hamano @ 2013-01-18 4:36 UTC (permalink / raw)
To: Jeff King
Cc: Chris Rorvick, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <20130118010638.GA29453@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, if instead of the rule being "blobs on the remote side
> cannot be replaced", if it becomes "the old value on the remote
> side must be referenced by what we replace it with", that _is_
> something we can calculate reliably on the sending side. And that
> is logically an extension of the fast-forward rule,...
It may be an extension of the fast-forward, but only in the graph
reachability sense. I can buy that it is mathmatically consistent
with the mode that has proven to be useful for commits at the branch
tips, which we know why "fast-forward" rule is an appropriate
default for. You haven't shown if that mathmatical consistency is
useful for non-commit case.
The primary reason "fast-forward" is a good default for branches is
not that "we do not want to lose objects to gc" (you have reflog for
that). The reason is non fast-forward is a sign of unintended
rewind, and later will cause duplicated history with merge
conflicts.
That comes from the way objects pointed by refs/heads aka branches
are used. It is not just "commit" (as object type), but how these
objects are used. Think why we decided it was a good idea to do one
thing in the topic that introduced the regression under discussion:
"Even if the new commit is a descendant of the old commit, we do not
want to fast-forward a ref if it is under refs/tags/". Type of object
may be one factor, but how it is used is more important factor in
deciding what kind of policy is appropriate.
If users have workflows that want to have a ref hierarchy that point
at a blob, there will not be any update to such a ref that will
satisfy your definition of "extended" fast-forward requirement, and
that requirement came solely from mathematical purity (i.e. graph
reachability), not from any workflow consideration. That is very
disturbing to me.
A workflow that employes such a "blob at a ref" may perfectly be
happy with replacing the blob as last-one-wins basis. I do not think
the client side should enforce a policy to forbid such a push.
I personally think the current client side that insists that updates
to any ref has to have the current object and must fast-forward and
requires --force otherwise was a mistake (this predates the change
by Chris). The receiving end does not implement such an arbitrary
restriction outside refs/heads/, and does so only for refs/heads/
only when deny-non-fast-forwards is set.
^ permalink raw reply
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: Sverre Rabbelier @ 2013-01-18 5:15 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <bcef80fb913ca829bd2d08284e364ebd55b7297e.1358448207.git.john@keeping.me.uk>
On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
> [1] http://wiki.python.org/moin/PortingPythonToPy3k
This link seems dead.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Torsten Bögershausen @ 2013-01-18 5:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King,
Junio C Hamano, git, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter environment
>> to work whatever the configuration of the user may be.
> Presumably 'git checkout-branches' is from git-stuff.
>
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts? Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> t/t9902-completion.sh | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..06dcfb2 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -192,19 +192,19 @@ test_expect_success 'general options' '
> '
>
> test_expect_success 'general options plus command' '
> - test_completion "git --version check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --git-dir=foo check" "checkout " &&
> - test_completion "git --bare check" "checkout " &&
> - test_completion "git --help des" "describe " &&
> - test_completion "git --exec-path=foo check" "checkout " &&
> - test_completion "git --html-path check" "checkout " &&
> - test_completion "git --no-pager check" "checkout " &&
> - test_completion "git --work-tree=foo check" "checkout " &&
> - test_completion "git --namespace=foo check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --info-path check" "checkout " &&
> - test_completion "git --no-replace-objects check" "checkout "
> + test_completion "git --version cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
> + test_completion "git --bare cherry-p" "cherry-pick " &&
> + test_completion "git --help cherry-p" "cherry-pick " &&
> + test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
> + test_completion "git --html-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-pager cherry-p" "cherry-pick " &&
> + test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
> + test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --info-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-replace-objects cherry-p" "cherry-pick "
> '
>
> test_expect_success 'setup for ref completion' '
That looks good to me, thanks.
^ permalink raw reply
* RE: Question re. git remote repository
From: Matt Seitz @ 2013-01-18 5:51 UTC (permalink / raw)
To: Lang, David, David Lang
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca>
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
> I thought the idea was that each developer installed git locally on their machines
Yes.
> and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network
> server
Yes, but committing their changes to the master repository is a two step process:
1. Each developer first commits their changes to their personal repository using the "git commit" command.
2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command
> (and which I'm assuming has git installed locally as well).
Maybe.
If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.
If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the "file protocol".
The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
http://permalink.gmane.org/gmane.comp.version-control.git/122670
The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
^ permalink raw reply
* RE: Question re. git remote repository
From: David Lang @ 2013-01-18 6:18 UTC (permalink / raw)
To: Matt Seitz
Cc: Lang, David, Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com>
On Fri, 18 Jan 2013, Matt Seitz wrote:
> From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
>
> The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
>
> http://permalink.gmane.org/gmane.comp.version-control.git/122670
>
> The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
>
> https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
I'm glad to learn that git is more robust than I feared.
David Lang
^ permalink raw reply
* [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 10:31 UTC (permalink / raw)
To: gitster; +Cc: felipe.contreras, git, Brandon Casey
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x from loading the completion script and breaks test 9902. We can
easily work around this by using standard Bash array notation.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..c14e329 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2431,7 +2431,7 @@ if [[ -n ${ZSH_VERSION-} ]]; then
--*=*|*.) ;;
*) c="$c " ;;
esac
- array+=("$c")
+ array[$(($#array+1))]="$c"
done
compset -P '*[=:]'
compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
--
1.8.1.1.252.gdb33759
^ permalink raw reply related
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: John Keeping @ 2013-01-18 10:32 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <CAGdFq_gew1-YmeUh=brWREHSYQvaV7vRBmEo0KFzi-ViqzOnaw@mail.gmail.com>
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>
> This link seems dead.
Looks like the Python wiki is down [1].
I'll replace it with [2] since the content is similar and it should be
easier to find a mirror of the Python documentation than of the wiki.
[1] http://pyfound.blogspot.co.uk/2013/01/wikipythonorg-compromised.html
[2] http://docs.python.org/3.3/howto/pyporting.html#during-installation
John
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2013-01-18 14:37 UTC (permalink / raw)
To: greened; +Cc: git list
In-Reply-To: <877gnx39aa.fsf@waller.obbligato.org>
On Mon, 31 Dec 2012 20:51:41 -0600
greened@obbligato.org wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
>
> Specifying a local branch works fine, though, as does a raw commit
> hash. What do you mean by "local commit?"
With no <repository> arg documented, my understanding was that I should first
"git remote add" and fetch the repo in which the branch to be added as subtree
lived. This when running "git subtree add", the commit was indeed existing
locally.
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
>
> Seems to work for me. Can you give me the command you're using when you
> see the problem?
Hm, can't remember exactly how I reached that. But when experimenting to
reproduce:
$ contrib/subtree/git-subtree.sh add -P foo . origin/maint
git fetch . origin/maint
From .
* remote-tracking branch origin/maint -> FETCH_HEAD
Added dir 'foo'
=> OK
$ contrib/subtree/git-subtree.sh add -P fooo . origin/maint^0
git fetch . origin/maint^0
fatal: Invalid refspec 'origin/maint^0'
=> a commit is advertised, but in fact it seems to require a refspec
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Andreas Schwab @ 2013-01-18 15:02 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, felipe.contreras, git
In-Reply-To: <1358505065-16913-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> + array[$(($#array+1))]="$c"
You don't need $(( )) since the array index is already evaluated as an
arithmethic expression.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Michael Haggerty @ 2013-01-18 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsj5zs5y2.fsf@alter.siamese.dyndns.org>
On 01/18/2013 01:14 AM, Junio C Hamano wrote:
> [...]
> * mh/imap-send-shrinkage (2013-01-15) 14 commits
> - imap-send.c: simplify logic in lf_to_crlf()
> - imap-send.c: fold struct store into struct imap_store
> - imap-send.c: remove unused field imap_store::uidvalidity
> - imap-send.c: use struct imap_store instead of struct store
> - imap-send.c: remove unused field imap_store::trashnc
> - imap-send.c: remove namespace fields from struct imap
> - imap-send.c: remove struct imap argument to parse_imap_list_l()
> - imap-send.c: inline parse_imap_list() in parse_list()
> - imap-send.c: remove some unused fields from struct store
> - imap-send.c: remove struct message
> - imap-send.c: remove struct store_conf
> - iamp-send.c: remove unused struct imap_store_conf
> - imap-send.c: remove struct msg_data
> - imap-send.c: remove msg_data::flags, which was always zero
>
> Remove a lot of unused code from "git imap-send".
>
> With a further comment fixup in patch #6, this seems ready for
> 'next'.
> Expecting a reroll.
I'm confused. It seems like you are referring to the comment
improvement suggested by Jonathan Nieder [1] that you have already
incorporated [2] into mh/imap-send-shrinkage. If you think there is
something that needs rerolling, please explain.
Thanks,
Michael
[1] http://permalink.gmane.org/gmane.comp.version-control.git/213672
[2] http://permalink.gmane.org/gmane.comp.version-control.git/213681
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Unable to convert a subversion repo to git
From: Michael J Gruber @ 2013-01-18 16:48 UTC (permalink / raw)
To: Timothy Kretschmer; +Cc: git
In-Reply-To: <CAO2=c4nr8PsbHmyKptWewQMmpqWP=YasKZSnCuB9CCkExpSF8A@mail.gmail.com>
Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
> I am seeing the following output while converting a subversion repo to git.
>
> >Found possible branch point: <repo-url>/trunk =>
> <repo-url>/branches/CMT_PHASE3, 18441
>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 Branch
>> cat-file commit refs/remotes/BlueSimViewer 5.0 20110316 Branch: command returned error: 128
>
> The command I am running to convert the repo is
>
>> git svn clone <repo-url> -A authors-transform.txt --stdlayout bluebox-git > svnlist
>
> I am running git version 1.8.1.1 on an Ubuntu 12.10 server. I am happy
> to provide any other information that would be helpful.
>
> I appreciate any assistance you can provide in this matter,
> -Tim
git-svn should cope with funky branch names. What is the exact name of
the "CMT..." and "BlueSimViewer..." branches? Are you using a case
challenged file system or just some standard linux fs?
Michael
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 16:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts?
How about doing something like this and set that variable in the
test instead? If STD_ONLY is not set, you will get everything, but
when STD_ONLY is set, we will stop reading from "help -a" when it
starts listing additional stuff.
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..415a078 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -534,7 +534,8 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(LANG=C LC_ALL=C git help -a |
+ sed -n ${GIT_HELP_STD_ONLY+-e /^git.*elsewhere/q} -e '/^ [a-zA-Z0-9]/p')
do
case $i in
*--*) : helper pattern;;
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Junio C Hamano @ 2013-01-18 16:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50F96589.4010408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/18/2013 01:14 AM, Junio C Hamano wrote:
>> [...]
>> * mh/imap-send-shrinkage (2013-01-15) 14 commits
>> - imap-send.c: simplify logic in lf_to_crlf()
>> - imap-send.c: fold struct store into struct imap_store
>> - imap-send.c: remove unused field imap_store::uidvalidity
>> - imap-send.c: use struct imap_store instead of struct store
>> - imap-send.c: remove unused field imap_store::trashnc
>> - imap-send.c: remove namespace fields from struct imap
>> - imap-send.c: remove struct imap argument to parse_imap_list_l()
>> - imap-send.c: inline parse_imap_list() in parse_list()
>> - imap-send.c: remove some unused fields from struct store
>> - imap-send.c: remove struct message
>> - imap-send.c: remove struct store_conf
>> - iamp-send.c: remove unused struct imap_store_conf
>> - imap-send.c: remove struct msg_data
>> - imap-send.c: remove msg_data::flags, which was always zero
>>
>> Remove a lot of unused code from "git imap-send".
>>
>> With a further comment fixup in patch #6, this seems ready for
>> 'next'.
>> Expecting a reroll.
>
> I'm confused. It seems like you are referring to the comment
> improvement suggested by Jonathan Nieder...
It was an indication that I just forgot our previous exchange in
which I said "the remaining issues are so minor I can squash these
in". Sorry about that.
Will merge to 'next'.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
From: Phil Hord @ 2013-01-18 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: John Keeping, Antoine Pelisse, Max Horn, git, Johannes Sixt,
Junio C Hamano
In-Reply-To: <CA+55aFxYSX2iYPSafKdCDSfWSMfQxP3R3Hqh8GuiiR6EbWfk3w@mail.gmail.com>
On Thu, Jan 17, 2013 at 11:44 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping <john@keeping.me.uk> wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk, which
>> I think is a legitimate warning - perhaps someone who understands integer type
>> promotion better than me can explain why the code is OK (patch->score is
>> declared as 'int'):
>>
>> builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615
>> with expression of type 'int' is always false
>> [-Wtautological-constant-out-of-range-compare]
>> if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
>
> The warning seems to be very very wrong, and implies that clang has
> some nasty bug in it.
>
> Since patch->score is 'int', and UNLONG_MAX is 'unsigned long', the
> conversion rules for the comparison is that the int result from the
> assignment is cast to unsigned long. And if you cast (int)-1 to
> unsigned long, you *do* get ULONG_MAX. That's true regardless of
> whether "long" has the same number of bits as "int" or is bigger. The
> implicit cast will be done as a sign-extension (unsigned long is not
> signed, but the source type of 'int' *is* signed, and that is what
> determines the sign extension on casting).
>
> So the "is always false" is pure and utter crap. clang is wrong, and
> it is wrong in a way that implies that it actually generates incorrect
> code. It may well be worth making a clang bug report about this.
>
> That said, clang is certainly understandably confused. The code
> depends on subtle conversion rules and bit patterns, and is clearly
> very confusingly written.
>
> So it would probably be good to rewrite it as
>
> unsigned long val = strtoul(line, NULL, 10);
> if (val == ULONG_MAX) ..
> patch->score = val;
>
> instead. At which point you might as well make the comparison be ">=
> INT_MAX" instead, since anything bigger than that is going to be
> bogus.
>
> So the git code is probably worth cleaning up, but for git it would be
> a cleanup. For clang, this implies a major bug and bad code
> generation.
Yes, I can tell by the wording of the error message that you are right
and clang has a problem. But the git code it complained about does
have a real problem, because the result of "signed int a = ULONG_MAX"
is implementation-defined. It cannot be guaranteed or expected that
patch->score will ever be assigned -1 there, and so the comparison may
always be false. I guess the warning is correct, but only
accidentally. :-)
Your rewrite is more sane and corrects the problem, I think.
Phil
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-01-18 17:50 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US)
Cc: Maxime Boissonneault, Philippe Vaucher, git@vger.kernel.org,
Sébastien Boisvert
In-Reply-To: <871B6C10EBEFE342A772D1159D1320853A044B42@umechphj.easf.csd.disa.mil>
Good idea!
I did a strace and here is the output with the error:
http://www.giref.ulaval.ca/~ericc/strace_git_error.txt
Hope it will be insightful!
Eric
On 01/17/2013 12:17 PM, Pyeron, Jason J CTR (US) wrote:
> Sorry, I am in cygwin mode, and I had crossed wires in my head. s/ProcessMon/strace/
>
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>> Behalf Of Maxime Boissonneault
>> Sent: Thursday, January 17, 2013 11:41 AM
>> To: Pyeron, Jason J CTR (US)
>> Cc: Eric Chamberland; Philippe Vaucher; git@vger.kernel.org; Sébastien
>> Boisvert
>> Subject: Re: GIT get corrupted on lustre
>>
>> I don't know of any lustre filesystem that is used on Windows. Barely
>> anybody uses Windows in the HPC industry.
>> This is a Linux cluster.
>>
>> Maxime Boissonneault
>>
>> Le 2013-01-17 11:40, Pyeron, Jason J CTR (US) a écrit :
>>>> -----Original Message-----
>>>> From: Eric Chamberland
>>>> Sent: Thursday, January 17, 2013 11:31 AM
>>>>
>>>> On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
>>>>>> Anyone has a new idea?
>>>>> Did you try Jeff King's code to confirm his idea?
>>>>>
>>>>> Philippe
>>>>>
>>>> Yes I did, but it was running without any problem....
>>>>
>>>> I find that my test case is "simple" (fresh git clone then "git gc"
>> in
>>>> a
>>>> crontab), I bet anyone who has access to a Lustre filesystem can
>>>> reproduce the problem... The problem is to have such a filesystem
>> to
>>>> do
>>>> the tests....
>>> Stabbing in the dark, but can you log the details with ProcessMon?
>>>
>>> http://technet.microsoft.com/en-us/sysinternals/bb896645
>>>
>>>> But I am available to do it...
>>> -Jason
>>
>>
>> --
>> ---------------------------------
>> Maxime Boissonneault
>> Analyste de calcul - Calcul Québec, Université Laval
>> Ph. D. en physique
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 18:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [2], there isn't any disagreement about using
2.6 as a base (see also [3]).
- The Git INSTALL document currently says:
Python version 2.6 or later is needed to use the git-p4
interface to Perforce.
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Following Pete's comment [5] I tested Python 2.6.0 and it does
support bytes literals, as suggested by [4] but contradicted by [6].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [7].
I chose to recommend `from __future__ import unicode_literals` since it
provides the widest range of compatibility (2.6+ and 3.0+) while
allowing us to be explicit about bytes vs. Unicode. The alternative
would be to advocate using the 'u' prefix on Unicode strings but this
isn't available in versions 3.0 - 3.2 (it is reintroduced in version 3.3
as a no-op in order to make it easier to write scripts targeting a wide
range of Python versions without needing to use 2to3 [1]). In reality I
doubt we will ever need to worry about this since ASCII strings will
just work in both Python 2 and Python 3.
[1] http://www.python.org/dev/peps/pep-0414/
[2] http://thread.gmane.org/gmane.comp.version-control.git/210329
[3] http://article.gmane.org/gmane.comp.version-control.git/210429
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://article.gmane.org/gmane.comp.version-control.git/213830
[6] http://docs.python.org/2.6/reference/lexical_analysis.html#literals
[7] http://www.python.org/dev/peps/pep-0404/
---
Documentation/CodingGuidelines | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 69f7e9b..baf3b41 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -179,6 +179,22 @@ For C programs:
- Use Git's gettext wrappers to make the user interface
translatable. See "Marking strings for translation" in po/README.
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+ also be compatible with Python 3. In this case we use
+ `from __future__ import unicode_literals` if we need to differentiate
+ Unicode string literals, rather than prefixing Unicode strings with
+ 'u' since the latter is not supported in Python versions 3.0 - 3.2.
+
+ - We use the 'b' prefix for bytes literals. Note that even though
+ the Python documentation for version 2.6 does not mention this
+ prefix it is supported since version 2.6.0.
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
--
1.8.1
^ permalink raw reply related
* Re: merge vs. rebase question
From: Phil Hord @ 2013-01-18 18:38 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git@vger.kernel.org
In-Reply-To: <50F8073F.90304@bellsouth.net>
On Thu, Jan 17, 2013 at 9:14 AM, Dennis Putnam <dap1@bellsouth.net> wrote:
> As a git noob I am having trouble understanding when to use which
> commands. I have a repository (bare) on my Linux server. I also created
> a build directory as a local repository. In my build script I do a 'git
> pull' to make sure the build directory is up to date. No changes are
> made to my source so this repository never does an 'add' or 'commit'.
> When I run my script with 'pull', the output indicates that changes were
> found and seems to have pulled them into the local directory. However,
> when I look at the resulting source, none of the expected changes show
> up. I then tried a 'fetch' and 'rebase'. That worked but I don't
> understand why. I thought 'pull' did a 'fetch' and a 'merge' so I don't
> understand why a 'fetch' and 'rebase' worked but 'fetch' and 'merge' did
> not. Unless my understanding of what 'pull' does is wrong. In my case,
> what should I be using in my script to assure that the build directory
> is current?
If your build directory never has any source changes or new commits,
then pull is the right thing to do. You might want to use 'git pull
--ff-only' to guarantee that your build directory is not creating
merges unexpectedly.
You did not provide enough information to help figure out why your
pull is failing to achieve the results you expect. I suggest you
perform the pull manually in your build directory. If it fails, git
should tell you why. If it reports success but actually fails, you
can post a detailed explanation of the problem here so someone can
suggest the cause.
Phil
^ permalink raw reply
* Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
From: Linus Torvalds @ 2013-01-18 18:52 UTC (permalink / raw)
To: Phil Hord
Cc: John Keeping, Antoine Pelisse, Max Horn, git, Johannes Sixt,
Junio C Hamano
In-Reply-To: <CABURp0pj35j7+W_0gYNud2uuEoahugOMBW9ezTgPZ7YvgnBz8w@mail.gmail.com>
On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord <phil.hord@gmail.com> wrote:
>
> Yes, I can tell by the wording of the error message that you are right
> and clang has a problem. But the git code it complained about does
> have a real problem, because the result of "signed int a = ULONG_MAX"
> is implementation-defined.
Only theoretically.
Git won't work on machines that don't have 8-bit bytes anyway, so
worrying about the theoretical crazy architectures that aren't two's
complement etc isn't something I'd care about.
There's a whole class of "technically implementation-defined" issues
in C that simply aren't worth caring for. Yes, the standard is written
so that it works on machines that aren't byte-addressable, or EBCDIC
or have things like 18-bit words and 36-bit longwords. Or 16-bit "int"
for microcontrollers etc.
That doesn't make those "implementation-defined" issues worth worrying
about these days. A compiler writer could in theory make up some
idiotic rules that are still "valid by the C standard" even on modern
machines, but such a compiler should simply not be used, and the
compiler writer in question should be called out for being an ass-hat.
Paper standards are only worth so much. And that "so much" really
isn't very much.
Linus
^ permalink raw reply
* RE: Question re. git remote repository
From: Lang, David @ 2013-01-18 18:33 UTC (permalink / raw)
To: 'Matt Seitz', David Lang; +Cc: git@vger.kernel.org
In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com>
Hi Matt and David,
Your responses have been very helpful for this newbie...thanks very much! I have a good sense now of the difference btw a CVCS and a DVCS. Here are two more questions...
1. I now get the sense that there's quite a few options in regards to the way that any one group implements their "origin"/"master"/<fill in your favourite name> repository. But ultimately, there shouldn't be a question of "if" you have a master repository but "where" you have the master repository, correct? Or in other words, it doesn't seem like you'd want to designate any one developer's local repository as also being the master repository, right? My sense is that would defeat the purpose of the DVCS.
2. Assuming I'm right about question #1, our first hurdle is where to host the master repository. Could you provide any suggestions for a setup based on our VERY simple department model? I work for a small IT department with a grand total of TWO developers (who sit five feet apart from one another)! The reason we're looking at a VCS is because I was hired a few months ago and the dept never needed one before now. We realize that git will be overkill for what we need but frankly anything will be overkill for what we need, and since git seems to be so well regarded in the community (and free) it looks like a good choice.
So the question is, how would either of you recommend we set up our master repository? We definitely want to keep everything "in house" so off-site hosting isn't something we'd consider. We have access to many servers on our company's network, some of which we have full rights to, so there's no issue in regards to storage space. I suppose another idea would be to have the master simply reside on one of the two developers local machines, so one of us would have both a local rep and the master rep and the other of us would have just a local rep. This would simplify the model. What do you think? Or is it best to always have the master hosted on a machine with no other local reps?
David
-----Original Message-----
From: Matt Seitz [mailto:mseitz@mhseitz.onmicrosoft.com]
Sent: Friday, January 18, 2013 12:52 AM
To: Lang, David; David Lang
Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Stephen Smith
Subject: RE: Question re. git remote repository
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
> I thought the idea was that each developer installed git locally on
> their machines
Yes.
> and (as needed) committed their changes to the master repository which
> resides externally to any of the local machines, such as on a network
> server
Yes, but committing their changes to the master repository is a two step process:
1. Each developer first commits their changes to their personal repository using the "git commit" command.
2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command
> (and which I'm assuming has git installed locally as well).
Maybe.
If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.
If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the "file protocol".
The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
http://permalink.gmane.org/gmane.comp.version-control.git/122670
The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete all copies.
Opinions, conclusions or other information contained in this e-mail may not be that of the organization.
^ 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