Hi, On Wed, 14 Feb 2007, Mark Levedahl wrote: > Johannes Schindelin wrote: > > This is not necessary. You should do this instead: > > > > . git-sh-setup > > > I debated that, it seemed a wash but can do. It makes things easier, doesn't it? > > Throughout git, we seem to do both "--output=<bla>" _and_ "--output <bla>" > > forms, or just the latter. > > > Patches gratefully accepted for that. This exceeds my skills in bash: I can > do that in python, C, or other languages, but in bash I am working through a > list that is a part of $* an arg at a time with no ability to look at the > next, which is what this needs. Unless of course bash arrays are part of > portable shell (not sure on that). Ah, I just realized that you do not shift. This is wrong. For example, git bundle --output=a1 a..b would pass "--output=a1 a..b" to git-rev-parse. While you say "--revs-only", this would work, but so would "these are no refs". You lose valuable information that way (namely invalid parameters). The standard shell way is nicely visible in git-tag.sh (see the while loop). It is basically while case "$#" in 0) break ;; esac do case "$1" in --output) # handle $1 (and check that you can write to it). ;; -*) usage ;; *) break esac done > > > +git-show-ref $refs > .gitBundleReferences > > > > > > > Would it not be better to say explicitely which refs are expected to be > > present already (they start with "^" in the output of `git-rev-parse`, but > > you would need to do a bit more work, since you cannot just take the > > symbolic names). > > > > Some general remarks: > > > > It would be so much nicer if you worked without temporary files (you > > could do that by starting the file with the refs, then have an empty > > line, and then just pipe the pack after that). > > > Originally, this was in python with zip file built in memory (no > temporaries). Sticking to portable shell makes many easy things really > hard. Not if you just pipe the two parts (refs & pack) into the output. Piping also allows for "--output -" meaning stdout... > > IMHO reliance on $(git fsck | grep ^missing) is not good. The file > > check might take very, very long, or use much memory. And you _can_ do > > better [*1*]. > > Good idea, but I think it is simpler to just keep the ^... output from > git-rev-parse and check that those exist. What you suggest below seems to > presume all bases are themselves references, which is not the case when > doing, for example, master~10..master. Not at all. I meant to verify that these _hashes_ exist as commits. Not necessarily refs. > > Also, your use of shallow is incorrect. If the boundary commits are > > present, you might just leave them as-are, but if they are not > > present, you have to mark them as shallow. Otherwise, you end up with > > a corrupt (not shallow) repository. > > > I have to say I do not understand what "mark them as shallow" means: can > you please enlighten me further? We have shallow clones. This means that you can mark commits as "fake root" commits, i.e. even if they have parents, they are treated as if they had no parents. You do this by adding the hashes of the shallow commits to .git/shallow. For a short description, search for "shallow" in Documentation/glossary.txt. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html