Re: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config
Matthieu Moy matthieu@grenoble-inp.fr writes: More precisely: you should have a look at git-multimail (in directory contrib/, in branch for now pu/, or from https://github.com/mhagger/git-multimail) before spending time on post-receive-email. Oh, by the way, is this a vote of confidence in that topic, hinting that we would want to advance it to 'next'? As it is only adding a new script to contrib/, it could be argued that we could even push it to 1.8.3-rc1, but until I hear from the original author (who will be the champion for that corner of the contrib/ area), I wouldn't do so. -- 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] deprecate core.statinfo at Git 2.0 boundary
Junio C Hamano gits...@pobox.com writes:
For now, add core.checkstat, and warn people who have core.statinfo
in their configuration file that we will remove it in Git 2.0.
And an obvious follow-up for the 2.0 looks like this.
-- 8 --
Subject: [PATCH] core.statinfo: remove as promised in Git 2.0
Signed-off-by: Junio C Hamano gits...@pobox.com
---
config.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/config.c b/config.c
index 7c55d05..1f2cc90 100644
--- a/config.c
+++ b/config.c
@@ -566,20 +566,7 @@ static int git_default_core_config(const char *var, const
char *value)
trust_ctime = git_config_bool(var, value);
return 0;
}
- if (!strcmp(var, core.statinfo) ||
- !strcmp(var, core.checkstat)) {
- /*
-* NEEDSWORK: statinfo was a typo in v1.8.2 that has
-* never been advertised. we will remove it at Git
-* 2.0 boundary.
-*/
- if (!strcmp(var, core.statinfo)) {
- static int warned;
- if (!warned++) {
- warning('core.statinfo' will be removed in Git
2.0;
- use 'core.checkstat' instead.);
- }
- }
+ if (!strcmp(var, core.checkstat)) {
if (!strcasecmp(value, default))
check_stat = 1;
else if (!strcasecmp(value, minimal))
--
1.8.3-rc1-154-g10dfae1
--
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 0/4] fix packed-refs races
Thanks. I queued this, and will push the result out on the side of 'pu' closer to 'next'. Could you double check the conflict resolution? I haven't got around to the peel-ref-cleanup yet. -- 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
thomas sabo charms - Barbie Charm bracelets
This early history on the attraction bracelet possesses manufactured an enormous comeback while using the * thomas sabo charms http://www.genuinethomassaboringsshop.co.uk/ * . No matter if you wish to allow the item absent to be a memento, wear it for equipment or maybe treat the item, this Thomas Sabo Attraction Clb captivates this bracelets addicts with some one of a kind technique. This sterling silver charm bracelets tell you of your particular minutes in addition to get fond remembrances. No matter if people rejoice minutes connected with likes, happiness, in addition to achievements or maybe another strange minute most of these charm bracelets become a ram to help these exclusive minutes. * http://www.genuinethomassaboringsshop.co.uk/ * -- View this message in context: http://git.661346.n2.nabble.com/thomas-sabo-charms-Barbie-Charm-bracelets-tp7585094.html Sent from the git mailing list archive at Nabble.com. -- 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
What's cooking in git.git (May 2013, #02; Mon, 6)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As we already have merged enough changes to 'master' during this
cycle that can potentially cause unforseen regressions, let's not
merge topics that are not regression fixes from 'next' to 'master',
either, until the final release.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to master]
* fc/remote-bzr (2013-04-30) 18 commits
- remote-bzr: access branches only when needed
- remote-bzr: delay peer branch usage
- remote-bzr: iterate revisions properly
- remote-bzr: improve progress reporting
- remote-bzr: add option to specify branches
- remote-bzr: add custom method to find branches
- remote-bzr: improve author sanitazion
- remote-bzr: add support for shared repo
- remote-bzr: fix branch names
- remote-bzr: add support for bzr repos
- remote-bzr: use branch variable when appropriate
- remote-bzr: fix partially pushed merge
- remote-bzr: fixes for branch diverge
- remote-bzr: add support to push merges
- remote-bzr: always try to update the worktree
- remote-bzr: fix order of locking in CustomTree
- remote-bzr: delay blob fetching until the very end
- remote-bzr: cleanup CustomTree
To replace the one we pushed out in 1.8.2 after hearing that Emacs
folks had a good experience with this version, this will be in
1.8.3-rc2.
--
[New Topics]
* fc/fast-export-persistent-marks (2013-05-06) 3 commits
- fast-export: don't parse commits while reading marks file
- fast-export: do not parse non-commit objects while reading marks file
- fast-{import,export}: use get_sha1_hex() directly
Seems to break a handful of topics when merged to the tip of 'pu'.
* jc/core-checkstat-2.0 (2013-05-06) 2 commits
- core.statinfo: remove as promised in Git 2.0
- deprecate core.statinfo at Git 2.0 boundary
The bottom one is a fix for a breakage of a new feature in 1.8.2
but it is not all that urgent.
* jk/packed-refs-race (2013-05-06) 4 commits
- for_each_ref: load all loose refs before packed refs
- get_packed_refs: reload packed-refs file when it changes
- add a stat_validity struct
- resolve_ref: close race condition for packed refs
--
[Stalled]
* mg/more-textconv (2013-04-23) 7 commits
- git grep: honor textconv by default
- grep: honor --textconv for the case rev:path
- grep: allow to use textconv filters
- t7008: demonstrate behavior of grep with textconv
- cat-file: do not die on --textconv without textconv filters
- show: honor --textconv for blobs
- t4030: demonstrate behavior of show with textconv
Rerolled. I am not sure if I like show blob and grep that use
textconv by default, though.
* mh/multimail (2013-04-21) 1 commit
- git-multimail: a replacement for post-receive-email
Waiting for comments.
* jc/format-patch (2013-04-22) 2 commits
- format-patch: --inline-single
- format-patch: rename no_inline field
A new option to send a single patch to the standard output to be
appended at the bottom of a message. I personally have no need for
this, but it was easy enough to cobble together. Tests, docs and
stripping out more MIMEy stuff are left as exercises to interested
parties.
Not ready for inclusion.
* jk/gitweb-utf8 (2013-04-08) 4 commits
- gitweb: Fix broken blob action parameters on blob/commitdiff pages
- gitweb: Don't append ';js=(0|1)' to external links
- gitweb: Make feed title valid utf8
- gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain,
and patch
Various fixes to gitweb.
Waiting for a reroll after a review.
* jk/commit-info-slab (2013-04-19) 3 commits
- commit-slab: introduce a macro to define a slab for new type
- commit-slab: avoid large realloc
- commit: allow associating auxiliary info on-demand
(this branch is used by jc/show-branch.)
Technology demonstration to show a way we could use unbound number
of flag bits on commit objects.
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used to complain and die. This loosens the check.
I do not think we agreed that this is a good idea, though.
--
[Cooking]
* fc/at-head (2013-05-02) 5 commits
- Add new @ shortcut for HEAD
- sha1_name: refactor reinterpret()
- sha1_name: compare variable with constant, not constant with variable
- sha1_name: remove unnecessary braces
- sha1_name: remove no-op
Instead of typing four capital letters HEAD, you can say @
instead.
There was another series from Ram that looked mostly test updates
but I lost
Re: [PATCH 4/4] fast-import: only store commit objects
On Tue, May 7, 2013 at 1:47 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 05/07/2013 06:47 AM, Felipe Contreras wrote: On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty mhag...@alum.mit.edu wrote: You conjectured earlier that nobody uses blob marks, and I provided a counterexample. Then you proposed a workaround that would require changes to the cvs2git documentation, and I even explained how your proposed workaround is not as flexible as the status quo. cvs2git does *not* need blob marks, it does not need marks at all. The use-case that you mentioned has nothing to do with cvs2git, in fact. I can be described as this: % ./generate-blobs blobs % git fast-import --export-marks=marks blobs % ./generate-commits commits % git fast-import --import-marks=marks commits In this example 'generate-commits' has no notion of marks at all, and 'git fast-import' doesn't need marks to process both blobs and commits. The generate-blobs program generates a mark for each blob and remembers the marks in a database. The generate-commits program reads the marks from the database and incorporates them in the definitions of the commits that it writes to its output. So yes, the program pair *does* rely on marks for blobs being exported correctly. Fine: % ./generate-data data % ./split-blobs data blobs % ./split-commits data commits How exactly the files 'blobs' and 'commits' are generated is irrelevant, 'git fast-import' will need them *once*, and never again, in fact, doesn't even need to know they are two files. There's no need for marks. I've tired of this discussion. I am quite sure that your change will not be accepted, so I see no need to participate further. Please do not interpret my silence as agreement with your quarrelsome arguments. How convenient. I ask the though questions, and you suddenly get tired of the discussion. So, let me answer for you: * Which the *vastly* more common case? That blobs are needed, or that they are not? That they are not. To suggest otherwise would be ridiculous. And of course this patch will not be accepted, because nobody is interested in improving things in the most easy and sensible way. Yours and everybody else's argument is one and the same: status quo, which is of course, not an argument at all. But it's pointless to try to convince you, because a) you are not interested in changing your mind b) you are not interested in seeking the most sensible solution c) you are only interested in doing what you are used to do, which is to not change anything, ever d) you know making this the default is only slightly risky, at best, and not only the world is not going to end, but most likely nobody would even notice, and the ones that would, are probably already participating in this conversation, but you don't even want to do something slightly risky, because it would show that others were right, and your concerns don't actually affect any real users at all. But as I said, drop the patch. Who needs progress? Cheers. -- Felipe Contreras -- 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 4/4] fast-import: only store commit objects
Michael Haggerty mhag...@alum.mit.edu writes: CVS stores all of the revisions of a single file in a single filename,v file in rcsfile(5) format. The revisions are stored as deltas ordered so that a single revision can be reconstructed from a single serial read of the file. cvs2git reads each of these files once, reconstructing *all* of the revisions for a file in a single go. It then pours them into a git-fast-import stream as blobs and sets a mark on each blob. This is more or less off-topic but in the bigger picture it is more interesting and important X-. The way you describe how cvs2git handles the blobs is the more efficient way, given that fast-import does not even attempt to bother to create good deltas. The only thing it does is to see if the current data deltifies against the last object. IIRC, CVS's backend storage is mostly recorded in backward delta, so if you are feeding the blob data from new to old, then the resulting pack would follow Linus's law (the file generally grows over time) and would generally give you a good deltified chain of objects. -- 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
An individual Learn how to Help make pandora sale?
* pandora uk http://www.pandoracharmsvipsale.co.uk/ * produce a great reward, any trend headline, plus a pleasurable for the vision inclusion in your assortment. Pandora drops enjoy specific activities and also situations simply by developing any Pandora diamond jewelry drops. They will can be found in antithetical indications, plants and also dog imprints, emblems, zodiac indications, shades and also materials offering an individual countless options and also products, creating Pandorabeads equally amazing and also specific. These kinds of drops use the particular common items regarding day-by-day typical living. It really is your option whether or not you employ these kinds of Pandorabeads over a wristlet or even a necklace around your neck. * http://www.pandoracharmsvipsale.co.uk/ * -- View this message in context: http://git.661346.n2.nabble.com/An-individual-Learn-how-to-Help-make-pandora-sale-tp7585097.html Sent from the git mailing list archive at Nabble.com. -- 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 4/4] fast-import: only store commit objects
On 05/07/2013 09:12 AM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: CVS stores all of the revisions of a single file in a single filename,v file in rcsfile(5) format. The revisions are stored as deltas ordered so that a single revision can be reconstructed from a single serial read of the file. cvs2git reads each of these files once, reconstructing *all* of the revisions for a file in a single go. It then pours them into a git-fast-import stream as blobs and sets a mark on each blob. This is more or less off-topic but in the bigger picture it is more interesting and important X-. The way you describe how cvs2git handles the blobs is the more efficient way, given that fast-import does not even attempt to bother to create good deltas. The only thing it does is to see if the current data deltifies against the last object. IIRC, CVS's backend storage is mostly recorded in backward delta, so if you are feeding the blob data from new to old, then the resulting pack would follow Linus's law (the file generally grows over time) and would generally give you a good deltified chain of objects. Yes, you are correct about how CVS orders commits on the mainline. Branches are stored in the opposite order--oldest to newest--but CVS users don't tend to get carried away with branches anyway, and if the changes are small deltafication should help a lot anyway. Cool. I knew that fast-import didn't do much in the way of compression, but I didn't realize that it can compute deltas only between adjacent blobs. So cvs2git happily hits the sweet-spot of fast-import. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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] contrib/hooks/post-receive-email: get description from repo.git/config
On 05/07/2013 08:36 AM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: More precisely: you should have a look at git-multimail (in directory contrib/, in branch for now pu/, or from https://github.com/mhagger/git-multimail) before spending time on post-receive-email. Oh, by the way, is this a vote of confidence in that topic, hinting that we would want to advance it to 'next'? As it is only adding a new script to contrib/, it could be argued that we could even push it to 1.8.3-rc1, but until I hear from the original author (who will be the champion for that corner of the contrib/ area), I wouldn't do so. My understanding is that we are waiting on two things: 1. Consensus from the community. I would characterize the feedback on the mailing list as limited in quantity but strongly positive [1-4] and I think that most/all of the wishes for post-receive-email features that were originally omitted from git-multimail have been implemented in the current version. Some of the mailing list feedback was about earlier versions. Do you want people to give feedback specifically about the current version? 2. For me to figure out what part of the git-multimail history I think should be included in the Git project, do any necessary repository rewriting, and submit a pull request to you. The fact that I haven't gotten to this is due to the fact that I've been busy getting git-imerge [5] ready to present at GitMerge. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/209168 (Branchaud) [2] http://article.gmane.org/gmane.comp.version-control.git/214941 (Bjarmason) [3] http://article.gmane.org/gmane.comp.version-control.git/214987 (Hiestand) [4] http://article.gmane.org/gmane.comp.version-control.git/216705 (Moy) [5] https://github.com/mhagger/git-imerge -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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] contrib/hooks/post-receive-email: get description from repo.git/config
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: More precisely: you should have a look at git-multimail (in directory contrib/, in branch for now pu/, or from https://github.com/mhagger/git-multimail) before spending time on post-receive-email. Oh, by the way, is this a vote of confidence in that topic, hinting that we would want to advance it to 'next'? I definitely would like to see git-multimail in contrib/, and to have it considered as the recommended way to send emails from a hook. It does all the old script did, and much more. post-receive-email can stay for people who don't have Python on their servers, or for existing users who don't want to migrate. My preference would go for a subtree merge to keep the existing history (that would mean extracting a subdirectory of git-multimail's tree before merging it to git.git). As it is only adding a new script to contrib/, it could be argued that we could even push it to 1.8.3-rc1, OTOH, it's not urgent, people can already use git-multimail by taking it from GitHub. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: Fwd: Uninit'ed submodules
On 07/05/13 07:16, Jens Lehmann wrote: Am 06.05.2013 02:19, schrieb Chris Packham: This did get me thinking. Why does an uninitialized submodule need to have an empty directory? If it didn't the maintainer in question probably would have realized that he needed to run git submodule update --init when his cd submodule command failed. I'm guessing there is a good reason for the empty directory - perhaps so that git can notice the fact that it exists in the worktree but is out of date? If it does need to have some presence in the worktree why not as a file? That way the cd command would still fail (albeit with a different error) providing the necessary indication to the user. The submodule update --init could then change from file - dir when it actually gets populated. Hmm, to me an empty directory is the natural representation of an unpopulated submodule, but I see why that made it hard for your maintainer to notice the fact that the submodule was uninitialized. I suspect changing an unpopulated submodule to be represented by a file will surprise quite some users (some of which will probably come up with perfectly valid use cases such a change will break). What about the following: Today's Git completely ignores empty submodule directories, but I think that when the recursive checkout support is there, the submodule.autoupdate flag - which I believe should control that behavior - could also make those empty submodule directories show up in git status as being unpopulated (after all they are configured to be updated automatically, so not having them populated is something Git should show). Would something like this have helped here? Until then I can only propose to establish a best practice of using git clone --recurse-submodules in these situations to avoid the problem you described. Yeah I think training people to use --recurse-submodules is probably the best thing we can do with the current version of git on our developers work stations. There is a bit of an issue when we add a new submodule (people aren't used to using submodule update --init), but that isn't a frequent occurrence. The recursive checkout sounds like something we'd benefit from. -- 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: another packed-refs race
On 05/07/2013 06:44 AM, Jeff King wrote: On Tue, May 07, 2013 at 06:32:12AM +0200, Michael Haggerty wrote: Another potential problem caused by the non-atomicity of loose reference reading could be to confuse reachability tests if process 1 is reading loose references while process 2 is renaming a reference: 1. Process 1 looks for refs/heads/a and finds it missing. 2. Process 2 renames z - a 3. Process 1 looks for refs/heads/z and finds it missing. Process 2 would think that any objects pointed to by a (formerly z) are unreachable. This would be unfortunate if it is doing an upload-pack and very bad if it is doing a gc. I wonder if this could be a problem in practice? (Gee, wouldn't it be nice to keep reflogs for deleted refs? :-) ) Ugh. Yeah, that is definitely a possible race, and it could be quite disastrous for prune. I am really starting to think that we need a pluggable refs architecture, and that busy servers can use something like sqlite to keep the ref storage. That would require bumping repositoryformatversion, of course, but it would be OK for a server accessible only by git protocols. That would be a fun project. I like the idea of not burdening people's local mostly-one-user-at-a-time repositories with code that is hardened against server-level pounding. I also wonder if we can spend extra time to get more reliable results for prune, like checking refs, coming up with a prune list, and then checking again. I have a feeling it's a 2-generals sort of problem where we can always miss a ref that keeps bouncing around, but we could bound the probability. I haven't thought that hard about it. Perhaps this will give us something to talk about on Thursday. :) It's not 100% solvable without big changes; there could always be a malign Dijkstra running around your system, renaming references right before you read them. But I guess it would be pretty safe if pack would keep the union of objects reachable from the references read at the beginning of the run and objects reachable from the references read at (aka near) the end of the run. * Preloading the whole tree of loose references before starting an iteration. As I recall, this was a performance *win*. It was on my to-do list of things to pursue when I have some free time (ha, ha). I mostly wanted to check first that there are not callers who abort the iteration soon after starting it. For example, imagine a caller who tries to determine are there any tags at all by iterating over refs/tags with a callback that just returns 1; such a caller would suffer the cost of reading all of the loose references in refs/tags. Well, you can measure my patches, because that's what they do. :) I didn't really consider an early termination from the iteration. Certainly something like: git for-each-ref refs/tags | head -1 would take longer. Though if you have that many refs that the latency is a big problem, you should probably consider packing them (it can't possibly bite you with a race condition, right?). No, I don't see a correctness issue. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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] deprecate core.statinfo at Git 2.0 boundary
On Mon, May 06, 2013 at 10:31:10PM -0700, Junio C Hamano wrote: c08e4d5b5cfa (Enable minimal stat checking, 2013-01-22) advertised the configuration variable core.checkstat in the documentation and its log message, but the code expected core.statinfo instead. For now, add core.checkstat, and warn people who have core.statinfo in their configuration file that we will remove it in Git 2.0. Yeah, that looks like a fine solution to me. To be honest, I doubt that it is even necessary to handle the backwards compatibility. The checkstat option never actually worked, statinfo was never advertised, and the broken state was available in only one release. So I'd be very surprised if anyone more than the author was actually using it. Still, it is not that hard to handle both, so I suppose it is better to be conservative. -Peff -- 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 0/4] fix packed-refs races
On Mon, May 06, 2013 at 11:40:47PM -0700, Junio C Hamano wrote: I queued this, and will push the result out on the side of 'pu' closer to 'next'. Could you double check the conflict resolution? I eyeballed the --cc output, as well as the resulting file, and it looks fine to me. I haven't got around to the peel-ref-cleanup yet. I'd leave that for now; the current code does have a bug, but it's not triggerable through any of the current callers, so we can afford to take our time. I'll try to work up a patch that just goes on top of Michael's series. -Peff -- 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
Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)
On 2013-05-04 01.14, Junio C Hamano wrote: Cygwin portability; both were reviewed by Jonathan, and the tip one seems to want a bit further explanation. Needs positive report from Cygwin 1.7 users who have been on 1.7 to make sure it does not regress for them. I was trying to verify that cygwin 1.7 is still Ok, but got puzzled. Running the test suite under cygwin doesn't seem to work any more (?): Scenario 1: The PC is running alone, and goes into the screen saver. Pressing CTRL-ALT-DEL didn't get any effect. Scenario 2: The PC didn't react any more, when the test suite was run in background. In 3 or 4 cases the PC needed to be reboot hardly. Using the commits before and after this change makes the test suite hang as well at some point, then it hangs somewhere at TC 3000--4000. Scenario 4: The I disabled the screensaver, upgdated cygwin, and went back to an older commit: The latest run from commit 52d63e70, April 28, hangs in TC 5500, ok 26 clone shallow object count. I can see 2 times git.exe pull --depth 4 ..A Scenario 5: The run of today 1.8.3-rc1, hangs in t5510, some git.exe are running fetch. (or pull) It seems as if some process/exes are not terminated in the way it should be. I will try on a different machine, comments are wellcome /Torsten -- 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: Pitfalls in auto-fast-forwarding heads that are not checked out?
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master Great trick -- thanks! In use in ppg now :-) m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: offtopic: ppg design decisions - encapsulation
On Mon, May 6, 2013 at 11:53 AM, John Keeping j...@keeping.me.uk wrote: I'm not sure I fully understand what the reports are, but it sounds like they are closely related to original configuration commits. If that is the case, have you considered using Git notes instead of a separate repository? Interesting suggestion! I read up on git-notes. Yes, reports are closely related to a commit -- it's a lot of the execution of puppet with that config on a client node. At the same time, we have one report per change deployment, per client -- with thousands of clients. So it will be a large dataset, and a transient one -- I intend to use git as a store-and-forward mechanism for the reports, and it is safesane to forget old reports. I don't see much ease-of-expiry in the notes, so I guess I would have to write that myself, which complicates things a bit :-) cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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 1/3] fast-{import,export}: use get_sha1_hex() directly
Felipe Contreras felipe.contre...@gmail.com writes: It's wrong to call get_sha1() if they should be SHA-1s, plus inefficient. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- It appears that they should be SHA-1s assumption does not hold; this patch breaks at least 3303, 9020, and 9300. Also assuming these are always 40-hex goes directly against what is documented in Documentation/git-fast-import.txt (look for Here committish is any of the following). My bad while reviewing the earlier round. I've redone 'pu' (which was failing the test last night) after dropping this and keeping only patches 2 and 3 from the series. -- 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] contrib/hooks/post-receive-email: get description from repo.git/config
Matthieu Moy matthieu@grenoble-inp.fr writes: OTOH, it's not urgent, people can already use git-multimail by taking it from GitHub. Yes. There are less and less reason to rush things into contrib/ these days, which is a very good thing from ecosystem's point of view. It is a sign that Git has matured that my tree no longer has to be the promotion place for third-party add-ons. -- 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 5/9] revision.c: Make --full-history consider more merges
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
+struct treesame_state {
+ unsigned int nparents;
+ unsigned char treesame[FLEX_ARRAY];
+};
I have been wondering if we want to do one-bit (not one-byte) per
parent but no biggie ;-)
I did start down that path, because I felt bad about bloat.
But then I realised how much I would be complicating and slowing the
code down to only save a few bytes each time we walk a merge with at
least 5 parents, and I came to my senses. :)
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: [PATCH] contrib/hooks/post-receive-email: get description from repo.git/config
Michael Haggerty mhag...@alum.mit.edu writes: My understanding is that we are waiting on two things: 1. Consensus from the community. I would characterize the feedback on the mailing list as limited in quantity but strongly positive [1-4] and I think that most/all of the wishes for post-receive-email features that were originally omitted from git-multimail have been implemented in the current version. Some of the mailing list feedback was about earlier versions. Do you want people to give feedback specifically about the current version? 2. For me to figure out what part of the git-multimail history I think should be included in the Git project, do any necessary repository rewriting, and submit a pull request to you. Both are intertwined. I was looking at the history of your project at GitHub. I got an impression that it is better to evolve as a standalone project with its own rich history, and the longer I looked at it, the more convinced I got that I shouldn't pull history from you. As batteries included service for the end users, it may be convenient to have a copy of a stable release of the script in the contrib/ area, but I do not think if it is the best for the script to further develop it in my tree. I'd be just an unnecessary bottleneck. I have a mildly strong suspicion that a better approach might be to: - Copy the current stable snapshot to the contrib/ area, but mark it clearly that the copy is merely for convenience, meant for end users who choose not to pull from your authoritative GitHub repository, and the real development happens elsewhere; - Keep the development at your GitHub repository, with you as the project lead. People who are interested in evolving it gather and work there; and - Update what is in contrib/ in my tree with a stable snapshot, every once in a while (close to the release points of Git project or of MultiMail project). -- 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 5/9] revision.c: Make --full-history consider more merges
Kevin Bracey ke...@bracey.fi writes:
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
+struct treesame_state {
+ unsigned int nparents;
+ unsigned char treesame[FLEX_ARRAY];
+};
I have been wondering if we want to do one-bit (not one-byte) per
parent but no biggie ;-)
I did start down that path, because I felt bad about bloat.
But then I realised how much I would be complicating and slowing the
code down to only save a few bytes each time we walk a merge with at
least 5 parents, and I came to my senses. :)
;-)
--
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] clone: allow cloning local paths with colons in them
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 67869b4..0629149 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -280,4 +280,9 @@ test_expect_success 'clone checking out a tag' ' test_cmp fetch.expected fetch.actual ' +test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path foo:bar' ' + cp -R src foo:bar + git clone ./foo:bar foobar +' Hmph, why not git clone --mirror src foo:bar git clone ./foo:bar foobar or something? Also do we have a easy negative case we want to test, i.e. a case where we do not want the new codepath to trigger by mistake? -- 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] contrib/hooks/post-receive-email: get description from repo.git/config
Junio C Hamano gits...@pobox.com writes: I have a mildly strong suspicion that a better approach might be to: - Copy the current stable snapshot to the contrib/ area, [...] - Keep the development at your GitHub repository, [...] - Update what is in contrib/ in my tree with a stable snapshot, every once in a while [...] I think this is not very different from - merge the current version in the contrib/ area - keep the development at the GitHub repository - merge the GitHub repository into the git.git once in a while (which is essentially what happens with gitk and git-gui as far as I understood) I tend to prefer the merge approach to the copy files from one repo to another, even if git_multimail is never edited directly from git.git. I find it conceptually cleaner, and it gives a bit more flexibility (e.g. if someone accidentally commits in git.git's repository, the commit would also be valid wrt git_multimail's GitHub repo, and can serve as a pull request). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 2/4] fetch-pack: prepare updated shallow file before fetching the pack
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be lead to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
git learns new global option --shallow-file to pass on the alternate
shallow file path. Undocumented (and not even support --shallow-file=
syntax) because it's unlikely to be used again elsewhere.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.h | 2 ++
fetch-pack.c | 69
+--
git.c | 5
shallow.c | 45 +++--
t/t5500-fetch-pack.sh | 7 ++
5 files changed, 91 insertions(+), 37 deletions(-)
diff --git a/commit.h b/commit.h
index 67bd509..6e9c7cd 100644
--- a/commit.h
+++ b/commit.h
@@ -176,6 +176,8 @@ extern int for_each_commit_graft(each_commit_graft_fn,
void *);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+extern void check_shallow_file_for_update(void);
+extern void set_alternate_shallow_file(const char *path);
int is_descendant_of(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit *);
diff --git a/fetch-pack.c b/fetch-pack.c
index f156dd4..1ca4f6b 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -20,6 +20,8 @@ static int no_done;
static int fetch_fsck_objects = -1;
static int transfer_fsck_objects = -1;
static int agent_supported;
+static struct lock_file shallow_lock;
+static const char *alternate_shallow_file;
#define COMPLETE (1U 0)
#define COMMON (1U 1)
@@ -683,7 +685,7 @@ static int get_pack(struct fetch_pack_args *args,
int xd[2], char **pack_lockfile)
{
struct async demux;
- const char *argv[20];
+ const char *argv[22];
char keep_arg[256];
char hdr_arg[256];
const char **av;
@@ -724,6 +726,11 @@ static int get_pack(struct fetch_pack_args *args,
do_keep = 1;
}
+ if (alternate_shallow_file) {
+ *av++ = --shallow-file;
+ *av++ = alternate_shallow_file;
+ }
+
if (do_keep) {
if (pack_lockfile)
cmd.out = -1;
@@ -779,6 +786,23 @@ static int cmp_ref_by_name(const void *a_, const void
*b_)
return strcmp(a-name, b-name);
}
+static void setup_alternate_shallow(void)
+{
+ struct strbuf sb = STRBUF_INIT;
+ int fd;
+
+ check_shallow_file_for_update();
+ fd = hold_lock_file_for_update(shallow_lock, git_path(shallow),
+LOCK_DIE_ON_ERROR);
+ if (write_shallow_commits(sb, 0)) {
+ if (write_in_full(fd, sb.buf, sb.len) != sb.len)
+ die_errno(failed to write to %s,
shallow_lock.filename);
+ alternate_shallow_file = shallow_lock.filename;
+ } else
+ alternate_shallow_file = ;
This empty string, not NULL trick needs to be commented here to
match the other place that uses this as a cue to do things
differently.
+ strbuf_release(sb);
+}
+
static struct ref *do_fetch_pack(struct fetch_pack_args *args,
int fd[2],
const struct ref *orig_ref,
@@ -858,6 +882,8 @@ static struct ref *do_fetch_pack(struct fetch_pack_args
*args,
if (args-stateless_rpc)
packet_flush(fd[1]);
+ if (args-depth 0)
+ setup_alternate_shallow();
if (get_pack(args, fd, pack_lockfile))
die(git fetch-pack: fetch failed.);
@@ -936,15 +962,9 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
struct ref **sought, int nr_sought,
char **pack_lockfile)
{
struct ref *ref_cpy;
fetch_pack_setup();
if (nr_sought)
nr_sought = remove_duplicates_in_refs(sought, nr_sought);
@@ -955,34 +975,13 @@ struct ref *fetch_pack(struct fetch_pack_args *args,
ref_cpy = do_fetch_pack(args, fd, ref, sought, nr_sought,
pack_lockfile);
if (args-depth 0) {
+ struct stat st;
+ if (!fstat(shallow_lock.fd, st)
+ st.st_size == 0) {
+ unlink_or_warn(git_path(shallow));
Are we unlinking the right file here?
+ rollback_lock_file(shallow_lock);
+ } else
+ commit_lock_file(shallow_lock);
}
reprepare_packed_git();
diff --git a/git.c b/git.c
index 1ada169..6450a38 100644
--- a/git.c
+++ b/git.c
@@ -4,6 +4,7 @@
#include help.h
#include quote.h
#include run-command.h
+#include commit.h
Re: [PATCH] get_sha1: improve ambiguity warning regarding SHA-1 and ref names
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
That's an important feature for safety. When a script has created an
object or learned about it some other way, as long as it doesn't
abbreviate its name it can be sure that git commands will not
misunderstand it.
So I think this is a bad change.
...
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
static const char *warn_msg = refname '%.*s' is ambiguous.;
+ unsigned char tmp_sha1[20];
char *real_ref = NULL;
int refs_found = 0;
int at, reflog_len;
- if (len == 40 !get_sha1_hex(str, sha1))
+ if (len == 40 !get_sha1_hex(str, sha1)) {
+ refs_found = dwim_ref(str, len, tmp_sha1, real_ref);
+ if (refs_found 0 warn_ambiguous_refs)
+ warning(warn_msg, len, str);
The warning is issued at the right spot from the codeflow's point of
view, but it is very likely that the user did not even mean to use
the str in question as a 'refname'. The warning message we see above
is not appropriate for this case, is it?
+ free(real_ref);
return 0;
+ }
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
@@ -481,7 +487,9 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
if (!refs_found)
return -1;
- if (warn_ambiguous_refs refs_found 1)
+ if (warn_ambiguous_refs
+ (refs_found 1 ||
+ !get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY)))
warning(warn_msg, len, str);
Ditto for the case in which (refs_found = 1) and get_short_sha1()
finds str as a short object name.
diff --git a/t/t1512-rev-parse-disambiguation.sh
b/t/t1512-rev-parse-disambiguation.sh
index 6b3d797..db22808 100755
--- a/t/t1512-rev-parse-disambiguation.sh
+++ b/t/t1512-rev-parse-disambiguation.sh
@@ -261,4 +261,22 @@ test_expect_success 'rev-parse --disambiguate' '
test $(sed -e s/^\(.\).*/\1/ actual | sort -u) = 0
'
+test_expect_success 'ambiguous 40-hex ref' '
+ TREE=$(git mktree /dev/null)
+ REF=`git rev-parse HEAD`
+ VAL=$(git commit-tree $TREE /dev/null)
+ git update-ref refs/heads/$REF $VAL
+ test `git rev-parse $REF 2err` = $REF
+ grep refname.*${REF}.*ambiguous err
+'
+
+test_expect_success 'ambiguous short sha1 ref' '
+ TREE=$(git mktree /dev/null)
+ REF=`git rev-parse --short HEAD`
+ VAL=$(git commit-tree $TREE /dev/null)
+ git update-ref refs/heads/$REF $VAL
+ test `git rev-parse $REF 2err` = $VAL
+ grep refname.*${REF}.*ambiguous err
+'
+
test_done
--
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 3/9] t6111: new TREESAME test set
Kevin Bracey ke...@bracey.fi writes: On 06/05/2013 23:36, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: +#,---E--. *H--. * marks !TREESAME parent paths +# /\ / \* +# *A--*B---D--*F-*G-K-*L-*M +# \ /* \ / +#`-C-' `-*I-*J +# +# A creates file, B and F change it. +# Odd merge G takes the old version from B. +# I changes it, but J reverts it. +# H and L both change it, and M merges those changes. + ... ... +check_outcome failure 'M L H' G..M -- file # includes J I +check_outcome failure 'M L H' G..M --parents -- file # includes J I I am not sure if it should be a failure or your expectation is wrong. G is outside the graph, so as far as the remainder of the graph is concerned, J is the sole remaining parent of K and I and J did change the path in question. What makes you think I and J should be excluded in these cases? Because it's the simplest answer to the question what happened in M since G, which is what G..M is supposed to mean. ... This all comes about because the formal graph definition doesn't match the user interface. The question B..C currently generates a graph of all commits in C since B, and the connections between those commits. It turns out to be problematic that the graph doesn't include the connection to B itself. It would be fine if only worrying about nodes in the graph. But it's not fine when you start doing graph operations that care about edge connections to parents. OK, that makes sense. ... What I'm effectively doing is extending the graph to actually include the unshown bottom. I think it just makes more sense. Yup, and this is a good summary. ... I assume you mean: That is, -a-p F..M makes F the sole remaining parent of G and G does change the path from F so it should be shown, while -a-p E..M makes E the sole parent of G, and G does not change the path from E, so it should not be shown. Yes. Which is the way the logic works - we treat F and E as interesting/priority parents when they're specified as a bottom in each case. Without doing that, G would have 2 differing and equally (un)important parents in each case, and thus would be shown in both cases. In this case, the same logic says that G is treated as an interesting parent of K because it is the specified bottom. Which then enables the default following to follow that path direct to G, rather than having to go down the IJ path (which leads to G anyway). OK. -- 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] clone: allow cloning local paths with colons in them
On Tue, May 07, 2013 at 08:34:51AM -0700, Junio C Hamano wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 67869b4..0629149 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -280,4 +280,9 @@ test_expect_success 'clone checking out a tag' ' test_cmp fetch.expected fetch.actual ' +test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path foo:bar' ' + cp -R src foo:bar + git clone ./foo:bar foobar +' Hmph, why not git clone --mirror src foo:bar git clone ./foo:bar foobar Yeah, not only does that avoid cp -R, but it is a nice check that we do not do anything stupid with colons on the dst argument (which we should obviously not, but it cannot hurt to exercise it). or something? Also do we have a easy negative case we want to test, i.e. a case where we do not want the new codepath to trigger by mistake? Yeah, checking git clone host:path would be nice, but such a case would want to go through ssh. I suspect we could point GIT_SSH at a script like: #!/bin/sh echo ssh: $* ssh-log host=$1; shift cd pretend-hosts/$host exec $@ It looks like t5602 does something similar already. -Peff -- 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] gitk: add support for -G'regex' pickaxe variant
I just did git rebase origin/master for the umpteenth time, which
reminded me this nice patch is still pending.
ping?
m
On Thu, Jun 14, 2012 at 2:34 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
From: Martin Langhoff mar...@laptop.org
git log -G'regex' is a very usable alternative to the classic
pickaxe. Minimal patch to make it usable from gitk.
[zj: reword message]
Signed-off-by: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
---
Martin's off on holidays, so I'm sending v2 after rewording.
gitk-git/gitk | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 22270ce..24eaead 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2232,7 +2232,8 @@ proc makewindow {} {
set gm [makedroplist .tf.lbar.gdttype gdttype \
[mc containing:] \
[mc touching paths:] \
- [mc adding/removing string:]]
+ [mc adding/removing string:] \
+ [mc with changes matching regex:]]
trace add variable gdttype write gdttype_change
pack .tf.lbar.gdttype -side left -fill y
@@ -4595,6 +4596,8 @@ proc do_file_hl {serial} {
set gdtargs [concat -- $relative_paths]
} elseif {$gdttype eq [mc adding/removing string:]} {
set gdtargs [list -S$highlight_files]
+} elseif {$gdttype eq [mc with changes matching regex:]} {
+ set gdtargs [list -G$highlight_files]
} else {
# must be containing:, i.e. we're searching commit info
return
--
1.7.11.rc3.129.ga90bc7a.dirty
--
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
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
--
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] CodingGuidelines: make it clear which files in Documentation are the sources
While learning about making a documentation patch, I noticed that Documentation/CodingGuideles isn't as clear as it could be regarding how to edit the documentation. In particular, it says Most (if not all) of the documentation pages are written in AsciiDoc - and processed into HTML output and manpages. without really specifying the details for those of us who aren't familiar with AsciiDoc. So I added a sentence stating explicitly which files are the sources and which are derived. It's also a test for submitting a patch. Dale From e87227498ef3d50dc20584c24c53071cce63c555 Mon Sep 17 00:00:00 2001 From: Dale Worley wor...@ariadne.com Date: Tue, 7 May 2013 13:39:46 -0400 Subject: [PATCH] CodingGuidelines: make it clear which files in Documentation are the sources --- Documentation/CodingGuidelines |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 7e4d571..b8eef7c 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -238,7 +238,9 @@ For Python scripts: Writing Documentation: Most (if not all) of the documentation pages are written in AsciiDoc - and processed into HTML output and manpages. + and processed into HTML output and manpages. This means that the *.txt + files in this directory are usually the sources from which the + corresponding *.html, *.1, and *.xml files are generated. Every user-visible change should be reflected in the documentation. The same general rule as for code applies -- imitate the existing -- 1.7.7.6 -- 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] CodingGuidelines: make it clear which files in Documentation are the sources
wor...@ariadne.com (Dale R. Worley) writes: It's also a test for submitting a patch. Then, the next step is to read SubmittingPatches (the part about how to format your email and the role of the ---, and the part about signed-off-by) ;-). Welcome aboard! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] remove the impression of unexpectedness when access is denied
On Mon, May 06, 2013 at 07:02:41AM -0700, Junio C Hamano wrote: Would it make sense for the server to send an ERR packet to give a more helpful diagnosis? I think git-daemon does so (or at least attempts to do so); path_ok() uses enter_repo() to check if the given path is a repository, returns NULL to run_service(), whichh in turn calls daemon_error() that does the ERR thing. Yeah, that went into v1.7.8. Do we have any simple way to find out which version kernel.org is running? They should probably also turn on the --informative-errors option, as they do not (AFAIK) have any private repos whose information could be leaked by better error messages. If they are running v1.7.8 and it is not producing an ERR message, then I think there is a bug. * The error message is the same whether the server returned no response or an incomplete pkt-line. Maybe in the latter case it should print the hung up unexpectedly thing. OK. I made a stab at this some time ago: http://article.gmane.org/gmane.comp.version-control.git/112189 There were some follow-up comments, and I remember trying to make something work with processing remote stderr, but running into complications. Alas, I don't remember any more details than that. But maybe it helps. -Peff -- 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 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
... there is AFAICS _no_ way for sscanf() - having
already done one or more format extractions - to indicate to its caller
that the input fails to match the trailing part of the format string.
Yeah, we can detect when we did not have enough, but we cannot tell
where it stopped matching.
It is interesting that this bug has stayed so long with us, which
may indicate that nobody actually uses the feature at all.
I don't know if people really care about whether
refs/remotes/origin/HEAD shortens to origin/HEAD or origin. I'm
guessing that people _do_ depend on the reverse - having origin
expand into refs/remotes/origin/HEAD, so we probably cannot rip out
the refs/remotes/%.*s/HEAD rule altogether...
Good eyes.
Cc: Bert Wesarg bert.wes...@googlemail.com
Signed-off-by: Johan Herland jo...@herland.net
---
refs.c | 82
+++--
t/t6300-for-each-ref.sh | 12
2 files changed, 43 insertions(+), 51 deletions(-)
diff --git a/refs.c b/refs.c
index d17931a..7231f54 100644
--- a/refs.c
+++ b/refs.c
@@ -2945,80 +2945,60 @@ struct ref *find_ref_by_name(const struct ref *list,
const char *name)
return NULL;
}
+int shorten_ref(const char *refname, const char *pattern, char *short_name)
Does this need to be an extern?
Nope, it should be static. Will fix.
{
+ /*
+ * pattern must be of the form [pre]%.*s[post]. Check if refname
+ * starts with [pre] and ends with [post]. If so, write the
+ * middle part into short_name, and return the number of chars
+ * written (not counting the added NUL-terminator). Otherwise,
+ * if refname does not match pattern, return 0.
+ */
+ size_t pre_len, post_start, post_len, match_len;
+ size_t ref_len = strlen(refname);
+ char *sep = strstr(pattern, %.*s);
+ if (!sep || strstr(sep + 4, %.*s))
+ die(invalid pattern in ref_rev_parse_rules: %s, pattern);
+ pre_len = sep - pattern;
+ post_start = pre_len + 4;
+ post_len = strlen(pattern + post_start);
+ if (pre_len + post_len = ref_len)
+ return 0; /* refname too short */
+ match_len = ref_len - (pre_len + post_len);
+ if (strncmp(refname, pattern, pre_len) ||
+ strncmp(refname + ref_len - post_len, pattern + post_start,
post_len))
+ return 0; /* refname does not match */
+ memcpy(short_name, refname + pre_len, match_len);
+ short_name[match_len] = '\0';
+ return match_len;
}
OK. Looks correct, even though I suspect some people might come up
with a more concise way to express the above.
Yeah, I made it sort of explicit to convince myself I'd gotten it
right. I'm sure the same can be expressed in fewer lines of code.
char *shorten_unambiguous_ref(const char *refname, int strict)
{
int i;
char *short_name;
/* skip first rule, it will always match */
- for (i = nr_rules - 1; i 0 ; --i) {
+ for (i = ARRAY_SIZE(ref_rev_parse_rules) - 1; i 0 ; --i) {
int j;
int rules_to_fail = i;
int short_name_len;
+ if (!ref_rev_parse_rules[i] ||
What is this skippage about? Isn't it what you already compensated
away by starting from ARRAY_SIZE() - 1?
There are various things being skipped at various points... The
ref_rev_parse_rules array looks like this:
const char *ref_rev_parse_rules[] = {
%.*s,
refs/%.*s,
refs/tags/%.*s,
refs/heads/%.*s,
refs/remotes/%.*s,
refs/remotes/%.*s/HEAD,
NULL
};
Obviously we want to skip looking at the last (sentinel) entry. But
there's also no point in looking at the first, since it trivially
shortens to itself.
The for loop in this function:
- for (i = nr_rules - 1; i 0 ; --i) {
+ for (i = ARRAY_SIZE(ref_rev_parse_rules) - 1; i 0 ; --i) {
is about skipping the _first_ array entry (we start at the last index,
and stop _before_ we reach 0).
The current line:
+ if (!ref_rev_parse_rules[i] ||
is about skipping the last (sentinel) entry. The previous code did
this by doing a pre-pass where nr_rules is set to
ARRAY_SIZE(ref_rev_parse_rules) - 1. I should have obviously done the
same by initializing i to ARRAY_SIZE(ref_rev_parse_rules) - 2 in the
above for loop.
Ahh, no. But wait. Isn't there a larger issue here?
+ !(short_name_len = shorten_ref(refname,
+ref_rev_parse_rules[i],
+short_name)))
continue;
- short_name_len = strlen(short_name);
-
/*
* in strict mode, all (except the matched one) rules
* must fail to resolve to a valid non-ambiguous ref
*/
[PATCHv2 1/3] t1514: Add tests of shortening refnames in strict/loose mode
These tests verify the correct behavior of git rev-parse --abbrev-ref
in both strict and loose modes. Really, it tests the correct behavior
of refs.c:shorten_unambiguous_ref() with its 'strict' argument set to
either true of false.
Signed-off-by: Johan Herland jo...@herland.net
---
t/t1514-rev-parse-shorten_unambiguous_ref.sh | 75
1 file changed, 75 insertions(+)
create mode 100755 t/t1514-rev-parse-shorten_unambiguous_ref.sh
diff --git a/t/t1514-rev-parse-shorten_unambiguous_ref.sh
b/t/t1514-rev-parse-shorten_unambiguous_ref.sh
new file mode 100755
index 000..41e0162
--- /dev/null
+++ b/t/t1514-rev-parse-shorten_unambiguous_ref.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+
+test_description='short refname disambiguation
+
+Create refs that share the same name, and make sure
+git rev-parse --abbrev-ref can present them all with as short a name
+as possible, while still being unambiguous.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ test_commit master_a
+ git remote add origin .
+ git fetch origin
+ test_commit master_b
+ git branch origin/master
+ test_commit master_c
+ git tag master
+ test_commit master_d
+ git update-ref refs/master master_d
+ test_commit master_e
+ test_commit master_f
+'
+
+cat expect.show-ref EOF
+$(git rev-parse master_f) refs/heads/master
+$(git rev-parse master_b) refs/heads/origin/master
+$(git rev-parse master_d) refs/master
+$(git rev-parse master_a) refs/remotes/origin/master
+$(git rev-parse master_c) refs/tags/master
+$(git rev-parse master_a) refs/tags/master_a
+$(git rev-parse master_b) refs/tags/master_b
+$(git rev-parse master_c) refs/tags/master_c
+$(git rev-parse master_d) refs/tags/master_d
+$(git rev-parse master_e) refs/tags/master_e
+$(git rev-parse master_f) refs/tags/master_f
+EOF
+
+test_expect_success 'we have the expected ref layout' '
+ git show-ref actual.show-ref
+ test_cmp expect.show-ref actual.show-ref
+'
+
+test_shortname () {
+ refname=$1
+ mode=$2
+ expect_shortname=$3
+ expect_tag=$4
+ echo $expect_shortname expect.shortname
+ actual_shortname=$(git rev-parse --abbrev-ref=$mode $refname)
+ echo $actual_shortname actual.shortname
+ test_cmp expect.shortname actual.shortname
+ git rev-parse --verify $expect_tag expect.sha1
+ git rev-parse --verify $actual_shortname actual.sha1
+ test_cmp expect.sha1 actual.sha1
+}
+
+test_expect_success 'shortening refnames in strict mode' '
+ test_shortname refs/heads/master strict heads/master master_f
+ test_shortname refs/heads/origin/master strict heads/origin/master
master_b
+ test_shortname refs/master strict refs/master master_d
+ test_shortname refs/remotes/origin/master strict remotes/origin/master
master_a
+ test_shortname refs/tags/master strict tags/master master_c
+'
+
+test_expect_success 'shortening refnames in loose mode' '
+ test_shortname refs/heads/master loose heads/master master_f
+ test_shortname refs/heads/origin/master loose origin/master master_b
+ test_shortname refs/master loose master master_d
+ test_shortname refs/remotes/origin/master loose remotes/origin/master
master_a
+ test_shortname refs/tags/master loose tags/master master_c
+'
+
+test_done
--
1.8.1.3.704.g33f7d4f
--
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
[PATCHv2 2/3] t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD
There is currently a bug in refs.c:shorten_unambiguous_ref() that causes
refs/remotes/origin/HEAD to be shortened to origin/HEAD instead of
origin (which is expected from matching against the refs/remotes/%.*s
pattern from refs.c:ref_rev_parse_rules).
Signed-off-by: Johan Herland jo...@herland.net
---
t/t1514-rev-parse-shorten_unambiguous_ref.sh | 8 ++--
t/t6300-for-each-ref.sh | 12
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/t/t1514-rev-parse-shorten_unambiguous_ref.sh
b/t/t1514-rev-parse-shorten_unambiguous_ref.sh
index 41e0162..ad75436 100755
--- a/t/t1514-rev-parse-shorten_unambiguous_ref.sh
+++ b/t/t1514-rev-parse-shorten_unambiguous_ref.sh
@@ -20,6 +20,7 @@ test_expect_success 'setup' '
test_commit master_d
git update-ref refs/master master_d
test_commit master_e
+ git update-ref refs/remotes/origin/HEAD master_e
test_commit master_f
'
@@ -27,6 +28,7 @@ cat expect.show-ref EOF
$(git rev-parse master_f) refs/heads/master
$(git rev-parse master_b) refs/heads/origin/master
$(git rev-parse master_d) refs/master
+$(git rev-parse master_e) refs/remotes/origin/HEAD
$(git rev-parse master_a) refs/remotes/origin/master
$(git rev-parse master_c) refs/tags/master
$(git rev-parse master_a) refs/tags/master_a
@@ -56,18 +58,20 @@ test_shortname () {
test_cmp expect.sha1 actual.sha1
}
-test_expect_success 'shortening refnames in strict mode' '
+test_expect_failure 'shortening refnames in strict mode' '
test_shortname refs/heads/master strict heads/master master_f
test_shortname refs/heads/origin/master strict heads/origin/master
master_b
test_shortname refs/master strict refs/master master_d
+ test_shortname refs/remotes/origin/HEAD strict origin master_e
test_shortname refs/remotes/origin/master strict remotes/origin/master
master_a
test_shortname refs/tags/master strict tags/master master_c
'
-test_expect_success 'shortening refnames in loose mode' '
+test_expect_failure 'shortening refnames in loose mode' '
test_shortname refs/heads/master loose heads/master master_f
test_shortname refs/heads/origin/master loose origin/master master_b
test_shortname refs/master loose master master_d
+ test_shortname refs/remotes/origin/HEAD loose origin master_e
test_shortname refs/remotes/origin/master loose remotes/origin/master
master_a
test_shortname refs/tags/master loose tags/master master_c
'
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 752f5cb..5d716c8 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -466,4 +466,16 @@ test_expect_success 'Verify sort with multiple keys' '
refs/tags/bogo refs/tags/master actual
test_cmp expected actual
'
+
+cat expected \EOF
+origin
+origin/master
+EOF
+
+test_expect_failure 'Check refs/remotes/origin/HEAD shortens to origin' '
+ git remote set-head origin master
+ git for-each-ref --format=%(refname:short) refs/remotes actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.1.3.704.g33f7d4f
--
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
[PATCHv2 3/3] shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin
When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
we use the ref_rev_parse_rules list of expansion patterns. This list
allows origin to be expanded into refs/remotes/origin/HEAD, by
using the refs/remotes/%.*s/HEAD pattern from that list.
shorten_unambiguous_ref() exists to provide the reverse operation:
turning a full ref name into a shorter (but still unambiguous) name.
It does so by matching the given refname against each pattern from
the ref_rev_parse_rules list (in reverse), and extracting the short-
hand name from the matching rule.
However, when given refs/remotes/origin/HEAD it fails to shorten it
into origin, because we misuse the sscanf() function when matching
refs/remotes/origin/HEAD against refs/remotes/%.*s/HEAD: We end
up calling sscanf like this:
sscanf(refs/remotes/origin/HEAD, refs/remotes/%s/HEAD, short_name)
In this case, sscanf() will match the initial refs/remotes/ part, and
then match the remainder of the refname against the %s, and place it
(origin/HEAD) into short_name. The part of the pattern following the
%s format is never verified, because sscanf() apparently does not
need to do that (it has performed the one expected format extraction,
and will return 1 correspondingly; see [1] for more details).
This patch replaces the misuse of sscanf() with a fairly simple function
that manually matches the refname against patterns, and extracts the
shorthand name.
[1]: If we assume that sscanf() does not do a verification pass prior
to format extraction, there is AFAICS _no_ way for sscanf() - having
already done one or more format extractions - to indicate to its caller
that the input fails to match the trailing part of the format string.
In other words, AFAICS, the scanf() family of function will only verify
matching input up to and including the last format specifier in the
format string. Any data following the last format specifier will not be
verified. Yet another reason to consider the scanf functions harmful...
Cc: Bert Wesarg bert.wes...@googlemail.com
Improved-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Johan Herland jo...@herland.net
---
refs.c | 77 ++--
t/t1514-rev-parse-shorten_unambiguous_ref.sh | 4 +-
t/t6300-for-each-ref.sh | 2 +-
3 files changed, 29 insertions(+), 54 deletions(-)
diff --git a/refs.c b/refs.c
index d17931a..a0ba2fd 100644
--- a/refs.c
+++ b/refs.c
@@ -2945,80 +2945,55 @@ struct ref *find_ref_by_name(const struct ref *list,
const char *name)
return NULL;
}
-/*
- * generate a format suitable for scanf from a ref_rev_parse_rules
- * rule, that is replace the %.*s spec with a %s spec
- */
-static void gen_scanf_fmt(char *scanf_fmt, const char *rule)
+static int shorten_ref(const char *refname, const char *pattern, char
*short_name)
{
- char *spec;
-
- spec = strstr(rule, %.*s);
- if (!spec || strstr(spec + 4, %.*s))
- die(invalid rule in ref_rev_parse_rules: %s, rule);
-
- /* copy all until spec */
- strncpy(scanf_fmt, rule, spec - rule);
- scanf_fmt[spec - rule] = '\0';
- /* copy new spec */
- strcat(scanf_fmt, %s);
- /* copy remaining rule */
- strcat(scanf_fmt, spec + 4);
-
- return;
+ /*
+* pattern must be of the form [pre]%.*s[post]. If refname
+* starts with [pre] and ends with [post], extract the middle
+* part into short_name, and return the number of chars in the
+* middle part (not counting the added NUL-terminator). Otherwise,
+* if refname does not match pattern, return 0.
+*/
+ int match_len;
+ const char *match_start, *sep = strstr(pattern, %.*s);
+ if (!sep || strstr(sep + 4, %.*s))
+ die(invalid pattern in ref_rev_parse_rules: %s, pattern);
+ match_start = refname + (sep - pattern);
+ match_len = strlen(refname) - (strlen(pattern) - 4);
+ if (match_len = 0 ||
+ strncmp(refname, pattern, match_start - refname) ||
+ strcmp(match_start + match_len, sep + 4))
+ return 0; /* refname does not match */
+ memcpy(short_name, match_start, match_len);
+ short_name[match_len] = '\0';
+ return match_len;
}
char *shorten_unambiguous_ref(const char *refname, int strict)
{
int i;
- static char **scanf_fmts;
- static int nr_rules;
char *short_name;
- /* pre generate scanf formats from ref_rev_parse_rules[] */
- if (!nr_rules) {
- size_t total_len = 0;
-
- /* the rule list is NULL terminated, count them first */
- for (; ref_rev_parse_rules[nr_rules]; nr_rules++)
- /* no +1 because strlen(%s) strlen(%.*s) */
- total_len += strlen(ref_rev_parse_rules[nr_rules]);
-
- scanf_fmts = xmalloc(nr_rules * sizeof(char *) + total_len);
-
-
Re: [PATCH] gitk: add support for -G'regex' pickaxe variant
On Tue, May 7, 2013 at 12:17 PM, Martin Langhoff martin.langh...@gmail.com wrote: I just did git rebase origin/master for the umpteenth time, which reminded me this nice patch is still pending. ping? For some reason getting patches into gitk takes a long long looong time. -- Felipe Contreras -- 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: What's cooking in git.git (May 2013, #02; Mon, 6)
On Tue, May 7, 2013 at 1:59 AM, Junio C Hamano gits...@pobox.com wrote: * fc/at-head (2013-05-02) 5 commits - Add new @ shortcut for HEAD - sha1_name: refactor reinterpret() - sha1_name: compare variable with constant, not constant with variable - sha1_name: remove unnecessary braces - sha1_name: remove no-op Instead of typing four capital letters HEAD, you can say @ instead. There was another series from Ram that looked mostly test updates but I lost track of which one was which. In any case, are people happy with this series? This series has cleanups and features that are good as they are. Ramkumar said he was going to resend his cleanup series, but he didn't. I'll try to gather all the patches and split them into cleanups, and features. Cheers. -- Felipe Contreras -- 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] deprecate core.statinfo at Git 2.0 boundary
This looks ok with me, though I can manage without backward compatibility. -- robin -- 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: Add porcelain command to revert a single staged file to its HEAD state while preserving its staged state
Junio C Hamano gits...@pobox.com wrote: Dimitar Bonev dsbo...@gmail.com writes: [administrivia: please do not drop people out of Cc list] That invites another question: if it is very well related, why isn't it an option to start from the state you have in the working tree (i.e. doing nothing), or in the index (i.e. git checkout controller)? But the answer does not matter that much in the end. It isn't an option to start from the staged state, because the staged implementation modified code that is present in the HEAD state. So the new implementation that I have in my mind requires to add its own kind of modifications which are incompatible with the staged implementation. It is much easier to start from HEAD state when both implementations require modifying 10% HEAD code and adding 90% new code. If I start from staged state I have to drop 90% new code and to figure out if the 10% modified state can work without the 90% dropped code. At the same time I know HEAD state is stable working code. There is no doubt that I have to start from HEAD state of the controller file for the described MVC example I think the story is essentially the same. Let's say you did git diff HEAD controller | git apply -R edit controller to get rid of the changes in the working tree, further worked on the controller part, and came up with a different implementation. Then you would presumably do git add controller but at that point you would lose the maybe OK version you had in the index. What if you think the version in the working tree might end up being better than maybe OK but can still be improved further? You never git add until the working tree version gets into truly a better shape? Yes, I 'git add' only what is to become part of the next commit so at least it has to be stable code (that passes some smoke tests or something similar). What happens fairly often is that you end up having more than _one_ versions that are both better than the version from the HEAD but cannot immediately say one is clearly better than the others in all counts, and at some point, you would need more than one intermediate states (while the index can have only one), to keep these competing versions. The next thing you would want to do is to take a deep breath and pick better parts from these good versions to come up with the single final version. Keeping one good version in the index does not let you do so. My case was not like that but if it was I would have made a commit to preserve the old implementation while working on the new one. I think people should learn to take the biggest advantage of using a distributed source control system, which is that commits do not have to be finished work, until you choose to declare they are done and push them out for others to see. Fear of commitment is a disease we do not have to suffer once we graduated centralized systems ;-). I used the wrong words - I meant 'stable state' instead of 'finished work'. If every commit was finished work then all my branches would have contain one specific commit. My branches are built from more than one commit and every commit adds a subfeature and the commit should be stable in sense that it should run without throwing exceptions - like trying to load some file that would be created in a future commit. One should be able to checkout a random commit and be able to run, inspect, write tests against, add new subfeature on top of that commit. -- 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 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
Johan Herland jo...@herland.net writes: New version coming up. I'm going to rip this patch out of the surrounding series, since it doesn't really belong there anyway. Thanks; will queue. -- 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 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
Johan Herland jo...@herland.net writes: On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: ... there is AFAICS _no_ way for sscanf() - having already done one or more format extractions - to indicate to its caller that the input fails to match the trailing part of the format string. Yeah, we can detect when we did not have enough, but we cannot tell where it stopped matching. It is interesting that this bug has stayed so long with us, which may indicate that nobody actually uses the feature at all. I don't know if people really care about whether refs/remotes/origin/HEAD shortens to origin/HEAD or origin. I'm guessing that people _do_ depend on the reverse - having origin expand into refs/remotes/origin/HEAD, so we probably cannot rip out the refs/remotes/%.*s/HEAD rule altogether... Oh, no doubt about that reverse conversion. The real reason nobody cared about refs/remotes/origin/HEAD is that nobody sane has anything but non-symbolic ref there. Your t1514 does this: ... git update-ref refs/master master_d test_commit master_e git update-ref refs/remotes/origin/HEAD master_e ... Nowhere in the set-up sequence, you see anything that does git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master or any other branch we copied from the remote. And the shortening is done after dereferencing the synbolic ref. Because of this, refs/remotes/origin/HEAD usually resolves to origin/master, not origin. t/t1514-rev-parse-shorten-unambiguous-ref.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t1514-rev-parse-shorten-unambiguous-ref.sh b/t/t1514-rev-parse-shorten-unambiguous-ref.sh index fd87ce3..556ad16 100755 --- a/t/t1514-rev-parse-shorten-unambiguous-ref.sh +++ b/t/t1514-rev-parse-shorten-unambiguous-ref.sh @@ -76,4 +76,11 @@ test_expect_success 'shortening refnames in loose mode' ' test_shortname refs/tags/master loose tags/master master_c ' +test_expect_success 'shortening is done after dereferencing a symref' ' + git update-ref refs/remotes/frotz/master master_e + git symbolic-ref refs/remotes/frotz/HEAD refs/remotes/frotz/master + test_shortname refs/remotes/frotz/HEAD strict frotz/master master_e + test_shortname refs/remotes/frotz/HEAD loose frotz/master master_e +' + test_done -- 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/7] t7900: Start testing usability of namespaced remote refs
On Tue, May 7, 2013 at 3:29 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
+test_expect_success 'work-around clone with namespaced remote refs' '
+ rm -rf client
+ git init client
+ (
+ cd client
+ git remote add origin ../server
+ git config --unset-all remote.origin.fetch
+ git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
If you were to do this, I think you should drop the remote add
origin step and illustrate what configuration variables should be
prepared (at least minimally---the final implementation of git
clone --separate-remote-layout may add some other configuration
variable as a hint to say this remote is using the new layout or
somesuch) in this client repository.
Sure, I can change the test into doing:
cd client
git config remote.origin.url ../server
git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/heads/*
git config --add remote.origin.fetch
+refs/tags/*:refs/remotes/origin/tags/*
git config --add remote.origin.fetch
+refs/notes/*:refs/remotes/origin/notes/*
git config --add remote.origin.fetch
+refs/replace/*:refs/remotes/origin/replace/*
git config remote.origin.tagopt --no-tags
git fetch
git checkout master
That would make the test more self documenting.
I am not convinced that it is a good idea to reuse remotes/origin
hierarchy which traditionally has been branches-only like this,
though. It may be better to use
refs/$remotes_new_layout/origin/{heads,tags,...}/*
for a value of $remotes_new_layout that is different from remote,
and teach the dwim_ref() machinery to pay attention to it, to avoid
confusion. Otherwise, you wouldn't be able to tell between a topic
branch that works on tags named tags/refactor under the old layout,
and a tag that marks a good point in a refactoring effort refactor
under the new layout.
I see your point, although I'm not convinced it is common among users
to have branch names of the tags/* form (or tag names of the
heads/* form, for that matter). I'm also not sure it's worth messing
with the remotes name which has had a long time to work its way into
our brains and into git's user interface.
That said, I could have a go at using refs/peers/* instead of
refs/remotes/*, and see how that works out.
If it sticks, how pervasive do we want this renaming to be? I guess we
don't want to rename the git remote command to git peer just
yet... What about the config? Do we rename remote.origin.url to
peer.origin.url for new-style remotes? For how long do you
anticipate having peers and remotes living side-by-side as
concepts in git?
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
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 v2 00/11] sha1_name: improvements
Hi,
While trying to add support for the @ shortcut lots of cleanups arised. Here
they are in a single series.
Felipe Contreras (7):
tests: at-combinations: simplify setup
tests: at-combinations: check ref names directly
tests: at-combinations: improve nonsense()
sha1_name: remove no-op
sha1_name: remove unnecessary braces
sha1_name: avoid Yoda conditions
sha1_name: reorganize get_sha1_basic()
Ramkumar Ramachandra (4):
tests: at-combinations: increase coverage
tests: at-combinations: @{N} versus HEAD@{N}
sha1_name: don't waste cycles in the @-parsing loop
sha1_name: check @{-N} errors sooner
sha1_name.c| 42 +++---
t/t1508-at-combinations.sh | 56 +-
2 files changed, 64 insertions(+), 34 deletions(-)
--
1.8.3.rc0.401.g45bba44
--
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 v2 01/11] tests: at-combinations: simplify setup
The test is setting up an upstream branch, but there's a much simpler way of doing that: git branch -u. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t1508-at-combinations.sh | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh index d5d6244..46e3f16 100755 --- a/t/t1508-at-combinations.sh +++ b/t/t1508-at-combinations.sh @@ -31,10 +31,8 @@ test_expect_success 'setup' ' git checkout -b new-branch test_commit new-one test_commit new-two - git config branch.old-branch.remote . - git config branch.old-branch.merge refs/heads/master - git config branch.new-branch.remote . - git config branch.new-branch.merge refs/heads/upstream-branch + git branch -u master old-branch + git branch -u upstream-branch new-branch ' check HEAD new-two -- 1.8.3.rc0.401.g45bba44 -- 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 v2 02/11] tests: at-combinations: check ref names directly
Some committishes might point to the same commit, but through a
different ref, that's why it's better to check directly for the ref,
rather than the commit message.
We can do that by calling rev-parse --symbolic-full-name, and to
differentiate the old from the new behavior we add an extra argument to
the check() helper.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t1508-at-combinations.sh | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 46e3f16..bd2d2fe 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -4,9 +4,14 @@ test_description='test various @{X} syntax combinations
together'
. ./test-lib.sh
check() {
-test_expect_${3:-success} $1 = $2
- echo '$2' expect
- git log -1 --format=%s '$1' actual
+test_expect_${4:-success} $1 = $3
+ if [ '$2' == 'commit' ]; then
+ echo '$3' expect
+ git log -1 --format=%s '$1' actual
+ else
+ echo '$3' expect
+ git rev-parse --symbolic-full-name '$1' actual
+ fi
test_cmp expect actual
}
@@ -35,14 +40,14 @@ test_expect_success 'setup' '
git branch -u upstream-branch new-branch
'
-check HEAD new-two
-check @{1} new-one
-check @{-1} old-two
-check @{-1}@{1} old-one
-check @{u} upstream-two
-check @{u}@{1} upstream-one
-check @{-1}@{u} master-two
-check @{-1}@{u}@{1} master-one
+check HEAD ref refs/heads/new-branch
+check @{1} commit new-one
+check @{-1} ref refs/heads/old-branch
+check @{-1}@{1} commit old-one
+check @{u} ref refs/heads/upstream-branch
+check @{u}@{1} commit upstream-one
+check @{-1}@{u} ref refs/heads/master
+check @{-1}@{u}@{1} commit master-one
nonsense @{u}@{-1}
nonsense @{1}@{u}
--
1.8.3.rc0.401.g45bba44
--
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 v2 03/11] tests: at-combinations: improve nonsense()
In some circumstances 'git log' might fail, but not because the @
parsing failed. For example: 'git rev-parse' might succeed and return a
bad object, and then 'git log' would fail.
The layer we want to test is revision parsing, so let's test that
directly.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t1508-at-combinations.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index bd2d2fe..2ea735e 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -17,7 +17,7 @@ test_expect_${4:-success} $1 = $3
}
nonsense() {
test_expect_${2:-success} $1 is nonsensical
- test_must_fail git log -1 '$1'
+ test_must_fail git rev-parse '$1'
}
fail() {
--
1.8.3.rc0.401.g45bba44
--
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 v2 04/11] tests: at-combinations: increase coverage
From: Ramkumar Ramachandra artag...@gmail.com
Add more tests exercising documented functionality.
[fc: commit message and extra tests]
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t1508-at-combinations.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 2ea735e..58cd1fe 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -42,13 +42,21 @@ test_expect_success 'setup' '
check HEAD ref refs/heads/new-branch
check @{1} commit new-one
+check HEAD@{1} commit new-one
+check @{now} commit new-two
+check HEAD@{now} commit new-two
check @{-1} ref refs/heads/old-branch
+check @{-1}@{0} commit old-two
check @{-1}@{1} commit old-one
check @{u} ref refs/heads/upstream-branch
+check HEAD@{u} ref refs/heads/upstream-branch
check @{u}@{1} commit upstream-one
check @{-1}@{u} ref refs/heads/master
check @{-1}@{u}@{1} commit master-one
nonsense @{u}@{-1}
+nonsense @{0}@{0}
nonsense @{1}@{u}
+nonsense HEAD@{-1}
+nonsense @{-1}@{-1}
test_done
--
1.8.3.rc0.401.g45bba44
--
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 v2 05/11] tests: at-combinations: @{N} versus HEAD@{N}
From: Ramkumar Ramachandra artag...@gmail.com
All the tests so far check that @{N} is the same as HEAD@{N} (for
positive N). However, this is not always the case; write a couple of
tests for this.
[fc: simplify some wording]
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t1508-at-combinations.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 58cd1fe..13b0372 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -59,4 +59,17 @@ nonsense @{1}@{u}
nonsense HEAD@{-1}
nonsense @{-1}@{-1}
+# @{N} versus HEAD@{N}
+
+check HEAD@{3} commit old-two
+nonsense @{3}
+
+test_expect_success 'switch to old-branch' '
+ git checkout old-branch
+'
+
+check HEAD ref refs/heads/old-branch
+check HEAD@{1} commit new-two
+check @{1} commit old-one
+
test_done
--
1.8.3.rc0.401.g45bba44
--
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 v2 06/11] sha1_name: remove no-op
'at' is always 0, since we can reach this point only if
!len reflog_len, and len=at when reflog is assigned.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..01e49a9 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -464,7 +464,7 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
struct strbuf buf = STRBUF_INIT;
int ret;
/* try the @{-N} syntax for n-th checkout */
- ret = interpret_branch_name(str+at, buf);
+ ret = interpret_branch_name(str, buf);
if (ret 0) {
/* substitute this branch name and restart */
return get_sha1_1(buf.buf, buf.len, sha1, 0);
--
1.8.3.rc0.401.g45bba44
--
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 v2 07/11] sha1_name: remove unnecessary braces
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 01e49a9..6530ddd 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -465,12 +465,11 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
int ret;
/* try the @{-N} syntax for n-th checkout */
ret = interpret_branch_name(str, buf);
- if (ret 0) {
+ if (ret 0)
/* substitute this branch name and restart */
return get_sha1_1(buf.buf, buf.len, sha1, 0);
- } else if (ret == 0) {
+ else if (ret == 0)
return -1;
- }
/* allow @{...} to mean the current branch reflog */
refs_found = dwim_ref(HEAD, 4, sha1, real_ref);
} else if (reflog_len)
--
1.8.3.rc0.401.g45bba44
--
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 v2 09/11] sha1_name: don't waste cycles in the @-parsing loop
From: Ramkumar Ramachandra artag...@gmail.com
The @-parsing loop unnecessarily checks for the sequence @{ from len -
2 unnecessarily. We can safely check from len - 4.
[fc: remove cruft]
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c
index 93c4e8c..0acc6e0 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -445,7 +445,7 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
if (len str[len-1] == '}') {
- for (at = len-2; at = 0; at--) {
+ for (at = len-4; at = 0; at--) {
if (str[at] == '@' str[at+1] == '{') {
if (!upstream_mark(str + at, len - at)) {
reflog_len = (len-1) - (at+2);
--
1.8.3.rc0.401.g45bba44
--
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 v2 10/11] sha1_name: reorganize get_sha1_basic()
Through the years the functionality to handle @{-N} and @{u} has moved
around the code, and as a result, code that once made sense, doesn't any
more.
There is no need to call this function recursively with the branch of
@{-N} substituted because dwim_{ref,log} already replaces it.
However, there's one corner-case where @{-N} resolves to a detached
HEAD, in which case we wouldn't get any ref back.
So we parse the nth-prior manually, and deal with it depending on
weather it's a SHA-1, or a ref.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 0acc6e0..c512c69 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -431,13 +431,14 @@ static inline int upstream_mark(const char *string, int
len)
}
static int get_sha1_1(const char *name, int len, unsigned char *sha1, unsigned
lookup_flags);
+static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf);
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
static const char *warn_msg = refname '%.*s' is ambiguous.;
char *real_ref = NULL;
int refs_found = 0;
- int at, reflog_len;
+ int at, reflog_len, nth_prior = 0;
if (len == 40 !get_sha1_hex(str, sha1))
return 0;
@@ -447,6 +448,10 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
if (len str[len-1] == '}') {
for (at = len-4; at = 0; at--) {
if (str[at] == '@' str[at+1] == '{') {
+ if (at == 0 str[2] == '-') {
+ nth_prior = 1;
+ continue;
+ }
if (!upstream_mark(str + at, len - at)) {
reflog_len = (len-1) - (at+2);
len = at;
@@ -460,19 +465,22 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
if (len ambiguous_path(str, len))
return -1;
- if (!len reflog_len) {
+ if (nth_prior) {
struct strbuf buf = STRBUF_INIT;
- int ret;
- /* try the @{-N} syntax for n-th checkout */
- ret = interpret_branch_name(str, buf);
- if (ret 0)
- /* substitute this branch name and restart */
- return get_sha1_1(buf.buf, buf.len, sha1, 0);
- else if (ret == 0)
- return -1;
+ int detached;
+
+ if (interpret_nth_prior_checkout(str, buf) 0) {
+ detached = (buf.len == 40 !get_sha1_hex(buf.buf,
sha1));
+ strbuf_release(buf);
+ if (detached)
+ return 0;
+ }
+ }
+
+ if (!len reflog_len)
/* allow @{...} to mean the current branch reflog */
refs_found = dwim_ref(HEAD, 4, sha1, real_ref);
- } else if (reflog_len)
+ else if (reflog_len)
refs_found = dwim_log(str, len, sha1, real_ref);
else
refs_found = dwim_ref(str, len, sha1, real_ref);
--
1.8.3.rc0.401.g45bba44
--
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 v2 11/11] sha1_name: check @{-N} errors sooner
From: Ramkumar Ramachandra artag...@gmail.com
It's trivial to check for them in the @{N} parsing loop.
[fc: style]
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index c512c69..db965af 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -448,7 +448,10 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
if (len str[len-1] == '}') {
for (at = len-4; at = 0; at--) {
if (str[at] == '@' str[at+1] == '{') {
- if (at == 0 str[2] == '-') {
+ if (str[at+2] == '-') {
+ if (at != 0)
+ /* @{-N} not at start */
+ return -1;
nth_prior = 1;
continue;
}
@@ -497,10 +500,6 @@ static int get_sha1_basic(const char *str, int len,
unsigned char *sha1)
unsigned long co_time;
int co_tz, co_cnt;
- /* a @{-N} placed anywhere except the start is an error */
- if (str[at+2] == '-')
- return -1;
-
/* Is it asking for N-th entry, or approxidate? */
for (i = nth = 0; 0 = nth i reflog_len; i++) {
char ch = str[at+2+i];
--
1.8.3.rc0.401.g45bba44
--
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 v2 08/11] sha1_name: avoid Yoda conditions
Speak in reverse we shall not; compare variable with constant, not
constant with variable.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 6530ddd..93c4e8c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -996,9 +996,9 @@ int interpret_branch_name(const char *name, struct strbuf
*buf)
if (!len)
return len; /* syntax Ok, not enough switches */
- if (0 len len == namelen)
+ if (len 0 len == namelen)
return len; /* consumed all */
- else if (0 len) {
+ else if (len 0) {
/* we have extra data, which might need further processing */
struct strbuf tmp = STRBUF_INIT;
int used = buf-len;
--
1.8.3.rc0.401.g45bba44
--
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 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
On Tue, May 7, 2013 at 11:31 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: On Mon, May 6, 2013 at 7:52 PM, Junio C Hamano gits...@pobox.com wrote: It is interesting that this bug has stayed so long with us, which may indicate that nobody actually uses the feature at all. I don't know if people really care about whether refs/remotes/origin/HEAD shortens to origin/HEAD or origin. I'm guessing that people _do_ depend on the reverse - having origin expand into refs/remotes/origin/HEAD, so we probably cannot rip out the refs/remotes/%.*s/HEAD rule altogether... Oh, no doubt about that reverse conversion. The real reason nobody cared about refs/remotes/origin/HEAD is that nobody sane has anything but non-symbolic ref there. Your t1514 does this: ... git update-ref refs/master master_d test_commit master_e ...oops, I see I forgot the trailing on this line. Do you want a resend, or fix up yourself? git update-ref refs/remotes/origin/HEAD master_e ... Nowhere in the set-up sequence, you see anything that does git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master or any other branch we copied from the remote. Correct. I first did a git remote set-head origin master, but quickly discovered that rev-parse resolved the symref as part of --abbrev-ref, so I had to fake up a non-symref to trigger the shortening logic I wanted to test. And the shortening is done after dereferencing the symbolic ref. Because of this, refs/remotes/origin/HEAD usually resolves to origin/master, not origin. t/t1514-rev-parse-shorten-unambiguous-ref.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t1514-rev-parse-shorten-unambiguous-ref.sh b/t/t1514-rev-parse-shorten-unambiguous-ref.sh index fd87ce3..556ad16 100755 --- a/t/t1514-rev-parse-shorten-unambiguous-ref.sh +++ b/t/t1514-rev-parse-shorten-unambiguous-ref.sh @@ -76,4 +76,11 @@ test_expect_success 'shortening refnames in loose mode' ' test_shortname refs/tags/master loose tags/master master_c ' +test_expect_success 'shortening is done after dereferencing a symref' ' + git update-ref refs/remotes/frotz/master master_e + git symbolic-ref refs/remotes/frotz/HEAD refs/remotes/frotz/master + test_shortname refs/remotes/frotz/HEAD strict frotz/master master_e + test_shortname refs/remotes/frotz/HEAD loose frotz/master master_e +' + test_done True. I'm not sure whether that's a feature or a bug in --abbrev-ref, probably a feature. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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 v4 0/2] New @ shortcut for HEAD
Hi, Same patches as before, except that the cleanup ones are in a different series, and this one doesn't depend on the other one. Felipe Contreras (2): sha1_name: refactor reinterpret() Add new @ shortcut for HEAD Documentation/git-check-ref-format.txt | 2 ++ Documentation/revisions.txt| 3 ++ refs.c | 4 +++ sha1_name.c| 59 +++--- t/t1508-at-combinations.sh | 2 ++ 5 files changed, 51 insertions(+), 19 deletions(-) -- 1.8.3.rc0.401.g45bba44 -- 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 v4 1/2] sha1_name: refactor reinterpret()
This code essentially replaces part of ref with another ref, for example
'@{-1}@{u}' is replaced with 'master@{u}', but this can be reused for
other purposes other than nth prior checkouts.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_name.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..fd2a95a 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -966,6 +966,27 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
return st;
}
+static int reinterpret(const char *name, int namelen, int len, struct strbuf
*buf)
+{
+ /* we have extra data, which might need further processing */
+ struct strbuf tmp = STRBUF_INIT;
+ int used = buf-len;
+ int ret;
+
+ strbuf_add(buf, name + len, namelen - len);
+ ret = interpret_branch_name(buf-buf, tmp);
+ /* that data was not interpreted, remove our cruft */
+ if (ret 0) {
+ strbuf_setlen(buf, used);
+ return len;
+ }
+ strbuf_reset(buf);
+ strbuf_addbuf(buf, tmp);
+ strbuf_release(tmp);
+ /* tweak for size of {-N} versus expanded ref name */
+ return ret - used + len;
+}
+
/*
* This reads short-hand syntax that not only evaluates to a commit
* object name, but also can act as if the end user spelled the name
@@ -999,25 +1020,8 @@ int interpret_branch_name(const char *name, struct strbuf
*buf)
return len; /* syntax Ok, not enough switches */
if (0 len len == namelen)
return len; /* consumed all */
- else if (0 len) {
- /* we have extra data, which might need further processing */
- struct strbuf tmp = STRBUF_INIT;
- int used = buf-len;
- int ret;
-
- strbuf_add(buf, name + len, namelen - len);
- ret = interpret_branch_name(buf-buf, tmp);
- /* that data was not interpreted, remove our cruft */
- if (ret 0) {
- strbuf_setlen(buf, used);
- return len;
- }
- strbuf_reset(buf);
- strbuf_addbuf(buf, tmp);
- strbuf_release(tmp);
- /* tweak for size of {-N} versus expanded ref name */
- return ret - used + len;
- }
+ else if (0 len)
+ return reinterpret(name, namelen, len, buf);
cp = strchr(name, '@');
if (!cp)
--
1.8.3.rc0.401.g45bba44
--
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 v4 2/2] Add new @ shortcut for HEAD
Typing 'HEAD' is tedious, especially when we can use '@' instead.
The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-check-ref-format.txt | 2 ++
Documentation/revisions.txt| 3 +++
refs.c | 4
sha1_name.c| 17 +
t/t1508-at-combinations.sh | 2 ++
5 files changed, 28 insertions(+)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index ec1739a..e8035ec 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -54,6 +54,8 @@ Git imposes the following rules on how references are named:
. They cannot contain a sequence `@{`.
+. They cannot be the single character `@`.
+
. They cannot contain a `\`.
These rules make it easy for shell script based tools to parse
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index d477b3f..09896a3 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -58,6 +58,9 @@ the '$GIT_DIR/refs' directory or from the
'$GIT_DIR/packed-refs' file.
While the ref name encoding is unspecified, UTF-8 is preferred as
some output processing may assume ref names in UTF-8.
+'@'::
+ '@' alone is a shortcut for 'HEAD'.
+
'refname@\{date\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
A ref followed by the suffix '@' with a date specification
enclosed in a brace
diff --git a/refs.c b/refs.c
index de2d8eb..4e70b3e 100644
--- a/refs.c
+++ b/refs.c
@@ -72,6 +72,10 @@ int check_refname_format(const char *refname, int flags)
{
int component_len, component_count = 0;
+ if (!strcmp(refname, @))
+ /* Refname is a single character '@'. */
+ return -1;
+
while (1) {
/* We are at the start of a path component. */
component_len = check_refname_component(refname, flags);
diff --git a/sha1_name.c b/sha1_name.c
index fd2a95a..dd30c7c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -966,6 +966,17 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
return st;
}
+/* parse @something syntax, when 'something' is not {.*} */
+static int interpret_empty_at(const char *name, int namelen, int len, struct
strbuf *buf)
+{
+ if (len || name[1] == '{')
+ return -1;
+
+ strbuf_reset(buf);
+ strbuf_add(buf, HEAD, 4);
+ return 1;
+}
+
static int reinterpret(const char *name, int namelen, int len, struct strbuf
*buf)
{
/* we have extra data, which might need further processing */
@@ -1026,9 +1037,15 @@ int interpret_branch_name(const char *name, struct
strbuf *buf)
cp = strchr(name, '@');
if (!cp)
return -1;
+
+ len = interpret_empty_at(name, namelen, cp - name, buf);
+ if (len 0)
+ return reinterpret(name, namelen, len, buf);
+
tmp_len = upstream_mark(cp, namelen - (cp - name));
if (!tmp_len)
return -1;
+
len = cp + tmp_len - name;
cp = xstrndup(name, cp - name);
upstream = branch_get(*cp ? cp : NULL);
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index d5d6244..277a1a2 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -45,6 +45,8 @@ check @{u} upstream-two
check @{u}@{1} upstream-one
check @{-1}@{u} master-two
check @{-1}@{u}@{1} master-one
+check @ new-two
+check @@{u} upstream-two
nonsense @{u}@{-1}
nonsense @{1}@{u}
--
1.8.3.rc0.401.g45bba44
--
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 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
Johan Herland jo...@herland.net writes: ...oops, I see I forgot the trailing on this line. Do you want a resend, or fix up yourself? I've pushed out a heavily fixed-up version on 'pu', mostly for styles and some log message changes to describe when it is not a symref. -- 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 00/11] sha1_name: improvements
On Tue, May 7, 2013 at 4:55 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
While trying to add support for the @ shortcut lots of cleanups arised. Here
they are in a single series.
Felipe Contreras (7):
tests: at-combinations: simplify setup
tests: at-combinations: check ref names directly
tests: at-combinations: improve nonsense()
sha1_name: remove no-op
sha1_name: remove unnecessary braces
sha1_name: avoid Yoda conditions
sha1_name: reorganize get_sha1_basic()
Ramkumar Ramachandra (4):
tests: at-combinations: increase coverage
tests: at-combinations: @{N} versus HEAD@{N}
sha1_name: don't waste cycles in the @-parsing loop
sha1_name: check @{-N} errors sooner
When merging this series to the @ shortcut one, there will be
conflicts, this is how I propose fixing them:
return len; /* syntax Ok, not enough switches */
- if (0 len len == namelen)
+ if (len 0 len == namelen)
return len; /* consumed all */
- else if (0 len)
...
++ else if (len 0)
+ return reinterpret(name, namelen, len, buf);
- check @ new-two
- check @@{u} upstream-two
...
++check @ ref refs/heads/new-branch
++check @@{u} ref refs/heads/upstream-branch
If that creates some kind of problem I would rather throw away this
series rather than the other one.
Cheers.
--
Felipe Contreras
--
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 1/3] fast-{import,export}: use get_sha1_hex() directly
On Tue, May 7, 2013 at 9:38 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
It's wrong to call get_sha1() if they should be SHA-1s, plus
inefficient.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
It appears that they should be SHA-1s assumption does not hold;
this patch breaks at least 3303, 9020, and 9300.
Also assuming these are always 40-hex goes directly against what is
documented in Documentation/git-fast-import.txt (look for Here
committish is any of the following). My bad while reviewing the
earlier round.
I've redone 'pu' (which was failing the test last night) after
dropping this and keeping only patches 2 and 3 from the series.
Turns out most of the get_sha1() calls were correct; this does the trick:
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 18fdfb3..d1d68e9 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -623,7 +623,7 @@ static void import_marks(char *input_file)
mark = strtoumax(line + 1, mark_end, 10);
if (!mark || mark_end == line + 1
- || *mark_end != ' ' || get_sha1(mark_end + 1, sha1))
+ || *mark_end != ' ' || get_sha1_hex(mark_end + 1, sha1))
die(corrupt mark line: %s, line);
if (last_idnum mark)
diff --git a/fast-import.c b/fast-import.c
index 5f539d7..3f32149 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1822,7 +1822,7 @@ static void read_marks(void)
*end = 0;
mark = strtoumax(line + 1, end, 10);
if (!mark || end == line + 1
- || *end != ' ' || get_sha1(end + 1, sha1))
+ || *end != ' ' || get_sha1_hex(end + 1, sha1))
die(corrupt mark line: %s, line);
e = find_object(sha1);
if (!e) {
--
Felipe Contreras
--
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/7] t7900: Start testing usability of namespaced remote refs
Johan Herland jo...@herland.net writes: That said, I could have a go at using refs/peers/* instead of refs/remotes/*, and see how that works out. Hmm, I had refs/track/ in mind. Perhaps peers may work as well. If it sticks, how pervasive do we want this renaming to be? I guess we don't want to rename the git remote command to git peer just yet. If we were to do this, I would expect that the transition would be similar to the way we introduced the separate remote layout. The effort was started at around v1.3.0 era and we allowed the users to choose the layout when they make a new clone for quite some time, until we made it the default at v1.5.0 boundary, IIRC. Let the user opt into using the new layout first, and then if the new layout turns out to be vastly more useful than the current one, then the userbase will welcome it as the new default (and otherwise, it won't become the new default). We _should_ be able to tell the layout being used by checking which of refs/peers/ or refs/remotes/ is populated, but I do not mind if we added core.remoteLayout configuration variable that explicitly tells us which, if such an explicit clue turns out necessary. -- 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 p4 submit failing
I reset all the files to be lf. I also forced all the windows users IDEs to use Unix endings. I haven't seen that error since then Thanks for the assistance On Thu, Apr 18, 2013 at 7:43 PM, Pete Wyckoff p...@padd.com wrote: christopher.yee...@gmail.com wrote on Thu, 18 Apr 2013 11:24 -0500: The issue is caused by the line endings. I retested the problem with a different file and in this case, the error is caused by the line endings of the file checked out in the perforce workspace being win-style crlf, and the line endings of the file in the git repo being unix style lf. (In this scenario, I took out the .gitattributes, core.autocrlf was set to false and LineEnd was set to share) In this case, I checked out the file in perforce, ran dos2unix against it, and submitted that, then ran git p4 submit and it worked. I noticed that the error is caused by the git apply failing in the def applyCommit(self, id) function at lines 1296-1305. diffcmd = git format-patch -k --stdout \%s^\..\%s\ % (id, id) patchcmd = diffcmd + | git apply tryPatchCmd = patchcmd + --check - applyPatchCmd = patchcmd + --check --apply - patch_succeeded = True if os.system(tryPatchCmd) != 0: fixed_rcs_keywords = False patch_succeeded = False print Unfortunately applying the change failed! So most likely in git apply command, it can't find the changes because of the line endings being different between them. I couldn't find a parameter that would magically make it work. When I added --verbose to git apply the output only says: error: while searching for: and then the first lines of the first diff That seems like exactly the correct diagnosis of the problem. What to do about it, I'm not so sure. We could suggest that people use the same line-ending conventions in both git and p4 land. This is easy if they are both lf. But, if crlf is preferred, do you know how to configure git to use crlf line endings? Does that fix it? There's also the config setting apply.ignorewhitespace; not sure if that would allow the apply step to apply an lf-ending patch to the crlf-ending p4 workspace. -- Pete Hello Simon, I have CCed you to alert you to the possible bug. Any assistance would be appreciated. On Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: Yes this is the case. Many of the files have crlf endings. core.autocrlf was recently set to input. I can't remember the timeline exactly though, but in addition to this, I have a .gitattributes file with the default set to text=auto (* text=auto) and the php files set to text eol=lf (*.php text eol=lf) Also my perforce workspace's LineEnd setting is set to Share. I've experienced the behavior in both .php and .xml files though Before all of this started I had core.autocrlf set to false, and no .gitattributes file and perforce workspace's LineEnd was set to the default, but I got a conflict where the only difference was the line endings, so I changed things to the way they are now. Any recommendations? Should I change everything back the way it was? On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff p...@padd.com wrote: l...@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100: Just a thought, but check the files that are failing to see if they've got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all sorts of nasty problems. That's assuming it's definitely not a CRLF line ending problem on Windows. I had recently debugged a similar-looking problem where core.autocrlf was set to input. Christopher, if you have this set and/or the .xml files have ^M (CRLF) line endings, please let us know. -- Pete On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: I tried running git p4 submit on a repo that I've been running as an interim bridge between git and perforce. Multiple people are using the repo as a remote and its being periodically submitted back to perforce. It's been working mostly fine. Then one day out of the blue I get this error. I can no longer push any git commits to perforce. (This is from the remote repo which I am pushing back to perforce) user@hostname:~/Source/code$ git p4 submit -M --export-labels Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying ffa390f comments in config xml files //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit
Re: [PATCH 1/7] shorten_unambiguous_ref(): Allow shortening refs/remotes/origin/HEAD to origin
On Wed, May 8, 2013 at 12:06 AM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: ...oops, I see I forgot the trailing on this line. Do you want a resend, or fix up yourself? I've pushed out a heavily fixed-up version on 'pu', mostly for styles and some log message changes to describe when it is not a symref. Looks good to me. Thanks! -- Johan Herland, jo...@herland.net www.herland.net -- 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
3 way merge during git p4 rebase is attempting to reapply past commits
Hello, I have a setup where I have a remote non-bare repo cloned from a perforce workspace. It is used as a remote repo that people clone into their own user repos, make commits to, then push back into the remote repo. Then I periodically run the following commands in a script to push those changes back to perforce. git checkout -f git clean -f git p4 rebase --import-labels git p4 submit -M --export-labels git checkout -f git clean -f Sometimes, always after commits from one user's machine specifically, I get the following error below when pushing back to perforce at the remote repo. It seems to happen randomly, or at least intermittently, since I often can't discern any major error during git committing to the remote repo that precipitates this error. It does happen pretty reliably when I get a file conflict that I resolve and fix during committing though. Performing incremental import into refs/remotes/p4/master git branch Depot paths: //depot/sub/folder/ No changes to import! Rebasing the current branch onto remotes/p4/master First, rewinding head to replay your work on top of it... Applying: A commit that has already been made previously Applying: A second commit that has already been made in a previous commit Using index info to reconstruct a base tree... stdin:15: space before tab in indent. a line of text stdin:24: space before tab in indent. another line of text stdin:25: space before tab in indent. a third line of text stdin:33: trailing whitespace. a forth line of text stdin:71: trailing whitespace. warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. Falling back to patching base and 3-way merge... Auto-merging file from second CONFLICT (content): Merge conflict in a/file/in/the/second/pre-existing/commit/file.php Auto-merging a/file/in/the/second/pre-existing/commit/file.php Failed to merge in the changes. Patch failed at 0002 A second commit that has already been made in a previous commit When you have resolved this problem run git rebase --continue. If you would prefer to skip this patch, instead run git rebase --skip. To check out the original branch and stop rebasing run git rebase --abort. Traceback (most recent call last): File /usr/lib/git-core/git-p4, line 3373, in module main() File /usr/lib/git-core/git-p4, line 3367, in main if not cmd.run(args): File /usr/lib/git-core/git-p4, line 3150, in run return self.rebase() File /usr/lib/git-core/git-p4, line 3167, in rebase system(git rebase %s % upstream) File /usr/lib/git-core/git-p4, line 183, in system raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'git rebase remotes/p4/master' returned non-zero exit status 1 The patch is usually one that is already in the remote git repo and in perforce. At that point I have to run git rebase --skip, to skip the patch, then rerun the commands in the script again. Sometimes it's multiple patches that cause this problem and I have to run git rebase --skip repeatedly. When I check the working copy of the remote repo, I don't see any changes, no conflict markers, just the file. The real problem happens when I run git rebase --continue. Usually I end up with repeated submits in perforce when I do that, which is obviously a corruption of data. It sounds a lot like this error, except I don't know how git p4 is branching, so I don't know how to diagnose it. http://stackoverflow.com/questions/4033009/git-rebase-conflicts-keep-blocking-progress I also asked stack overflow and someone there said it's probably the perforce user being different from the git user info, so I had all the git users switch to having the same info as the perforce user info and that did NOT solve the problem. http://stackoverflow.com/questions/16106900/git-p4-rebase-attempts-to-reapply-past-commits I'm not sure what could possibly be causing this or how to fix it. Does anyone have any ideas? Thanks Christopher Yee Mon -- 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 1/3] fast-{import,export}: use get_sha1_hex() directly
Felipe Contreras felipe.contre...@gmail.com writes: Turns out most of the get_sha1() calls were correct; this does the trick: diff --git a/builtin/fast-export.c b/builtin/fast-export.c index 18fdfb3..d1d68e9 100644 --- a/builtin/fast-export.c +++ b/builtin/fast-export.c @@ -623,7 +623,7 @@ static void import_marks(char *input_file) mark = strtoumax(line + 1, mark_end, 10); if (!mark || mark_end == line + 1 - || *mark_end != ' ' || get_sha1(mark_end + 1, sha1)) + || *mark_end != ' ' || get_sha1_hex(mark_end + 1, sha1)) die(corrupt mark line: %s, line); if (last_idnum mark) diff --git a/fast-import.c b/fast-import.c index 5f539d7..3f32149 100644 --- a/fast-import.c +++ b/fast-import.c @@ -1822,7 +1822,7 @@ static void read_marks(void) *end = 0; mark = strtoumax(line + 1, end, 10); if (!mark || end == line + 1 - || *end != ' ' || get_sha1(end + 1, sha1)) + || *end != ' ' || get_sha1_hex(end + 1, sha1)) This is where --import-marks is handled, and we should be seeing :markid SHA-1 one per each line (according to Documentation/git-fast-import.txt). So this one should be get_sha1_hex(). The other one in fast-export.c would be the same. The other ones in the original patch were reading from the fast-import stream and shouldn't have insisted on 40-hex. Will replace the body of the change with only these two hunks and requeue. 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
[PATCH] remote-bzr: fix for disappeared revisions
It's possible that the previous tip goes away, we should not assume it's always present. Fortunately we are only using it to calculate the progress to display to the user, so only that needs to be fixed. Also, add a test that triggers this issue. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-bzr | 15 ++ contrib/remote-helpers/test-bzr.sh| 37 +++ 2 files changed, 48 insertions(+), 4 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 0ef30f8..3e452af 100755 --- a/contrib/remote-helpers/git-remote-bzr +++ b/contrib/remote-helpers/git-remote-bzr @@ -282,9 +282,13 @@ def export_branch(repo, name): branch.lock_read() revs = branch.iter_merge_sorted_revisions(None, tip, 'exclude', 'forward') -tip_revno = branch.revision_id_to_revno(tip) -last_revno, _ = branch.last_revision_info() -total = last_revno - tip_revno +try: +tip_revno = branch.revision_id_to_revno(tip) +last_revno, _ = branch.last_revision_info() +total = last_revno - tip_revno +except bzrlib.errors.NoSuchRevision: +tip_revno = 0 +total = 0 for revid, _, seq, _ in revs: @@ -353,7 +357,10 @@ def export_branch(repo, name): progress = (revno - tip_revno) if (progress % 100 == 0): -print progress revision %d '%s' (%d/%d) % (revno, name, progress, total) +if total: +print progress revision %d '%s' (%d/%d) % (revno, name, progress, total) +else: +print progress revision %d '%s' (%d) % (revno, name, progress) branch.unlock() diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh index cec55f1..3f417ad 100755 --- a/contrib/remote-helpers/test-bzr.sh +++ b/contrib/remote-helpers/test-bzr.sh @@ -300,4 +300,41 @@ test_expect_success 'proper bzr repo' ' test_cmp ../expected actual ' +test_expect_success 'strip' ' + mkdir -p tmp cd tmp + test_when_finished cd .. rm -rf tmp + + ( + bzr init bzrrepo + cd bzrrepo + + echo one content + bzr add content + bzr commit -m one + + echo two content + bzr commit -m two + ) + + git clone bzr::$PWD/bzrrepo gitrepo + + ( + cd bzrrepo + bzr uncommit --force + + echo three content + bzr commit -m three + + echo four content + bzr commit -m four + bzr log --line | sed -e s/^[0-9]\+: // ../expected + ) + + (cd gitrepo + git fetch + git log --format=%an %ad %s --date=short origin/master ../actual) + + test_cmp actual expected +' + test_done -- 1.8.3.rc1.553.gac13664 -- 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-bzr: fix for disappeared revisions
On Tue, May 7, 2013 at 6:39 PM, Felipe Contreras felipe.contre...@gmail.com wrote: + (cd gitrepo + git fetch + git log --format=%an %ad %s --date=short origin/master ../actual) + + test_cmp actual expected Hmm: test_cmp expected actual -- Felipe Contreras -- 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] remote-helpers: trivial cleanup
The comment was copied from hg-fast-export, not used anymore. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-bzr | 1 - contrib/remote-helpers/git-remote-hg | 1 - 2 files changed, 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index c19ed0e..3604c7d 100755 --- a/contrib/remote-helpers/git-remote-bzr +++ b/contrib/remote-helpers/git-remote-bzr @@ -323,7 +323,6 @@ def export_branch(branch, name): count += 1 if (count % 100 == 0): print progress revision %s (%d/%d) % (revid, count, len(revs)) -print # repo.unlock() diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 06920f2..96ad30d 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -453,7 +453,6 @@ def export_ref(repo, name, kind, head): count += 1 if (count % 100 == 0): print progress revision %d '%s' (%d/%d) % (rev, name, count, len(revs)) -print # # make sure the ref is updated print reset %s/%s % (prefix, ename) -- 1.8.3.rc1.553.gac13664 -- 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
Please pull updates for Git 1.8.3 l10n round 2
Hi Junio, The following changes since commit 7e6a0cc47da79dd22c0338aee8750fda92ced5d9: git-completion.bash: add remote.pushdefault to config list (2013-04-29 09:57:47 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 4dcdc3d8ccfb7e6ae3a2d151b5df59785548a040: l10n: zh_CN.po: translate 44 messages (2080t0f0u) (2013-05-08 08:13:32 +0800) Jiang Xin (3): l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed) Merge remote-tracking branch 'vi-vnwildman/master' l10n: zh_CN.po: translate 44 messages (2080t0f0u) Peter Krefting (1): l10n: Update Swedish translation (2080t0f0u) Ralf Thielow (1): l10n: de.po: translate 44 new messages Tran Ngoc Quan (1): l10n: Update Vietnamese translation (2080t0f0u) po/de.po| 1328 ++- po/git.pot | 1175 +--- po/sv.po| 1268 po/vi.po| 1290 + po/zh_CN.po | 1258 +++ 5 files changed, 3650 insertions(+), 2669 deletions(-) -- Jiang Xin -- 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 v6 4/7] git-clean: use a git-add-interactive compatible UI
2013/5/7 Junio C Hamano gits...@pobox.com: What is this message trying to achieve? self review??? A bit puzzled Maybe I should send a new rerolled patch series after this. Yesterday I wanted to wait for a while to see suggestions and reviews from others. -- Jiang Xin -- 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: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)
On 05/07/2013 10:27 AM, Torsten Bögershausen wrote: On 2013-05-04 01.14, Junio C Hamano wrote: Cygwin portability; both were reviewed by Jonathan, and the tip one seems to want a bit further explanation. Needs positive report from Cygwin 1.7 users who have been on 1.7 to make sure it does not regress for them. I was trying to verify that cygwin 1.7 is still Ok, but got puzzled. Running the test suite under cygwin doesn't seem to work any more (?): Scenario 1: The PC is running alone, and goes into the screen saver. Pressing CTRL-ALT-DEL didn't get any effect. Scenario 2: The PC didn't react any more, when the test suite was run in background. In 3 or 4 cases the PC needed to be reboot hardly. Using the commits before and after this change makes the test suite hang as well at some point, then it hangs somewhere at TC 3000--4000. Scenario 4: The I disabled the screensaver, upgdated cygwin, and went back to an older commit: The latest run from commit 52d63e70, April 28, hangs in TC 5500, ok 26 clone shallow object count. I can see 2 times git.exe pull --depth 4 ..A Scenario 5: The run of today 1.8.3-rc1, hangs in t5510, some git.exe are running fetch. (or pull) It seems as if some process/exes are not terminated in the way it should be. I will try on a different machine, comments are wellcome /Torsten I have run into very similar problems trying to test these patches, so I declined to reply thinking someone else might have better or at least explicable results. I am able to build git on cygwin 1.7 using the proposed patches, it seems to work, but I've run into strange problems such as the main git repo becoming corrupted, no idea how or why. Mark -- 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: Please pull updates for Git 1.8.3 l10n round 2
Jiang Xin worldhello@gmail.com writes: Hi Junio, The following changes since commit 7e6a0cc47da79dd22c0338aee8750fda92ced5d9: git-completion.bash: add remote.pushdefault to config list (2013-04-29 09:57:47 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 4dcdc3d8ccfb7e6ae3a2d151b5df59785548a040: l10n: zh_CN.po: translate 44 messages (2080t0f0u) (2013-05-08 08:13:32 +0800) Thanks, will pull. -- 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
stdout versus stderr for cmd line git
I have been building some automated patching scripts to update multiple servers at once from our dev host. In doing so I ran into some oddities with linux command line GIT version 1.8.0-rc0, so a couple minor revisions behind. First, a git pull puts the list of branches updated onto stderr. These are not errors and should be on stdout. E.g. Filtered error: From git host:service-framework Filtered error:017f911..b1f72db patching - origin/patching Ok, we can filter that out. But worse is that actual errors in a pull request are sent to stdout instead of standard error. For example, merge conflicts or pull failures because you have unstaged changes. For now I have to merge all stdout to stderr on my git requests in my patching script, then filter the results to find the real errors. Can we please make it so all actual errors appear on stderr, but not non-errors? If this was fixed in 1.8.2 latest, please forgive as I am running fast and furious to get this available tonight. 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] remote-bzr: fix for disappeared revisions
Felipe Contreras felipe.contre...@gmail.com writes: On Tue, May 7, 2013 at 6:39 PM, Felipe Contreras felipe.contre...@gmail.com wrote: + (cd gitrepo + git fetch + git log --format=%an %ad %s --date=short origin/master ../actual) + + test_cmp actual expected Hmm: test_cmp expected actual Yeah, right. -- 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: 3 way merge during git p4 rebase is attempting to reapply past commits
On 08/05/13 00:12, Christopher Yee Mon wrote: Hello, I have a setup where I have a remote non-bare repo cloned from a perforce workspace. It is used as a remote repo that people clone into their own user repos, make commits to, then push back into the remote repo. Why is your p4 clone non-bare? I thought pushing into a non-bare repo tended to cause problems? Then I periodically run the following commands in a script to push those changes back to perforce. % man cron :-) git checkout -f git clean -f git p4 rebase --import-labels git p4 submit -M --export-labels git checkout -f git clean -f Sometimes, always after commits from one user's machine specifically, I get the following error below when pushing back to perforce at the remote repo. It seems to happen randomly, or at least intermittently, since I often can't discern any major error during git committing to the remote repo that precipitates this error. It does happen pretty reliably when I get a file conflict that I resolve and fix during committing though. Performing incremental import into refs/remotes/p4/master git branch Depot paths: //depot/sub/folder/ No changes to import! Rebasing the current branch onto remotes/p4/master First, rewinding head to replay your work on top of it... Applying: A commit that has already been made previously Applying: A second commit that has already been made in a previous commit Using index info to reconstruct a base tree... stdin:15: space before tab in indent. a line of text stdin:24: space before tab in indent. another line of text stdin:25: space before tab in indent. a third line of text stdin:33: trailing whitespace. a forth line of text stdin:71: trailing whitespace. warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. Falling back to patching base and 3-way merge... Auto-merging file from second CONFLICT (content): Merge conflict in a/file/in/the/second/pre-existing/commit/file.php Auto-merging a/file/in/the/second/pre-existing/commit/file.php Failed to merge in the changes. Patch failed at 0002 A second commit that has already been made in a previous commit When you have resolved this problem run git rebase --continue. If you would prefer to skip this patch, instead run git rebase --skip. To check out the original branch and stop rebasing run git rebase --abort. Traceback (most recent call last): File /usr/lib/git-core/git-p4, line 3373, inmodule main() File /usr/lib/git-core/git-p4, line 3367, in main if not cmd.run(args): File /usr/lib/git-core/git-p4, line 3150, in run return self.rebase() File /usr/lib/git-core/git-p4, line 3167, in rebase system(git rebase %s % upstream) File /usr/lib/git-core/git-p4, line 183, in system raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'git rebase remotes/p4/master' returned non-zero exit status 1 The patch is usually one that is already in the remote git repo and in perforce. At that point I have to run git rebase --skip, to skip the patch, then rerun the commands in the script again. Sometimes it's multiple patches that cause this problem and I have to run git rebase --skip repeatedly. When I check the working copy of the remote repo, I don't see any changes, no conflict markers, just the file. The real problem happens when I run git rebase --continue. Usually I end up with repeated submits in perforce when I do that, which is obviously a corruption of data. It sounds a lot like this error, except I don't know how git p4 is branching, so I don't know how to diagnose it. http://stackoverflow.com/questions/4033009/git-rebase-conflicts-keep-blocking-progress I also asked stack overflow and someone there said it's probably the perforce user being different from the git user info, so I had all the git users switch to having the same info as the perforce user info and that did NOT solve the problem. http://stackoverflow.com/questions/16106900/git-p4-rebase-attempts-to-reapply-past-commits I'm not sure what could possibly be causing this or how to fix it. Does anyone have any ideas? Thanks Christopher Yee Mon -- 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 -- 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-helpers: trivial cleanup
Felipe Contreras felipe.contre...@gmail.com writes: The comment was copied from hg-fast-export, not used anymore. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-bzr | 1 - contrib/remote-helpers/git-remote-hg | 1 - 2 files changed, 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index c19ed0e..3604c7d 100755 --- a/contrib/remote-helpers/git-remote-bzr +++ b/contrib/remote-helpers/git-remote-bzr @@ -323,7 +323,6 @@ def export_branch(branch, name): count += 1 if (count % 100 == 0): print progress revision %s (%d/%d) % (revid, count, len(revs)) -print # repo.unlock() THe above no longer is relevant, I think, after a39769995050 (remote-bzr: improve progress reporting, 2013-04-30). I'll apply only the hunk for remote-hg. diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 06920f2..96ad30d 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -453,7 +453,6 @@ def export_ref(repo, name, kind, head): count += 1 if (count % 100 == 0): print progress revision %d '%s' (%d/%d) % (rev, name, count, len(revs)) -print # # make sure the ref is updated print reset %s/%s % (prefix, ename) -- 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 02/11] tests: at-combinations: check ref names directly
Felipe Contreras felipe.contre...@gmail.com writes:
Some committishes might point to the same commit, but through a
different ref, that's why it's better to check directly for the ref,
rather than the commit message.
We can do that by calling rev-parse --symbolic-full-name, and to
differentiate the old from the new behavior we add an extra argument to
the check() helper.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
It is signed-off by Ram first but who is the author? You, or him?
t/t1508-at-combinations.sh | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 46e3f16..bd2d2fe 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -4,9 +4,14 @@ test_description='test various @{X} syntax combinations
together'
. ./test-lib.sh
check() {
-test_expect_${3:-success} $1 = $2
- echo '$2' expect
- git log -1 --format=%s '$1' actual
+test_expect_${4:-success} $1 = $3
+ if [ '$2' == 'commit' ]; then
+ echo '$3' expect
+ git log -1 --format=%s '$1' actual
+ else
+ echo '$3' expect
+ git rev-parse --symbolic-full-name '$1' actual
+ fi
Move the echo outside of if, and match the overall style.
echo '$3' expect
if test '$2' = commit
then
git log ...
else
git rev-parse ...
fi
test_cmp expect actual
}
@@ -35,14 +40,14 @@ test_expect_success 'setup' '
git branch -u upstream-branch new-branch
'
-check HEAD new-two
-check @{1} new-one
-check @{-1} old-two
-check @{-1}@{1} old-one
-check @{u} upstream-two
-check @{u}@{1} upstream-one
-check @{-1}@{u} master-two
-check @{-1}@{u}@{1} master-one
+check HEAD ref refs/heads/new-branch
+check @{1} commit new-one
+check @{-1} ref refs/heads/old-branch
+check @{-1}@{1} commit old-one
+check @{u} ref refs/heads/upstream-branch
+check @{u}@{1} commit upstream-one
+check @{-1}@{u} ref refs/heads/master
+check @{-1}@{u}@{1} commit master-one
nonsense @{u}@{-1}
nonsense @{1}@{u}
--
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 03/11] tests: at-combinations: improve nonsense()
Felipe Contreras felipe.contre...@gmail.com writes:
In some circumstances 'git log' might fail, but not because the @
parsing failed. For example: 'git rev-parse' might succeed and return a
bad object, and then 'git log' would fail.
The layer we want to test is revision parsing, so let's test that
directly.
Hmph, but
git rev-parse Makefile
would happily succeed if there happens to be Makefile in the
directory.
Are we expecting that they are always object names? If that is the
case, perhaps
git rev-parse --verify $1
would express the intention better.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t1508-at-combinations.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index bd2d2fe..2ea735e 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -17,7 +17,7 @@ test_expect_${4:-success} $1 = $3
}
nonsense() {
test_expect_${2:-success} $1 is nonsensical
- test_must_fail git log -1 '$1'
+ test_must_fail git rev-parse '$1'
}
fail() {
--
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 00/11] sha1_name: improvements
Felipe Contreras felipe.contre...@gmail.com writes:
When merging this series to the @ shortcut one, there will be
conflicts, this is how I propose fixing them:
return len; /* syntax Ok, not enough switches */
- if (0 len len == namelen)
+ if (len 0 len == namelen)
return len; /* consumed all */
- else if (0 len)
...
++ else if (len 0)
+ return reinterpret(name, namelen, len, buf);
- check @ new-two
- check @@{u} upstream-two
...
++check @ ref refs/heads/new-branch
++check @@{u} ref refs/heads/upstream-branch
The resolution for the tests wrapper that acquired an extra
parameter matches what I did locally. Thanks for a merge sanity
check.
I didn't see any conflicts on the sha1_name.c side, but I applied
the Yoda thing slightly differently to result in a slightly more
streamlined codeflow:
if (!len) {
return len;
} else if (len 0) {
if (len == namelen)
return len;
else
return reinterpret(...);
}
which I think shows the choices better.
Although I haven't looked at the largest one (10/11) carefully,
everything else looked quite straightforward and readable.
I am not very happy about how $n parameters are quoted in t1508,
but that suboptimal quoting were there before this series, and I'd
consider it outside of the scope for now.
Will queue. 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
