Re: Python extension commands in git - request for policy change
On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote: On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond e...@thyrsus.com wrote: Krzysztof Mazur krzys...@podlesie.net: What about embedded systems? git is also useful there. C and shell is everywhere, python is not. Supposing this is true (and I question it with regard to shell) if you tell me how you live without gitk and the Perl pieces I'll play that right back at you as your answer. gitk is unlikely to be used on an embedded system, the perl pieces more so. Currently even perl is used only for few very high level commands that are not really needed there. I think that python is ok for pieces that use perl now, but I think that it shouldn't be used for basic porcelain commands. I also don't think that we should prefer python over other languages and especially I don't think that some existing code should be rewritten to python. Even if python is really better, I think that the natural migration is much better. I have never understood why people complain about readability in perl. Just because it uses the ascii charset a bit more? You expect a mathematician or indeed any scientist to use special symbols to mean special things, why not programmers? Because some perl programmers really create write-only code, but the maintainer can just reject that code. It's not the language that create non-readable code, but the programmer. I think that the perl code in git is readable, at least is parts I've seen. Krzysiek -- 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] diff: Fixes shortstat number of files
Indeed stat seems to be broken on master by commit 74faaa16 from Linus Torvalds
There are three separated issues here:
- unmerged files are marked as interesting in stat and probably
shouldn't, with some patch like this:
data-is_interesting = p-status != 0;
if (!one || !two) {
data-is_unmerged = 1;
+ data-is_interesting = 0;
return;
}
By the way, I don't get the point of this code then:
else if (data-files[i]-is_unmerged) {
fprintf(options-file, %s, line_prefix);
show_name(options-file, prefix, name, len);
fprintf(options-file, Unmerged\n);
continue;
}
and
if (file-is_unmerged) {
/* Unmerged is 8 characters */
bin_width = bin_width 8 ? 8 : bin_width;
continue;
}
Are we ever supposed to print that ? I feel like it could be removed.
- Unmerged files are not filtered out in shortstat, thus counted
twice (addressed by the patch)
- no file has ever been filtered out of numstat, and probably should
the way it's done in stat. That is with something like this:
if (!data-files[i]-is_interesting
(added + deleted == 0)) {
continue;
}
Cheers,
Antoine Pelisse
-- Forwarded message --
From: Junio C Hamano gits...@pobox.com
Date: Mon, Nov 26, 2012 at 4:28 AM
Subject: Re: [PATCH] diff: Fixes shortstat number of files
To: Antoine Pelisse apeli...@gmail.com
Cc: git@vger.kernel.org
Antoine Pelisse apeli...@gmail.com writes:
Subject: Re: [PATCH] diff: Fixes shortstat number of files
Please replace Fixes with Fix at least (because our log messages
are written as if a patch is giving an order to the codebase, iow,
in imperative mood), but we would prefer to see a concrete
description on what is fixed, when we can. And in this case, I
think we can, perhaps:
diff: do not count unmerged paths twice in --shortstat/--numstat
or something.
There is a discrepancy between the last line of `git diff --stat`
and `git diff --shortstat` in case of a merge.
The unmerged files are actually counted twice, thus doubling the
value of file changed.
I think the current 'master' and upward is broken with respect to
this; I am consistently getting two entries for unmerged paths
across --stat, --shortstat and --numstat options (iow, not just
shortstat and numstat but the '--stat' seems to be broken as well).
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: Multiple threads of compression
Brandon Casey dixit: The number of threads that pack uses can be configured in the global or system gitconfig file by setting pack.threads. […] The other setting you should probably look at is pack.windowMemory which should help you control the amount of memory git uses while packing. Also look at core.packedGitWindowSize and core.packedGitLimit if your repository is really large. OK, thanks a lot! I can’t really say much about the repositories beforehand because it’s a generic code hosting platform, several instances of which we run at my employer’s place (I also run one privately now), and which is also run by e.g. Debian. But I’ll try to figure out some somewhat sensible defaults. Running 'git gc' with --aggressive should be as safe as running it without --aggressive. OK, thanks. But, you should think about whether you really need to run it more than once, or at all. When you use --aggressive, git will perform the […] Great explanation! I think that I’d want to run it once, after the repository has been begun to be used (probably not correct English but you know what I want to say), but have to figure out a way to do so… but I’ll just leave out the --aggressive from the cronjob then. Much appreciated, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- 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: Requirements for integrating a new git subcommand
Eric S. Raymond: and (b) include the removal of import-directories.perl in my integration patch. Yes, please. -- \\// Peter - http://www.softwolves.pp.se/ -- 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: Python extension commands in git - request for policy change
On 11/25/2012 11:44 PM, Eric S. Raymond wrote: Felipe Contreras felipe.contre...@gmail.com: According to the results of the last survey, our users do care about performance, so I don't think there's anything excessive about it. Are there any hidden costs in maintenance problems? I don't think so. Then you're either pretending or very naive. Three decades of experience as a C programmer tells me that C code at any volume is a *serious* maintainance problem relative to almost any language with GC. Prudent architects confine it is much as possible. Prudent architects also avoid rewrites as much as possible, since it's inevitable that bugs will be introduced that have been fixed in the official version. Personally, I think if you'd left your suggestion on It would be great to have guidelines for python scripts. I propose 2.6 as the minimum required python verison and left it at that, there would have been very little disagreement. The suggestion that things should be rewritten in python for some spurious long-term savings seems mostly designed to refuel everyone's favourite flamethrower, and you know as well as I do that it just won't happen unless there's at least a chance of some substantial technical benefits from doing so. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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] Fix bash completion when `egrep` is aliased to `egrep --color=always`
On Thu, Nov 22, 2012 at 02:55:21PM -0500, Marc Khouzam wrote:
On Thu, Nov 22, 2012 at 10:41 AM, Adam Tkac at...@redhat.com wrote:
Hello all,
attached patch fixes bash completion when `egrep` is aliased to `egrep
--color=always`.
To avoid any aliases, it may be better to use
\egrep
Good idea, thanks. Improved patch is attached.
Regards, Adam
This could be worthwhile for all utilities used by the script.
Just a thought.
Marc
Comments are welcomed.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
--
Adam Tkac, Red Hat, Inc.
From 255192296cd175fddcac2647447a66a0ca55b855 Mon Sep 17 00:00:00 2001
From: Adam Tkac at...@redhat.com
Date: Thu, 22 Nov 2012 16:34:58 +0100
Subject: [PATCH] If `egrep` is aliased, temporary disable it in
bash.completion
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac at...@redhat.com
Signed-off-by: Holger Arnold holge...@gmail.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0960acc..79073c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS= $'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
Re: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac at...@redhat.com wrote: Good idea, thanks. Improved patch is attached. It is custom on this list to mail the patches, rather than attaching them, so people can review your changes in-line. You can read more about it in in git/Documentation/SubmittingPatches. Cheers, Frans -- 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 0/7] New remote-bzr remote helper
On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. -- 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] fast-export: Allow pruned-references in mark file
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com writes: fast-export can fail because of some pruned-reference when importing a mark file. The problem happens in the following scenario: $ git fast-export --export-marks=MARKS master (rewrite master) $ git prune $ git fast-export --import-marks=MARKS master This might fail if some references have been removed by prune because some marks will refer to non-existing commits. Let's warn when we have a mark for a commit we don't know. Also, increment the last_idnum before, so we don't override the mark. Is this a safe and sane thing to do, and if so why? Could you describe that in the log message here? Why would fast-export try to export something that was pruned? Doesn't that mean it wasn't reachable? Essentially, if 'git rev-list $foo' can't possibly export this pruned object, why would 'git fast-export $foo' would? 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: [RFC] pack-objects: compression level for non-blobs
Add config pack.graphcompression similar to pack.compression. Applies to non-blob objects and if unspecified falls back to pack.compression. We may identify objects compressed with level 0 by their leading bytes. Use this to force recompression when the source and target levels mismatch. Limit its application to when the config pack.graphcompression is set. Signed-off-by: David Michael Barr b...@rr-dav.id.au (mailto:b...@rr-dav.id.au) --- builtin/pack-objects.c | 49 + 1 file changed, 45 insertions(+), 4 deletions(-) I started working on this just before taking a vacation, so it's been a little while coming. The intent is to allow selective recompression of pack data. For small objects/deltas the overhead of deflate is significant. This may improve read performance for the object graph. I ran some unscientific experiments with the chromium repository. With pack.graphcompression = 0, there was a 2.7% increase in pack size. I saw a 35% improvement with cold caches and 43% otherwise on git log --raw. I neglected to mention that this is a WIP. I get failures with certain repositories: fatal: delta size changed -- David Michael Barr -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Option to revert order of parents in merge commit
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote: Kacper Kornet drae...@pld-linux.org writes: The following patch is an attempt to implement this idea. I think revert is a wrong word (implying you have already done something and you are trying to defeat the effect of that old something), and you meant to say reverse (i.e. the opposite of normal) or something. You are right. Probably transpose is the best description what the patch really does. I am unsure about the usefulness of this, though. After completing a topic on branch A, you would merge it to your own copy of the integration branch (e.g. 'master') and try to push, which may be rejected due to non-fast-forwardness: $ git checkout master $ git merge A $ git push At that point, if you _care_ about the merge parent order, you could do this (still on 'master'): $ git fetch origin $ git reset --hard origin/master $ git merge A $ test test test $ git push With --reverse-parents, it would become: $ git pull --reverse-parents $ test test test $ git push which certainly is shorter and looks simpler. The workflow however would encourage people to work directly on the master branch, which is a bit of downside. Our developers work mainly on master branches. The project consists of many thousands independent git repositories, and at the given time a developer usually wants to make only one commit in the given repository and push his changes upstream. So he usually doesn't care to make a branch. Then after failed pushed, one needs to add creation and removal of temporary branch (see the commit message of the suggested patch). The possibility to do git pull --reverse-parent would make the life easier in this case. Is there any interaction between this pull --reverse-parents change and possible conflict resolution when the command stops and asks the user for help? For example, whom should --ours and -X ours refer to? Us, or the upstream? The change of order of parents happens at the very last moment, so ours in merge options is local version and theirs upstream. -- Kacper Kornet -- 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: Can I zip a git repo without losing anything?
On Mon, 26 Nov 2012 04:55:10 + Carl Smith carl.in...@gmail.com wrote: After suggesting using zip files to move our projects around, I was told that you can not zip a git repo without loosing all the history. This didn't make sense to me, but two people told me the same thing, so I wasn't sure. I think they may have been confusing the zipped file you can download from GitHub with a zipped git repo. If someone could put me straight on this, I'd really appreciate it. To amend the already provided answer -- if you need to move repos around using the sneakernet, the tool you should probably use is `git bundle`. -- 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
commit gone after merge - how to debug?
Hi, This looks really weird and I cannot explain why it occurs. Setup is as follows: - origin - mirror - local clone Reference repository is origin from where builds are done etc. Parallel to that, we keep a mirror that is synced manually (fetch/merge/push). I do this from my local clone (which is mostly just tracking origin and mirror, no local branches). What happened is that after a merge of mirror/master into local master, a commit (that also exists on origin/master) is lost. Lost as in: pre-merge: git log file modified by commit - commit shown in history git merge mirror/master - no conflicts git log file modified by commit - commit NOT shown in file history any more and file does not have this change Doing git log shows commit as being present in repository history. One interesting point is that one of the parents is previous merge commit of same branches. Unfortunately, I cannot open up repository for public access, but would appreciate any pointers how to debug this. git fsck finds some dangling blobs/commits, but no other warnings/errors, I can clone repo just fine, everything seams in order. How can I debug what the merge is doing? git version 1.7.12.1 on mac: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 Regards, Igor PS. please keep me in CC, I'm not on list -- 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: commit gone after merge - how to debug?
On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar igor.lau...@gmail.com wrote: git log file modified by commit - commit NOT shown in file history any more and file does not have this change does `git log --full-history file modified by commit` show the 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] fast-export: Allow pruned-references in mark file
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote: Is this a safe and sane thing to do, and if so why? Could you describe that in the log message here? Why would fast-export try to export something that was pruned? Doesn't that mean it wasn't reachable? Hello Junio, Hello Felipe, Actually the issue happened while using Felipe's branch with his git-remote-hg. Everything was going fine until I (or did it run automatically, I dont remember) ran git gc that pruned unreachable objects. Of course some of the branch I had pushed to the hg remote had been changed (most likely rebased). References no longer exists in the repository (cleaned by gc), but the reference still exists in mark file, as it was exported earlier. Thus the failure when git fast-export reads the mark file. Then, is it safe ? Updating the last_idnum as I do in the patch doesn't work because if the reference is the last, the number is going to be overwriten in the next run. From git point of view, I guess it is fine. The file is fully read at the beginning of fast-export and fully written at the end. The issue is more for git-remote-hg that keeps track of matches between git marks and hg commits. The marks are going to change and be overriden. It will most likely need to read the mark file to see if a ref has changed, and update it's dictionary. One of the solution I'm thinking of, is to update the mark file with marks of newly exported objects instead of recreating it, and let obsolete references in the file. But of course that is not acceptable. Cheers, Antoine -- 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: commit gone after merge - how to debug?
On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: The other related question being: does reading the section History Simplification in man git-log help? ;-) Somewhat, but it does not explain why the file no longer has that change. I can understand omitting history if end result is the same, but here it shouldn't be - I cannot find a commit that reversed that change, so the change should still be in after the merge? The file in question was not modified on mirror, nor was modified on origin after that change. -- 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: commit gone after merge - how to debug?
Igor Lautar igor.lau...@gmail.com writes: On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: The other related question being: does reading the section History Simplification in man git-log help? ;-) Somewhat, but it does not explain why the file no longer has that change. It still has, but it's not shown by git log file, probably because one of the parent of the merge commit introduces no change for this file, so one side of the merge is not needed to explain you how you went from the origin of time to the last commit. Try this: commit=sha1 of your merge commit # Show diff with first parent: git diff $commit $commit^1 # Show diff with second parent: git diff $commit $commit^2 I can understand omitting history if end result is the same, but here it shouldn't be - I cannot find a commit that reversed that change, so the change should still be in after the merge? revert is not the only situation that can lead to history simplification. I'm no expert in the domain, but I think if you did the same change in two branches, the merge will be candidate for history simplification. -- 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: commit gone after merge - how to debug?
On Mon, Nov 26, 2012 at 2:38 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Igor Lautar igor.lau...@gmail.com writes: Somewhat, but it does not explain why the file no longer has that change. It still has, but it's not shown by git log file, probably because one of the parent of the merge commit introduces no change for this file, so one side of the merge is not needed to explain you how you went from the origin of time to the last commit. No, the change is not there. See below. Try this: commit=sha1 of your merge commit # Show diff with first parent: git diff $commit $commit^1 # Show diff with second parent: git diff $commit $commit^2 Yes, change is shown in commit^2, but actual file after merge does not have it. I've double and triple checked, it is just not there. In the end, I've cherry-picked the same commit after the merge and change is applied. If change would be there after the merge, cherry-pick would not have anything to do (whole commit is a one line change in single file). So its not that the history is hidden, the change *is* missing after the merge. Is there anything else I can try to figure out why its missing (other than actually debugging git code/scripts)? Like debug output for each change being considered/merged in? Regards, Igor -- 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] fast-export: Allow pruned-references in mark file
On Mon, Nov 26, 2012 at 2:23 PM, Antoine Pelisse apeli...@gmail.com wrote: On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote: Is this a safe and sane thing to do, and if so why? Could you describe that in the log message here? Why would fast-export try to export something that was pruned? Doesn't that mean it wasn't reachable? Hello Junio, Hello Felipe, Actually the issue happened while using Felipe's branch with his git-remote-hg. Everything was going fine until I (or did it run automatically, I dont remember) ran git gc that pruned unreachable objects. Of course some of the branch I had pushed to the hg remote had been changed (most likely rebased). References no longer exists in the repository (cleaned by gc), but the reference still exists in mark file, as it was exported earlier. Thus the failure when git fast-export reads the mark file. Ah, I see, so these objects are _before_ fast-export tries to do anything, it's just importing the marks without any knowledge if these objects are going to be used in the export or not. If that's the case, I don't think it should throw a warning even just skip them. Then, in the actual export if some of these objects are referenced the export would fail anyway (but they won't). 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] fast-export: Allow pruned-references in mark file
If that's the case, I don't think it should throw a warning even just skip them. Removing the warning seems fine to me. Then, in the actual export if some of these objects are referenced the export would fail anyway (but they won't). Of course it will fail to export anything that requires the missing object. As they are unreachable, it will be hard to provide a ref that needs it anyway. On the other hand, I'm afraid that your file '.git/hg/remote/marks-hg' needs consistent references to mark. If a mark is removed, and then replaced by another object, can it break somehow git-remote-hg ? If not, I can provide a simpler patch. If it does, it will be more complicated. Cheers, Antoine -- 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: commit gone after merge - how to debug?
On Mon, Nov 26, 2012 at 3:03 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Your initial message was about the output of git log. Do you mean that the file, on the filesystem, does not have the line introduced by the commit? Yes, sorry if I was not clear enough. If so, check the content registered in the repository too: git show merge-commit:file-name Content shown is identical to the one in working copy, ie., it is missing one line change. git annotate file merge commit - shows that particular line as if it has originated from when the file was originally added to repo. git annotate file merge commit^2 - shows line as being modified by a commit done after file was added - ie., state I would expect after a merge -- 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: commit gone after merge - how to debug?
On Mon, Nov 26, 2012 at 3:19 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: What about git annotate file merge-commit^1? No change, line version goes back to when file was added. Was the merge completely automatic, or were there any conflict? No conflicts at all. In fact, that particular file was not touched by one side of merge, only by another. It seems like git ignored the change, but still recorded history (shown only with --full-history). -- 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-fetch does not work from .git subdirectory
Patrik Gornicz wrote: Just a hunch but your remote's location uses a relative path '../linux-2.6.git', perhaps git is messing up what the path is relative to. That makes sense. Git is looking at the URL and not realizing that it's relative to the home directory. [remote upstream] url = ../linux-2.6.git/ fetch = +refs/heads/*:refs/remotes/upstream/* Note sure what the fix will be though as it'll likely break existing repositories that use relative paths either way. Can you try an absolute path to see if that fixes thing? If I change that to [remote upstream] url = /home/b04825/git/linux-2.6.git/ fetch = +refs/heads/*:refs/remotes/upstream/* then everything works. IMHO, this is a bug in git. -- Timur Tabi Linux kernel developer at Freescale -- 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 v5 15/15] fast-export: don't handle uninteresting refs
Hi Junio, On Sun, 25 Nov 2012, Junio C Hamano wrote: From: Johannes Schindelin johannes.schinde...@gmx.de Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET) Message-ID: alpine.deb.1.00.1211021612320.7...@s15462909.onlinehome-server.info (which is $gmane/208946) that says: Note that $ git branch foo master~1 $ git fast-export foo master~1..master still does not update the foo ref, but a partial fix is better than no fix. If you changed your stance on the patch Sverre and I sent to fix this, we could get a non-partial fix for this. You wanted a fix for a bigger problem, though, which I am unwilling to fix because it is not my itch to scratch and I have to balance my time. Ciao, Johannes -- 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 5/5] git-send-email: allow edit invalid email address
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
In some cases the user may want to send email with Cc: line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
git-send-email.perl | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d42dca2..9996735 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
sub validate_address {
my $address = shift;
- if (!extract_valid_address($address)) {
+ while (!extract_valid_address($address)) {
print STDERR error: unable to extract a valid address from:
$address\n;
- $_ = ask(What to do with this address? ([q]uit|[d]rop): ,
- valid_re = qr/^(?:quit|q|drop|d)/i,
+ $_ = ask(What to do with this address? ([q]uit|[d]rop|[e]dit):
,
+ valid_re = qr/^(?:quit|q|drop|d|edit|e)/i,
default = 'q');
if (/^d/i) {
return undef;
@@ -862,6 +862,9 @@ sub validate_address {
cleanup_compose_files();
exit(0);
}
+ $address = ask(Who should the email be sent to (if any)? ,
+ default = ,
+ valid_re = qr/\@.*\./, confirm_only = 1);
Not having this new code inside elsif (/^e/) { } feels somewhat
sloppy, even though it is not *too* bad. Also do we know this
ok, I will fix that.
function will never be used for addresses other than recipients' (I
gave a cursory look to see what is done to the $sender and it does
not seem to go through this function, tho)?
Yes, this function is called only from validate_address_just()
to filter @initial_to, @initial_cc, @bcc_list as early as possible,
and filter @to and @cc added in each email.
Krzysiek
--
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 5/5] git-send-email: allow edit invalid email address
Krzysztof Mazur krzys...@podlesie.net writes:
In some cases the user may want to send email with Cc: line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
git-send-email.perl | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d42dca2..9996735 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
sub validate_address {
my $address = shift;
- if (!extract_valid_address($address)) {
+ while (!extract_valid_address($address)) {
print STDERR error: unable to extract a valid address from:
$address\n;
- $_ = ask(What to do with this address? ([q]uit|[d]rop): ,
- valid_re = qr/^(?:quit|q|drop|d)/i,
+ $_ = ask(What to do with this address? ([q]uit|[d]rop|[e]dit):
,
+ valid_re = qr/^(?:quit|q|drop|d|edit|e)/i,
default = 'q');
if (/^d/i) {
return undef;
@@ -862,6 +862,9 @@ sub validate_address {
cleanup_compose_files();
exit(0);
}
+ $address = ask(Who should the email be sent to (if any)? ,
+ default = ,
+ valid_re = qr/\@.*\./, confirm_only = 1);
Not having this new code inside elsif (/^e/) { } feels somewhat
sloppy, even though it is not *too* bad. Also do we know this
function will never be used for addresses other than recipients' (I
gave a cursory look to see what is done to the $sender and it does
not seem to go through this function, tho)?
--
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] fast-export: Allow pruned-references in mark file
Antoine Pelisse apeli...@gmail.com writes: On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote: Is this a safe and sane thing to do, and if so why? Could you describe that in the log message here? Why would fast-export try to export something that was pruned? Doesn't that mean it wasn't reachable? Hello Junio, Hello Felipe, Actually the issue happened while using Felipe's branch with his git-remote-hg. Everything was going fine until I (or did it run automatically, I dont remember) ran git gc that pruned unreachable objects. Of course some of the branch I had pushed to the hg remote had been changed (most likely rebased). References no longer exists in the repository (cleaned by gc), but the reference still exists in mark file, as it was exported earlier. Thus the failure when git fast-export reads the mark file. You described that part very well in your proposed log message and I got it just fine. Then, is it safe ? Updating the last_idnum as I do in the patch doesn't work because if the reference is the last, the number is going to be overwriten in the next run. From git point of view, I guess it is fine. The file is fully read at the beginning of fast-export and fully written at the end. I am not sure I follow the above, but anyway, I think the patch does is safe because (1) future fast-export will not refer to these pruned objects in its output (we have decided that these pruned objects are not used anywhere in the history so nobody will refer to them) and (2) we still need to increment the id number so that later objects in the marks file get assigned the same id number as they were assigned originally (otherwise we will not name these objects consistently when we later talk about them). And I wanted to see that kind of reasoning behind the patch in the proposed log message, because other people will need to refer to it when they read git log output to understand the change. 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 v5 15/15] fast-export: don't handle uninteresting refs
Johannes Schindelin johannes.schinde...@gmx.de writes: If you changed your stance on the patch Sverre and I sent to fix this, we could get a non-partial fix for this. This is long time ago so I may be misremembering the details, but I thought the original patch was (ab)using object flags to mark this was explicitly asked for, even though some other range operation may have marked it uninteresting. Because it predated the introduction of the rev_cmdline_info mechanism to record what was mentioned on the command line separately from what objects are uninteresting (i.e. object flags), it may have been one convenient way to record this information, but it still looked unnecessarily ugly hack to me, in that it allocated scarce object flag bits to represent a narrow special case (iirc, only a freestanding A on the command line but not A spelled in B..A, or something), making it more expensive to record other kinds of command line information in a way consistent with the approach chosen (we do not want to waste object flag bits in order to record this was right hand side tip of the symmetric difference range and such). If you are calling do not waste object flags to represent one special case among endless number of possibilities, as it will make it impossible to extend it my stance, that hasn't changed. We added rev_cmdline_info since then so that we can tell what refs were given from the command line in what way, and I thought that we applied a patch from Sverre that uses it instead of the object flags. Am I misremembering things? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Option to revert order of parents in merge commit
Kacper Kornet drae...@pld-linux.org writes: Is there any interaction between this pull --reverse-parents change and possible conflict resolution when the command stops and asks the user for help? For example, whom should --ours and -X ours refer to? Us, or the upstream? The change of order of parents happens at the very last moment, so ours in merge options is local version and theirs upstream. That may be something that wants to go to the proposed commit log message. I am neutral on the feature (i.e. not against it but not extremely enthusiastic about it either). 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: Long clone time after done.
Hi guys, Any further interest on this scalability problem or should I move on? Thanks, Uri On Thu, Nov 8, 2012 at 5:35 PM, Uri Moszkowicz u...@4refs.com wrote: I tried on the local disk as well and it didn't help. I managed to find a SUSE11 machine and tried it there but no luck so I think we can eliminate NFS and OS as significant factors now. I ran with perf and here's the report: ESC[31m69.07%ESC[m git /lib64/libc-2.11.1.so [.] memcpy ESC[31m12.33%ESC[m git prefix/git-1.8.0.rc2.suse11/bin/git [.] blk_SHA1_Block ESC[31m 5.11%ESC[m git prefix/zlib/local/lib/libz.so.1.2.5 [.] inflate_fast ESC[32m 2.61%ESC[m git prefix/zlib/local/lib/libz.so.1.2.5 [.] adler32 ESC[32m 1.98%ESC[m git /lib64/libc-2.11.1.so [.] _int_malloc ESC[32m 0.86%ESC[m git [kernel] [k] clear_page_c Does this help? Machine has 396GB of RAM if it matters. On Thu, Nov 8, 2012 at 4:33 PM, Jeff King p...@peff.net wrote: On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote: I ran git cat-file commit some-tag for every tag. They seem to be roughly uniformly distributed between 0s and 2s and about 2/3 of the time seems to be system. My disk is mounted over NFS so I tried on the local disk and it didn't make a difference. I have only one 1.97GB pack. I ran git gc --aggressive before. Ah. NFS. That is almost certainly the source of the problem. Git will aggressively mmap. I would not be surprised to find that RHEL4's NFS implementation is not particularly fast at mmap-ing 2G files, and is spending a bunch of time in the kernel servicing the requests. Aside from upgrading your OS or getting off of NFS, I don't have a lot of advice. The performance characteristics you are seeing are so grossly off of what is normal that using git is probably going to be painful. Your 2s cat-files should be more like .002s. I don't think there's anything for git to fix here. You could try building with NO_MMAP, which will emulate it with pread. That might fare better under your NFS implementation. Or it might be just as bad. -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] Fix typo in remote set-head usage
Antoine Pelisse apeli...@gmail.com writes:
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
---
This will also break all translation files, should I also send a patch
to update them ?
git grep -A2 -e 'remote set-head name' po/ tells me that we
already have both the correct variant and the broken one, and they
are both translated ;-) so I do not think we have much to worry
about the i18n fallout in this case, but thanks anyway for thinking
about it.
You would need to sign off your patch, but otherwise looks good to
me.
Thanks.
Cheers,
Antoine Pelisse
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..937484d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
};
static const char * const builtin_remote_sethead_usage[] = {
- N_(git remote set-head name (-a | -d | branch])),
+ N_(git remote set-head name (-a | -d | branch)),
NULL
};
--
1.7.9.5
--
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: commit gone after merge - how to debug?
On Mon, Nov 26, 2012 at 3:50 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: What's possible is that someone had already merged the branch containing new, got conflicts, and resolved it in favor of old somewhere in the history of your master branch. This is exactly what happened. I've actually found a merge of origin to mirror which reversed the change some time back and was subsequently merged back to origin later on. Most probably human error during merge. Interestingly, this was my first thought as well, but I've must have overlooked that particular merge the first time. Anyhow, it sorted now, many thanks for your help, Igor -- 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] makefile: hide stderr of curl-config test
Paul Gortmaker paul.gortma...@windriver.com writes: Currently, if you don't have curl installed, you will get $ make distclean 21 | grep curl /bin/sh: curl-config: not found /bin/sh: curl-config: not found /bin/sh: curl-config: not found /bin/sh: curl-config: not found /bin/sh: curl-config: not found $ The intent is not to alarm the user, but just to test if there is a new enough curl installed. However, if you look at search engine suggested completions, the above error messages are confusing people into thinking curl is a hard requirement. Good observation and identification of an issue to tackle. But why isn't the patch like this? PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p) + curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | sort -r | sed -ne 2p) ifeq $(curl_check) 070908 Removal of the reject old libcURL is logically a separate thing regardless of the alarming output from make, and it probably is better done as a separate step in a two-patch series. Doing things that way, when somebody objects to this: It wants to ensure curl is newer than 070908. The oldest machine I could find (RHEL 4.6) is 2007 vintage according to /proc/version data, and it has curl 070C01. saying that their installation still cares about older libcURL, we can still keep the remove alarming output from make bit. The failure here is to mask stderr in the test. However, since the chance of curl being installed, but too old is essentially nil, lets just check for existence and drop the ancient version threshold check, if for no other reason, than to simplifly the parsing of what the makefile is trying to do by humans. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com diff --git a/Makefile b/Makefile index 9bc5e40..56f55f6 100644 --- a/Makefile +++ b/Makefile @@ -1573,8 +1573,8 @@ else REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES) PROGRAM_OBJS += http-fetch.o PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p) - ifeq $(curl_check) 070908 + curl_check := $(shell curl-config --vernum 2/dev/null) + ifneq $(curl_check) ifndef NO_EXPAT PROGRAM_OBJS += http-push.o endif -- 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] push: return reject reasons via a mask
Chris Rorvick ch...@rorvick.com writes: Pass all rejection reasons back from transport_push(). The logic is simpler and more flexible with regard to providing useful feedback. Signed-off-by: Chris Rorvick ch...@rorvick.com --- Thanks for a reroll. I do not think they are masks, by the way. They are set of flags (i.e. a bitset). A bitset is often called a mask when it is used to mask a subset of bits in another bitset that has the real information, either to ignore irrelevant bits or to pick only the relevant bits from the latter. And your reject_mask is never used as a mask in this patch---it is the bitset that has the real information and it gets masked by constant masks like REJECT_NON_FF_HEAD. In any case, naming it as reject_mask is like calling a counter as counter_int. It is more important to name it after its purpose than after its type, and because this is to record the reasons why the push was rejected, rejection_reason might be a better name for it. -- 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 7/7] push: clarify rejection of update to non-commit-ish
Chris Rorvick ch...@rorvick.com writes: Pushes must already (by default) update to a commit-ish due the fast- forward check in set_ref_status_for_push(). But rejecting for not being a fast-forward suggests the situation can be resolved with a merge. Flag these updates (i.e., to a blob or a tree) as not forwardable so the user is presented with more appropriate advice. Signed-off-by: Chris Rorvick ch...@rorvick.com --- remote.c | 5 + 1 file changed, 5 insertions(+) diff --git a/remote.c b/remote.c index f5bc4e7..ee0c1e5 100644 --- a/remote.c +++ b/remote.c @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref) if (!o || o-type != OBJ_COMMIT) return 0; + /* new object must be commit-ish */ + o = deref_tag(parse_object(ref-new_sha1), NULL, 0); + if (!o || o-type != OBJ_COMMIT) + return 0; + I think the original code used ref_newer() which took commit-ish on both sides. With this code, the old must be a commit but new can be a tag that points at a commit? Why? -- 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 5/7] push: require force for refs under refs/tags/
Chris Rorvick ch...@rorvick.com writes: diff --git a/remote.c b/remote.c index 4a6f822..012b52f 100644 --- a/remote.c +++ b/remote.c @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, * * (1) if the old thing does not exist, it is OK. * - * (2) if you do not have the old thing, you are not allowed + * (2) if the destination is under refs/tags/ you are + * not allowed to overwrite it; tags are expected + * to be static once created + * + * (3) if you do not have the old thing, you are not allowed * to overwrite it; you would not know what you are losing * otherwise. * - * (3) if both new and old are commit-ish, and new is a + * (4) if both new and old are commit-ish, and new is a * descendant of old, it is OK. * - * (4) regardless of all of the above, removing :B is + * (5) regardless of all of the above, removing :B is * always allowed. */ We may want to reword (0) to make it clear that --force (and +A:B) can be used to defeat all the other rules. The updated logic in the patch looks sensible. Thanks. ... +test_expect_success 'push requires --force to update lightweight tag' ' + mk_test heads/master + mk_child child1 + mk_child child2 + ( + cd child1 + git tag Tag + git push ../child2 Tag + git push ../child2 Tag + file1 + git add file1 + git commit -m file1 + git tag -f Tag + test_must_fail git push ../child2 Tag + git push --force ../child2 Tag + git tag -f Tag + test_must_fail git push ../child2 Tag HEAD~ + git push --force ../child2 Tag + ) +' + -- 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] Fix typo in remote set-head usage
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..937484d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
};
static const char * const builtin_remote_sethead_usage[] = {
- N_(git remote set-head name (-a | -d | branch])),
+ N_(git remote set-head name (-a | -d | branch)),
NULL
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git bundle format
I may need to be nudged in a better direction, but please try to understand my intentions. I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1]. Given we have a public repository which was cloned on to a secret development repository. Now the developers do some work which should not be sensitive in any way and commit and push it to the secret repository. Now they want to release it out to the public. The current process is to review the text files to ensure that there is no secret sauce in there and then approve its release. This current process ignores the change tracking and all non-content is lost. In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the git-bundle2text program which would result in a human inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository. Am I barking up the right tree? 1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information 2: http://git-scm.com/book/ch9-4.html smime.p7s Description: S/MIME cryptographic signature
RE: git bundle format
Left off a citation to an old thread. -Original Message- From: Pyeron, Jason J CTR (US) Sent: Monday, November 26, 2012 2:25 PM I may need to be nudged in a better direction, but please try to understand my intentions. I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1]. Given we have a public repository which was cloned on to a secret development repository. Now the developers do some work which should not be sensitive in any way and commit and push it to the secret repository. Now they want to release it out to the public. The current process is to review the text files to ensure that there is no secret sauce in there and then approve its release. This current process ignores the change tracking and all non-content is lost. In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the git-bundle2text program which would result in a human inspectable format [3] as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository. Am I barking up the right tree? 1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information 2: http://git-scm.com/book/ch9-4.html 3: http://git.661346.n2.nabble.com/How-to-extract-files-out-of-a-quot-git-bundle-quot-no-matter-what-td1679188.html smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] fast-export: Allow pruned-references in mark file
I am not sure I follow the above, but anyway, I think the patch does is safe because (1) future fast-export will not refer to these pruned objects in its output (we have decided that these pruned objects are not used anywhere in the history so nobody will refer to them) and (2) we still need to increment the id number so that later objects in the marks file get assigned the same id number as they were assigned originally (otherwise we will not name these objects consistently when we later talk about them). I fully agree on (1), not so much on (2) though. I have the following behavior using my patch and running that script that doesn't look correct. echo Working scenario git init test (cd test git commit --allow-empty -m Commit mark :1 git commit --allow-empty -m Commit mark :2 git fast-export --export-marks=MARKS master /dev/null cat MARKS git reset HEAD~1 sleep 1 git reflog expire --all --expire=now git prune --expire=now git commit --allow-empty -m Commit mark :3 git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null cat MARKS) rm -rf test echo Non-working scenario git init test (cd test git commit --allow-empty -m Commit mark :1 git commit --allow-empty -m Commit mark :2 git fast-export --export-marks=MARKS master /dev/null cat MARKS git reset HEAD~1 sleep 1 git reflog expire --all --expire=now git prune --expire=now git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null git commit --allow-empty -m Commit mark :3 git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null cat MARKS) rm -rf test outputs something like this: Working scenario Initialized empty Git repository in /home/antoine/test/.git/ [master (root-commit) 6cf350d] Commit mark :1 [master 8f97f85] Commit mark :2 :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 :2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e [master 21cadfd] Commit mark :3 warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 :3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae Non-working scenario Initialized empty Git repository in /home/antoine/test/.git/ [master (root-commit) 5b5f7ec] Commit mark :1 [master b224390] Commit mark :2 :2 b224390daee199644495c15503882eb84df07df5 :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 warning: Could not read blob b224390daee199644495c15503882eb84df07df5 [master 181a774] Commit mark :3 :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 :2 181a7744c6d3428edb01a1adc9df247e9620be5f Both commit mark :2 and commit mark :3 end up being marked :2. Any tool like git-remote-hg that is using a mapping from mark - hg changeset could then 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: git-gui: textconv not used on unstaged files
On 2012-10-24 20:33, Peter Oberndorfer wrote: Hi, i am using a textconv filter to display .doc files as plain text. It seems git gui does not use this textconv filter for displaying new unstaged files (other files? = _O) It seems diff.tcl start_show_diff calls show_other_diff because of this. This manually loads the file and does not care about textconv filters. Is this manual loading really necessary or can't we just ask git? If it is can it be modified to use the textconv filter? Does anybody have a idea which git command would output the diff of a untracked file against /dev/null? So I can show the textconved version of the file in git gui. (and not reinvent the code to apply textconv already in git) Thanks, Greetings Peter .gitattributes: *.docdiff=astextplain gitconfig: [diff astextplain] textconv = astextplain -- 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 bundle format
Pyeron, Jason J CTR (US) jason.j.pyeron@mail.mil writes: In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the git-bundle2text program which would result in a human inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository. The bundle file is a thinly wrapped packfile, with extra information that tells what objects in the bundle are the tips of histories and what objects the repository the bundle gets unbundled has to have. So your git-bundle2text would likely to involve fetching from the bundle and inspecting the resulting history and the working tree files. -- 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] fast-export: Allow pruned-references in mark file
On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse apeli...@gmail.com wrote: I am not sure I follow the above, but anyway, I think the patch does is safe because (1) future fast-export will not refer to these pruned objects in its output (we have decided that these pruned objects are not used anywhere in the history so nobody will refer to them) and (2) we still need to increment the id number so that later objects in the marks file get assigned the same id number as they were assigned originally (otherwise we will not name these objects consistently when we later talk about them). I fully agree on (1), not so much on (2) though. I have the following behavior using my patch and running that script that doesn't look correct. echo Working scenario git init test (cd test git commit --allow-empty -m Commit mark :1 git commit --allow-empty -m Commit mark :2 git fast-export --export-marks=MARKS master /dev/null cat MARKS git reset HEAD~1 sleep 1 git reflog expire --all --expire=now git prune --expire=now git commit --allow-empty -m Commit mark :3 git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null cat MARKS) rm -rf test echo Non-working scenario git init test (cd test git commit --allow-empty -m Commit mark :1 git commit --allow-empty -m Commit mark :2 git fast-export --export-marks=MARKS master /dev/null cat MARKS git reset HEAD~1 sleep 1 git reflog expire --all --expire=now git prune --expire=now git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null git commit --allow-empty -m Commit mark :3 git fast-export --import-marks=MARKS \ --export-marks=MARKS master /dev/null cat MARKS) rm -rf test outputs something like this: Working scenario Initialized empty Git repository in /home/antoine/test/.git/ [master (root-commit) 6cf350d] Commit mark :1 [master 8f97f85] Commit mark :2 :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 :2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e [master 21cadfd] Commit mark :3 warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 :3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae Non-working scenario Initialized empty Git repository in /home/antoine/test/.git/ [master (root-commit) 5b5f7ec] Commit mark :1 [master b224390] Commit mark :2 :2 b224390daee199644495c15503882eb84df07df5 :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 warning: Could not read blob b224390daee199644495c15503882eb84df07df5 [master 181a774] Commit mark :3 :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 :2 181a7744c6d3428edb01a1adc9df247e9620be5f Both commit mark :2 and commit mark :3 end up being marked :2. Any tool like git-remote-hg that is using a mapping from mark - hg changeset could then fail. I don't understand. commit mark :2 'git fast-export' would never point to that object again, the new commit would override that mark: commit refs/heads/master mark :2 ... commit mark :3 Then 'git remote-hg' should override that mark as well. But it doesn't matter, because that would be the case only for the last object, as soon as you find another valid object, that object's mark will be considered the last one. And what Junio said is consistent with what you want: last_idnum should be updated even if the object is not valid. 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] fast-export: Allow pruned-references in mark file
Antoine Pelisse apeli...@gmail.com writes: I am not sure I follow the above, but anyway, I think the patch does is safe because (1) future fast-export will not refer to these pruned objects in its output (we have decided that these pruned objects are not used anywhere in the history so nobody will refer to them) and (2) we still need to increment the id number so that later objects in the marks file get assigned the same id number as they were assigned originally (otherwise we will not name these objects consistently when we later talk about them). I fully agree on (1), not so much on (2) though. ... Both commit mark :2 and commit mark :3 end up being marked :2. Any tool like git-remote-hg that is using a mapping from mark - hg changeset could then fail. Yeah, I think I agree that you would need to make sure that the other side does not use the revision marked with :2, once you retire the object you originally marked with :2 by pruning. Shouldn't the second export show :1 and :3 but not :2? It feels like a bug in the exporter to me that the mark number is reused in such a case. -- 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 bundle format
-Original Message- From: Felipe Contreras Sent: Monday, November 26, 2012 3:20 PM On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US) jason.j.pyeron@mail.mil wrote: I may need to be nudged in a better direction, but please try to understand my intentions. I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1]. snip/ Am I barking up the right tree? Have you tried 'git fast-export'? The output is definitely not human inspectable, but should be relatively easy to parse to generate such a format. And instead of 'git bundle unbundle' you could use 'git fast-import'. or simply do the conversion in your script. No. But I am going to read up on it today. It clearly says You can use it as a human-readable bundle replacement[4]. My initial question is does it ever use deltas? The repositories I just tested it on only seem to output full blobs (which is really nice from this use case point of view). -Jason 4: http://www.kernel.org/pub/software/scm/git/docs/git-fast-export.html smime.p7s Description: S/MIME cryptographic signature
RE: git bundle format
-Original Message- From: Junio C Hamano Sent: Monday, November 26, 2012 3:38 PM Pyeron, Jason J CTR (US) writes: In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the git-bundle2text program which would result in a human inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the *** Assumed that the inspector had a copy of the original public repo help of the public repository see how the data changes the repository. The bundle file is a thinly wrapped packfile, with extra information that tells what objects in the bundle are the tips of histories and what objects the repository the bundle gets unbundled has to have. So your git-bundle2text would likely to involve fetching from the bundle and inspecting the resulting history and the working tree files. Yea, I knew the inspection tool was going to get messy. -Jason smime.p7s Description: S/MIME cryptographic signature
Re: git-gui: textconv not used on unstaged files
Peter Oberndorfer kumbay...@arcor.de writes: Does anybody have a idea which git command would output the diff of a untracked file against /dev/null? The --no-index option is meant as a bolt-on to let you use various features of git diff that is missing from other people's diff in a context where git does not know anything about that file. It should be usable even outside a git repository. $ git diff --no-index /dev/null new-file.txt I do not know offhand (and didn't bother to check) if textconv applies, though. It does need access to a git repository as it reads from the $GIT_DIR/config to learn what to do. -- 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/4] git-submodule add: Add --local-branch option
From: W. Trevor King wk...@tremily.us
This option allows you to record a submodule.name.branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current consumers:
Ævar uses this setting to designate the local branch to checkout when
pulling submodule updates:
$ git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason ava...@gmail.com
Date: Fri May 21 16:10:10 2010 +
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Earlier version of this patch remained agnostic on the variable usage,
but this was deemed potentially confusing. Future patches in this
series will extend the submodule command to use the stored value
internally.
[1]
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King wk...@tremily.us
---
Documentation/git-submodule.txt | 12 ++--
Documentation/gitmodules.txt| 5 +
git-submodule.sh| 19 ++-
t/t7400-submodule-basic.sh | 25 +
4 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..d0b4436 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
- [--reference repository] [--] repository [path]
+'git submodule' [--quiet] add [-b branch] [--local-branch[=branch]]
+ [-f|--force] [--reference repository] [--] repository [path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -209,6 +209,14 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+--local-branch::
+ Record a branch name used as `submodule.path.branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form
+ (`--local-branch=branch`), not `--local-branch branch`.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 4effd78..840ccfe 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -47,6 +47,11 @@ submodule.name.update::
This config option is overridden if 'git submodule update' is given
the '--merge', '--rebase' or '--checkout' options.
+submodule.name.branch::
+ A local branch name for the submodule (to avoid headless operation).
+ Set with the --local-branch option to git submodule add, or
+ directly using git config.
+
submodule.name.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
submodule. If this option is also present in the submodules entry in
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..6eed008 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--reference repository] [--]
repository [path]
+USAGE=[--quiet] add [-b branch] [--local-branch[=branch]] [-f|--force]
[--reference repository] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference repository] [--merge] [--recursive] [--] [path...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+local_branch=
+local_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ --local-branch)
+ local_branch_empty=true
+ ;;
+ --local-branch=*)
+ local_branch=${1#*=}
+ ;;
-f | --force)
[PATCH v4 3/4] git-submodule update: Add --branch option
From: W. Trevor King wk...@tremily.us This allows users to checkout the current superproject-recorded-submodule-sha as a branch, avoiding the detached head state that the standard submodule update creates. This may be useful for the existing --rebase/--merge workflows which already avoid detached heads. It is also useful if you want easy tracking of upstream branches. The particular upstream branch to be tracked is configured locally with .git/modules/name/config. With the new option Ævar's suggested $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm odules submodule.$name.branch) git pull' reduces to a $ git submodule update --branch after each supermodule .gitmodules edit, and a $ git submodule foreach 'git pull' whenever you feel like updating the submodules. Your still on you're own to commit (or not) the updated submodule hashes in the superproject's .gitmodules. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/git-submodule.txt | 20 +++-- git-submodule.sh| 48 +-- t/t7406-submodule-update.sh | 50 - 3 files changed, 98 insertions(+), 20 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index d0b4436..34392a1 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -13,7 +13,7 @@ SYNOPSIS [-f|--force] [--reference repository] [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] @@ -136,11 +136,11 @@ init:: update:: Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. + checkout the commit specified in the index of the containing + repository. This will make the submodules HEAD be detached unless + `--branch`, `--rebase`, `--merge` is specified or the key + `submodule.$name.update` is set to `branch`, `rebase`, `merge` or + `none`. `none` can be overridden by specifying `--checkout`. + If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the @@ -207,7 +207,13 @@ OPTIONS -b:: --branch:: - Branch of repository to add as submodule. + When used with the add command, gives the branch of repository to + add as submodule. ++ +When used with the update command, checks out a branch named +`submodule.name.branch` (as set by `--local-branch`) pointing at the +current HEAD SHA-1. This is useful for commands like `update +--rebase` that do not work on detached heads. --local-branch:: Record a branch name used as `submodule.path.branch` in diff --git a/git-submodule.sh b/git-submodule.sh index c51b6ae..28eb4b1 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -8,7 +8,7 @@ dashless=$(basename $0 | sed -e 's/-/ /') USAGE=[--quiet] add [-b branch] [--local-branch[=branch]] [-f|--force] [--reference repository] [--] repository [path] or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...] or: $dashless [--quiet] init [--] [path...] - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] + or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--branch] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] [commit] [--] [path...] or: $dashless [--quiet] foreach [--recursive] command or: $dashless [--quiet] sync [--] [path...] @@ -539,6 +539,9 @@ cmd_update() -f|--force) force=$1 ;; + -b|--branch) + update=branch + ;; -r|--rebase) update=rebase ;; @@ -593,6 +596,7 @@ cmd_update() fi name=$(module_name $sm_path) || exit url=$(git config submodule.$name.url) + branch=$(git config submodule.$name.branch) if ! test -z $update
[PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'
From: W. Trevor King wk...@tremily.us --- git-submodule.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index 28eb4b1..f4a681c 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -640,7 +640,7 @@ Maybe you want to use 'update --init'?) subforce=-f fi - if test -z $nofetch + if test -z $nofetch -a $subsha1 != $sha1 then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. -- 1.8.0.3.g95edff1.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
RE: git bundle format [OT]
-Original Message- From: Stephen Bash Sent: Monday, November 26, 2012 3:56 PM - Original Message - From: Jason J CTR Pyeron (US) Sent: Monday, November 26, 2012 2:24:54 PM Subject: git bundle format I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1]. As someone who faced a similar situation in a previous life, I'll offer my $0.02, but I'm certainly not the technical expert here. Kind of what I am looking for as a side effect. Given we have a public repository which was cloned on to a secret development repository. Now the developers do some work which should not be sensitive in any way and commit and push it to the secret repository. Now they want to release it out to the public. The current process is to review the text files to ensure that there is no secret sauce in there and then approve its release. This current process ignores the change tracking and all non-content is lost. In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the git-bundle2text program which would result in a human inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository. Am I barking up the right tree? First, a shot out of left field: how about a patch based workflow? (similar to the mailing list, just replace email with sneakernet) Patches are plain text and simple to review (preferable to an opaque binary format?). This is to only address the accidental development on a high side. Using this or any process should come with shame or punishment for wasting resources/time by not developing on a low side to start with. But accepting reality there will be times where code and its metadata (commit logs, etc) will be created on a high side and should be brought back to the low side. Second, thinking about your proposed bundle-based workflow I have two questions I'd have to answer to be comfortable with the solution: 1) Does the binary bundle contain any sensitive information? Potentially, hence the review. If the reviewer cannot prove the data he is looking at then the presumption is yes. 2) Do the diffs applied to public repo contain any sensitive data? That is a great question. Can the change of code while neither the original or the resultant be secret while the change imply or demonstrate the secret. I think the answer is yes. Question 1 seems tricky to someone who knows *nothing* about the bundle format (e.g. me). Maybe some form of bundle2text can be vetted enough that everyone involved believes that there is no other information traveling with the bundle (if so, you're golden). Here I have to trust other experts. On the flip side, even if the bundle itself is polluted (or considered to be lacking proof to the contrary), if (2) is considered safe, the patching of the public repo could potentially be done on a sacrificial hard drive before pushing. The logistics are well established and here and now is not a place to go in to that. But the above is the crux of what I am trying to get at. Question 2 is relatively straight forward and lead me to the patch idea. I would: - Bundle the public repository - Init a new repo in the secure space from the public bundle - Fetch from the to-be-sanitized bundle into the new repo - Examine commits (diffs) introduced by branches in the to-be- sanitized bundle - Perhaps get a list of all the objects in the to-be-sanitized bundle and do a git-cat-file on each of them (if the bundle is assembled correctly it shouldn't have any unreachable objects...). This step may be extraneous after the previous. Here we would be missing the metadata that goes along with the commit. Especially the SHA sums. Thanks. -Jason smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
Hi Junio, On Mon, 26 Nov 2012, Junio C Hamano wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: If you changed your stance on the patch Sverre and I sent to fix this, we could get a non-partial fix for this. This is long time ago so I may be misremembering the details, but I thought the original patch was (ab)using object flags to mark this was explicitly asked for, even though some other range operation may have marked it uninteresting. Because it predated the introduction of the rev_cmdline_info mechanism to record what was mentioned on the command line separately from what objects are uninteresting (i.e. object flags), it may have been one convenient way to record this information, but it still looked unnecessarily ugly hack to me, in that it allocated scarce object flag bits to represent a narrow special case (iirc, only a freestanding A on the command line but not A spelled in B..A, or something), making it more expensive to record other kinds of command line information in a way consistent with the approach chosen (we do not want to waste object flag bits in order to record this was right hand side tip of the symmetric difference range and such). Good to know. I will find some time to look at rev_cmdline_info and patch my patch. If you are calling do not waste object flags to represent one special case among endless number of possibilities, as it will make it impossible to extend it my stance, that hasn't changed. We added rev_cmdline_info since then so that we can tell what refs were given from the command line in what way, and I thought that we applied a patch from Sverre that uses it instead of the object flags. Am I misremembering things? It does sound so familiar that I am intended to claim that you remember things correctly. Ciao, Johannes -- 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] Fix typo in remote set-head usage
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: git bundle format [OT]
- Original Message - From: Jason J CTR Pyeron (US) jason.j.pyeron@mail.mil Sent: Monday, November 26, 2012 4:06:59 PM Subject: RE: git bundle format [OT] First, a shot out of left field: how about a patch based workflow? (similar to the mailing list, just replace email with sneakernet) Patches are plain text and simple to review (preferable to an opaque binary format?). This is to only address the accidental development on a high side. Using this or any process should come with shame or punishment for wasting resources/time by not developing on a low side to start with. Ah, if only more of those I (previously) worked with thought as you do :) But accepting reality there will be times where code and its metadata (commit logs, etc) will be created on a high side and should be brought back to the low side. Using git format-patch and git am it's possible to retain the commit messages (and other associated metadata). But again, I'm not the expert on this :) I've made it work a few times to test patches from this list, but so far I've avoided serious integration into the mailing list workflow. 2) Do the diffs applied to public repo contain any sensitive data? That is a great question. Can the change of code while neither the original or the resultant be secret while the change imply or demonstrate the secret. I think the answer is yes. In actual fact I was thinking about the simple case where the result included an Eek! 3.1415926 cannot show up in this code! (sometimes that's easier to see in a diff than a full text blob). Obviously the first line of defense should catch such mistakes. But yes, your point is also a good one. I'd be hard pressed to argue that a particular series of commits leaks information on their own, but they can certainly corroborate other available information. Question 2 is relatively straight forward and lead me to the patch idea. I would: - Bundle the public repository - Init a new repo in the secure space from the public bundle - Fetch from the to-be-sanitized bundle into the new repo - Examine commits (diffs) introduced by branches in the to-be- sanitized bundle - Perhaps get a list of all the objects in the to-be-sanitized bundle and do a git-cat-file on each of them (if the bundle is assembled correctly it shouldn't have any unreachable objects...). This step may be extraneous after the previous. Here we would be missing the metadata that goes along with the commit. Especially the SHA sums. Ah sorry, I guess I wasn't complete. Once that process has been done on the high side one has to go back to question 1 and see if it's safe to move the bundle out to repeat the process on the low side. Stephen -- 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
Interesting git-format-patch bug
I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) This is should be one of those rare corner case don't do that occurrences. Unfortunately it does happen once in a while on our branches and it screws up some of the automated processes we rely on. Is there a way around that (other than don't) or can this be fixed? -- 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] Third try at documenting command integration requirements.
Junio C Hamano gits...@pobox.com: I'll reword the title (readers of git log output 6 months down the road will not care if this is the third try or the first one) and tweak things here and there before queuing. Result looks good from here. The next things on my git to-do list are 1. Audit the in-tree Python for version dependencies. Add floor-version checks. 2. Submit a doc patch containing guidelines that (a) Python scripts should check for their floor version and error out gracefully if they won't run with the host's interpreter, and (b) Python scripts sbould be 2.6-compatible. 3. Submit the git-weave integration patch. I could do that now, but while my regression test speaks TAP it doesn't presently use the test library. I plan to re-work it to do that. Do you have any other pending tasks for which you think my expertise would be useful? I refer specifically to the facts that (a) I find writing and editing documentation easy and can do it rapidly, (b) I'm a Python expert, and (c) I am very interested in, and know a lot about, tools for repository surgery and import/export. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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] Third try at documenting command integration requirements.
e...@thyrsus.com (Eric S. Raymond) writes:
@@ -0,0 +1,91 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git. It should be read alongside api-builtin.txt.
+
+== Runtime environment ==
+
+git subcommands are standalone executables that live in the git
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
--
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 v5 15/15] fast-export: don't handle uninteresting refs
On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: We added rev_cmdline_info since then so that we can tell what refs were given from the command line in what way, and I thought that we applied a patch from Sverre that uses it instead of the object flags. Am I misremembering things? It does sound so familiar that I am intended to claim that you remember things correctly. FWIW, I implemented that in http://thread.gmane.org/gmane.comp.version-control.git/184874 but didn't do the work to get it merged. -- Cheers, Sverre Rabbelier -- 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 00/11] alternative unify appending of sob
Brandon Casey draf...@gmail.com writes: So, this series should result in s-o-b and (cherry picked from...) being appended to commit messages in a more consistent and deterministic way. For example, the decision about whether to insert a blank line before appending a s-o-b. As discussed, cherry-pick and commit will only refrain from appending a s-o-b if the committer's s-o-b appears as the last one in a conforming footer, while format-patch will refrain from appending it if it appears anywhere within the footer. Sounds sensible; we may want to fix format-patch later, but with something like this series, it is just the matter of flipping one bit. 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
Re: [PATCH] Third try at documenting command integration requirements.
Junio C Hamano gits...@pobox.com:
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
Noted for the future, thank you.
--
a href=http://www.catb.org/~esr/;Eric S. Raymond/a
--
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 v5 15/15] fast-export: don't handle uninteresting refs
Sverre Rabbelier srabbel...@gmail.com writes: On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin johannes.schinde...@gmx.de wrote: We added rev_cmdline_info since then so that we can tell what refs were given from the command line in what way, and I thought that we applied a patch from Sverre that uses it instead of the object flags. Am I misremembering things? It does sound so familiar that I am intended to claim that you remember things correctly. FWIW, I implemented that in http://thread.gmane.org/gmane.comp.version-control.git/184874 but didn't do the work to get it merged. Ah, OK. Should I expect an updated series then? How would it interact with the recent work by Felipe? -- 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: Interesting git-format-patch bug
Olsen, Alan R alan.r.ol...@intel.com writes: I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) As you literally have patches that do essentially the same or similar things on two branches that was merged, you cannot expect to export each individual commit into a patch and not have conflicts among them. So I do not think there is no answer than don't do that. I think you could make your some other process that rewrites commits to cull the duplicates out of the format-patch output, though. Each output file identifies what commit object the patch came from, and your some other process that rewrote the commits ought to know which commit updated which other commit did, which is the piece of information needed to remove duplicates that format-patch does not have. -- 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 5/5] git-send-email: allow edit invalid email address
Krzysztof Mazur krzys...@podlesie.net writes:
Not having this new code inside elsif (/^e/) { } feels somewhat
sloppy, even though it is not *too* bad. Also do we know this
ok, I will fix that.
function will never be used for addresses other than recipients' (I
gave a cursory look to see what is done to the $sender and it does
not seem to go through this function, tho)?
Yes, this function is called only from validate_address_just()
to filter @initial_to, @initial_cc, @bcc_list as early as possible,
and filter @to and @cc added in each email.
Thanks; when merged to 'pu', this series seems to break t9001. I'll
push the result out with breakages but could you take a look?
Test Summary Report
---
t9001-send-email.sh (Wstat: 256 Tests: 102 Failed:
77)
Failed tests: 4-7, 9-10, 12-13, 15, 17-21, 23-29, 31-33
35, 37, 39, 41, 43, 45, 47, 49, 51-58, 61-88
91, 93-95, 98-102
Non-zero exit status: 1
--
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 p1.1 00/14] fast-export and remote-testgit improvements
Felipe Contreras felipe.contre...@gmail.com writes: On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I'm rerolling this series with the changes fron Junio, plus a bit more cleanups. I dropped the last patch, because I found an issue and a separate patch series would take care of that. Other than that the main changes remain the same. The old remote-testgit is now remote-testpy (as it's testing the python framework, not really remote helpers). The tests are simplified, and exercise more features of transport-helper, and unsuprisingly, find more bugs. Thanks. I've queued [v6 p1.1] but not later parts (yet). The result merged to 'pu' however seems to break t5800. It could be a stupid and trivial merge error or something, but I didn't look into the details. Yeah, the last patch triggers that. It should be moved to part2. The patch fast-export: don't handle uninteresting refs should fix that, which is why I believe it should be applied first. Didn't I already say that? You may have, but I am leaky ;-) as I am not 100% focused on this series alone. In the meantime, I'll drop the last one, push out the 'pu' branch after rebuilding, and then revisit it when I queue the part 2. 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: gitpacker progress report and a question
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
in fact already fixed the subdirectories bug (I've updated my
regression test to check) and have full support for branchy repos,
preserving tags and branch heads.
So you are criticizing my code saying it would then be almost
completely useless..., when this is in fact what you sent to the
list.
For the record, here is the output of a test with your script vs.
mine: the output is *exactly the same*:
---
== log ==
* afcbedc (tag: v0.2, master) bump
| * cbd2dce (devel) dev
|/
* 46f1813 (HEAD, test) remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 (tag: v0.1) one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/test
== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21 /home/felipec/Downloads/gitpacker.txt
Unpacking..(0.13 sec) done.
Packing..(0.28 sec) done.
== log ==
* 5d0b634 (HEAD, master) bump
* 2fe4a6d remove
* 0c27d3b dot .
* 5e36d3f with spaces
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/master
== script ==
33edcb28667b683fbb5f8782383f782f73c5e9e1 /home/felipec/bin/git-weave
== log ==
* afcbedc (HEAD, master) bump
* 46f1813 remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/test
---
Unfortunately, when I enable some testing stuff, this is what your
script throws:
---
== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21 /home/felipec/Downloads/gitpacker.txt
Unpacking..(0.17 sec) done.
Packing..(0.02 sec) done.
Traceback (most recent call last):
File /home/felipec/Downloads/gitpacker.txt, line 308, in module
git_pack(indir, outdir, quiet=quiet)
File /home/felipec/Downloads/gitpacker.txt, line 171, in git_pack
command += .join(map(lambda p: -p + commit_id[int(p)],parents))
File /home/felipec/Downloads/gitpacker.txt, line 171, in lambda
command += .join(map(lambda p: -p + commit_id[int(p)],parents))
IndexError: list index out of range
== log ==
fatal: bad default revision 'HEAD'
== files ==
fatal: tree-ish master not found.
== spaces ==
fatal: ambiguous argument ':/with': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
== dot ==
fatal: ambiguous argument ':/dot': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
== orig ref ==
refs/heads/master
---
I'm attaching it in case you are interested.
Anyway, I can add support for branches and tags in no time, but I
wonder what's the point. Who will take so much time and effort to
generate all the branches and tags, and the log file?
If the goal is as you say importing older projects that are available
only as sequences of release tarballs, then that code is overkill,
and it's not even making it easier to import the tarballs.
For that case my proposed format:
tag v0.1 gst-av-0.1.tar Release 0.1
tag v0.2 gst-av-0.2.tar Release 0.2
tag v0.3 gst-av-0.3.tar Release 0.3
Would be much more suitable.
It doesn't issue delete ops.
What do you mean?
out.puts 'deleteall' - All current files are removed
Yours emits no D ops for files removed after a particular snapshot.
man git fast-import
---
This command is extremely useful if the frontend does not know (or
does not care to know) what files are currently on the branch, and
therefore cannot generate the proper filedelete commands to update the
content.
---
Why would I want to emit D operations, again, deleteall takes care of that.
Be aware, however, that I consider easy editability by human beings
much more important than squeezing the last microsecond out of the
processing time. So, for example, I won't use data byte counts rather
than end delimiters, the way import streams do.
Well, if there's a line with a single dot in the commit message ('.'),
things would go very bad.
Apparently you missed the part where I byte-stuffed the message content.
It's a technique used in a lot of old-school Internet protocols, notably
in SMTP.
You might have done that, but the user that generated the log file
might have not.
Personally I would prefer something like this:
There's a certain elegance to that, but it would be hard to generate by hand.
You think this is hard to generate by hand:
---
tag v0.1 gst-av-0.1.tar Release 0.1
tag v0.2 gst-av-0.2.tar Release 0.2
tag v0.3 gst-av-0.3.tar Release 0.3
---
Than this?
---
commit 1
directory gst-av-0.1
Release 0.1
.
commit 2
directory gst-av-0.2
Release 0.2
.
commit 3
directory gst-av-0.3
Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com This example in the documentation seems to be trying to describe the likely remote tracking branch that will be updated by a push to the origin remote with the destination branch 'satellite/master', but it forgot to specify the remote name in the path specification. So, refs/remotes/satellite/master should be spelled like refs/remotes/origin/satellite/master I might make sense to rename 'origin' to 'mothership' in that example and explain that this is emulating 'git fetch' run on the mothership to integrate the work done on 'satellite' using 'git push' in the opposite direction, which is often necessary when you can only make connection in one way (i.e. satellite can ssh into mothership but mothership cannot initiate connection to satellite because the latter is behind a firewall or does not run sshd). If you were to run 'git fetch' on the mothership to intgrate the work on the 'satellite', it would have a remote called 'satellite', and would keep remote-tracking branches for the branches local to 'satellite' in the 'refs/remotes/satellite/' hierarchy. You would push your local 'master' to their 'refs/remotes/satellite/master', to emulate 'git fetch' done on the mothership in the reverse direction. So refs are correct. The context is not sufficiently explained. Signed-off-by: Brandon Casey bca...@nvidia.com --- Documentation/git-push.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index fe46c42..a18f929 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -387,8 +387,8 @@ the ones in the examples below) can be configured as the default for `git push origin master:satellite/master dev:satellite/dev`:: Use the source ref that matches `master` (e.g. `refs/heads/master`) to update the ref that matches `satellite/master` (most probably - `refs/remotes/satellite/master`) in the `origin` repository, then - do the same for `dev` and `satellite/dev`. + `refs/remotes/origin/satellite/master`) in the `origin` repository, + then do the same for `dev` and `satellite/dev`. `git push origin HEAD:master`:: Push the current branch to the remote ref matching `master` in the -- 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] Documentation: improve phrasing in git-push.txt
The current version contains the sentence: Further suppose that the other person already pushed changes leading to A back to the original repository you two obtained the original commit X. which doesn't parse for me; I've changed it to Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X. Signed-off-by: Mark Szepieniec mszep...@gmail.com --- Documentation/git-push.txt |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index fe46c42..6d19d59 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -286,7 +286,8 @@ leading to commit A. The history looks like this: Further suppose that the other person already pushed changes leading to A -back to the original repository you two obtained the original commit X. +back to the original repository from which you two obtained the original +commit X. The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward. -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
On 11/26/2012 5:30 PM, Junio C Hamano wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com This example in the documentation seems to be trying to describe the likely remote tracking branch that will be updated by a push to the origin remote with the destination branch 'satellite/master', but it forgot to specify the remote name in the path specification. So, refs/remotes/satellite/master should be spelled like refs/remotes/origin/satellite/master I might make sense to rename 'origin' to 'mothership' in that example and explain that this is emulating 'git fetch' run on the mothership to integrate the work done on 'satellite' using 'git push' in the opposite direction, which is often necessary when you can only make connection in one way (i.e. satellite can ssh into mothership but mothership cannot initiate connection to satellite because the latter is behind a firewall or does not run sshd). If you were to run 'git fetch' on the mothership to intgrate the work on the 'satellite', it would have a remote called 'satellite', and would keep remote-tracking branches for the branches local to 'satellite' in the 'refs/remotes/satellite/' hierarchy. You would push your local 'master' to their 'refs/remotes/satellite/master', to emulate 'git fetch' done on the mothership in the reverse direction. So refs are correct. The context is not sufficiently explained. Ah, I see. Yeah, I think that is complex enough to merit an extended explanation. -Brandon --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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] push: return reject reasons via a mask
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: Pass all rejection reasons back from transport_push(). The logic is simpler and more flexible with regard to providing useful feedback. Signed-off-by: Chris Rorvick ch...@rorvick.com --- In any case, naming it as reject_mask is like calling a counter as counter_int. It is more important to name it after its purpose than after its type Agreed. and because this is to record the reasons why the push was rejected, rejection_reason might be a better name for it. Yes, that is better for all the reasons you mention. I will fix this up. -- 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 7/7] push: clarify rejection of update to non-commit-ish
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: Pushes must already (by default) update to a commit-ish due the fast- forward check in set_ref_status_for_push(). But rejecting for not being a fast-forward suggests the situation can be resolved with a merge. Flag these updates (i.e., to a blob or a tree) as not forwardable so the user is presented with more appropriate advice. Signed-off-by: Chris Rorvick ch...@rorvick.com --- remote.c | 5 + 1 file changed, 5 insertions(+) diff --git a/remote.c b/remote.c index f5bc4e7..ee0c1e5 100644 --- a/remote.c +++ b/remote.c @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref) if (!o || o-type != OBJ_COMMIT) return 0; + /* new object must be commit-ish */ + o = deref_tag(parse_object(ref-new_sha1), NULL, 0); + if (!o || o-type != OBJ_COMMIT) + return 0; + I think the original code used ref_newer() which took commit-ish on both sides. That is still called later in set_ref_status_for_push() to calculate the nonfastforward flag. The only reason for even checking the new here is to exclude trees and blobs now so they are flagged as already-existing and thus avoid nonsensical fetch-and-merge advice. Otherwise the behavior is unchanged by this last patch. ref_newer() does end up redoing computation now done in the new is_forwardable() function. I could probably factor this out of ref_newer() into a commit_newer() function that could be reused in set_ref_status_for_push() to avoid this overhead, but it didn't seem like a big deal. Thoughts? With this code, the old must be a commit but new can be a tag that points at a commit? Why? The old must not be a tag because fast-forwarding from it is potentially destructive; a tag would likely be left dangling in this case. This is not true for the new, though. I'm not sure fast-forwarding from a commit to a tag is useful, but I didn't see a reason to prevent it either. The refs/tags/ hierarchy is excluded from fast-forwarding before this check, and refs/heads/ is already protected against anything but commits. So it seems very unlikely that someone would accidentally make use of this behavior. So, fast-forwarding to a tag seemed fairly benign and unlikely to cause confusion, so I leaned towards allowing it in case someone found a use case for it. -- 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] Support for git aliasing for tcsh completion
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
This issue was reported by someone already making use of the tcsh
completion script.
Thanks for considering this fix.
Marc
contrib/completion/git-completion.tcsh | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index dc5678c..44bd544 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -23,6 +23,12 @@
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+# Check that the user put the script in the right place
+if ( ! -e ${__git_tcsh_completion_original_script} ) then
+ echo git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work.
+ exit
+endif
+
cat EOF ${__git_tcsh_completion_script}
#!bash
#
@@ -34,13 +40,13 @@ cat EOF ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
# Set COMP_WORDS in a way that can be handled by the bash script.
-COMP_WORDS=(\$1)
+COMP_WORDS=(\$2)
# The cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
-if [ \${1: -1} == ]; then
+if [ \${2: -1} == ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=\${#COMP_WORDS[@]}
@@ -51,13 +57,12 @@ else
COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
fi
-# Call _git() or _gitk() of the bash script, based on the first
-# element of the command-line
-_\${COMP_WORDS[0]}
+# Call _git() or _gitk() of the bash script, based on the first argument
+_\${1}
IFS=\$'\n'
echo \${COMPREPLY[*]} | sort | uniq
EOF
-complete git 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE}`/'
-complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE}`/'
+complete git 'p/*/`bash ${__git_tcsh_completion_script} git
${COMMAND_LINE}`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script} gitk
${COMMAND_LINE}`/'
--
1.8.0.1.g9fe2839
--
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 5/7] push: require force for refs under refs/tags/
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: diff --git a/remote.c b/remote.c index 4a6f822..012b52f 100644 --- a/remote.c +++ b/remote.c @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, * * (1) if the old thing does not exist, it is OK. * - * (2) if you do not have the old thing, you are not allowed + * (2) if the destination is under refs/tags/ you are + * not allowed to overwrite it; tags are expected + * to be static once created + * + * (3) if you do not have the old thing, you are not allowed * to overwrite it; you would not know what you are losing * otherwise. * - * (3) if both new and old are commit-ish, and new is a + * (4) if both new and old are commit-ish, and new is a * descendant of old, it is OK. * - * (4) regardless of all of the above, removing :B is + * (5) regardless of all of the above, removing :B is * always allowed. */ We may want to reword (0) to make it clear that --force (and +A:B) can be used to defeat all the other rules. On that note, having (5) be regardless of all of the above ... seems a little awkward. That would seem to fit better towards the top. -- 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: Interesting git-format-patch bug
Junio C Hamano gits...@pobox.com wrote: Olsen, Alan R alan.r.ol...@intel.com writes: I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) As you literally have patches that do essentially the same or similar things on two branches that was merged, you cannot expect to export each individual commit into a patch and not have conflicts among them. So I do not think there is no answer than don't do that. To me, this seems to miss Alan's point: only one patch was merged to branch A, so git-format-patch applied to branch A should find only one patch. It can be argued either way whether that one-patch report should include the gerrit annotations, but surely the application of gerrit on branch B, _after the merge to branch A has already been performed_, should not cause an additional patch to magically appear on branch A. -- 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: difftool -d symlinks, under what conditions
On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
matthewlmccl...@gmail.com wrote:
I'm finding the behavior of `git difftool -d` surprising. It seems that it
only uses symlinks to the working copy for files that are modified in the
working copy since the most recent commit. I would have expected it to use
symlinks for all files whose version under comparison is the working copy
version, regardless of whether the working copy differs from the HEAD.
I'm using
$ git --version
git version 1.8.0
on a Mac from Homebrew.
cc:ing Tim since he probably remembers this feature.
This is a side-effect of how it's currently implemented,
and the general-purpose nature of the diff command.
diff can also be used for diffing arbitrary commits.
The simplest way to implement that is to create two temporary
directories containing a/ and b/ and then launch the tool
against them. That's what difftool does; it creates a temporary
index and uses `git checkout-index` to populate these two dirs.
The worktree handling is a bolt-on that symlinks
(or copies (on windows or with --no-symlinks)) modified
worktree files into one of these temporary directories.
When symlinks are used (the default) we avoid needing to
copy these files back into the worktree; we can blindly
remove the temporary directories without checking whether
the tool edited any files.
When copies are used we check their content for changes
before deciding to copy them back into the worktree.
Files that are not modified are not considered part of the
set of files to check when copying back, or when symlinking,
mostly because that's just how it's implemented right now.
It seems that there is an edge case here that we are not
accounting for: unmodified worktree paths, when checked out
into the temporary directory, can be edited by the tool when
comparing against older commits. These edits will be lost.
If we had a way to know that either a/ or b/ can be replaced
with the worktree itself then we could make it even simpler.
Right now we don't because difftool barely parses the
command-line at all; most of it is parsed by git-diff.
Originally, difftool was a read-only tool so it was able to
avoid needing to know too much about what diff is really doing.
We would need to a way to re-use git's diff command-line parsing
logic to answer: is the worktree involved in this diff invocation?
When we can do that then we avoid needing to have a temporary
directory altogether for any dir-diffs that involve the worktree.
Does anyone know of a good way to answer that question?
The input is the command-line provided to diff/difftool.
The output is one of ('a', 'b', 'x'), where 'a' means the left
side of the diff is the worktree, 'b' means the right side,
and 'x' means neither (e.g. the command-line contains two refs).
Assuming we can do this, it would also make dir-diff faster
since we can avoid needing to checkout the entire tree for
that side of the diff.
--
David
--
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: gitpacker progress report and a question
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
---
commit 1
directory foo-1.1
Release 1.1 of project foo
.
commit 2
directory foo-1.2
..This is an example of a byte-stuffed line.
Release 1.2 of project foo
.
commit 3
directory foo-1.3
Release 1.3 of project foo
.
---
The main objective of the logfile design is to make hand-crafting
these easy.
Here's another version with YAML:
---
-
author: me Felipe Contreras felipe.contre...@gmail.com
date: 2011-1-1
msg: one
- tag v0.1
-
author: *me
date: 2011-1-2
msg: extra
-
author: *me
date: 2011-1-3
msg: |
with
spaces
-
author: *me
date: 2011-1-4
msg: |
dot
.
-
author: *me
date: 2011-1-5
msg: remove
ref: remove
- checkout devel
-
author: *me
date: 2011-1-6
msg: dev
- checkout master
-
author: *me
date: 2011-1-7
msg: bump
- tag v0.2
- checkout test remove
---
I believe that log file is much more human readable. Yet I still fail
to see why would anybody want so much detail only to import tarballs.
diff --git a/contrib/weave/git-weave b/contrib/weave/git-weave
new file mode 100755
index 000..646aeaa
--- /dev/null
+++ b/contrib/weave/git-weave
@@ -0,0 +1,234 @@
+#!/usr/bin/env ruby
+
+require 'optparse'
+require 'find'
+require 'fileutils'
+require 'yaml'
+
+$last = nil
+$branches = {}
+$branch = 'master'
+$refs = {}
+
+class Commit
+
+ attr_reader :id, :parents, :author, :committer, :date, :msg, :ref
+
+ @@num = 0
+
+ def initialize(args)
+@id = @@num += 1
+@parents = []
+args.each do |key, value|
+ instance_variable_set(@#{key}, value)
+end
+if @author =~ /(.+ .+) (.+)/
+ @author = $1
+end
+if @committer =~ /(.+ .+) (.+)/
+ @committer = $1
+ @date = DateTime.strptime($2, '%s %z')
+end
+$refs[@ref] = @id if @ref
+ end
+
+end
+
+def export_commit(cmd, indir, out)
+
+ c = Commit.new(cmd)
+ $last = c.id
+
+ # commit
+ out.puts 'commit refs/heads/%s' % $branch
+ out.puts 'mark :%u' % c.id
+ if c.author and c.committer
+out.puts 'author %s %s' % [c.author, c.date.strftime('%s %z')]
+out.puts 'committer %s %s' % [c.committer, c.date.strftime('%s %z')]
+ else
+out.puts 'committer %s %s' % [c.author, c.date.strftime('%s %z')]
+ end
+ out.puts 'data %u' % c.msg.bytesize
+ out.puts c.msg
+
+ # parents
+ c.parents.each_with_index do |p, i|
+ref = $refs[p]
+if i == 0
+ out.puts 'from :%u' % ref
+else
+ out.puts 'merge :%u' % ref
+end
+ end
+
+ # files
+ out.puts 'deleteall'
+ FileUtils.cd(File.join(indir, c.id.to_s)) do
+Find.find('.') do |e|
+ next unless File.file?(e)
+ content = File.read(e)
+ filename = e.split(File::SEPARATOR).slice(1..-1).join(File::SEPARATOR)
+ if File.symlink?(e)
+mode = '12'
+content = File.readlink(e)
+ else
+mode = File.executable?(e) ? '100755' : '100644'
+ end
+ out.puts 'M %s inline %s' % [mode, filename]
+ out.puts 'data %u' % content.bytesize
+ out.puts content
+end
+ end
+ out.puts
+
+end
+
+def do_reset(out, ref, from)
+ out.puts reset %s % ref
+ out.puts from :%u % from
+ out.puts
+end
+
+def export_reset(cmd, indir, out)
+ _, ref, from = cmd.split
+ do_reset(out, ref, from)
+end
+
+def export_checkout(cmd, indir, out)
+ _, $branch, from = cmd.split
+ from = ':%u' % $last if not $branches[$branch]
+ do_reset(out, 'refs/heads/%s' % $branch, from) if from
+ $branches[$branch] = true
+end
+
+def export_tag(cmd, indir, out)
+ _, tag = cmd.split
+ do_reset(out, 'refs/tags/%s' % tag, $last)
+end
+
+def export(indir = '.', out = STDOUT)
+
+ $branches['master'] = true
+
+ YAML.load_file(File.join(indir, 'log')).each do |e|
+case e
+when Hash
+ export_commit(e, indir, out)
+when /^checkout /
+ export_checkout(e, indir, out)
+when /^tag /
+ export_tag(e, indir, out)
+when /^reset /
+ export_reset(e, indir, out)
+end
+ end
+
+end
+
+def import(outdir, out)
+ format = 'format:commit %H%nauthor %an %ae %ad%ncommitter %cn
%ce %cd%nparents %P%n%n%B'
+ cmd = ['git', 'log', '-z', '-s', '--date=raw', '--format=%s' %
format, '--reverse', '--all']
+ commits = {}
+
+ cmds = []
+
+ IO.popen(cmd).each_with_index(\0) do |data, i|
+@msg = nil
+@parents = []
+data.chomp(\0).each_line do |l|
+ if not @msg
+case l
+when /^commit (.+)$/
+ @id = $1
+when /^author (.+)$/
+ @author = $1
+when /^committer (.+)$/
+ @committer = $1
+when /^parents (.+)$/
+ @parents = $1.split( )
+when /^$/
+ @msg =
+end
+ else
+@msg l
+ end
+end
+
+num = i + 1
+commits[@id] = num
+
+cmds {
+ :author = @author,
+ :committer = @committer,
+ :msg = @msg,
+ :ref = num,
+ :parents =
Re: gitpacker progress report and a question
Felipe Contreras felipe.contre...@gmail.com: I believe that log file is much more human readable. Yet I still fail to see why would anybody want so much detail only to import tarballs. The first time I needed such a tool (and I really should have built it then) was during the events I wrote up in 2010 the INTERCAL Reconstruction Massacree; full story at http://esr.ibiblio.org/?p=2491 Note in particular the following paragraphs: Reconstructing the history of C-INTERCAL turned out to be something of an epic in itself. 1990 was back in the Dark Ages as far as version control and release-management practices go; our tools were paleolithic and our procedures likewise. The earliest versions of C-INTERCAL were so old that even CVS wasn’t generally available yet (CVS 1.0 didn’t even ship until six months after C-INTERCAL 0.3, my first public release). SCCS had existed since the early 1980s but was proprietary; the only game in town was RCS. Primitive, file-oriented RCS. I was a very early adopter of version control; when I wrote Emacs’s VC mode in 1992 the idea of integrating version control into normal workflow that closely was way out in front of current practice. Today’s routine use of such tools wasn’t even a gleam in anyone’s eye then, if only because disks were orders of magnitude smaller and there was a lot of implied pressure to actually throw away old versions of stuff. So I only RCSed some of the files in the project at the time, and didn’t think much about that. As a result, reconstructing C-INTERCAL’s history turned into about two weeks of work. A good deal of it was painstaking digital archeology, digging into obscure corners of the net for ancient release tarballs Alex and I didn’t have on hand any more. I ended up stitching together material from 18 different release tarballs, 11 unreleased snapshot tarballs, one release tarball I could reconstruct, one release tarball mined out of an obsolete Red Hat source RPM, two shar archives, a pax archive, five published patches, two zip files, a darcs archive, and my partial RCS history, and that’s before we got to the aerial photography. To perform the surgery needed to integrate this, I wrote a custom Python program assisted by two shellscripts, topping out at a hair over 1200 lines of code. The second time was much more recent and concerned a project called (seriously) robotfindskitten. This code existed as a partial CVS repository created by someone other than the original author, and some disconnected tarballs from before the repo. The author has requested that I knit the tarballs and the CVS history (which is now in git) into one repository. In both cases the object was to assemble a coherent history from all the available metadata as if the projects had been using version control all along. I know of at least one other group of disconnected tarballs, of a program called xlife, that is likely to need similar treatment. It's not an uncommon situation for projects over a certain age, and there is lots of code like xlife dating from before the mid-1990s waiting for someone to pick up the pieces. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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
Many ladies have already been fanatical search for tiffany uk
[url=http://www.cheaptiffanyjewellerysale.co.uk/]tiffany uk[/url] is certainly maintaining that will available your different singapore jewelry generates near to the universe so that the human beings with countless many section benefit your preferred specialist together with lesser tiffany jewelry. Any guests has got set up a great promote, and this is certainly super fast rising a new buyer immoral together with producing different behaviours. Any cir has got longer together with those periods there is end up viewed as a good trademark which unfortunately illustrates fantastic, results together with nibble. only one extremely conventional Tiffany picks happen to be funky tiffanies sounds, specialist tiffany hoops, tiffany ornament together with charms. Tiffany has got utilised any favors of each and every exclusive gal towards predicament together with establish countless defined style of necklace like conventional precious metal armlet that will precious metal jewelry necklace. http://www.cheaptiffanyjewellerysale.co.uk -- View this message in context: http://git.661346.n2.nabble.com/Many-ladies-have-already-been-fanatical-search-for-tiffany-uk-tp7572057.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: gitpacker progress report and a question
Felipe Contreras felipe.contre...@gmail.com: The main objective of the logfile design is to make hand-crafting these easy. Here's another version with YAML: Clever. Now I have to decide if I should allow my aesthetic dislike of YAML to prevail despite the fact that it's pretty well suited to this job. There is definitely a case for applying a standard metaprotocol like YAML (ugh) or XML (double ugh). -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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: Python extension commands in git - request for policy change
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras felipe.contre...@gmail.com wrote: And I don't agree that the project would be better off with something else, if it was, somebody would have proposed an alternative by now, but there aren't any. I have tried gitg, and giggle, and I have even contributed to them, but they are just not as good and useful as plain old gitk, I always keep coming back. gitk: * is blazing fast to start * doesn't have a lot of dependencies: just tcl/tk * works on Windows without a major fuzz * is actively maintained * shows a proper graph (unlike gitg or giggle) Now, show me an alternative that fulfills all these points. And I'm pretty sure you won't find one, because if you did, it would have been already proposed for mainline git... there isn't any. And if you did, we would start with oh, but it's GTK+, or it's Qt, and how do you make it work on Windows. No, gitk is just fine, and works great. Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern, but that only tells you how an awful job the modern toolkits have done with regards to portability and flexibility. You were arguing for portability, well, Tcl/Tk works on all platforms, here, have a look, there's no other tool that fulfills this: http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces *cough* git-cola *cough* it runs everywhere. Yes, windows too. It's written in python. It's been actively maintained since 2007. It's modern and has features that don't exist anywhere else. It even has tests. It even comes with a building full of willing guinea-pigs^Wtesters that let me know right away when anything goes wrong. It uses Qt but that's really the whole point of Qt - cross-platform. (not sure how that wiki page ended up saying Gnome/GTK?) The DAG aka git-dag (in its master branch, about to be released) is nicer looking then gitk IMO. gitk still has some features that are better too--there's no silver bullet, but the delta is pretty small. The only point this doesn't fulfill is dependency-free-ness. With that requirement the answer can *only* be tcl/tk. So saying, go look for one you won't find it is really a tautology. It's not even an entertaining one. http://xkcd.com/703/ When the requirement is, what is the best user experience possible, then you use a mature GUI library. These are different requirements and probably different use cases. For the gitk use case, gitk is the perfect tool. Anyways, just sayin', you make it sound like this stuff doesn't exist, but it does. I've never proposed it for mainline git because I'm very aware of the dependency requirements. But, if git recommended it I would very much appreciate the extra eyes and contributions. Being in mainline git could possibly help with that. A submodule under contrib/ would be an interesting experiment. In any case, I think documenting the python standards (even if within contrib/ only) is a good thing. We'd be increasing the overall portability by documenting what we support and sticking to it, just like what is done for shell scripts and perl versions. Eric is helping make that happen, let's not throw out the baby with the bathwater. FWIW, I would also make my python expertise available. This thread has gotten into meta-meta territory -- it's discussing code that has not yet even been written, and going off on all sorts of tangents. Let's stay on target. I think bringing up python as an extension language would help in a these key areas: - There are a few python modules floating around that are similar to the ruby grit library. Having an official python module would be good. - Commands on the edges of the git experience (GUIs, import/export/etc) can benefit from python. git-p4 is one example. git-weave is another. Are there any arguments against it for these use cases? BTW, Felipe, if you're going to be rewriting python code to ruby, please, pretty please rewrite that darn GUI ;-) You can call it git-new-cola: project kansas http://en.wikipedia.org/wiki/New_Coke I expect a patch by the morning ;-p I kid, of course, but if you do pull it off I WILL buy you a soda-pop! -- David -- 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
