git commit --interactive patch-mode no longer allows selecting files
Hi, i'm not entirely sure if this is a bug or intended (couldn't find it in the changelogs though)... Before 2.12.0 a `git commit --int` / `git add --int` followed by [p] for patch-mode, would allow a numeric selection of the files to patch hunks for (this behavior is well documented all over the internet). Since 2.12.0 the numeric selection is skipped and automatically drops me directly into hunk mode (Mac OS X homebrew). I would see this as a feature if only one file is changed. As soon as multiple files are changed, i often have the use-case that i'm in some bigger change, but want to quickly fix something in other files. In those cases, the new behavior forces me to `d` out of potentially many files, just to quickly commit some small change :-/ I already tried in several repos and without ~/.gitconfig . Are there any config options i'm missing? Best, Jörn
publish from certain commit onward, keeping earlier history private, but provable
Hi, I've been hacking away on a library for quite some time and have a lot of commits in my private repository: A -> B -> C -> D -> E Finally, I'm nearing completion of a first version, and want to publish it to a remote called public from D onward keeping A..C to myself, so public should afterwards look like this: D -> E My main motivation is that i don't really want to put ridiculously first trials online, but still (on demand) I'd like to be able to prove how i arrived at D (think of copyright claims, etc). As (at the moment) it's pretty much impossible to reverse-engineer the hashes of commits in the chain with times and changesets, i thought just keeping D's parent pointer to C would be one of the genius advantages of git. Sadly i can't find a way to actually make this work. Can i somehow push D -> E to public making it a fully functional public repository with all the necessary objects included to checkout D or E and D still pointing to C as parent? If not, why is that? What doesn't seem to work: - push with range git push public D..E:master error: src refspec D..E does not match any. error: failed to push some refs to '' - any form of squashing / history rewriting As far as i know squashing A..D would introduce a new commit removing the parent pointer to C and thereby removing provability of the existence of A..C. (Simple example: say C reversed B, then you'd never be able to prove B was in there at some point.) I could obviously manually note the hash of C in the description of the squash commit, but there already is a parent pointer field, why not use it? Also in order to contribute further changes to public I'd have to rebase my private branches on top of this new squashed commit, which just seems as wrong... - push from local clone with limited depth I thought i found a solution to this by first creating a local clone local_public with the desired depth before pushing that clone to public like this: git clone --depth 2 file:/// local_public With git log --pretty=raw I can verify that local_public only contains D -> E and that the commit, tree and parent hashes are the same, which is exactly what i want. The problem is that when i try to push to an added public remote from local_public i get an error like this: ! [remote rejected] master -> master (shallow update not allowed) Any ideas how to make this work? Cheers, Jörn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: Fix cloning and sharing bug
Hi,
On 4 Aug 2013, at 12:38, Antoine Pelisse apeli...@gmail.com wrote:
[…]
I also decided to always clone local repositories because what Jörn Hees
said makes sense:
If you have a local clone of a big repository, and then want to add a slow
remote, you would have to reclone everything.
I think the trade-off is good, because clone from local should not be that
time expensive (maybe it can be on disk-space though).
I was working on a similar patch in the meantime, this point was the only thing
that
kept me from submitting… Can someone of you think of an easy way to do this
lazily
on the first non-local remote being added?
In case we don't have a non-local clone (a mercurial dir with a clone subdir)
yet, we
would try to go though the local mercurial remotes and then clone them… Just
would
need a way to get their URLs. I thought about going through all git remote -v
This way we wouldn't need to copy by default (bad for big repos), but could
still do this
in a cheap way if a slow remote is added later on.
Btw, is there any reason why we don't just use the local mercurial remotes as
shared
repo? Cause it's not under our git dir and might be deleted?
[…]
contrib/remote-helpers/git-remote-hg | 47 --
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..487c13d 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -385,33 +385,42 @@ def get_repo(url, alias):
extensions.loadall(myui)
-if hg.islocal(url) and not os.environ.get('GIT_REMOTE_HG_TEST_REMOTE'):
-repo = hg.repository(myui, url)
-if not os.path.exists(dirname):
-os.makedirs(dirname)
-else:
-shared_path = os.path.join(gitdir, 'hg')
-if not os.path.exists(shared_path):
+hgdir = os.path.join(gitdir, 'hg')
+try:
+os.mkdir(hgdir)
+except OSError:
+pass
+
+shared_path = os.path.join(hgdir, '.shared')
I thought we had agreed to use .git/hg as the shared directory before? (so that
a clone into that dir would end up in .git/hg/.hg instead of
.git/hg/.shared/.hg)
+if not os.path.exists(shared_path):
+for remote in os.listdir(hgdir):
+try:
+hg.clone(myui, {}, os.path.join(hgdir, remote, 'clone'),
+ shared_path, update=False, pull=True)
+break
+except error.RepoError:
+pass
+else:
Elegant use of the for-else clause, but to my experience confuses many people.
This would also be the place to check for local remotes after not finding
already
cloned non-local remotes (the lazy approach mentioned above). As this would
cause nested for-else loops, i'd rather repeatedly check for existence of
.git/hg/.hg
and list the several fallback in order, the last one being this one:
try:
hg.clone(myui, {}, url, shared_path, update=False, pull=True)
except:
die('Repository error')
If you want i'll send around my patch as RFC.
In the end i don't care which one is accepted and how, most important that one
is
accepted to fix the bug.
Cheers,
Jörn--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug resolved] remotes-hg: timezones are transformed
Hi, On 4 Aug 2013, at 01:17, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Aug 3, 2013 at 11:36 AM, Jörn Hees d...@joernhees.de wrote: it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a mercurial repo the timezone information of commits gets transformed into your current timezone. (command: git clone hg::…) I noticed this when a colleague in another timezone used Kiln to also export the same mercurial repo that i had cloned from git before. Fetching from his git repo gives me a second root tree with all commits duplicated. A git show of two equivalent commit reveals that the Date: line of the commits changed. Tracking this back into the original mercurial repo reveals that _his_ times are correct. This will also make two or more clones from different timezones all using the same hg remote repo incompatible! Example: Original mercurial commit (timezone: -7200 = -4h) https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/ sorry, i feel stupid for this now… this obviously is -2h: 2*60*60… not 4 (but see below) Lipis git export via Kiln: (-4h) https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c so is this: it should've said -2h My export via git clone hg::ssh://h...@bitbucket.org/lipis/gae-init (+2h) https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae this one was correct: +2h Actually our version is the correct one: % hg commit -m one -d 2012-04-28 11:28 +0200 % hg export # HG changeset patch # User Felipe Contreras felipe.contre...@gmail.com # Date 1335605280 -7200 # Sat Apr 28 11:28:00 2012 +0200 Thanks for clarifying this. I had falsely assumed that no one would dare to flip the sign of the timezone spec. Turns out that mercurial commits contain the _negative_ timezone offset in seconds, so UTC+2 will actually be saved as -7200! I was actually still doubtful so i searched for some credible ref and was able to find this insanity documented in hg help dates: - 1165432709 0 (Wed Dec 6 13:18:29 2006 UTC) This is the internal representation format for dates. The first number is the number of seconds since the epoch (1970-01-01 00:00 UTC). The second is the offset of the local timezone, in seconds west of UTC (negative if the timezone is east of UTC). I use the word insane here, as there are many standards for date times, but not one dares to switch the timezone sign! https://en.wikipedia.org/wiki/Time_zone https://upload.wikimedia.org/wikipedia/commons/a/ad/Standard_time_zones_of_the_world.png I'm sorry for reporting this as a bug and instead have to pull my hat. Cheers, Jörn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: Fix cloning and sharing bug
On 4 Aug 2013, at 15:31, Felipe Contreras felipe.contre...@gmail.com wrote:
git config --get-regexp '^remote.*.url' is probably more appropriate.
Either way, I don't see why such a change should be in the same patch.
+1
This is my solution:
--- a/contrib/remote-helpers/git-remote-hg.py
+++ b/contrib/remote-helpers/git-remote-hg.py
@@ -391,11 +391,22 @@ def get_repo(url, alias):
os.makedirs(dirname)
else:
shared_path = os.path.join(gitdir, 'hg')
-if not os.path.exists(shared_path):
-try:
-hg.clone(myui, {}, url, shared_path, update=False, pull=True)
-except:
-die('Repository error')
+
+# check and upgrade old organization
+hg_path = os.path.join(shared_path, '.hg')
+if os.path.exists(shared_path) and not os.path.exists(hg_path):
+repos = os.listdir(shared_path)
+for x in repos:
+local_hg = os.path.join(shared_path, x, 'clone', '.hg')
+if not os.path.exists(local_hg):
+continue
+shutil.copytree(local_hg, hg_path)
+
+# setup shared repo (if not there)
+try:
+hg.peer(myui, {}, shared_path, create=True)
Didn't look this up, this will raise the error below when it exists already?
+except error.RepoError:
+pass
if not os.path.exists(dirname):
os.makedirs(dirname)
It should also work in all the cases, but there would not be an extra
unnecessary clone while upgrading, and it doesn't sneak in any other
changes.
+1
Seems to be the best fix until now.
Cheers,
Jörn--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug] remotes-hg: timezones are transformed
Hi, it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a mercurial repo the timezone information of commits gets transformed into your current timezone. (command: git clone hg::…) I noticed this when a colleague in another timezone used Kiln to also export the same mercurial repo that i had cloned from git before. Fetching from his git repo gives me a second root tree with all commits duplicated. A git show of two equivalent commit reveals that the Date: line of the commits changed. Tracking this back into the original mercurial repo reveals that _his_ times are correct. This will also make two or more clones from different timezones all using the same hg remote repo incompatible! Example: Original mercurial commit (timezone: -7200 = -4h) https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/ Lipis git export via Kiln: (-4h) https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c My export via git clone hg::ssh://h...@bitbucket.org/lipis/gae-init (+2h) https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae Expected would be that the hashes of both git exports are the same. His are correct as far as i can tell. Cheers, Jörn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] remotes-hg: bugfix for fetching non local remotes
On 25 Jul 2013, at 21:12, Felipe Contreras felipe.contre...@gmail.com wrote:
[…]
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..f4e9d1c 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -390,7 +390,7 @@ def get_repo(url, alias):
if not os.path.exists(dirname):
os.makedirs(dirname)
else:
-shared_path = os.path.join(gitdir, 'hg')
+shared_path = os.path.join(gitdir, 'hg', '.shared')
if not os.path.exists(shared_path):
try:
hg.clone(myui, {}, url, shared_path, update=False, pull=True)
--
1.8.3.4
I don't like this approach because if it's a huge repository the user
would have to clone again, not only if he was using v1.8.3, but also
if he was using the latest and greatest (because you are changing the
location again). t's relatively trivial to move from the old to the
shared organization, so that's what I vote for. Besides, I don't see
the point of having a '.shared/.hg' directory, and nothing else on
that '.shared' folder.
Agreed… it just was the shortest possible fix with an in my POV minor
optimisation drawback of once refetching...
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] remotes-hg: bugfix for fetching non local remotes
On 25 Jul 2013, at 23:10, Antoine Pelisse apeli...@gmail.com wrote: On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: That's true. Maybe something like: for x in repos: local_hg = os.path.join(shared_path, x, 'clone', '.hg') if os.path.exists(local_hg): shutil.copytree(local_hg, hg_path) break I think that would work yupp, might work, but holding you liable to the same optimality restriction you imposed on me before: This will still refetch the whole repo once if it was cloned from a local hg repo first (they don't have a clone subdir). Shouldn't we then also go through the additional effort and copy the .hg dir from local remotes when a remote remote is added and there's no other remote remote? j -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
Hi,
On 24.07.2013, at 10:52, Antoine Pelisse apeli...@gmail.com wrote:
I think the best way would be to create the shared repository in
.git/hg/$share, with $share being a path that can't be a remote name
(so that it doesn't conflict with remote directories),
and then apply the following patch (copied in gmail)
Maybe .git/hg/.share?
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..21c8091 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -390,7 +390,7 @@ def get_repo(url, alias):
if not os.path.exists(dirname):
os.makedirs(dirname)
else:
-shared_path = os.path.join(gitdir, 'hg')
+shared_path = os.path.join(gitdir, 'hg', $share)
if not os.path.exists(shared_path):
try:
hg.clone(myui, {}, url, shared_path, update=False, pull=True)
That way, the share can be created even if .git/hg already exists
(because of a previous import, before the shared machinery existed, or
because you already have a local remote).
I like the idea of having independent remotes (fetching one, doesn't update
another). http://mercurial.selenic.com/wiki/ShareExtension warns about this,
and i wasn't sure it wouldn't cause intricate bugs. This is why I opted for the
explicit cloning, no shared history for several remotes.
I'd really like some feedback on this one as he probably knows the hg internals
well enough that he can make a more educated guess on this than I can: when you
import several hg remotes and fetch them / push to one, wouldn't such a shared
repo cause problems?
If unsure i still opt for my version as it keeps things isolated at the cost of
some optimization.
Changing gitdir to dirname causes shared_path ==
.git/hg/remote_name/hg. The call to hg.share with local_path ==
.git/hg/remote_name/clone works again.
I think that will be a problem, because then the shared_path will no
longer be shared, will it ?
Yupp, the shared_paths won't be shared, so it's not as optimal as possible, but
it will work at least ;)
Cheers,
Jörn
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
On 24.07.2013, at 15:14, Antoine Pelisse apeli...@gmail.com wrote: On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees d...@joernhees.de wrote: On 24.07.2013, at 10:52, Antoine Pelisse apeli...@gmail.com wrote: I think the best way would be to create the shared repository in .git/hg/$share, with $share being a path that can't be a remote name (so that it doesn't conflict with remote directories), Maybe .git/hg/.share? According to Documentation/git-check-ref-format.txt, I'm not sure if we should start with a dot, or end with it. I favor starting with a dot as it's nothing the user should fiddle with ;) That way, the share can be created even if .git/hg already exists (because of a previous import, before the shared machinery existed, or because you already have a local remote). I like the idea of having independent remotes (fetching one, doesn't update another). http://mercurial.selenic.com/wiki/ShareExtension warns about this, and i wasn't sure it wouldn't cause intricate bugs. This is why I opted for the explicit cloning, no shared history for several remotes. I think the goal of using sharing here is that Mercurial and Git may use different schemes to handle branches. Mercurial may lead you to have separate repositories for each branch (They seem to do it for its own development [1]). All these branches actually share most of the same history, and are fully related, and we usually handle this situation in Git with one repository with multiple branches. Using hg share, we allow a smooth transition from Mercurial model to Git model by merging all Mercurial repositories into one, and then map this single repository to the Git repository. IOW, the goal is to have only one copy of each hg object that are shared amongst many remotes (and potentially import them only once, though I don't think it currently works for me). Alright, i just tested it out by sharing several repos and pushing to one of them, then fetching all again. Behavior seems as expected, so the remotes and their branches shown are isolated correctly. Plus the initial fetching is quite a lot faster, less disk space used, etc… So i think this is the way to go, thanks for the nudge. Changing gitdir to dirname causes shared_path == .git/hg/remote_name/hg. The call to hg.share with local_path == .git/hg/remote_name/clone works again. I think that will be a problem, because then the shared_path will no longer be shared, will it ? Yupp, the shared_paths won't be shared, so it's not as optimal as possible, but it will work at least ;) If we decided to remove the sharing idea, I think we should revert Felipe's commit rather than leave the shared_path variable, and call hg.share() on repository we don't even mean to share. That would be very confusing. +1 I'll prepare a v2 of the patch. Cheers, Jörn -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
On 24 Jul 2013, at 17:20, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees d...@joernhees.de wrote:
On 24.07.2013, at 10:52, Antoine Pelisse apeli...@gmail.com wrote:
I think the best way would be to create the shared repository in
.git/hg/$share, with $share being a path that can't be a remote name
(so that it doesn't conflict with remote directories),
Maybe .git/hg/.share?
According to Documentation/git-check-ref-format.txt, I'm not sure if
we should start with a dot, or end with it.
What are in these directories under .git/hg? Surely they cannot be
refs in Git's sense, as that hierarchy is not known to anything and
will not be protected from git gc.
Puzzled...
Goes and looks...
OK, the tracking branches for these are created under refs/hg/*
using the same name.
A refname shouldn't begin or end with a dot, because the range
master...share
will become ambiguous if you allowed .share as a refname
shorthand. It could mean either one of these:
master..refs/heads/.share
master...refs/heads/share
The same for the trailing dot share.; the range share...master
becomes ambiguous.
I think there is a slight misunderstanding here:
.git/hg/remote_name will be the actual directory for a hg:: remote, which
will then use mercurial internal magic to refer to the shared repo
.git/hg/.shared in case the remote is not somewhere on the local filesystem,
otherwise that path is used.
What will appear in the refs is something like:
hg/remote_name/{branches,bookmarks}/{master,default,…}.
So the .shared will correctly never appear in a git ref, which is what we want.
It can also not clash with a remote as .shared is not a valid name… also what
we want ;)
Cheers,
Jörn
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] remotes-hg: bugfix for fetching non local remotes
On 25 Jul 2013, at 01:02, Junio C Hamano gits...@pobox.com wrote: Joern Hees d...@joernhees.de writes: Changing shared_path to .git/hg/.shared will solve this problem Here you say shared and the code says share; which one is preferred (I know either would work, but we would want to be consistent). I'd vote for shared, but I do not see a compelling reason to pick one over the other so…? ok, v3 coming... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
