* 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: [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
* 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 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
* 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 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 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] 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
* What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Junio C Hamano @ 2013-01-18 0:14 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* fc/remote-hg-fixup-url (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at d2acb2d)
+ remote-hg: store converted URL
Update to the Hg remote helper (in contrib/).
Will merge to 'master'.
* mh/remote-hg-mode-bits-fix (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at ad57d9f)
+ remote-hg: fix handling of file perms when pushing
Update to the Hg remote helper (in contrib/).
Will merge to 'master'.
* jc/valgrind-memcmp-bsearch (2013-01-14) 1 commit
- ignore memcmp() overreading in bsearch() callback
Squelch false positive in valgrind tests
Will discard.
* 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.
* nd/attr-debug-fix (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at 8460acf)
+ attr: make it build with DEBUG_ATTR again
Fix debugging support that was broken in earlier change.
Will merge to 'master'.
* nd/fix-directory-attrs-off-by-one (2013-01-16) 2 commits
(merged to 'next' on 2013-01-16 at bd63e61)
+ attr: avoid calling find_basename() twice per path
(merged to 'next' on 2013-01-15 at e0a0129)
+ attr: fix off-by-one directory component length calculation
Fix performance regression introduced by an earlier change to let
attributes apply to directories.
Will merge to 'master'.
* nd/fix-perf-parameters-in-tests (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at fedbdb9)
+ test-lib.sh: unfilter GIT_PERF_*
Allow GIT_PERF_* environment variables to be passed through the
test framework.
Will merge to 'master'.
* pw/p4-branch-fixes (2013-01-15) 14 commits
(merged to 'next' on 2013-01-15 at 1ee379e)
+ git p4: fix submit when no master branch
+ git p4 test: keep P4CLIENT changes inside subshells
+ git p4: fix sync --branch when no master branch
+ git p4: fail gracefully on sync with no master branch
+ git p4: rearrange self.initialParent use
+ git p4: allow short ref names to --branch
+ git p4 doc: fix branch detection example
+ git p4: clone --branch should checkout master
+ git p4: verify expected refs in clone --bare test
+ git p4: create p4/HEAD on initial clone
+ git p4: inline listExistingP4GitBranches
+ git p4: add comments to p4BranchesInGit
+ git p4: rearrange and simplify hasOrigin handling
+ git p4: test sync/clone --branch behavior
Fix "git p4" around branch handling.
Will merge to 'master'.
* ss/help-htmlpath-config-doc (2013-01-15) 1 commit
(merged to 'next' on 2013-01-17 at 99bfae2)
+ config.txt: Document help.htmlpath config parameter
Add missing doc.
Will merge to 'master'.
* cr/push-force-tag-update (2013-01-16) 1 commit
- push: fix "refs/tags/ hierarchy cannot be updated without --force"
Regression fix.
Will merge to 'next' and then to 'master' soonish.
* jk/suppress-clang-warning (2013-01-16) 1 commit
- fix clang -Wunused-value warnings for error functions
Will merge to 'next'.
* rs/clarify-entry-cmp-sslice (2013-01-16) 1 commit
- refs: use strncmp() instead of strlen() and memcmp()
Will merge to 'next'.
* ch/add-auto-submitted-in-sample-post-receive-email (2013-01-17) 1 commit
- Add Auto-Submitted header to post-receive-email
Will merge to 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
- simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
As this touches a fairly core part of the revision traversal
infrastructure, it is appreciated to have an extra set of eyes for
sanity check.
Waiting for comments.
* jk/remote-helpers-in-python-3 (2013-01-17) 8 commits
- git-remote-testpy: call print as a function
- git-remote-testpy: don't do unbuffered text I/O
- git-remote-testpy: hash bytes explicitly
- svn-fe: allow svnrdump_sim.py to run with Python 3
- git_remote_helpers: use 2to3 if building with Python 3
- git_remote_helpers: force rebuild if python version changes
- git_remote_helpers: fix input when running under Python 3
- git_remote_helpers: allow building with Python 3
Except for one instance of <user-generated-string>.encode('utf-8'),
nothing looked wrong. People who have worked on git_remote_helpers
should review and Ack, though. Perhaps Sverre?
Waiting for further comments.
--------------------------------------------------
[Stalled]
* mp/complete-paths (2013-01-11) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' help and review.
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jc/cvsimport-upgrade (2013-01-14) 8 commits
- t9600: adjust for new cvsimport
- t9600: further prepare for sharing
- cvsimport-3: add a sample test
- cvsimport: make tests reusable for cvsimport-3
- cvsimport: start adding cvsps 3.x support
- cvsimport: introduce a version-switch wrapper
- cvsimport: allow setting a custom cvsps (2.x) program name
- Makefile: add description on PERL/PYTHON_PATH
The most important part of this series is the addition of the new
cvsimport by Eric Raymond that works with cvsps 3.x. Given some
distros have inertia to be conservative, Git with cvsimport that
does not work with both 3.x will block adoption of cvsps 3.x by
them, and shipping Git with cvsimport that does not work with cvsps
2.x will block such a version of Git, so we'll do the proven "both
old and new are available, but we aim to deprecate and remove the
old one in due time" strategy that we used successfully in the
past.
Both folks on the Git side and Chris Rorvick (contributor to cvsps
3.0 and new cvsimport) seem happy with the new layout, so let's
wait for a few days to see how it evolves and merge it to 'next'.
Waiting for Eric to say something, but otherwise will merge to 'next'.
* as/pre-push-hook (2013-01-14) 4 commits
- Add sample pre-push hook script
- [SQUASH???] t5571 sample hooks should consume their input
- push: Add support for pre-push hooks
- hooks: Add function to check if a hook exists
Add an extra hook so that "git push" that is run without making
sure what is being pushed is sane can be checked and rejected (as
opposed to the user deciding not pushing).
Will merge to 'next' after squashing the fix in.
* dl/am-hg-locale (2013-01-14) 1 commit
- am: invoke perl's strftime in C locale
Datestamp recorded in "Hg" format patch was reformatted incorrectly
to an e-mail looking date using locale dependant strftime, causing
patch application to fail.
This is an original "everything in C locale" version; the later one
that uses LC_TIME may technically be more correct, so I may replace
this with it later ($gmane/213660).
* jk/config-parsing-cleanup (2013-01-14) 7 commits
- [DONTMERGE] reroll coming
- submodule: simplify memory handling in config parsing
- submodule: use match_config_key when parsing config
- userdiff: drop parse_driver function
- convert some config callbacks to match_config_key
- archive-tar: use match_config_key when parsing config
- config: add helper function for parsing key names
Expecting a reroll.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
* ph/rebase-preserve-all-merges (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at 3a67878)
+ rebase --preserve-merges: keep all merge commits including empty ones
An earlier change to add --keep-empty option broke "git rebase
--preserve-merges" and lost merge commits that end up being the
same as its parent.
Will merge to 'master'.
* rs/archive-tar-config-parsing-fix (2013-01-14) 1 commit
- archive-tar: fix sanity check in config parsing
Configuration parsing for tar.* configuration variables were
broken; Peff's config parsing clean-up topic will address the same
breakage, so this may be superseded by that other topic.
* rs/pretty-use-prefixcmp (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at d76452d)
+ pretty: use prefixcmp instead of memcmp on NUL-terminated strings
Will merge to 'master'.
* rt/commit-cleanup-config (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at c4742ae)
+ commit: make default of "cleanup" option configurable
Add a configuration variable to set default clean-up mode other
than "strip".
Will merge to 'master'.
* jc/custom-comment-char (2013-01-16) 1 commit
- Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
I don't know how useful this will be in real life, though.
Waiting for bug reports and user feedback.
* jn/maint-trim-vim-contrib (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at ad80a9d)
+ contrib/vim: simplify instructions for old vim support
Will merge to 'master'.
* mz/reset-misc (2013-01-16) 20 commits
(merged to 'next' on 2013-01-16 at 937bc20)
+ reset: update documentation to require only tree-ish with paths
(merged to 'next' on 2013-01-15 at a93b394)
+ reset [--mixed]: use diff-based reset whether or not pathspec was given
+ reset: allow reset on unborn branch
+ reset $sha1 $pathspec: require $sha1 only to be treeish
+ reset.c: inline update_index_refresh()
+ reset.c: finish entire cmd_reset() whether or not pathspec is given
+ reset [--mixed]: only write index file once
+ reset.c: move lock, write and commit out of update_index_refresh()
+ reset.c: move update_index_refresh() call out of read_from_tree()
+ reset.c: replace switch by if-else
+ reset: avoid redundant error message
+ reset --keep: only write index file once
+ reset.c: share call to die_if_unmerged_cache()
+ reset.c: extract function for updating {ORIG_,}HEAD
+ reset.c: remove unnecessary variable 'i'
+ reset.c: extract function for parsing arguments
+ reset: don't allow "git reset -- $pathspec" in bare repo
+ reset.c: pass pathspec around instead of (prefix, argv) pair
+ reset $pathspec: exit with code 0 if successful
+ reset $pathspec: no need to discard index
Various 'reset' optimizations and clean-ups, followed by a change
to allow "git reset" to work even on an unborn branch.
Will merge to 'master'.
* pe/doc-email-env-is-trumped-by-config (2013-01-10) 1 commit
(merged to 'next' on 2013-01-14 at 6b4d555)
+ git-commit-tree(1): correct description of defaults
In the precedence order, the environment variable $EMAIL comes
between the built-in default (i.e. taking value by asking the
system's gethostname() etc.) and the user.email configuration
variable; the documentation implied that it is stronger than the
configuration like $GIT_COMMITTER_EMAIL is, which is wrong.
Will merge to 'master'.
* ds/completion-silence-in-tree-path-probe (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at 7542d21)
+ git-completion.bash: silence "not a valid object" errors
An internal ls-tree call made by completion code only to probe if
a path exists in the tree recorded in a commit object leaked error
messages when the path is not there. It is not an error at all and
should not be shown to the end user.
Will merge to 'master'.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
Will cook in 'next'.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
Will cook in 'next'.
* mk/complete-tcsh (2013-01-07) 1 commit
(merged to 'next' on 2013-01-11 at b8b30b1)
+ Prevent space after directories in tcsh completion
Update tcsh command line completion so that an unwanted space is
not added to a single directory name.
Will merge to 'master'.
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* ap/log-mailmap (2013-01-10) 11 commits
(merged to 'next' on 2013-01-10 at 8544084)
+ log --use-mailmap: optimize for cases without --author/--committer search
+ log: add log.mailmap configuration option
+ log: grep author/committer using mailmap
+ test: add test for --use-mailmap option
+ log: add --use-mailmap option
+ pretty: use mailmap to display username and email
+ mailmap: add mailmap structure to rev_info and pp
+ mailmap: simplify map_user() interface
+ mailmap: remove email copy and length limitation
+ Use split_ident_line to parse author and committer
+ string-list: allow case-insensitive string list
Teach commands in the "log" family to optionally pay attention to
the mailmap.
Will merge to 'master'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* nd/clone-no-separate-git-dir-with-bare (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at 64f441a)
+ clone: forbid --bare --separate-git-dir <dir>
Forbid a useless combination of options to "git clone".
Will merge to 'master'.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
* jc/doc-maintainer (2013-01-03) 2 commits
(merged to 'next' on 2013-01-11 at f35d582)
+ howto/maintain: mark titles for asciidoc
+ Documentation: update "howto maintain git"
Describe tools for automation that were invented since this
document was originally written.
* mo/cvs-server-updates (2012-12-09) 18 commits
(merged to 'next' on 2013-01-08 at 75e2d11)
+ t9402: Use TABs for indentation
+ t9402: Rename check.cvsCount and check.list
+ t9402: Simplify git ls-tree
+ t9402: Add missing &&; Code style
+ t9402: No space after IO-redirection
+ t9402: Dont use test_must_fail cvs
+ t9402: improve check_end_tree() and check_end_full_tree()
+ t9402: sed -i is not portable
+ cvsserver Documentation: new cvs ... -r support
+ cvsserver: add t9402 to test branch and tag refs
+ cvsserver: support -r and sticky tags for most operations
+ cvsserver: Add version awareness to argsfromdir
+ cvsserver: generalize getmeta() to recognize commit refs
+ cvsserver: implement req_Sticky and related utilities
+ cvsserver: add misc commit lookup, file meta data, and file listing functions
+ cvsserver: define a tag name character escape mechanism
+ cvsserver: cleanup extra slashes in filename arguments
+ cvsserver: factor out git-log parsing logic
Various git-cvsserver updates.
Will cook in 'next' for a while to see if anybody screams.
* as/check-ignore (2013-01-16) 13 commits
- clean.c, ls-files.c: respect encapsulation of exclude_list_groups
(merged to 'next' on 2013-01-14 at 9df2afc)
+ t0008: avoid brace expansion
+ add git-check-ignore sub-command
+ setup.c: document get_pathspec()
+ add.c: extract new die_if_path_beyond_symlink() for reuse
+ add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
+ pathspec.c: rename newly public functions for clarity
+ add.c: move pathspec matchers into new pathspec.c for reuse
+ add.c: remove unused argument from validate_pathspec()
+ dir.c: improve docs for match_pathspec() and match_pathspec_depth()
+ dir.c: provide clear_directory() for reclaiming dir_struct memory
+ dir.c: keep track of where patterns came from
+ dir.c: use a single struct exclude_list per source of excludes
Add a new command "git check-ignore" for debugging .gitignore
files.
The variable names may want to get cleaned up but that can be done
in-tree.
Will merge to 'next'.
* nd/retire-fnmatch (2013-01-01) 7 commits
(merged to 'next' on 2013-01-07 at ab31f9b)
+ Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
+ wildmatch: advance faster in <asterisk> + <literal> patterns
+ wildmatch: make a special case for "*/" with FNM_PATHNAME
+ test-wildmatch: add "perf" command to compare wildmatch and fnmatch
+ wildmatch: support "no FNM_PATHNAME" mode
+ wildmatch: make dowild() take arbitrary flags
+ wildmatch: rename constants and update prototype
Originally merged to 'next' on 2013-01-04
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
Will cook in 'next' a bit longer than other topics.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* zk/clean-report-failure (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at 5b31614)
+ git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Will merge to 'master'.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
--------------------------------------------------
[Discarded]
* er/replace-cvsimport (2013-01-12) 7 commits
. t/lib-cvs: cvsimport no longer works without Python >= 2.7
. t9605: test for cvsps commit ordering bug
. t9604: fixup for new cvsimport
. t9600: fixup for new cvsimport
. t/lib-cvs.sh: allow cvsps version 3.x.
. t/t960[123]: remove leftover scripts
. cvsimport: rewrite to use cvsps 3.x to fix major bugs
Rerolled as jc/cvsimport-upgrade.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 0:12 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:
> 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?
Yeah, it would be a robust alternative approach to verify that (1)
output is a superset of what we expect, and (2) they all share the
string we fed to the machinery as the common prefix, I would think.
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Jonathan Nieder @ 2013-01-18 0:04 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Torsten Bögershausen, Jeff King, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <201301172347.50157.avila.jn@gmail.com>
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' '
--
1.8.1
^ permalink raw reply related
* Re: Question re. git remote repository
From: Jeff King @ 2013-01-17 23:49 UTC (permalink / raw)
To: David Lang
Cc: Stephen Smith, Konstantin Khomoutov, git@vger.kernel.org,
Lang, David
In-Reply-To: <alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>
On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote:
> >>This one [1] for instance. I also recall seing people having other
> >>"mystical" problems with setups like this so I somehow developed an idea
> >>than having a repository on a networked drive is asking for troubles.
> >>Of course, if there are happy users of such setups, I would be glad to
> >>hear as my precautions might well be unfounded for the recent versions
> >>of Git.
> >>
> >>1. http://code.google.com/p/msysgit/issues/detail?id=130
> >
> >A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. --
>
> I think the risk is that if you have multiple people doing actions on
> the shared filesystem you can run into trouble.
>
> As long as only one copy of git is ever running against the
> repository, I don't see any reason for there to be a problem.
That should not be an issue. Git on a server has to deal with multiple
independent receive-pack's running to accept several simultaneous
pushes. They coordinate through the use of file locks. Having multiple
machines pushing over a shared filesystem should work the same, as long
as the filesystem support atomic creation of files with O_EXCL.
There may be other subtle issues lurking (e.g., the Windows issue that
Konstantin mentioned), but as far as I know, it _should_ work in
general.
-Peff
^ permalink raw reply
* RE: Question re. git remote repository
From: David Lang @ 2013-01-17 23:19 UTC (permalink / raw)
To: Lang, David
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrUIr001039@smtpb01.one-mail.on.ca>
distributed version control systems let each developer have a full repository
locally on their machine, they then can send updates to other people who have a
repository (or a pull request which asks the other person to pull from the
developers repository to the other persons repository)
Most projects have one repository that they designate as being the 'main'
repository for the project, and developers push updates to it (or send pull
requests to the people who own that repository)
The communication between developers is typically via e-mail and the repository
updates are sent via the git-daemon and the git network protocol.
This sort of thing is very different from the model where there is one
repository on a shared disk somewhere and everyone accesses that shared disk to
do their work or apply updates via NFS/CIFS protocols.
Does this clarify the difference?
David Lang
On Thu, 17 Jan 2013, Lang, David wrote:
> Hi David,
>
> Ok, now I'm really lost! This is definitely due to my newbie git status but
> I'll ask anyway. I'm confused by your statement "... if you try to have one
> filesystem, with multiple people running git on their machines against that
> shared filesystem, I would expect you to have all sorts of problems."
>
> Isn't that the whole point of git, or any versioning system? I thought the
> idea was that each developer installed git locally on their machines 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 (and
> which I'm assuming has git installed locally as well).
>
> What am I missing?
>
> The 'other' David Lang ;-)
>
> -----Original Message-----
> From: David Lang [mailto:david@lang.hm]
> Sent: Wednesday, January 16, 2013 6:01 PM
> To: Stephen Smith
> Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David
> Subject: Re: Question re. git remote repository
>
> On Wed, 16 Jan 2013, Stephen Smith wrote:
>
>>>>>> Ideally we'd prefer to simply create our remote repository on a
>>>>>> drive of one of our local network servers. Is this possible?
>>>>>
>>>>> Yes, this is possible, but it's not advised to keep such a
>>>>> "reference" repository on an exported networked drive for a number
>>>>> of reasons (both performance and bug-free operation).
>>>>
>>>> I agree that performance is not ideal (although if you are on a fast
>>>> LAN, it probably would not matter much), but I do not recall any
>>>> specific bugs in that area. Can you elaborate?
>>>
>>> This one [1] for instance. I also recall seing people having other
>>> "mystical" problems with setups like this so I somehow developed an
>>> idea than having a repository on a networked drive is asking for troubles.
>>> Of course, if there are happy users of such setups, I would be glad
>>> to hear as my precautions might well be unfounded for the recent
>>> versions of Git.
>>>
>>> 1. http://code.google.com/p/msysgit/issues/detail?id=130
>>
>> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. --
>
> I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble.
>
> As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem.
>
> But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.
>
> David Lang
>
> 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
* Re: git pull - reporting that I modified files, but I did not
From: Max Horn @ 2013-01-17 22:59 UTC (permalink / raw)
To: Jay Vee; +Cc: git
In-Reply-To: <CADq_mb-k8mP6PAsPciYEkx6fvFNdGK+ejsFEZ4nCJVcUQ6odGg@mail.gmail.com>
On 17.01.2013, at 20:29, Jay Vee wrote:
> When I do a git pull, I am getting a messages that changes to local
> files would be overwritten by a merge, but I have not changed these
> files locally at all, I have not opened them in my IDE.
> This happens every now and then.
>
> 1) Why does this happen?
This is hard to tell given the little information you provide. But clearly *something* modified those files, whether consciously triggered by you or not. But files don't magically change themselves :-). I recommend that you run "git diff" on those files to figure out in what way they changed -- this will likely provide a clue to the cause for this.
All I can say is that it is extremely unlikely that git did this, unless it happens to be something you (or somebody who has access to your git config resp. the repository config) explicitly activated and thus requested from git (e.g. via clean or smudge filters in gitattributes).
> 2) How do I prevent this from happening in the future?
As this largely depends on the cause, it can't be answered before 1) is answered...
>
> 3) How do I get out of this state so that I can do a git pull and
> rebuild my code?
At least over here, when I do a "git status", it actually prints a nice message that explains how to do this. For example, I see something like this:
# On branch next
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: src/MyClass.java
# deleted: src/AnotherClass.java
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/MyModifiedClass.java
# deleted: src/YetAnotherClass.java
...
But I would strongly urge you to first review those changes, to make sure that they are really OK to discard. For example, you wouldn't want to throw away a change you did make on purpose but forgot to commit.
>
> ---
> In other instances, when I do a git pull (not getting the message
> above, I will see something like:
> M src/MyClass.java <= a file that I did not touch or modify
> D src/AnotherClass.java <= a file that I did not delete or touch
> M src/MyModifiedClass.java <= a file that I indeed modified for
> which in the pull there are no merge conflicts.
Hmm, where is this output from?
>
> and the pull is successful, (then I want to push my changes), but I
> did not change either of the above two files
Did you try to find out what the change in them is? E.g. using "git diff" ? My guess would be that the nature of the changes would give a big clue as to their cause. E.g. did indention change? Line breaks? Where RCS keywords expanded / contracted? Was a random piece of code inserted somewhere?
>
> If I see the above, am I OK to push? My thinking is that git thinks I
> changed 'src/MyClass.java' and if I do a diff there are differences,
> but I do not want to push because I NEVER TOUCHED THAT FILE IN ANY
> WAY.
Shouting doesn't help :-). Something on your computer *did* touch the file. Git does not magically change your stuff -- unless in very special cases, but then only when *explicitly* configured to do so by somebody.
>
> What is going on here? Maybe this is normal and I simply do not
> understand correctly.
It doesn't sound "normal", but it doesn't sound like an issue with git either, more like one with your particular setup. It is hard to say more since you give us very little concrete information. E.g. what kind of changes are in those files? Which git version, and what OS are you on? Do you use git via the command line exclusively, or do you use a frontend(s) for it? etc.
>
> What is happening? I would expect to see only line items 'M' and 'D'
> for files that I personally have modified and deleted.
What do you mean by "personally"? Is a cron job you setup and forgot counting towards this, too? What about automatic changes caused by an IDE or a Git frontend? What about automatic changes caused by a git config setting you or a friendly co-worker setup in your gitconfig but you forgot about?
> If I push at this point, will I overwrite changes in the repo pushed
> by others and muck things up?
A push will only push any commits you made. And a commit will only include changes you explicitly staged via "git add", or told "git commit" to include by listing files when doing the commit... So if you worry that what you are about to push is broken, I'd recommend to a) review all local commits and their contents before pushing them, and b) testing your work before pushing it.
Cheers,
Max
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 22:57 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117223050.GL4574@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> You're right - I think we need to add ", errors='replace'" to the call
>>> to encode.
>>
>> Of if it is used just as a opaque token, you can .encode('hex') or
>> something to punt on the whole issue, no?
>
> Even better. Are you happy to squash that in (assuming nothing else
> comes up) or shall I resend?
If you go the .encode('hex') route, the log message needs to explain
why the hashed values are now different from the old implementation
and justify why it is safe to do so. I do not think I want to do
that myself ;-).
Thanks.
>
>>>>> git-remote-testpy.py | 8 ++++----
>>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
>>>>> index d94a66a..f8dc196 100644
>>>>> --- a/git-remote-testpy.py
>>>>> +++ b/git-remote-testpy.py
>>>>> @@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
>>>>> from git_remote_helpers.git.importer import GitImporter
>>>>> from git_remote_helpers.git.non_local import NonLocalGit
>>>>>
>>>>> -if sys.hexversion < 0x01050200:
>>>>> - # os.makedirs() is the limiter
>>>>> - sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
>>>>> +if sys.hexversion < 0x02000000:
>>>>> + # string.encode() is the limiter
>>>>> + sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
>>>>> sys.exit(1)
>>>>>
>>>>> def get_repo(alias, url):
>>>>> @@ -45,7 +45,7 @@ def get_repo(alias, url):
>>>>> repo.get_head()
>>>>>
>>>>> hasher = _digest()
>>>>> - hasher.update(repo.path)
>>>>> + hasher.update(repo.path.encode('utf-8'))
>>>>> repo.hash = hasher.hexdigest()
>>>>>
>>>>> repo.get_base_path = lambda base: os.path.join(
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Jean-Noël AVILA @ 2013-01-17 22:47 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Jeff King, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy
In-Reply-To: <50F64597.2070100@web.de>
Le mercredi 16 janvier 2013 07:15:51, Torsten Bögershausen a écrit :
> On 01/16/2013 12:24 AM, Jeff King wrote:
> > On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
> >> "Jean-Noël AVILA"<avila.jn@gmail.com> writes:
> >>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a
> >>> known issue?
> >>
> >> Which branch?
> >
> > t9902.10 is overly sensitive to extra git commands in your PATH, as well
> > as cruft in your build dir (especially if you have been building 'pu',
> > which has git-check-ignore). Try "make clean&& make test".
> >
> > -Peff
>
> This may help, or it may not.
>
> If there are other binaries like
> "git-check-email" or "git-check-ignore" in the PATH
> .....
>
> When you switch to a branch generating a file like
> git-check-ignore then "make clean" will know about it
> and will remove it.
> If you switch to master, then "make clean" will not remove it.
>
> What does "git status" say?
>
> We had a discussion about this some weeks ago, but never concluded.
>
> How about this:
> http://comments.gmane.org/gmane.comp.version-control.git/211907
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.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <7v622vtplm.fsf@alter.siamese.dyndns.org>
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
>> You're right - I think we need to add ", errors='replace'" to the call
>> to encode.
>
> Of if it is used just as a opaque token, you can .encode('hex') or
> something to punt on the whole issue, no?
Even better. Are you happy to squash that in (assuming nothing else
comes up) or shall I resend?
>>>> git-remote-testpy.py | 8 ++++----
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
>>>> index d94a66a..f8dc196 100644
>>>> --- a/git-remote-testpy.py
>>>> +++ b/git-remote-testpy.py
>>>> @@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
>>>> from git_remote_helpers.git.importer import GitImporter
>>>> from git_remote_helpers.git.non_local import NonLocalGit
>>>>
>>>> -if sys.hexversion < 0x01050200:
>>>> - # os.makedirs() is the limiter
>>>> - sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
>>>> +if sys.hexversion < 0x02000000:
>>>> + # string.encode() is the limiter
>>>> + sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
>>>> sys.exit(1)
>>>>
>>>> def get_repo(alias, url):
>>>> @@ -45,7 +45,7 @@ def get_repo(alias, url):
>>>> repo.get_head()
>>>>
>>>> hasher = _digest()
>>>> - hasher.update(repo.path)
>>>> + hasher.update(repo.path.encode('utf-8'))
>>>> repo.hash = hasher.hexdigest()
>>>>
>>>> repo.get_base_path = lambda base: os.path.join(
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: Junio C Hamano @ 2013-01-17 22:24 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117210048.GI4574@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> You're right - I think we need to add ", errors='replace'" to the call
> to encode.
Of if it is used just as a opaque token, you can .encode('hex') or
something to punt on the whole issue, no?
>
>> > git-remote-testpy.py | 8 ++++----
>> > 1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/git-remote-testpy.py b/git-remote-testpy.py
>> > index d94a66a..f8dc196 100644
>> > --- a/git-remote-testpy.py
>> > +++ b/git-remote-testpy.py
>> > @@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
>> > from git_remote_helpers.git.importer import GitImporter
>> > from git_remote_helpers.git.non_local import NonLocalGit
>> >
>> > -if sys.hexversion < 0x01050200:
>> > - # os.makedirs() is the limiter
>> > - sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
>> > +if sys.hexversion < 0x02000000:
>> > + # string.encode() is the limiter
>> > + sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
>> > sys.exit(1)
>> >
>> > def get_repo(alias, url):
>> > @@ -45,7 +45,7 @@ def get_repo(alias, url):
>> > repo.get_head()
>> >
>> > hasher = _digest()
>> > - hasher.update(repo.path)
>> > + hasher.update(repo.path.encode('utf-8'))
>> > repo.hash = hasher.hexdigest()
>> >
>> > repo.get_base_path = lambda base: os.path.join(
^ permalink raw reply
* [PATCH] simplify-merges: drop merge from irrelevant side branch
From: Junio C Hamano @ 2013-01-17 22:23 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Phil Hord
In-Reply-To: <7vk3re0zyt.fsf@alter.siamese.dyndns.org>
The merge simplification rule stated in 6546b59 (revision traversal:
show full history with merge simplification, 2008-07-31) still
treated merge commits too specially. Namely, in a history with this
shape:
---o---o---M
/
x---x---x
where three 'x' were on a history completely unrelated to the main
history 'o' and do not touch any of the paths we are following, we
still said that after simplifying all of the parents of M, 'x'
(which is the leftmost 'x' that rightmost 'x simplifies down to) and
'o' (which would be the last commit on the main history that touches
the paths we are following) are independent from each other, and
both need to be kept.
That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the paths.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The old test vector had a history ending at I; the updates to it
adds an unrelated side branch rooted at J, merge of I and J which
is K, and then an extra commit L on top.
A---(some merge mess)---I---K---L
/
J
revision.c | 19 +++++++++++++++++++
t/t6012-rev-list-simplify.sh | 26 +++++++++++++++++++++-----
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/revision.c b/revision.c
index 33cb207..532611b 100644
--- a/revision.c
+++ b/revision.c
@@ -1424,6 +1424,22 @@ static struct merge_simplify_state *locate_simplify_state(struct rev_info *revs,
return st;
}
+static void remove_treesame_parents(struct commit *commit)
+{
+ struct commit_list **pp, *p;
+
+ pp = &commit->parents;
+ while ((p = *pp) != NULL) {
+ struct commit *parent = p->item;
+ if (parent->object.flags & TREESAME) {
+ *pp = p->next;
+ free(p);
+ continue;
+ }
+ pp = &p->next;
+ }
+}
+
static struct commit_list **simplify_one(struct rev_info *revs, struct commit *commit, struct commit_list **tail)
{
struct commit_list *p;
@@ -1469,6 +1485,9 @@ static struct commit_list **simplify_one(struct rev_info *revs, struct commit *c
pst = locate_simplify_state(revs, p->item);
p->item = pst->simplified;
}
+
+ remove_treesame_parents(commit);
+
cnt = remove_duplicate_parents(commit);
/*
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index 510bb96..d6d79c4 100755
--- a/t/t6012-rev-list-simplify.sh
+++ b/t/t6012-rev-list-simplify.sh
@@ -59,7 +59,23 @@ test_expect_success setup '
echo "Final change" >file &&
test_tick && git commit -a -m "Final change" &&
- note I
+ note I &&
+
+ git symbolic-ref HEAD refs/heads/unrelated &&
+ git rm -f "*" &&
+ echo "Unrelated branch" >side &&
+ git add side &&
+ test_tick && git commit -m "Side root" &&
+ note J &&
+
+ git checkout master &&
+ test_tick && git merge -m "Coolest" unrelated &&
+ note K &&
+
+ echo "Immaterial" >elif &&
+ git add elif &&
+ test_tick && git commit -m "Last" &&
+ note L
'
FMT='tformat:%P %H | %s'
@@ -82,10 +98,10 @@ check_result () {
'
}
-check_result 'I H G F E D C B A' --full-history
-check_result 'I H E C B A' --full-history -- file
-check_result 'I H E C B A' --full-history --topo-order -- file
-check_result 'I H E C B A' --full-history --date-order -- file
+check_result 'L K J I H G F E D C B A' --full-history
+check_result 'K I H E C B A' --full-history -- file
+check_result 'K I H E C B A' --full-history --topo-order -- file
+check_result 'K I H E C B A' --full-history --date-order -- file
check_result 'I E C B A' --simplify-merges -- file
check_result 'I B A' -- file
check_result 'I B A' --topo-order -- file
--
1.8.1.1.431.g469ab37
^ permalink raw reply related
* [PATCH] git-svn: teach find-rev to find near matches
From: John Keeping @ 2013-01-17 22:19 UTC (permalink / raw)
To: git; +Cc: Eric Wong
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>
---
Documentation/git-svn.txt | 10 ++++++++++
git-svn.perl | 12 ++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 69decb1..34d438b 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -346,6 +346,16 @@ Any other arguments are passed directly to 'git log'
corresponding git commit hash (this can optionally be followed by a
tree-ish to specify which branch should be searched). When given a
tree-ish, returns the corresponding SVN revision number.
++
+--before;;
+ Don't require an exact match if given an SVN revision, instead find
+ the commit corresponding to the state of the SVN repository (on the
+ current branch) at the specified revision.
++
+--after;;
+ Don't require an exact match if given an SVN revision; if there is
+ not an exact match return the closest match searching forward in the
+ history.
'set-tree'::
You should consider using 'dcommit' instead of this command.
diff --git a/git-svn.perl b/git-svn.perl
index bd5266c..d086694 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -114,6 +114,7 @@ my ($_stdin, $_help, $_edit,
$_message, $_file, $_branch_dest,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
+ $_before, $_after,
$_merge, $_strategy, $_preserve_merges, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
$_commit_url, $_tag, $_merge_info, $_interactive);
@@ -258,7 +259,8 @@ my %cmd = (
} ],
'find-rev' => [ \&cmd_find_rev,
"Translate between SVN revision numbers and tree-ish",
- {} ],
+ { 'before' => \$_before,
+ 'after' => \$_after } ],
'rebase' => [ \&cmd_rebase, "Fetch and rebase your working directory",
{ 'merge|m|M' => \$_merge,
'verbose|v' => \$_verbose,
@@ -1191,7 +1193,13 @@ sub cmd_find_rev {
"$head history\n";
}
my $desired_revision = substr($revision_or_hash, 1);
- $result = $gs->rev_map_get($desired_revision, $uuid);
+ if ($_before) {
+ $result = $gs->find_rev_before($desired_revision, 1);
+ } elsif ($_after) {
+ $result = $gs->find_rev_after($desired_revision, 1);
+ } else {
+ $result = $gs->rev_map_get($desired_revision, $uuid);
+ }
} else {
my (undef, $rev, undef) = cmt_metadata($revision_or_hash);
$result = $rev;
--
1.8.1.1
^ permalink raw reply related
* RE: Question re. git remote repository
From: Lang, David @ 2013-01-17 21:53 UTC (permalink / raw)
To: David Lang
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>
Hi David,
Ok, now I'm really lost! This is definitely due to my newbie git status but I'll ask anyway. I'm confused by your statement "... if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems."
Isn't that the whole point of git, or any versioning system? I thought the idea was that each developer installed git locally on their machines 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 (and which I'm assuming has git installed locally as well).
What am I missing?
The 'other' David Lang ;-)
-----Original Message-----
From: David Lang [mailto:david@lang.hm]
Sent: Wednesday, January 16, 2013 6:01 PM
To: Stephen Smith
Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David
Subject: Re: Question re. git remote repository
On Wed, 16 Jan 2013, Stephen Smith wrote:
>>>>> Ideally we'd prefer to simply create our remote repository on a
>>>>> drive of one of our local network servers. Is this possible?
>>>>
>>>> Yes, this is possible, but it's not advised to keep such a
>>>> "reference" repository on an exported networked drive for a number
>>>> of reasons (both performance and bug-free operation).
>>>
>>> I agree that performance is not ideal (although if you are on a fast
>>> LAN, it probably would not matter much), but I do not recall any
>>> specific bugs in that area. Can you elaborate?
>>
>> This one [1] for instance. I also recall seing people having other
>> "mystical" problems with setups like this so I somehow developed an
>> idea than having a repository on a networked drive is asking for troubles.
>> Of course, if there are happy users of such setups, I would be glad
>> to hear as my precautions might well be unfounded for the recent
>> versions of Git.
>>
>> 1. http://code.google.com/p/msysgit/issues/detail?id=130
>
> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. --
I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble.
As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem.
But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.
David Lang
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
* [PATCH] git-svn: do not escape certain characters in paths
From: Peter Wu @ 2013-01-17 22:07 UTC (permalink / raw)
To: git
Subversion 1.7 and newer implement HTTPv2, an extension that should make HTTP
more efficient. Servers with support for this protocol will make the subversion
client library take an alternative code path that checks (with assertions)
whether the URL is "canonical" or not.
This patch fixes an issue I encountered while trying to `git svn dcommit` a
rename action for a file containing a single quote character ("User's Manual"
to "UserMan.tex"). It does not happen for older subversion 1.6 servers nor
non-HTTP(S) protocols such as the native svn protocol, only on an Apache server
shipping SVN 1.7. Trying to `git svn dcommit` under the aforementioned
conditions yields the following error which aborts the commit process:
Committing to http://example.com/svn ...
perl: subversion/libsvn_subr/dirent_uri.c:1520: uri_skip_ancestor:
Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
error: git-svn died of signal 6
An analysis of the subversion source for the cause:
- The assertion originates from uri_skip_ancestor which calls
svn_uri_is_canonical, which fails when the URL contains percent-encoded values
that do not necessarily have to be encoded (not "canonical" enough). This is
done by a table lookup in libsvn_subr/path.c. Putting some debugging prints
revealed that the character ' is indeed encoded to %27 which is not
considered canonical.
- url_skip_ancestor is called by svn_ra_neon__get_baseline_info with the root
repository URL and path as parameters;
- which is called by copy_resource (libsvn_ra_neon/commit.c) for a copy action
(or in my case, renaming which is actually copy + delete old);
- which is called by commit_add_dir;
- which is assigned as a structure method "add_file" in
svn_ra_neon__get_commit_editor.
In the whole path, the path argument is not modified.
Through some more uninteresting wrapper functions, the Perl bindings gives you
access to the add_file method which will pass the path argument without
modifications to svn.
git-svn calls the "R"(ename) subroutine in Git::SVN::Editor which contains:
326 my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
327 $self->url_path($m->{file_a}), $self->{r});
"repo_path" basically returns the path as-is, unless the "svn.pathnameencoding"
configuration property is set. "url_path" tries to escape some special
characters, but does not take all special characters into account, thereby
causing the path to contain some escaped characters which do not have to be
escaped.
The list of characters not to be escaped are taken from the
subversion/libsvn_subr/path.c file to fully account for all characters. Tested
with a filename containing all characters in the range 0x20 to 0x78 (inclusive).
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
---
perl/Git/SVN/Editor.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 3bbc20a..30f92cb 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -145,7 +145,8 @@ sub repo_path {
sub url_path {
my ($self, $path) = @_;
if ($self->{url} =~ m#^https?://#) {
- $path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
+ # characters are taken from subversion/libsvn_subr/path.c
+ $path =~ s#([^~a-zA-Z0-9_./!$&'()*+,-])#uc sprintf("%%%02x",ord($1))#eg;
}
$self->{url} . '/' . $self->repo_path($path);
}
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH 2/8] Add --unannotate
From: James Nylen @ 2013-01-17 21:07 UTC (permalink / raw)
To: greened; +Cc: Junio C Hamano, git
In-Reply-To: <87sj6kfsbz.fsf@waller.obbligato.org>
On Tue, Jan 1, 2013 at 5:31 PM, <greened@obbligato.org> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "David A. Greene" <greened@obbligato.org> writes:
>>
>>> From: James Nylen <jnylen@gmail.com>
>>>
>>> Teach git-subtree about --unannotate. This option strips a prefix
>>> from a commit message when doing a subtree split.
>>
>> Hrm. This looks like a workaround for a short-sighted misdesign of
>> the annotate option that only allowed prefixing a fixed string. I
>> have to wonder if it is better to deprecate --annotate and replace
>> it with a more general "commit log rewriting" facility that can
>> cover both use cases?
>
> That's not a bad idea. I'd have to think a bit about a sensible design.
> Do you have any ideas, James?
I just now saw these emails. I'm having a hard time thinking of any
good use case other than:
- add "fancylib" as a subtree of "myprog"
- commit to myprog repo: "fancylib: don't crash as much"
- split these commits back out to fancylib's main repo, and remove
the "fancylib: " prefix
You could potentially have something like "Don't crash as much
(fancylib)" but that's awkward. What might you want to do with a
pattern-based rewrite that doesn't involve removing a prefix when
splitting commits?
In fact, I don't see the use of the original --annotate option at all,
since it causes more detailed commit messages in the smaller of the
two repositories.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <20130117210048.GI4574@serenity.lan>
On Thu, Jan 17, 2013 at 09:00:48PM +0000, John Keeping wrote:
> On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> Under Python 3 'hasher.update(...)' must take a byte string and not a
>>> unicode string. Explicitly encode the argument to this method as UTF-8
>>> so that this code works under Python 3.
>>>
>>> This moves the required Python version forward to 2.0.
>>>
>>> Signed-off-by: John Keeping <john@keeping.me.uk>
>>> ---
>>
>> Hmph. So what happens when the path is _not_ encoded in UTF-8?
>
> Do you mean encodable? As you say below it will currently throw an
> exception.
Now my brain's not working - we shouldn't get an error converting from a
Unicode string to UTF-8, so I think this patch is OK as it is.
> > Is the repo.hash (and local.hash that gets a copy of it) something
> > that needs to stay the same across multiple invocations of this
> > remote helper, and between the currently shipped Git and the version
> > of Git after applying this patch?
>
> It's used to specify the path of the repository for importing or
> exporting, so it should stay consistent across invocations. However,
> this is only an example remote helper so I don't think we should worry
> if it changes from one Git release to the next.
^ permalink raw reply
* Re: [PATCH v2 6/8] git-remote-testpy: hash bytes explicitly
From: John Keeping @ 2013-01-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Pete Wyckoff
In-Reply-To: <7vtxqftulq.fsf@alter.siamese.dyndns.org>
On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
>> Under Python 3 'hasher.update(...)' must take a byte string and not a
>> unicode string. Explicitly encode the argument to this method as UTF-8
>> so that this code works under Python 3.
>>
>> This moves the required Python version forward to 2.0.
>>
>> Signed-off-by: John Keeping <john@keeping.me.uk>
>> ---
>
> Hmph. So what happens when the path is _not_ encoded in UTF-8?
Do you mean encodable? As you say below it will currently throw an
exception.
> Is the repo.hash (and local.hash that gets a copy of it) something
> that needs to stay the same across multiple invocations of this
> remote helper, and between the currently shipped Git and the version
> of Git after applying this patch?
It's used to specify the path of the repository for importing or
exporting, so it should stay consistent across invocations. However,
this is only an example remote helper so I don't think we should worry
if it changes from one Git release to the next.
> If that is not the case, and if
> this is used only to get a randomly-looking 40-byte hexadecimal
> string, then a lossy attempt to .encode('utf-8') and falling back to
> replace or ignore bytes in the original that couldn't be interpreted
> as part of a UTF-8 string would be OK, but doesn't .encode('utf-8')
> throw an exception if not told to 'ignore' or something?
You're right - I think we need to add ", errors='replace'" to the call
to encode.
> > git-remote-testpy.py | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> > index d94a66a..f8dc196 100644
> > --- a/git-remote-testpy.py
> > +++ b/git-remote-testpy.py
> > @@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
> > from git_remote_helpers.git.importer import GitImporter
> > from git_remote_helpers.git.non_local import NonLocalGit
> >
> > -if sys.hexversion < 0x01050200:
> > - # os.makedirs() is the limiter
> > - sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
> > +if sys.hexversion < 0x02000000:
> > + # string.encode() is the limiter
> > + sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
> > sys.exit(1)
> >
> > def get_repo(alias, url):
> > @@ -45,7 +45,7 @@ def get_repo(alias, url):
> > repo.get_head()
> >
> > hasher = _digest()
> > - hasher.update(repo.path)
> > + hasher.update(repo.path.encode('utf-8'))
> > repo.hash = hasher.hexdigest()
> >
> > repo.get_base_path = lambda base: os.path.join(
^ 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