Re: how to make full copy of a repo
On 2015-03-28 03.56, Christoph Anton Mitterer wrote: Hey. I was looking for an ideally simple way to make a full copy of a git repo. Many howtos are floating around on this on the web, with also lots of voodoo. First, it shouldn't be just a clone, i.o.w. - I want to have all refs (local/remote branches/tags) and of course all objects from the source repo copied as is. So it's local branches should become my local branches and not remote branches as well - and so on. Basically I want to be able to delete the source afterwards (and all backups ;) ) and not having anything lost. - It shouldn't set the source repo as origin or it's branches as remote tracking branches, as said it should be identical the source repo, just freshly copied via the Git aware transport mechanisms. - Whether GC or repacking happens, I don't care, as long as nothing that is still reachable in the source repo wouldn't get lost (or get lost once I run a GC in the copied repo). - Whether anything that other tools have added to .git (e.g. git-svn stuff) get's lost, I don't care. - It should work for both, bare and non-bare repos, but it's okay when it doesn't copy anything that is not committed or stashed. I'd have said that either: $ git clone --mirror URl-to-source-repo copy for the direction from outside the source to a copy, or alternatively: $ cd source-repo $ git push --mirror URl-to-copy for the direction from within the source to a copy with copy being an empty bare or non-bare repo, would do the job. But: a) but the git-clone(1) part for --mirror: and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository. kinda confuses me since I wanted to get independent of the source repo and this ssems to set up a remote to it? b) do I need --all --tags for the push as well? c) When following https://help.github.com/articles/duplicating-a-repository/ it doesn't seem as if --mirror is what I want because they seem to advertise it rather as having the copy tracking the source repo. Of course I read about just using git-clone --bare, but that seems to not copy everything that --mirror does (remote-tracking branches, notes). So I'm a bit confused... This instructions have 3 repos: the source, old, the destination new and a temporary one. As you only push to new, new should have no information about old or temp. 1) Is it working like I assumed above? 2) Does that also copy things like git-config, hooks, etc.? 3) Does it copy the configured remotes from the source? 4) What else is not copied by that? I'd assume anything that is not tracked by git and the stash of the source? You didn't write if this is a bare repository, if it is on a local disc, if it is reachable by rsync ? Linux or Windows ? For a full clone (in the sense of having everything, bit for bit) I would probably use rsync. (After stopping all activities on the repo) But I don't know where you repos life, are they bare or not, so there may be other ways to go. Thanks a lot, Chris. -- 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: how to make full copy of a repo
On Sat, Mar 28, 2015 at 7:52 PM, Torsten Bögershausen tbo...@web.de wrote: On 2015-03-28 03.56, Christoph Anton Mitterer wrote: Hey. I was looking for an ideally simple way to make a full copy of a git repo. Many howtos are floating around on this on the web, with also lots of voodoo. First, it shouldn't be just a clone, i.o.w. - I want to have all refs (local/remote branches/tags) and of course all objects from the source repo copied as is. So it's local branches should become my local branches and not remote branches as well - and so on. Basically I want to be able to delete the source afterwards (and all backups ;) ) and not having anything lost. - It shouldn't set the source repo as origin or it's branches as remote tracking branches, as said it should be identical the source repo, just freshly copied via the Git aware transport mechanisms. - Whether GC or repacking happens, I don't care, as long as nothing that is still reachable in the source repo wouldn't get lost (or get lost once I run a GC in the copied repo). - Whether anything that other tools have added to .git (e.g. git-svn stuff) get's lost, I don't care. - It should work for both, bare and non-bare repos, but it's okay when it doesn't copy anything that is not committed or stashed. I'd have said that either: $ git clone --mirror URl-to-source-repo copy for the direction from outside the source to a copy, or alternatively: $ cd source-repo $ git push --mirror URl-to-copy for the direction from within the source to a copy with copy being an empty bare or non-bare repo, would do the job. But: a) but the git-clone(1) part for --mirror: and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository. kinda confuses me since I wanted to get independent of the source repo and this ssems to set up a remote to it? b) do I need --all --tags for the push as well? c) When following https://help.github.com/articles/duplicating-a-repository/ it doesn't seem as if --mirror is what I want because they seem to advertise it rather as having the copy tracking the source repo. Of course I read about just using git-clone --bare, but that seems to not copy everything that --mirror does (remote-tracking branches, notes). So I'm a bit confused... This instructions have 3 repos: the source, old, the destination new and a temporary one. As you only push to new, new should have no information about old or temp. 1) Is it working like I assumed above? 2) Does that also copy things like git-config, hooks, etc.? 3) Does it copy the configured remotes from the source? 4) What else is not copied by that? I'd assume anything that is not tracked by git and the stash of the source? You didn't write if this is a bare repository, if it is on a local disc, if it is reachable by rsync ? Linux or Windows ? For a full clone (in the sense of having everything, bit for bit) I would probably use rsync. (After stopping all activities on the repo) This warrants more emphasis. If you rsync a repository that's active, i.e. getting pushes you *will* get corrupt copies. E.g. you can easily copy something out of the objects directory that's in the middle of being written, or copy the refs namespace after you copy objects and end up with an unreachable object. There's unfortunately no good solution to this other than doing both git --mirror backups and rsync backups (for hooks etc.) and combining the two, or pushing a hook for the duration that bans all updates. -- 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
git gui bug: filenames starting with ~
I didn't check if git claims to support arbitrary filenames. If a leading ~ isn't allowed, then this isn't a bug. I'm using git-gui version 0.19.GITGUI, from git version 2.3.4, from the Ubuntu PPA. git 2:2.3.4-1avh1~utopic1 steps to reproduce: mkdir -p git-shellmeta cd git-shellmeta git init touch '~bin' '~xyz' git gui In the gui, ~bin appears in the list of files with unstaged changes. However, instead of appearing as a file, the diff pane shows Git Repository (subproject) Selecting ~xyz pops up a dialog saying: Error loading file: user xyz doesn't exist So I guess username expansion is happening somewhere it shouldn't. The home directory of the bin user on my system is /bin, which is not a (subdir of a) git repo. The message that ~bin is a subproject is another symptom of this bug. PS. no, I didn't name that ~bin file. Someone else left it lying around in a directory. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC signature.asc Description: Digital signature
Re: how to make full copy of a repo
On Sat, 2015-03-28 at 15:31 +0100, Kevin D wrote: What you are losing on clone is: * config settings (this includes the configures remotes) * hooks that would be okay... * reflog (history of refs, though, by default disabled for bare repositories) is there a way to get this copied? * Stashes, because the reference to them is stored in the reflog * unreferenced objects (though you said those are not a requirement, it is still something that is lost) that would be okay for me either. git clone --mirror is used for repositories that regularly get updates from the repositories they were cloned from. Though this is not what you want, it's not difficult to reset the refspecs to the default refspecs. What do you mean here? What would I need to reset exactly? git clone --mirror is the closest you are going to get by only using git. I see, thanks :) So to summarize, git clone is only used for cloning history, which means objects and refs, the rest is not part of cloning. To get more, you have to go outside git. Thanks :) Chris. smime.p7s Description: S/MIME cryptographic signature
Re: how to make full copy of a repo
On Sat, 2015-03-28 at 19:52 +0100, Torsten Bögershausen wrote: As you only push to new, new should have no information about old or temp. Exactly, that would be the goal. 1) Is it working like I assumed above? 2) Does that also copy things like git-config, hooks, etc.? 3) Does it copy the configured remotes from the source? 4) What else is not copied by that? I'd assume anything that is not tracked by git and the stash of the source? You didn't write if this is a bare repository, if it is on a local disc, if it is reachable by rsync ? Linux or Windows ? Linux. And in principle I have both cases, but mostly non-bare repos. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] l10n: de.po: translate 99 new messages
2015-03-28 20:38 GMT+01:00 Ralf Thielow ralf.thie...@gmail.com: #: builtin/rm.c:17 -#, fuzzy msgid git rm [options] [--] file... -msgstr git rm [Optionen] [--] [Datei...] +msgstr git rm [Optionen] [--] [Datei...] The file argument is not optional. Will be fixed in a reroll. -- 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] config.c: split some variables to $GIT_DIR/config.worktree
On Fri, Mar 27, 2015 at 5:19 AM, Max Kirillov m...@max630.net wrote: On Thu, Mar 26, 2015 at 07:04:24PM +0700, Nguyễn Thái Ngọc Duy wrote: When you define $GIT_DIR/info/config.worktree, which contains of gitignore-style patterns (*), config variables that match these patterns will be saved in $GIT_DIR/config.worktree instead of $GIT_DIR/config. Should it rather be in GIT_COMMON_DIR? As far as I understand, its meaning is variables which we allow to use per-worktree because we intend to have them different in different worktrees, and sure no bad issues can happen because this. It is not hardcored in git because the list is going to extend, and we'd like to allow older versions of git (and other git implementations) to be still able to understand newer repositories. So there should be no sense to make the list worktree-specific. I'm not sure if it means $GIT_DIR/config.worktree or $GIT_DIR/info/config.worktree. At this point $GIT_COMMON_DIR is not involved (i.e. you can still spit config even in a normal repo). .../info/config.worktree may be shared, I guess. The older versions of git (and other git implementations) raises an issue with this patch. Older impl just ignore config.worktree. I think I need to bump core.repositoryformatversion up to avoid that. Also, probably the per-worktree variables should be searched for in both common config and per-worktree config, and the main repository should not have config.worktree, to be able to work with implementations which are not aware of the whole multiple worktrees feature. And in worktrees, if the variable is not defined in config.wortree, the default vaalue should come from common config. This though has downside that worktree cannot use the more global vlue for variable implicitly. The main worktree may or may not use per-worktree config (it's technically possible): if we enforce config.worktree on the main worktree, we don't have to worry about the same variable defined in both common and per-worktree config. Enforcing may require more work: imagine the worktree list is updated, some in the common config may become per-worktree and need to be moved to config.worktree.. If we allow per-worktree vars in the common config, other worktrees should ignore them in common config. -- Duy -- 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
[PATCH] l10n: de.po: translate 99 new messages
Translate 99 messages came from git.pot update in c2ea120 (l10n: git.pot: v2.4.0 round 1 (99 new, 92 removed)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 289 ++- 1 file changed, 101 insertions(+), 188 deletions(-) diff --git a/po/de.po b/po/de.po index c68804f..df9b15c 100644 --- a/po/de.po +++ b/po/de.po @@ -32,21 +32,19 @@ msgstr und zu committen. #: archive.c:11 -#, fuzzy msgid git archive [options] tree-ish [path...] -msgstr git archive [Optionen] Commit-Referenz [Pfad...] +msgstr git archive [Optionen] Commit-Referenz [Pfad...] #: archive.c:12 msgid git archive --list msgstr git archive --list #: archive.c:13 -#, fuzzy msgid git archive --remote repo [--exec cmd] [options] tree-ish [path...] msgstr -git archive --remote Repository [--exec Programm] [Optionen] Commit- -Referenz [Pfad...] +git archive --remote Repository [--exec Programm] [Optionen] Commit- +Referenz [Pfad...] #: archive.c:14 msgid git archive --remote repo [--exec cmd] --list @@ -1144,9 +1142,8 @@ msgstr zusammenzuführen)\n #: revision.c:2348 -#, fuzzy msgid --first-parent is incompatible with --bisect -msgstr Die Option --dirty kann nicht mit Commits verwendet werden. +msgstr Die Optionen --first-parent und --bisect sind inkompatibel. #: run-command.c:83 msgid open /dev/null failed @@ -1167,10 +1164,9 @@ msgstr die Gegenseite unterstützt keinen signierten Versand (\--signed push\) #: send-pack.c:366 -#, fuzzy msgid server does not support --atomic push msgstr -die Gegenseite unterstützt keinen signierten Versand (\--signed push\) +die Gegenseite unterstützt keinen atomaren Versand (\--atomic push\) #: sequencer.c:172 builtin/merge.c:782 builtin/merge.c:893 builtin/merge.c:995 #: builtin/merge.c:1005 @@ -2047,9 +2043,8 @@ msgid failed to unlink '%s' msgstr Konnte '%s' nicht entfernen. #: builtin/add.c:22 -#, fuzzy msgid git add [options] [--] pathspec... -msgstr git add [Optionen] [--] [Pfadspezifikation...] +msgstr git add [Optionen] [--] Pfadspezifikation... #: builtin/add.c:65 #, c-format @@ -2200,9 +2195,8 @@ msgid Unable to write new index file msgstr Konnte neue Staging-Area-Datei nicht schreiben. #: builtin/apply.c:59 -#, fuzzy msgid git apply [options] [patch...] -msgstr git apply [Optionen] [Patch...] +msgstr git apply [Optionen] [Patch...] #: builtin/apply.c:112 #, c-format @@ -2390,9 +2384,9 @@ msgid read of %s failed msgstr Konnte %s nicht lesen #: builtin/apply.c:3238 -#, fuzzy, c-format +#, c-format msgid reading from '%s' beyond a symbolic link -msgstr Pfadspezifikation '%s' ist hinter einem symbolischen Verweis +msgstr Lese von '%s' hinter einem symbolischen Verweis #: builtin/apply.c:3266 builtin/apply.c:3488 #, c-format @@ -2429,9 +2423,9 @@ msgid %s has type %o, expected %o msgstr %s ist vom Typ %o, erwartete %o #: builtin/apply.c:3688 builtin/apply.c:3690 -#, fuzzy, c-format +#, c-format msgid invalid path '%s' -msgstr Ungültige Option: %s +msgstr Ungültiger Pfad '%s' #: builtin/apply.c:3745 #, c-format @@ -2454,9 +2448,9 @@ msgid new mode (%o) of %s does not match old mode (%o) of %s msgstr neuer Modus (%o) von %s entspricht nicht dem alten Modus (%o) von %s #: builtin/apply.c:3793 -#, fuzzy, c-format +#, c-format msgid affected file '%s' is beyond a symbolic link -msgstr Pfadspezifikation '%s' ist hinter einem symbolischen Verweis +msgstr betroffene Datei '%s' ist hinter einem symbolischen Verweis #: builtin/apply.c:3797 #, c-format @@ -2607,9 +2601,8 @@ msgid apply a patch without touching the working tree msgstr Patch anwenden, ohne Änderungen im Arbeitsverzeichnis vorzunehmen #: builtin/apply.c:4546 -#, fuzzy msgid accept a patch that touches outside the working area -msgstr Patch anwenden, ohne Änderungen im Arbeitsverzeichnis vorzunehmen +msgstr Patch anwenden, der Änderungen außerhalb des Arbeitsverzeichnisses vornimmt #: builtin/apply.c:4548 msgid also apply the patch (use with --stat/--summary/--check) @@ -2761,14 +2754,12 @@ msgid update BISECT_HEAD instead of checking out the current commit msgstr BISECT_HEAD aktualisieren, anstatt den aktuellen Commit auszuchecken #: builtin/blame.c:30 -#, fuzzy msgid git blame [options] [rev-opts] [rev] [--] file -msgstr git blame [Optionen] [rev-opts] [rev] [--] Datei +msgstr git blame [Optionen] [rev-opts] [Commit] [--] Datei #: builtin/blame.c:35 -#, fuzzy msgid rev-opts are documented in git-rev-list(1) -msgstr [rev-opts] sind dokumentiert in git-rev-list(1) +msgstr rev-opts sind dokumentiert in git-rev-list(1) #: builtin/blame.c:2500 msgid Show blame entries as we find them, incrementally @@ -2876,24 +2867,20 @@ msgid 4 years, 11 months ago msgstr vor 4 Jahren, und 11 Monaten #: builtin/branch.c:24 -#, fuzzy msgid git branch [options] [-r | -a] [--merged | --no-merged] -msgstr git branch [Optionen] [-r | -a] [--merged | --no-merged] +msgstr git branch
[PATCH 1/2] git-p4: Check branch detection and client view together
Add failing scenario where using branch detection and a client view will break git p4 submit functionality. Signed-off-by: Vitor Antunes vitor@gmail.com --- t/t9801-git-p4-branch.sh | 98 ++ 1 file changed, 98 insertions(+) diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh index 2bf142d..2f0361a 100755 --- a/t/t9801-git-p4-branch.sh +++ b/t/t9801-git-p4-branch.sh @@ -504,6 +504,104 @@ test_expect_success 'use-client-spec detect-branches skips files in branches' ' ) ' +test_expect_success 'restart p4d' ' + kill_p4d + start_p4d +' + +# +# 1: //depot/branch1/base/file1 +#//depot/branch1/base/file2 +# 2: integrate //depot/branch1/base/... - //depot/branch2/base/... +# 3: //depot/branch1/base/file3 +# 4: //depot/branch1/base/file2 (edit) +# 5: integrate //depot/branch1/base/... - //depot/branch3/base/... +# +# Note: the client view remove the base folder from the workspace +test_expect_success 'add simple p4 branches with common base folder on each branch' ' + ( + cd $cli + client_view //depot/branch1/base/... //client/branch1/... \ + //depot/branch2/base/... //client/branch2/... \ + //depot/branch3/base/... //client/branch3/... + mkdir -p branch1 + cd branch1 + echo file1 file1 + echo file2 file2 + p4 add file1 file2 + p4 submit -d Create branch1 + p4 integrate //depot/branch1/base/... //depot/branch2/base/... + p4 submit -d Integrate branch2 from branch1 + echo file3 file3 + p4 add file3 + p4 submit -d add file3 in branch1 + p4 open file2 + echo update file2 + p4 submit -d update file2 in branch1 + p4 integrate //depot/branch1/base/... //depot/branch3/base/... + p4 submit -d Integrate branch3 from branch1 + ) +' + +# Configure branches through git-config and clone them. +# All files are tested to make sure branches were cloned correctly. +# Finally, make an update to branch1 on P4 side to check if it is imported +# correctly by git p4. +# git p4 is expected to use the client view to also not include the common +# base folder in the imported directory structure. +test_expect_success 'git p4 clone simple branches with base folder on server side' ' + test_create_repo $git + ( + cd $git + git config git-p4.branchList branch1:branch2 + git config --add git-p4.branchList branch1:branch3 + git p4 clone --dest=. --use-client-spec --detect-branches //depot@all + git log --all --graph --decorate --stat + git reset --hard p4/depot/branch1 + test -f file1 + test -f file2 + test -f file3 + grep update file2 + git reset --hard p4/depot/branch2 + test -f file1 + test -f file2 + test ! -f file3 + ! grep update file2 + git reset --hard p4/depot/branch3 + test -f file1 + test -f file2 + test -f file3 + grep update file2 + cd $cli + cd branch1 + p4 edit file2 + echo file2_ file2 + p4 submit -d update file2 in branch1 + cd $git + git reset --hard p4/depot/branch1 + git p4 rebase + grep file2_ file2 + ) +' + +# Now update a file in one of the branches in git and submit to P4 +test_expect_failure 'Update a file in git side and submit to P4 using client view' ' + test_when_finished cleanup_git + ( + cd $git + git reset --hard p4/depot/branch1 + echo client spec file1 + git add -u . + git commit -m update file1 in branch1 + git config git-p4.skipSubmitEdit true + git p4 submit --verbose + cd $cli + p4 sync ... + cd branch1 + grep client spec file1 + ) +' + test_expect_success 'kill p4d' ' kill_p4d ' -- 1.7.10.4 -- 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 6/6] WIP/RFC/entry.c: fix a memleak
On Fri, Mar 27, 2015 at 08:14:28PM -0400, Eric Sunshine wrote:
On Friday, March 27, 2015, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller sbel...@google.com wrote:
I observe that filter is going out of scope, but the
implementation proposed in this patch produces just a
crash instead of any helpful fix.
Signed-off-by: Stefan Beller sbel...@google.com
---
diff --git a/entry.c b/entry.c
index 1eda8e9..5383001 100644
--- a/entry.c
+++ b/entry.c
@@ -152,8 +152,10 @@ static int write_entry(struct cache_entry *ce,
if (filter
!streaming_write_entry(ce, path, filter,
state, to_tempfile,
- fstat_done, st))
+ fstat_done, st)) {
+ free_stream_filter(filter);
Aside from the crash you are seeing, this is a bogus fix anyway.
You're only freeing 'filter' if it was allocated _and_ if
streaming_write_entry() returned 0. I would guess your intention was
to free 'filter' regardless of the result of streaming_write_entry().
Unless streaming_write_entry() is freeing the filter for you -- there
is a free_stream_filter() call in close_method_decl() in streaming.c
-- in which case your new free_stream_filter() call would attempt to
free the already-freed filter.
Yes, I think the correct fix for this leak is to make
stream_blob_to_fd() always free the filter, since there's only one path
out that doesn't at the moment and there's no way for the caller to
figure out whether or not the filter has been freed:
-- 8 --
diff --git a/streaming.c b/streaming.c
index 2ff036a..811fcc2 100644
--- a/streaming.c
+++ b/streaming.c
@@ -507,8 +507,11 @@ int stream_blob_to_fd(int fd, unsigned const char *sha1,
struct stream_filter *f
int result = -1;
st = open_istream(sha1, type, sz, filter);
- if (!st)
+ if (!st) {
+ if (filter)
+ free_stream_filter(filter);
return result;
+ }
if (type != OBJ_BLOB)
goto close_and_exit;
for (;;) {
--
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: Git Rev News edition 1 published
On Wed, Mar 25, 2015 at 11:00:21AM +0100, Christian Couder wrote: Hi, Git Rev News edition 1 is now available: http://git.github.io/rev_news/edition-1.html Thanks a lot to all the contributors and helpers, especially Junio! Enjoy, Christian and Thomas. Thank you for your work on this. -- 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: how to make full copy of a repo
On Sat, Mar 28, 2015 at 03:56:37AM +0100, Christoph Anton Mitterer wrote: Hey. I was looking for an ideally simple way to make a full copy of a git repo. Many howtos are floating around on this on the web, with also lots of voodoo. First, it shouldn't be just a clone, i.o.w. - I want to have all refs (local/remote branches/tags) and of course all objects from the source repo copied as is. So it's local branches should become my local branches and not remote branches as well - and so on. Basically I want to be able to delete the source afterwards (and all backups ;) ) and not having anything lost. - It shouldn't set the source repo as origin or it's branches as remote tracking branches, as said it should be identical the source repo, just freshly copied via the Git aware transport mechanisms. - Whether GC or repacking happens, I don't care, as long as nothing that is still reachable in the source repo wouldn't get lost (or get lost once I run a GC in the copied repo). - Whether anything that other tools have added to .git (e.g. git-svn stuff) get's lost, I don't care. - It should work for both, bare and non-bare repos, but it's okay when it doesn't copy anything that is not committed or stashed. I'd have said that either: $ git clone --mirror URl-to-source-repo copy for the direction from outside the source to a copy, or alternatively: $ cd source-repo $ git push --mirror URl-to-copy for the direction from within the source to a copy with copy being an empty bare or non-bare repo, would do the job. But: a) but the git-clone(1) part for --mirror: and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository. kinda confuses me since I wanted to get independent of the source repo and this ssems to set up a remote to it? b) do I need --all --tags for the push as well? c) When following https://help.github.com/articles/duplicating-a-repository/ it doesn't seem as if --mirror is what I want because they seem to advertise it rather as having the copy tracking the source repo. Of course I read about just using git-clone --bare, but that seems to not copy everything that --mirror does (remote-tracking branches, notes). So I'm a bit confused... 1) Is it working like I assumed above? 2) Does that also copy things like git-config, hooks, etc.? 3) Does it copy the configured remotes from the source? 4) What else is not copied by that? I'd assume anything that is not tracked by git and the stash of the source? Thanks a lot, Chris. Git clone is never going to get you a copy where nothing is lost. What you are losing on clone is: * config settings (this includes the configures remotes) * hooks * reflog (history of refs, though, by default disabled for bare repositories) * Stashes, because the reference to them is stored in the reflog * unreferenced objects (though you said those are not a requirement, it is still something that is lost) git clone --mirror is used for repositories that regularly get updates from the repositories they were cloned from. Though this is not what you want, it's not difficult to reset the refspecs to the default refspecs. Because it fetches all refs, it's not necessary to add --all --tags (because tags are also refs). git clone --mirror is the closest you are going to get by only using git. I guess you are aware of this, but if you want to retain more information, you have to rely on other means, like scp to get the other things So to summarize, git clone is only used for cloning history, which means objects and refs, the rest is not part of cloning. To get more, you have to go outside git. Hope this helps to clear some confussion. Kevin -- 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
[PATCH 0/2] git-p4: Improve client path detection
I'm adding a test case for a scenario I was confronted with when using branch detection and a client view specification. It is possible that the implemented fix may not cover all possible scenarios, but there is no regression in the available tests. Vitor Antunes (2): git-p4: Check branch detection and client view together git-p4: Improve client path detection when branches are used git-p4.py| 11 -- t/t9801-git-p4-branch.sh | 98 ++ 2 files changed, 105 insertions(+), 4 deletions(-) -- 1.7.10.4 -- 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
Arrow keys broken in gitk
Hi, in gitk on Debian jessie (Git version 2.1.4), the left/right arrow keys don't work in the text input fields. When I click into the SHA ID field or either search field and press the left or right arrow key, nothing happens. I'd expect the text cursor to move one character forward or back. Roland -- 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 0/2] git-p4: Small updates to test cases
Will apply both. It seems that I am to blame for 1/2 for botching the shell syntax X-. Thanks for fixing. I was not entirely happy with the we could find either file10 or file11 because they are the same, so let's declare both are success in the original, f69b3a93 (git p4 test: copy source indeterminate, 2012-06-27) in the first place, which survived the 9b6513ac (git p4 test: split up big t9800 test, 2012-06-27) and e832f737 (t9814: fix misconversion from test $a -o $b to test $a || test $b, 2014-07-25). I think a better fix would have been not to have multiple identical copies in the tested tree to begin with. But 2/2 is an acceptable interim fix that uses the same approach as we have been using since f69b3a93, so it should do at least for now. Thanks. -- 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 2/2] git-p4: Fix copy detection test
Vitor Antunes vitor@gmail.com writes: Vitor Antunes vitor@gmail.com wrote: Junio C Hamano gits...@pobox.com wrote: Pete, these tests blame to your 9b6513ac (git p4 test: split up big t9800 test, 2012-06-27). I presume that you tested the result of this splitting, but do you happen to know if we did something to cause the test to break recently? I also worked on these tests at that time and they were passing before and after the reorganization. I'll prepare a bisect script and will try to find the commit that started making this test fail. According to bisect, this is the first commit that makes the test fail: 7c85f8acb2282e3ed108c46b59fd5daa78bf17db Does this make sense to you? Yeah, as the blamed commit changes the way the hashtable is used record and choose the rename source candidates, it is not surprising if it changes how two or more candidates with the same rename score are tie-broken. Thanks. -- 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: [RFC/GSoC] Proposal Draft: Unifying git branch -l, git tag -l, and git for-each-ref
On 03/26/2015 10:07 PM, Jeff King wrote: On Mon, Mar 23, 2015 at 06:39:20PM +0530, karthik nayak wrote: All three commands select a subset of the repository’s refs and print the result. There has been an attempt to unify these commands by Jeff King[3]. I plan on continuing his work[4] and using his approach to tackle this project. I would be cautious about the work in my for-each-ref-contains-wip branch. At one point it was reasonably solid, but it's now a year and a half old, and I've been rebasing it without paying _too_ much attention to correctness. I think some subtle bugs have been introduced as it has been carried forward. Also, the very first patch (factoring out the contains traversal) is probably better served by this series: http://thread.gmane.org/gmane.comp.version-control.git/252472 I don't remember all of the issues offhand that need to be addressed in it, but there were plenty of review comments. Thanks for the link, will go through that. For extended selection behaviour such as ‘--contains’ or ‘--merged’ we could implement these within the library by providing functions which closely mimic the current methods used individually by ‘branch -l’ and ‘tag -l’. For eg to implement ‘--merged’ we implement a ‘compute_merge()’ function, which with the help of the revision API’s will be able to perform the same function as ‘branch -l --merged’. One trick with making a library-like interface is that some of the selection routines can work on a streaming list of refs (i.e., as we see each ref we can say yes or no) and some must wait until the end (e.g., --merged does a single big merge traversal). It's probably not the end of the world to just always collect all the refs, then filter them, then sort them, then print them. It may delay the start of output in some minor cases, but I doubt that's a big deal (and anyway, the packed-refs code will load them all into an array anyway, so collecting them in a second array is probably not a big deal). I think I noted this down while going through your implementation also. You even mentioned this on the mailing list if I'm not wrong. Will have to work out a design around this and think about it more. For formatting functionality provided by ‘for-each-ref’ we replicate the ‘show_ref’ function in ‘for-each-ref.c’ where the format is given to the function and the function uses the format to obtain atom values and prints the corresponding atom values to the screen. This feature would allow us to provide format functionality which could act as a base for the ‘-v’ option also. Yeah, I'd really like to see --format for git branch, and have -v just feed that a hard-coded format string (or even a configurable one). Although Jeff has built a really good base to build upon, I shall use his work as more of a reference and work on unification of the three commands from scratch. Good. :) -Peff Thanks for the Review/Tips. Regards -Karthik -- 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
