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: 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: [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree
On Fri, Mar 27, 2015 at 5:19 AM, Max Kirillov 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
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, Mar 28, 2015 at 7:52 PM, Torsten Bögershausen 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
Re: [PATCH] l10n: de.po: translate 99 new messages
2015-03-28 20:38 GMT+01:00 Ralf Thielow : > > #: builtin/rm.c:17 > -#, fuzzy > msgid "git rm [] [--] ..." > -msgstr "git rm [Optionen] [--] [...]" > +msgstr "git rm [] [--] [...]" > The 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
[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 --- 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 [] [...]" -msgstr "git archive [Optionen] [...]" +msgstr "git archive [] [...]" #: archive.c:12 msgid "git archive --list" msgstr "git archive --list" #: archive.c:13 -#, fuzzy msgid "" "git archive --remote [--exec ] [] [...]" msgstr "" -"git archive --remote [--exec ] [Optionen] [Pfad...]" +"git archive --remote [--exec ] [] [...]" #: archive.c:14 msgid "git archive --remote [--exec ] --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 [] [--] ..." -msgstr "git add [Optionen] [--] [...]" +msgstr "git add [] [--] ..." #: 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 [] [...]" -msgstr "git apply [Optionen] [...]" +msgstr "git apply [] [...]" #: 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 [] [] [] [--] file" -msgstr "git blame [Optionen] [rev-opts] [rev] [--] Datei" +msgstr "git blame [] [] [] [--] Datei" #: builtin/blame.c:35 -#, fuzzy msgid " are documented in git-rev-list(1)" -msgstr "[rev-opts] sind dokumentiert in git-rev-list(1)" +msgstr " 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 [] [-r | -a] [--merged | --no-merged]" -msgstr "git branch [Optionen] [-r | -a] [--merged | --no-merged]" +msgstr "git branch [] [-r | -a] [--merged | --no-merged]" #: builtin/branch.c:25 -#, fuzzy msgid "git branch [] [-l] [-f] []" -msgstr "git branch [Optionen] [-l] [-f] []" +msgstr "git branch [] [-l] [-f] []" #: builtin/branc
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: [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
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 2/2] git-p4: Fix copy detection test
Vitor Antunes writes: > Vitor Antunes wrote: > >>Junio C Hamano 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: [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: 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
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
[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 --- 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
[PATCH 2/2] git-p4: Improve client path detection when branches are used
A client view can be used to remap folder locations in the workspace. To support
this when branch detection is enabled it is necessary to get the client path
through "p4 where". This patch does two things to achieve this:
1. Force usage of "p4 where" when P4 branches exist in the git repository.
2. Search for mappings that contain the depot path, instead of requiring an
exact match.
Signed-off-by: Vitor Antunes
---
git-p4.py| 11 +++
t/t9801-git-p4-branch.sh |2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 549022e..6954549 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -502,12 +502,12 @@ def p4Cmd(cmd):
def p4Where(depotPath):
if not depotPath.endswith("/"):
depotPath += "/"
-depotPath = depotPath + "..."
-outputList = p4CmdList(["where", depotPath])
+depotPathLong = depotPath + "..."
+outputList = p4CmdList(["where", depotPathLong])
output = None
for entry in outputList:
if "depotFile" in entry:
-if entry["depotFile"] == depotPath:
+if entry["depotFile"].find(depotPath) >= 0:
output = entry
break
elif "data" in entry:
@@ -1627,7 +1627,10 @@ class P4Submit(Command, P4UserMap):
if self.useClientSpec:
self.clientSpecDirs = getClientSpec()
-if self.useClientSpec:
+# Check for the existance of P4 branches
+branchesDetected = (len(p4BranchesInGit().keys()) > 1)
+
+if self.useClientSpec and not branchesDetected:
# all files are relative to the client spec
self.clientPath = getClientRoot()
else:
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index 2f0361a..4fe4e18 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -585,7 +585,7 @@ test_expect_success 'git p4 clone simple branches with base
folder on server sid
'
# 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_expect_success 'Update a file in git side and submit to P4 using client
view' '
test_when_finished cleanup_git &&
(
cd "$git" &&
--
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
[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
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 wrote:
> > On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller 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
> > > ---
> > > 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
