Re: [RFC/PATCH 0/7] Rework git core for native submodules
From: "Ramkumar Ramachandra" Sent: Monday, April 08, 2013 10:03 PM This is going nowhere. You're stuck at making the current submodule system work, not answering my questions, diverting conversation, repeatedly asking the same stupid questions, labelling everything that I say "subjective", and refusing to look at the objective counterpart (aka, the code). It's clear to me that no matter how many more emails I write, you're not going to concede. I'm not interested in wasting any more of my time with this nonsense. I give up. -- Please don't "give up". It is a bit of a 'wicked' problem [1]. Yes to taking a rest, stepping back and trying to summarise/review what was discussed. I couldn't keep up with all the discussion, and I doubt many others kept up, especially those who have been frustrated in their (mis-) use of submodules. Do remember that Junio has multiple roles which belie the softness of the word 'maintainer'. It includes "Defender of the Heritage" in the same way that keepers of ancient monuments will want visitors to enjoy the site, but rail against a garish new stainless steel and glass entrance to the Colosseum (choose you local heritage site) (see [1] again). I get confused (about sub-modules) with msysgit where git.git is a sub-module, and is the fastest moving (an inversion of control issue), and when hacking at (just) the msys level when the git sub-module isn't in sync. In many ways sub-module tracking is like file renames and empty directories (both of which come up a lot). The submodule meta information issue has great similarity to the empty directories issue. It's about meta information, not about content (which is certified verified by sha1), and about how users know what is going on and get a (natural) feeling of control (without upsetting other users/controllers) . regards Philip [now to schedule some time to do the catch up reading. $dayjob beckons] [1] www.poppendieck.com/wicked.htm -- 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 crash in Ubuntu 12.04
Sivaram Kannan writes:
> Hi,
>
> I am using git with Gitlab/Gitolite configuration. Git version is
> 1.7.9.5 in Ubuntu 12.04. There has been a consistent git crash
> recently and have attached the /var/crash/_usr_lib_git-core_
> git.1001.crash file.
>
> The crash output is pasted in the following link
>
> http://pastebin.com/uAQS81BX
>
> I removed some long binary information at the end of the file as
> pastebin does not allow more than 500k pasting. The crash is
> consistently happening and I am planning on for a debian deployment of
> gitlab.
Can you tell us what command you ran, and also try to get a readable
backtrace from your installation?
It seems that the paste would have contained a core dump (you snipped
it9, but it would be pretty useless without the corresponding binary
anyway. Once you have the coredump in hand (as a file) you can use
gdb $(which git) the_coredump_file
and then in the GDB prompt, enter 'backtrace' and paste its output, to
give us an idea what is going on.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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 rebase : knowing where I am...
Hello is there some way to know how far you are within a rebase when the rebase is interupted by a conflict other than the message given by git rebase when it was interrupted ? I would have expected a git rebase --status or something similar... Regards Jérémy Rosen fight key loggers : write some perl using vim -- 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] completion: add more cherry-pick options
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 93eba46..d257b90 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1124,9 +1124,14 @@ _git_cherry ()
_git_cherry_pick ()
{
+ local dir="$(__gitdir)"
+ if [ -f "$dir"/CHERRY_PICK_HEAD ]; then
+ __gitcomp "--continue --quit --abort"
+ return
+ fi
case "$cur" in
--*)
- __gitcomp "--edit --no-commit"
+ __gitcomp "--edit --no-commit --signoff --strategy= --mainline"
;;
*)
__gitcomp_nl "$(__git_refs)"
--
1.8.2.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 v3 2/7] completion: get rid of empty COMPREPLY assignments
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras wrote: > There's no functional reason for those, the only purpose they are > supposed to serve is to say "we don't provide any words here", but even > for that it's not used consitently. s/consitently/consistently/ > Signed-off-by: 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 v3 5/7] completion: get rid of compgen
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
wrote:
> The functionality we use from compgen is not much, we can do the same
> manually, with drastical improvements in speed, specially when dealing
s/drastical/drastic/
s/specially/especially/
> with only a few words.
>
> This patch also has the sideffect that brekage reported by Jeroen Meijer
s/sideffect/side effect/
s/brekage/breakage/
> and SZEDER Gábor gets fixed because we no longer expand the resulting
> words.
>
> So, unless 'git checkout ' usually gives you more than 10
> results, you'll get an improvement :)
>
> Other possible solutions perform better after 1000 words, but worst if
s/worst/worse/
> less than that:
>
> COMPREPLY=($(awk -v cur="$3" -v pre="$2" -v suf="$4"
> '$0 ~ cur { print pre$0suf }' <<< "$1" ))
>
> COMPREPLY=($(printf -- "$2%s$4\n" $1 | grep "^$2$3"))
>
> Signed-off-by: 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 v3 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras wrote: > There's no point in calling a separate function that is only used in one > place. Specially considering that there's no need to call compgen, and s/Specially/Especially/ > we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. s/ourselves/ourself/ > So lets squash the functions together, and traverse only once. s/lets/let's/ > This improves performance. For N number of words: > > == 1 == > original: 0.002s > new: 0.000s > == 10 == > original: 0.005s > new: 0.001s > == 100 == > original: 0.009s > new: 0.006s > == 1000 == > original: 0.027s > new: 0.019s > == 1 == > original: 0.163s > new: 0.151s > == 10 == > original: 1.555s > new: 1.497s > > No functional changes. > > Signed-off-by: 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 1/4] gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch
On 09.04.2013 at 23:59, Jürgen Kreileder wrote: > Jakub Narębski writes: > >> On 08.04.2013, Junio C Hamano wrote: >>> j...@blackdown.de (Jürgen Kreileder) writes: >>> Fixes the encoding for several _plain actions and for text/* and */*+xml blobs. Signed-off-by: Jürgen Kreileder >> >> I see that this patch does (or tries to do) two _independent_ things, >> and should be split into at least two separate commits: [...] >> First, it extends adding "; charset=$default_text_plain_charset" to >> other mimetypes for 'blob_plain' view to all 'text/*' and '*/*+xml' >> mimetypes (without changing name of variable... though this is more >> complicated as it is configuration variable and we would want to >> preserve backward compatibility, but at least a comment would be, >> I think, needed). >> >> Originally it applied only to 'text/plain' files, which can be >> displayed inline by web browser, and which need charset in >> 'Content-Type:' HTTP header to be displayed correctly, as they >> do not include such information inside the file. > > What prompted the change is that some browsers (Chrome and Safari) also > display other file types inline: text/x-chdr, text/x-java, text/x-objc, > text/x-sh, ... > > At least on my system these files do get served with charset set! > (ISO-8859-1 even though Apache has "AddDefaultCharset UTF-8"...) [...] I think this (the reason behind this change) should be explained in the commit message. >> 'text/html' and 'application/xhtml+xml' can include such information >> inside them (meta http-equiv for 'text/html' and for >> 'application/xhtml+xml'). I don't know what browser does when there >> is conflicting information about charset, i.e. which one wins, but >> it is certainly something to consider. > > As shown above, even without my patch, this already can happen! > >> It might be a good change; I don't know what web browser do when >> serving 'text/css', 'text/javascript', 'text/xml' to client to >> view without media type known. There are few options on how to handle this. First, there is an issue of $default_text_plain_charset configuration variable. Any changes to its use (or adding new configuration variables) should be accompanied with changing / adding comment near the place where the default value is set, and changing / adding to the documentation, namely gitweb.conf.txt We can either: 1.) Use $default_text_plain_charset variable both for 'text/plain' and 'text/*' etc. content types in 'blob_plain' (aka 'raw') view for backwards compatibility, just add comment that it applies more than 'text/plain' 2.) Add new configuration variable, e.g. $default_blob_plain_charset and use it in place of $default_text_plain_charset as above, initializing it to $default_text_plain_charset. This practically renames $default_text_plain_charset preserving backward compatibility. Documentation would talk now about new variable name. 3.) Add new configuration variable, e.g. $default_text_other_charset, or $default_blob_plain_charset, or $default_inline_charset, etc. which will be used for files other than 'text/plain'. This would make it possible to turn this new feature on and off. 3.a.) New feature default to on, i.e. to $default_text_plain_charset 3.b.) New feature default to off, i.e. undef Second, there is an issue of file types, like HTML or XML (or XHTML, or sometimes for LaTeX), which have the information about encoding embedded in file. We can: A.) Skip this issue, and always add charset for 'text/*' and '*/*-xml' files B.) Threat those few media types in special way, excluding them from adding charset C.) Make which types to be added charset configurable. Anyway I think this feature is much less urgent. It fixes an annoyance rather than bug, as you can always choose which charset to use to display content in a browser. We can take time to implement it well, especially that it interacts with config (and backward compatibility of config variables). >> BTW I have noticed that we do $prevent_xss dance outside >> blob_contenttype(), in it's only caller i.e. git_blob_plain()... >> which for example means that 'text/html' converted to 'text/plain' >> don't get '; charset=...' added. I guess that it *might* be >> what prompted this part of change... but if it is so, it needs >> to be fixed at source, e.g. by moving $prevent_xss to >> blob_contenttype() subroutine. > > Jep. But I see this is yet another separate issue. >> Second it changes 'blobdiff_plain', 'commitdiff_plain' (which I think >> that should be abandoned in favor of 'patch' view; but that is >> a separate issue) and 'patch' views so they use binary-safe output. >> >> Note that in all cases (I think) we use >> >>$cgi->header( >> -type => 'text/plain', >> -charset => 'utf-8', >> ... >>); >> >> promising web browser that output is as whole in 'utf-8' encoding. > > Yes. > >> It is not explained in the
Re: [PATCH v3 5/7] completion: get rid of compgen
On Wed, Apr 10, 2013 at 5:10 AM, Eric Sunshine wrote: > s/specially/especially/ http://www.merriam-webster.com/dictionary/specially -- 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 v3 5/7] completion: get rid of compgen
On Wed, Apr 10, 2013 at 06:07:33AM -0500, Felipe Contreras wrote: > On Wed, Apr 10, 2013 at 5:10 AM, Eric Sunshine > wrote: > > s/specially/especially/ > > http://www.merriam-webster.com/dictionary/specially But see also: http://www.merriam-webster.com/dictionary/especially which notes "in particular" as a synonym, which is what makes it more natural in the case under discussion here. -- 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 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote: > On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras > wrote: > > we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. > > s/ourselves/ourself/ Huh? "we traverse ... ourselves" is correct since "ourselves" is associated with the "we". I don't think "ourself" is ever correct in normal usage - the dictionary notes that it applies only to the "royal we". -- 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: [BUG] shallow clones over http
Jeff King peff.net> writes: > > I'm trying to track down a protocol bug that happens with shallow clones > over smart-http. As far as I can tell, the bug has existed in all > versions. > > You can reproduce it using the attached repository, which is a shallow > clone of https://github.com/mileszs/ack.vim.git, like: > > $ tar xzf repo.tar.gz > $ cd repo.git > $ git fetch --depth=10 > fatal: git fetch-pack: expected shallow list The problem occurs to me also when I want to "deepen" a shallow clone of MediaWiki via https:// git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git pull --depth=9 fatal: git fetch-pack: expected shallow list. Perhaps it helps someone to find the reason. -- 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: [BUG] shallow clones over http
Tom wrote: > git pull --depth=9 Unrelated nit: we now have git fetch --unshallow. -- 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: [BUG] shallow clones over http
The problem occurs to me also when I want to "deepen" a shallow clone of MediaWiki via https:// git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git pull --depth=9 fatal: git fetch-pack: expected shallow list. Perhaps it helps someone to find the reason. UPDATE: This however works git clone --depth=2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git git fetch --depth=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: [PATCH] glossary: extend "detached HEAD" description
Junio C Hamano wrote: > diff --git a/Documentation/glossary-content.txt > b/Documentation/glossary-content.txt > index f928b57..69c90d1 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -100,9 +100,22 @@ to point at the new commit. > > [[def_detached_HEAD]]detached HEAD:: > Normally the <> stores the name of a > - <>. However, git also allows you to > <> > - an arbitrary <> that isn't necessarily the tip of any > - particular branch. In this case HEAD is said to be "detached". > + <>, and commands that operate on the > + history HEAD represents operate on the history leading to the > + tip of the branch the HEAD points at. However, Git also > + allows you to <> an arbitrary > + <> that isn't necessarily the tip of any > + particular branch. The HEAD in such a state is called > + "detached". Should we also add that "git branch" output shows this situation as "(no branch)"? Nb. this is not documented in git-branch(1) manpage either... -- Jakub Narębski -- 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: [ITCH] Specify refspec without remote
Jonathan Nieder wrote: > git push origin korg -- master; # push master to 2 remotes > git push -- master next; # push two refs to default remote > git push origin -- master; # push master to origin, more explicitly > git push origin korg --; # push default refspec to 2 remotes, again I definitely like the idea of using -- to disambiguate, as it is consistent with existing git commands (that are internally using the rev-list machinery). However, I disagree with the idea of being able to specify multiple remotes: what does 'git push A B -- master +next' mean? Do I know that master and next are present in both A and B? Do I know for certain that a force-push to next won't wipe any data on either A or B accidentally? As the number of remotes and refs increase, the amount of information that the user must know about each of the remotes is simply huge. Therefore, I think it is unnecessarily confusing and unnecessary. Moreover, it can easily be achieved in shell, and there is no advantage to supporting it in push unless we're doing something like a parallel push. >git push host:some/path; # ambiguous argument. Please disambiguate. Regression. It should just treat host:some/path as a destination, not a ref. >git push origin; # is a remote name and not a refname. Good. >git push master; # is a ref name and not a remote name. Good. This is what I finally want. With your -- to disambiguate, the logic for doing this has been simplified greatly. -- 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: [ITCH] Specify refspec without remote
Jeff King wrote: > git push --remote=host:some/path > > if we are willing to break the existing syntax. Though your proposal > does have the benefit of breaking only one particular syntax which is > (I'm guessing) less frequently used. But we'd still need the usual > deprecation period, I think. Why? 'git push host:some/path' should treat host:some/path as a destination and not a refspec. If the user meant refspec, she should do 'git push -- host:some/path' instead. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries
Junio C Hamano wrote: > And I also misread "we currently don't handle" above as "but we > really should allow adding d/f when d is at the top of the working > tree of another project", but that was not what you meant to say. > Instead, "We do not notice such a bad case in today's code yet" was > what you meant. But if we are to use "there are cases" in [1/n] and > start [2/n] with "Now we have renamed, let's do this", then we do > not have to bother saying anything in [1/n] about the upcoming > change in [2/n], especially the patches come back-to-back in a > single series. Exactly. Yeah, I don't think you patch makes sense as a standalone anyway: I'll use appropriate wording when I roll the series, so it follows nicely. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: refuse to add paths beyond repository boundaries
Junio C Hamano wrote: > One can have symlinks to anywhere all one wants. We track symlinks. > [...] Yes, I know. We store symlinks as blobs containing one line, the path to the file, without a trailing newline. And we have a mode for it to distinguish it from regular files. What I meant is: echo "baz" >newfile cd foo/bar/quux ln -s ../../../newfile cd ../../..# Back to toplevel git add foo/bar/quux/newfile This is allowed. While: cd foo/bar/quux echo "baz" >newfile cd ../../..# Back to toplevel ln -s foo/bar/quux git add quux/newfile is disallowed. Then again, if we were to replace the last line with: cd quux git add newfile and it works. Notice that both symlinks are pointing to paths inside out repository, and the only difference is that the second example attempts to add a path with a symlink as the non-final component. The path is not pointing "outside" our repository, as the function name would indicate. Anyway, it's just a minor detail that would be nice to fix in the future. Nothing urgent. -- 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] test-lint-duplicates: Only check for numbered test cases
On 03.04.13 16:28, Jeff King wrote:
> On Wed, Apr 03, 2013 at 07:54:02AM +0200, Torsten Bögershausen wrote:
>
>> Running make inside contrib/remote-helpers fails in "test-lint-duplicates"
>>
>> This was because the regexp checking for duplicate numbers strips everything
>> after the first "-" in the filename, including the prefix.
>>
>> As a result, 2 pathnames like
>> "/contrib/remote-helpers/test-bzr.sh" and
>> "/contrib/remote-helpers/test-hg-bidi.sh"
>>
>> are both converted into
>> "/contrib/remote", and reported as duplicate.
>>
>> Improve the regexp:
>> Remove everything after t- (where X stand for a digit)
>
> I think the approach to just make test-lint-duplicates a no-op on
> non-numbered tests is reasonable, but this is side-stepping half of the
> issue. The problems are:
>
> 1. We do not have numbers in our test names.
>
> 2. We _do_ have full paths in the test names, which might have
> elements which look like test script names.
>
> Your patch tightens the match so that a hyphen in the path name does not
> confuse our script. But it trades it for being confused by t in the
> pathname. Which is admittedly less likely, but is not addressing the
> fundamental issues that we should only be processing basenames.
>
> So something like "sed 's,.*/,,'" would fix that. But that still leaves
> us with a bunch of tests called "test-foo", "test-bar", etc, which will
> appear as duplicates. So we would still want to tighten the number
> parsing.
>
> Like:
>
> diff --git a/t/Makefile b/t/Makefile
> index 5c6de81..e5afa4c 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -47,7 +47,9 @@ test-lint-duplicates:
> test-lint: test-lint-duplicates test-lint-executable
>
> test-lint-duplicates:
> - @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` && \
> + @dups=`echo $(T) | tr ' ' '\n' | \
> + sed -e 's,.*/,,' -e 's/\(t[0-9][0-9][0-9][0-9]\)-.*/\1/' | \
> + sort | uniq -d` && \
> test -z "$$dups" || { \
> echo >&2 "duplicate test numbers:" $$dups; exit 1; }
>
>
> -Peff
I thinkg we need both the striping of the path and the "grepping" for
numbered test cases only.
I'll send a patch in a minute
--
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] test-lint-duplicates: consider only numbered test cases
Running make inside contrib/remote-helpers may fail in "test-lint-duplicates"
This was because the regexp checking for duplicate numbers strips everything
after the first "-" in the filename, including the prefix.
As a result, 2 pathnames like
"/contrib/remote-helpers/test-XX.sh" and
"/contrib/remote-helpers/test-YY.sh"
are both converted into
"/contrib/remote", and reported as duplicate.
Improve the regexp:
- strip the leading path and look only at the basename
- only look at files which have t- (where N stand for a digit) in the name
Signed-off-by: Torsten Bögershausen
---
http://comments.gmane.org/gmane.comp.version-control.git/214194
t/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/t/Makefile b/t/Makefile
index 1923cc1..cfd6d5a 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -48,7 +48,9 @@ clean: clean-except-prove-cache
test-lint: test-lint-duplicates test-lint-executable test-lint-shell-syntax
test-lint-duplicates:
- @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` && \
+ @dups=`echo $(T) | tr ' ' '\n' | \
+ sed -e 's,.*/,,' -ne
's|\(.*/\)*t\([0-9][0-9][0-9][0-9]\)-.*|\2|p' | \
+ sort | uniq -d` && \
test -z "$$dups" || { \
echo >&2 "duplicate test numbers:" $$dups; exit 1; }
--
1.8.2.282.g4bc7171
--
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
[rfh] do I need to use something more complex to do this?
I have set of items with two attributes, , and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same . The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the "specific" order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item , there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking , there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. E.g. if I have these 6 items (ignore the lines between the items for now): <104,U>--<105,U>--<106,4> / <101,U>--<100,U>--<102,3>--<104,4> I would want to pick them up in this order: <106,4> <105,U> <104,U> <104,4> <102,3> <101,U> <100,U> I see how this can easily be done by using a two priority lists, i.e. one for items with Y=Unspecified that is sorted by X, and the other for all other items that is sorted by . Peek the top of both, and pick the top of the former until its X is smaller than the value of X of the top of the latter, otherwise pick the top of the latter. I am wondering if I can use less complex data structure, like a single ordered sorted array, with a clever comparison function. For the curious, the items in the above picture represents commits, and lines are ancestry chains between them. I am thinking how we can extend the still_interesting() function with an optional generation number. -- 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] glossary: extend "detached HEAD" description
Jakub Narębski writes: > Junio C Hamano wrote: > >> diff --git a/Documentation/glossary-content.txt >> b/Documentation/glossary-content.txt >> index f928b57..69c90d1 100644 >> --- a/Documentation/glossary-content.txt >> +++ b/Documentation/glossary-content.txt >> @@ -100,9 +100,22 @@ to point at the new commit. >> >> [[def_detached_HEAD]]detached HEAD:: >> Normally the <> stores the name of a >> -<>. However, git also allows you to >> <> >> -an arbitrary <> that isn't necessarily the tip of any >> -particular branch. In this case HEAD is said to be "detached". >> +<>, and commands that operate on the >> +history HEAD represents operate on the history leading to the >> +tip of the branch the HEAD points at. However, Git also >> +allows you to <> an arbitrary >> +<> that isn't necessarily the tip of any >> +particular branch. The HEAD in such a state is called >> +"detached". > > Should we also add that "git branch" output shows this situation > as "(no branch)"? > > Nb. this is not documented in git-branch(1) manpage either... Sounds good. Please make it so, perhaps for both. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-imap-send.txt: remove the use of sslverify=false in GMail example
Since GMail is SSL capable there is no need to set sslverify to false, the example using it may confuse readers that it's needed since it's also used in the previous example configurations, too Signed-off-by: Barbu Paul - Gheorghe --- Documentation/git-imap-send.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d283..b15dffe 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -123,7 +123,6 @@ to specify your account settings: host = imaps://imap.gmail.com user = u...@gmail.com port = 993 - sslverify = false - You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error -- Barbu Paul - Gheorghe Common sense is not so common - Voltaire Visit My GitHub profile to see my open-source projects - https://github.com/paullik -- 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: [rfh] do I need to use something more complex to do this?
On 04/10/2013 04:40 PM, Junio C Hamano wrote: I have set of items with two attributes, , and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same . The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the "specific" order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item , there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking , there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. So X is primary sort and Y is secondary, except Y=Undefined trumps all other values for Y, but never trumps X as primary sort. Can't you just have U be the largest unsigned integer value of the type you choose? For this particular application, I doubt there's any risk of the defined numbers catching up with it. I might have missed something though. This seems a bit too trivial for you to ask for help. -- 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
à¹à¸¡à¸·à¹à¸à¸à¹à¸³à¹à¸¥à¹à¸à¹à¸£à¸²à¸à¹à¸¡à¸µà¸à¸à¸«à¸¥à¸§à¸
"...à¹à¸à¹à¸¡à¸²à¹à¸à¸¢à¸à¸¹à¸à¹à¸à¸à¸à¹à¸² มีà¹à¸¡à¸ à¸à¸³à¹à¸¡à¸¡à¸µà¹à¸¡à¸à¸à¸¢à¹à¸²à¸à¸à¸µà¹ à¸à¸³à¹à¸¡à¸à¸°à¸à¸¶à¸à¹à¸¡à¸à¸à¸µà¹à¸¥à¸à¸¡à¸²à¹à¸«à¹à¹à¸à¹ à¸à¹à¹à¸à¸¢à¹à¸à¹à¸¢à¸´à¸à¹à¸£à¸·à¹à¸à¸à¸à¸²à¸£à¸à¸³à¸à¸ à¸à¹à¸¡à¸²à¸à¸£à¸²à¸£à¸ à¸à¸±à¸à¸à¸¸à¸à¹à¸à¸à¸¤à¸à¸à¸´à¹ à¸à¸à¸à¸³à¹à¸à¹à¸¡à¸µ มีหà¸à¸±à¸à¸ªà¸·à¸ à¹à¸à¸¢à¸à¹à¸²à¸à¸«à¸à¸±à¸à¸ªà¸·à¸à¸à¸³à¹à¸à¹..." à¸à¸¸à¸à¸à¸¨à¸±à¸à¸£à¸²à¸2498à¸à¸¶à¸à¹à¸à¹à¸¡à¸µà¸à¸£à¸°à¸£à¸²à¸à¸à¸³à¸£à¸´à¸à¹à¸à¸«à¸²à¸§à¸´à¸à¸µà¸à¸²à¸£ à¸à¸µà¹à¸à¸°à¸à¸³à¹à¸«à¹à¹à¸à¸´à¸à¸à¸à¸à¸à¸à¸à¸à¹à¸«à¸à¸·à¸à¸à¸²à¸à¸à¸µà¹à¸à¸°à¹à¸à¹à¸£à¸±à¸ à¸à¸²à¸à¸à¸£à¸£à¸¡à¸à¸²à¸à¸´à¹à¸à¸¢à¸à¸³à¹à¸à¸à¹à¸à¹à¸¥à¸¢à¸µà¸à¸³à¸ªà¸¡à¸±à¸¢à¹à¸¥à¸°à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£ à¸à¸µà¹à¸¡à¸µà¸à¸¢à¸¹à¹à¸à¸£à¸°à¸¢à¸¸à¸à¸à¹à¸à¸±à¸à¸¨à¸±à¸à¸¢à¸ าà¸à¸à¸à¸à¸à¸²à¸£à¹à¸à¸´à¸à¸à¸ à¹à¸à¹à¸à¸à¸£à¹à¸à¸ à¹à¸à¹à¸ à¸à¸£à¸°à¹à¸à¸¨à¹à¸à¸¢à¸¡à¸¸à¹à¸à¸à¸à¸±à¸à¸à¸±à¸à¸«à¸² à¸à¸§à¸²à¸¡à¹à¸à¸·à¸à¸à¸£à¹à¸à¸à¸à¸±à¸à¸à¸¥à¹à¸²à¸§ à¹à¸¥à¸°à¸à¸£à¸à¸¡à¸µà¸à¸£à¸°à¸£à¸²à¸à¸«à¸¤à¸à¸±à¸¢ à¹à¸à¸·à¹à¸à¸¡à¸±à¹à¸à¸§à¹à¸²à¸§à¸´à¸à¸µà¸à¸²à¸£à¸à¸±à¸à¸à¸¥à¹à¸²à¸§à¸à¸µà¹ à¸à¸°à¸à¸³à¹à¸«à¹ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸à¸à¸²à¸£à¸à¸±à¸à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¸à¹à¸³à¸à¸à¸à¸à¸²à¸à¸´à¹à¸à¸´à¸ à¸à¸§à¸²à¸¡à¸à¸£à¹à¸à¸¡à¹à¸¥à¸°à¸à¸£à¸à¸à¸£à¸´à¸à¸¹à¸£à¸à¹à¸à¸²à¸¡à¸§à¸±à¸à¸à¸±à¸à¸£à¸à¸à¸ à¸à¹à¸³ à¸à¸·à¸ 1. à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¹à¸à¹à¸à¸´à¸ 2. à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸°à¸à¸ à¸à¸²à¸£à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¸à¸´à¸§à¸à¸´à¸ 3. à¸à¸²à¸£à¸à¸±à¸à¸à¸² à¸à¸²à¸£ à¸à¸±à¸à¸à¸²à¸£à¸à¸£à¸±à¸à¸¢à¸²à¸à¸£à¹à¸«à¸¥à¹à¸à¸à¹à¸³à¹à¸ à¸à¸£à¸£à¸¢à¸²à¸à¸²à¸¨ à¸à¸£à¸à¹à¸à¸·à¹à¸à¸¡à¸±à¹à¸à¹à¸à¸à¸£à¸°à¸£à¸²à¸à¸«à¸¤à¸à¸±à¸¢ วà¹à¸²à¸à¹à¸§à¸¢ ลัà¸à¸©à¸à¸°à¸ ูมิà¸à¸£à¸°à¹à¸à¸¨à¹à¸¥à¸°à¸ ูมิà¸à¸²à¸à¸²à¸¨ à¸à¸à¸à¸à¸£à¸°à¹à¸à¸¨à¸à¸° สามารà¸à¸à¸³à¹à¸à¸´à¸à¸à¸²à¸£à¹à¸«à¹à¸à¸±à¸à¹à¸à¸´à¸à¸à¸¥à¸ªà¸³à¹à¸£à¹à¸à¹à¸à¹ à¸à¸¢à¹à¸²à¸à¹à¸à¹à¸à¸à¸ à¸à¸±à¸à¸à¸±à¹à¸ à¹à¸à¸à¸µ à¸à¸¸à¸à¸à¸¨à¸±à¸à¸£à¸²à¸ 2499 à¸à¸¶à¸à¹à¸à¹à¸à¸£à¸ à¸à¸£à¸°à¸¡à¸«à¸²à¸à¸£à¸¸à¸à¸²à¸à¸£à¸°à¸£à¸²à¸à¸à¸²à¸ à¹à¸à¸£à¸à¸à¸²à¸£à¸à¸£à¸°à¸£à¸²à¸à¸à¸³à¸£à¸´ "à¸à¸à¸«à¸¥à¸§à¸" à¹à¸«à¹à¸«à¸¡à¹à¸à¸¡à¸£à¸²à¸à¸§à¸à¸¨à¹ à¹à¸à¸à¸¤à¸à¸à¸´à¹ à¹à¸à¸§à¸à¸¸à¸¥ รัà¸à¹à¸à¸à¸³à¹à¸à¸´à¸à¸à¸²à¸£ ศึà¸à¸©à¸² วิà¸à¸±à¸¢ à¹à¸¥à¸° à¸à¸²à¸£à¸à¸±à¸à¸à¸² à¸à¸£à¸£à¸¡à¸§à¸´à¸à¸µà¸à¸²à¸£à¸à¸³à¸à¸à¹à¸«à¹à¸à¸±à¸à¹à¸à¸´à¸à¸à¸¥à¹à¸à¸¢à¹à¸£à¹à¸§ à¹à¸«à¸¥à¹à¸à¸à¸µà¹à¸¡à¸² http://www.konthairakkan.com/2009-06-28-14-07-02.html à¹à¸¥à¸° http://www.thaigoodview.com/library/studentshow/2549/m6/sri09/html/activities-sci2.htm <>
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 06:52:51PM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > git push --remote=host:some/path > > > > if we are willing to break the existing syntax. Though your proposal > > does have the benefit of breaking only one particular syntax which is > > (I'm guessing) less frequently used. But we'd still need the usual > > deprecation period, I think. > > Why? 'git push host:some/path' should treat host:some/path as a > destination and not a refspec. If the user meant refspec, she should > do 'git push -- host:some/path' instead. You snipped the part of Jonathan's message I quoted; I was responding specifically to making "git push host:some/path" an error. I do not think that is a good idea, and doing so would require a deprecation period. -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] test-lint-duplicates: Only check for numbered test cases
On Wed, Apr 10, 2013 at 04:14:34PM +0200, Torsten Bögershausen wrote:
> > test-lint-duplicates:
> > - @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` && \
> > + @dups=`echo $(T) | tr ' ' '\n' | \
> > + sed -e 's,.*/,,' -e 's/\(t[0-9][0-9][0-9][0-9]\)-.*/\1/' | \
> > + sort | uniq -d` && \
> > test -z "$$dups" || { \
> > echo >&2 "duplicate test numbers:" $$dups; exit 1; }
> >
> >
> > -Peff
> I thinkg we need both the striping of the path and the "grepping" for
> numbered test cases only.
> I'll send a patch in a minute
I think it is fine either way. My command above turns:
/path/to/test-one.sh
/path/to/test-two.sh
into
test-one.sh
test-two.sh
which is fine for running through uniq. If you use "sed -n", you simply
end up with an empty list, which is also fine.
-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] test-lint-duplicates: consider only numbered test cases
On Wed, Apr 10, 2013 at 04:22:57PM +0200, Torsten Bögershausen wrote: > Running make inside contrib/remote-helpers may fail in "test-lint-duplicates" > > This was because the regexp checking for duplicate numbers strips everything > after the first "-" in the filename, including the prefix. > > As a result, 2 pathnames like > "/contrib/remote-helpers/test-XX.sh" and > "/contrib/remote-helpers/test-YY.sh" > > are both converted into > "/contrib/remote", and reported as duplicate. > > Improve the regexp: > - strip the leading path and look only at the basename > - only look at files which have t- (where N stand for a digit) in the name > > Signed-off-by: Torsten Bögershausen > --- Yeah, I think this is fine. Though note that we already have Felipe's patch to just set TEST_LINT explicitly, so I think it is a non-issue now. -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 2/2] add: refuse to add paths beyond repository boundaries
Ramkumar Ramachandra writes: > Exactly. Yeah, I don't think you patch makes sense as a standalone > anyway. Yes, it was purely a preparatory step. -- 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: [ITCH] Specify refspec without remote
Jeff King writes: > On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote: > >> >git push -- master next; # push two refs to default remote >> >> ... or default "push remote" if there is one, I presume? >> >> As you are giving what to push, I am assuming that >> branch.$name.remote would not come into play in this case. > >... > The missing case 4 is obviously: > > dst=missing, refs=present > ... > Do you want to explain your thinking? I'm guessing it has to do with the > fact that choosing branch.*.remote is about trying to push to the > configured upstream (even though we traditionally do _not_ take into > account branch.*.merge when doing so). With the branch.$name.remote, the user tells us "When I am on this branch, I want to talk to this remote". When you did git push -- master next ;# case #4 on branch maint, branch.maint.remote should not come into play. Would we want to push our 'master' to branch.master.remote in a way git checkout master && git push would do, while at the same time because we were told to do the same for 'next', we do the same as git checkout next && git push would do? That would work if you give just branch names, but that is not a general enough definition to cover your case #4, e.g. git push -- v1.2.3 master:refs/remotes/mothership/master If we define case #4 to push to the remote.pushdefault (falling back to remote.default), this case would do what can simply be expected; if the earlier cases also push to that same place, ignoring branch.$name.remote for master and next, that would be consistent. -- 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: [ITCH] Specify refspec without remote
Jeff King writes: > On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote: > >> Random idea: today you can do >> >> git push origin master; # push branch master to remote origin >> git push --multiple origin korg; # push default refspec to 2 remotes > > Can we do "git push --multiple" today? You can have multiple destination URLs for a single remote nickname. Wouldn't that be sufficient for regular publishing purposes? -- 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/RFC 2/3] Teach mv to move submodules using a gitfile
Am 10.04.2013 01:08, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> diff --git a/submodule.c b/submodule.c
>> index 975bc87..eba9b42 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const
>> char *path,
>> ...
>> +if (!fp)
>> +die(_("Could not create git link %s"), gitfile_name.buf);
>> +fprintf(fp, gitfile_content.buf);
>
> Perhaps.
>
> fprintf(fp, "%s", gitfile_content.buf);
Sure. Will fix in v2.
--
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: tar on Mac does not like empty tar from git archive
Am 08.04.2013 20:36, schrieb BJ Hargrave:
> Git 1.8.2.1 includes commit bd54cf17 - archive: handle commits with
> an empty tree
>
> Test 2 of t5004-archive-corner-cases, "tar archive of empty tree is
> empty", fails on Mac OS X 10.8.3 (with XCode 4.6.1) since the tar
> command exits with return code 1 on the generated tar file.
>
> expecting success:
> git archive --format=tar HEAD >empty.tar &&
> make_dir extract &&
> "$TAR" xf empty.tar -C extract &&
> check_dir extract
>
> tar: Damaged tar archive
> tar: Error exit delayed from previous errors.
> not ok 2 - tar archive of empty tree is empty
>
> tar tf "trash directory.t5004-archive-corner-cases/empty.tar"; echo $?
> tar: Damaged tar archive
> tar: Error exit delayed from previous errors.
> 1
>
> tar --version
> bsdtar 2.8.3 - libarchive 2.8.3
>
> It appears that bsdtar does not like the empty tar files created by
> git archive. An empty tar file created by bsdtar is accepted.
>
> tar cT /dev/null | tar t; echo $?
> 0
I've opened an issue for libarchive for that behaviour:
http://code.google.com/p/libarchive/issues/detail?id=314
We can work around bsdtar's dislike of not-quite-empty tar archives by
leaving out the comment that contains the commit hash.
-- >8 --
Subject: t5004: fix issue with empty archive test and bsdtar
bsdtar, which is the default tar on Mac OS X, handles empty archives
just fine but reports archives containing only a pax extended header
comment as damaged. Work around the issue by explicitly generating
the archive for the tree and not the commit, which causes git archive
to omit the commit hash comment record from the tar file.
Reported-by: BJ Hargrave
Signed-off-by: Rene Scharfe
---
t/t5004-archive-corner-cases.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
index cdb7d7a..bfdb56a 100755
--- a/t/t5004-archive-corner-cases.sh
+++ b/t/t5004-archive-corner-cases.sh
@@ -28,7 +28,7 @@ check_dir() {
}
test_expect_success 'tar archive of empty tree is empty' '
- git archive --format=tar HEAD >empty.tar &&
+ git archive --format=tar HEAD: >empty.tar &&
make_dir extract &&
"$TAR" xf empty.tar -C extract &&
check_dir extract
--
1.8.2.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: git instaweb - share all project files
W dniu 07.04.2013 05:02, Trenton D. Adams pisze:
> On that first page that shows up, it shows the .git folder. It would
> be kind of nice if it shared out both the git repo and the actual
> current project files. I frequently have stuff I'd like to see in a
> web browser, and even requires one (i.e. Navigating to
> file:///home/blah/blah doesn't work; ajax requests for example)
There are a few possible solutions, from simplest to most complicated:
1. Configure gitweb ran by git-instaweb to have 'worktree' link in
the action bar pointing to 'file:///path/to/repo' (or rather
'file:///path/to/workdir') via 'actions' feature, adding e.g.
$feature{'actions'}{'default'} =
[('worktree', 'file:///path/to/repo', 'summary')];
to gitweb_config.perl / gitweb.conf used by git-instaweb's gitweb.
This of course works only for local use, so either git-instaweb
or gitweb (in config) should check that we use it locally
(e.g. if hostname is 'localhost' or equivalent).
2. In the web server configuration generated by git-instaweb, perhaps
as an option, add serving of worktree (with mod_autoindex aka.
'Options +Indexes' for Apache2, and equivalent solutions for *all*
other supported web servers: lighttpd, mongoose, plack, webrick).
This may require some fiddling with URI rewriting, or change of
gitweb URI, to be able to have both worktree index and gitweb
script (gitweb is now under '/'), so it should probably be protected
by an option to git-instaweb.
3. Add proper support to gitweb: add 'worktree' action (similar to
'tree' action / view). Probably needs to be made somewhat
configurable (and of course enabled in git-instaweb).
Unfortunately solution 1.) which is simplest is not enough for your
situation...
I can add 3.) to my gitweb TODO, but I don't know when I would be able
to get to implementing it.
--
Jakub Narębski
--
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: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote: > > The missing case 4 is obviously: > > > > dst=missing, refs=present > > ... > > Do you want to explain your thinking? I'm guessing it has to do with the > > fact that choosing branch.*.remote is about trying to push to the > > configured upstream (even though we traditionally do _not_ take into > > account branch.*.merge when doing so). > > With the branch.$name.remote, the user tells us "When I am on this > branch, I want to talk to this remote". When you did > > git push -- master next ;# case #4 > > on branch maint, branch.maint.remote should not come into play. I understand that's your position, but I don't understand _why_. If branch.$name.remote is "when I am on this branch, I want to talk to this remote", that rule is not be impacted by the presence of refspecs at all. If it meant "when I am on this branch, and I do not specify any refspecs, then I would by default want to push this branch to that remote", then your proposed behavior would make more sense. And if you are using push.default=upstream, that is what happens. But historically the default push has been "matching". So in your other examples: > Would we want to push our 'master' to branch.master.remote in a way > > git checkout master && git push > > would do, while at the same time because we were told to do the same > for 'next', we do the same as > > git checkout next && git push These do not have anything to do with pushing the checked-out branch in particular. The first one may very well be pushing "next" to the remote specified by branch.master.remote. So I would argue that one of these two makes sense: 1. branch.*.remote means "use this as the default remote on this branch, no matte which refs we are pushing" 2. branch.*.remote is not respected at all for remote selection with "matching". It is used only when combined with branch.*.merge, which means that only the "upstream" mode would use it. I advocated (1) in my previous message, but I would also be OK with (2), even though it is a change from the current behavior. But what you are suggesting seems like an inconsistent mix of the two. > would do? That would work if you give just branch names, but that > is not a general enough definition to cover your case #4, e.g. > > git push -- v1.2.3 master:refs/remotes/mothership/master > > If we define case #4 to push to the remote.pushdefault (falling back > to remote.default), this case would do what can simply be expected; > if the earlier cases also push to that same place, ignoring > branch.$name.remote for master and next, that would be consistent. So I think what you are getting at is that branch.*.remote is about saying "when we push X, it goes to remote Y". And with v1.2.3, we obviously cannot have such a hint, because it is not a branch. But my point is that is _not_ how it works today. So if you want consistency, we would also need to adjust how branch.*.remote interacts with "matching". -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: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote: > > > >> Random idea: today you can do > >> > >>git push origin master; # push branch master to remote origin > >>git push --multiple origin korg; # push default refspec to 2 remotes > > > > Can we do "git push --multiple" today? > > You can have multiple destination URLs for a single remote nickname. > Wouldn't that be sufficient for regular publishing purposes? Yes, though that is different than specifying two different remotes, which may have their own sets of default refspecs (i.e., what Jonathan wrote above). If they are two URLs of the same configured remote, there is no question that they should respect the same refspecs. -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
[PATCH] archive: clarify explanation of --worktree-attributes
Make it a bit clearer that --worktree-attributes is about files in the working tree (checked out files, possibly changed) and not the current working directory ($PDW). Link to the ATTRIBUTES section, which has more details. Reported-by: Amit Bakshi Signed-off-by: Rene Scharfe --- Does this help a bit? Documentation/git-archive.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index b4c2e24..3dd3069 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -56,7 +56,8 @@ OPTIONS Write the archive to instead of stdout. --worktree-attributes:: - Look for attributes in .gitattributes in working directory too. + Look for attributes in .gitattributes files in the working tree + as well (see <>). :: This can be any options that the archiver backend understands. -- 1.8.2.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: Advice and repo setup
Michael Campbell wrote: > My company is moving from CVS to git in a few weeks (and we have a > training class scheduled with the github folks). > > That said our CI/build guys have already got gitorious set up (we get > to it through ssh with ssh keys and one "git" user on the server) Note that gitorious is git hosting software / software forge, i.e. combination of git hosting [configuration] software, web interface to repositories, and web-based administration. This is not the only solution. Among other all-in-one solutions are GitHUb:FI / GitHub Enterprise (proprietary and costly), InDefero, GitLab, Girocco + gitweb (what repo.or.cz uses). There are also pure web interfaces, and there are pure repository management software like gitosis (possibly unmaintained) and gitolite. I see GitHub Enterprise and GitLab both recommended as alternatives to Gitorious. But supposedly the most trouble is with installation, and you write that you "have already got gitorious set up". Unfortunately the Git Tools wiki page is not very actively maintained: https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools > and > we are in the process of migrating all new CVS checkins to a git repo. What tool do you use for that? Do you have tool selected to perform a full migration from CVS to Git (to have full history in Git), or will you cut off the history (perhaps stitching it later with historical repo with history imported from CVS, via grafts or git-replace), like Linux kernel did when moving from BitKeeper to Git? BTW. it might make sense if you have time to massage the history imported from CVS to remove CVS-related crufts and mishaps, e.g. with the reposurgeon tool (http://www.catb.org/esr/reposurgeon/) > As a business decision we have decided to pull in some "staff > augmentation". We don't want the remote developers to have direct > access. Our plan is to have some sort of external repo on which they > can push things, and locally we can pull those changes to our > "official" repo and check it as we go. So far so good. Another possible workflow is to have each of remote developers to get updates from central "blessed" official repository, but for each to have their own publishing repository they push to (and send pull requests about). Or maybe something hierarchical, with each group having their own repository... > Our product has several logically separate projects, which right now > we have in the one big mega repo (in CVS, and migrating per checkin to > Gitorious). Errr... didn't you use so called "modules" in CVS? Those usually translate to projects, which translate to git repositories. > So... I was wondering what the best way to split up our new repo might > be - or is it best to NOT split it? One of the concerns we have is > that in the one big repo we can't control access to the various > projects. So far we haven't needed to but this might be because we > couldn't. Split it, of course, into individual independent (more or less) project repositories. Note for example that you can tag (give name to a release) only whole repository. > So one plan is to have multiple repos, and then a mirror of those for > the remote devs. The other plan is to say "sod it" and have one local > and one remote and just suffer through possible non-requirements of > varying authorization profiles. It would also lead to slower operations (git works well with large number of files, but not necessarily with very large number of files), and increased storage (you can clone only whole repository even if nowadays you can check out only part of it; and you want for each developer to have their own private clone to work in). > Is there documentation I can refer to for this, or is there an obvious > way to do these things? Any help or pointers appreciated. -- Jakub Narębski -- 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] rebase: use -f for checkout
If a file's case is changed on rename (Foo -> foo), rebase fails on Windows because the file already exists. The change is safe, because if working directory is not clean rebase fails before checking out. --- git-rebase.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase.sh b/git-rebase.sh index b2f1c76..28fdc32 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -522,7 +522,7 @@ test "$type" = interactive && run_specific_rebase # Detach HEAD and reset the tree say "$(gettext "First, rewinding head to replay your work on top of it...")" -git checkout -q "$onto^0" || die "could not detach HEAD" +git checkout -fq "$onto^0" || die "could not detach HEAD" git update-ref ORIG_HEAD $orig_head # If the $onto is a proper descendant of the tip of the branch, then -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase : knowing where I am...
Jeremy Rosen writes: > is there some way to know how far you are within a rebase when the > rebase is interupted by a conflict other than the message given by > git rebase when it was interrupted ? I do not think there is a "git $anything" command to do that, but in the meantime you could "cat .git/rebase-*/git-rebase-todo" or something. Recent trend is to teach "git status" more about these internal states, so with time the command may learn to include this in its output. -- 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: [rfh] do I need to use something more complex to do this?
Junio C Hamano writes: > I have set of items with two attributes, , and would like to > keep them in some data structure in such a way that it is efficient > to (1) add a new item to the data structure, and (2) pick an item in > a specific order. There can be multiple items that share the same > value for X, or Y, or both X and Y, and it does not matter in what > order items comes out among those that share the same . > > The type of X is totally ordered. The type of Y also usually is, but > Y can take a special value U(nspecified). > > Now on to the "specific" order I want to pick an item. I'd like to > take the item with the largest value of Y in general, and tiebreaking > on the value of X which also I prefer to take from larger to smaller. > > But with a twist. > > When I am picking an item , there should be no item > remaining in the data store with a value of Y that is smaller than m > (duplicates are allowed, so there can still be items with Y=m), and > also when I am picking , there should be no item with > Y=Unspecified that has a value of X that is equal or smaller than n. > > E.g. if I have these 6 items (ignore the lines between the items for > now): > > <104,U>--<105,U>--<106,4> >/ > <101,U>--<100,U>--<102,3>--<104,4> > > I would want to pick them up in this order: > > <106,4> <105,U> <104,U> <104,4> <102,3> <101,U> <100,U> Note that with the above specification, a possible solution is to show all the items with Y=Unspecified before showing others, but that would not be ideal for the intended use case; pretending Y=U as if Y=max_range is not a usable workaround. This is "I create a stream of items with specified Y in descending order. There are some items with Y=Unspecified and I want to find appropriate places to mix the latter into that stream". Because the desired ordering is not a total order, I need to go to the "pair of priority list" route, I think. > > I see how this can easily be done by using a two priority lists, > i.e. one for items with Y=Unspecified that is sorted by X, and the > other for all other items that is sorted by . Peek the top of > both, and pick the top of the former until its X is smaller than the > value of X of the top of the latter, otherwise pick the top of the > latter. I am wondering if I can use less complex data structure, > like a single ordered sorted array, with a clever comparison > function. > > For the curious, the items in the above picture represents commits, > and lines are ancestry chains between them. I am thinking how we can > extend the still_interesting() function with an optional generation > number. -- 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 6/7] completion: get rid of __gitcomp_1
On Wed, Apr 10, 2013 at 7:35 AM, John Keeping wrote: > On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote: >> On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras >> wrote: >> > we traverse the words ourselves both in __gitcompadd, and __gitcomp_1. >> >> s/ourselves/ourself/ > > Huh? "we traverse ... ourselves" is correct since "ourselves" is > associated with the "we". I don't think "ourself" is ever correct in > normal usage - the dictionary notes that it applies only to the "royal > we". Late-night lapse. Thanks for the correction. -- 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] submodule: add verbose mode for add/update
Executes checkout without -q
---
git-submodule.sh | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
] [--] []
+USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
] [-v|--verbose] [--] []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] deinit [-f|--force] [--] ...
- or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--]
[...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ] [--merge] [--recursive]
[-v|--verbose] [--] [...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive]
or: $dashless [--quiet] sync [--recursive] [--] [...]"
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it." >&2
module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" ||
exit
(
clear_local_git_env
+ if test -z "$VERBOSE"
+ then
+ subquiet=-q
+ fi
cd "$sm_path" &&
# ash fails to wordsplit ${branch:+-b "$branch"...}
case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
+ '') git checkout -f $subquiet ;;
+ ?*) git checkout -f $subquiet -B "$branch"
"origin/$branch" ;;
esac
) || die "$(eval_gettext "Unable to checkout submodule
'\$sm_path'")"
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update="checkout"
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?")"
must_die_on_failure=yes
;;
*)
- command="git checkout $subforce -q"
+ if test -z "$VERBOSE"
+ then
+ subquiet=-q
+ fi
+ command="git checkout $subforce $subquiet"
die_msg="$(eval_gettext "Unable to checkout
'\$sha1' in submodule path '\$prefix\$sm_path'")"
say_msg="$(eval_gettext "Submodule path
'\$prefix\$sm_path': checked out '\$sha1'")"
;;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] glossary: extend "detached HEAD" description
W dniu 10.04.2013 16:45, Junio C Hamano pisze: > Jakub Narębski writes: > >> Junio C Hamano wrote: >> >>> diff --git a/Documentation/glossary-content.txt >>> b/Documentation/glossary-content.txt >>> index f928b57..69c90d1 100644 >>> --- a/Documentation/glossary-content.txt >>> +++ b/Documentation/glossary-content.txt >>> @@ -100,9 +100,22 @@ to point at the new commit. >>> >>> [[def_detached_HEAD]]detached HEAD:: >>> Normally the <> stores the name of a >>> - <>. However, git also allows you to >>> <> >>> - an arbitrary <> that isn't necessarily the tip of any >>> - particular branch. In this case HEAD is said to be "detached". >>> + <>, and commands that operate on the >>> + history HEAD represents operate on the history leading to the >>> + tip of the branch the HEAD points at. However, Git also >>> + allows you to <> an arbitrary >>> + <> that isn't necessarily the tip of any >>> + particular branch. The HEAD in such a state is called >>> + "detached". >> >> Should we also add that "git branch" output shows this situation >> as "(no branch)"? >> >> Nb. this is not documented in git-branch(1) manpage either... > > Sounds good. Please make it so, perhaps for both. Err... I can try to add such documentation in git-branch(1), but shouldn't I wait for your changes to glossary before adding info about "(no branch)"? P.S. From some StackOverflow questions the connection between "(no branch)" and detached HEAD is not clear for git newbies... -- Jakub Narębski -- 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] archive: clarify explanation of --worktree-attributes
On Wed, Apr 10, 2013 at 1:49 PM, René Scharfe wrote: > Make it a bit clearer that --worktree-attributes is about files in the > working tree (checked out files, possibly changed) and not the current > working directory ($PDW). Link to the ATTRIBUTES section, which has s/PDW/PWD/ > more details. > > Reported-by: Amit Bakshi > Signed-off-by: Rene Scharfe -- 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] git-imap-send.txt: remove the use of sslverify=false in GMail example
Barbu Paul - Gheorghe writes: > Since GMail is SSL capable there is no need to set sslverify to false, the > example using it may confuse readers that it's needed since it's also used in > the previous example configurations, too > > Signed-off-by: Barbu Paul - Gheorghe > --- Thanks. While removing that item from the configuration is a good thing to do in the post 1.8.2.1 era, the reason why it is does not have much to do with "GMail is SSL capable". The configuration item is not about "Do we connect over SSL when talking to this host?", but is about "When we use SSL with this host, do we verify the certificate it gave us?". The reason why we can run with sslverify=true against gmail is because we know imap.gmail.com gives a validly signed certificate that leads all the way to a root CA the user's OpenSSL installation is likely to trust (if your hand-rolled imap-over-ssl server uses a snakeoil certificate, even though the server may be "SSL capable", you may not be able to successfully connect to it without sslverify turned off). Side note. Before 1.8.2 and/or 1.8.1.4, git-imap-send did not implement sslverify correctly; CVS-2013-0308 was inherited from its origin "isync", where it _did_ verify the certificate is valid, but did not make sure the certificate was for the host it thought it was talking with. Also note that 1.8.2.1 and/or 1.8.1.6 were the first versions that support Server Name Identification (RFC4366). Connection with older versions of git-imap-send over SSL to hosts like googlemail.com that multi-home different SSL hosts can receive a valid certificate for another host that sits at the same IP address, which will lead to the sslverify check to fail. > Documentation/git-imap-send.txt | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt > index 875d283..b15dffe 100644 > --- a/Documentation/git-imap-send.txt > +++ b/Documentation/git-imap-send.txt > @@ -123,7 +123,6 @@ to specify your account settings: > host = imaps://imap.gmail.com > user = u...@gmail.com > port = 993 > - sslverify = false > - > You might need to instead use: folder = "[Google Mail]/Drafts" if you get > an error -- 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: segfault in git-remote-http
On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote: > > which should show both program names. Git invokes git-remote-* based > > on the URL you fed it. So if you are seeing a segfault in > > git-remote-http, presumably you fed it an http URL (which may still > > execute SSL code if it redirects to an https URL). > > Here's the command I ran (from initial post): > git clone https://github.com/bitcoin/bitcoin.git > > This returns no error on the command line and produced the segfault > reported by the kernel. git clone returns immediately. It does correctly report a failed exit code. The lack of message is because git assumes that the helper will produce a useful message before dying, but obviously it doesn't. There's already a patch[1] to fix this, but it hasn't been merged yet. As for why dmesg reports git-remote-http, I'm not sure. If you "strace -f" the command, you can see that git is running git-remote-https. Why the kernel chooses to report "git-remote-http", I don't know; you'd have to look into how the kernel makes that decision. But I doubt it is related to the reason for the segfault in the first place. -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: [ITCH] Specify refspec without remote
Jeff King writes:
>> With the branch.$name.remote, the user tells us "When I am on this
>> branch, I want to talk to this remote". When you did
>>
>> git push -- master next ;# case #4
>>
>> on branch maint, branch.maint.remote should not come into play.
>
> I understand that's your position, but I don't understand _why_.
>
> If branch.$name.remote is "when I am on this branch, I want to talk to
> this remote", that rule is not be impacted by the presence of refspecs
> at all.
So running the above while on 'maint' will send master and next to
the remote your "git push" would send to when run without any
refspecs?
That is internally consistent and understandable, and I have no
objection to it. Certainly much better than basing the decision on
branch.{master,next}.remote as I thought you were suggesting 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
Re: [PATCH] archive: clarify explanation of --worktree-attributes
René Scharfe writes: > Make it a bit clearer that --worktree-attributes is about files in the > working tree (checked out files, possibly changed) and not the current > working directory ($PDW). Link to the ATTRIBUTES section, which has > more details. > > Reported-by: Amit Bakshi > Signed-off-by: Rene Scharfe > --- > Does this help a bit? I personally thought that the original was already clear enough (especially when taken in the context of Git), but the new wording is not too verbose and should help avoiding misinterpretation. Thanks. > > Documentation/git-archive.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt > index b4c2e24..3dd3069 100644 > --- a/Documentation/git-archive.txt > +++ b/Documentation/git-archive.txt > @@ -56,7 +56,8 @@ OPTIONS > Write the archive to instead of stdout. > > --worktree-attributes:: > - Look for attributes in .gitattributes in working directory too. > + Look for attributes in .gitattributes files in the working tree > + as well (see <>). > > :: > This can be any options that the archiver backend understands. -- 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: [msysGit] Script for handling UTF-16 files
Am 10.04.2013 01:47, schrieb Ken Ismert: > > I bumped into the UTF-16 display problem with Git Extensions running on top > of msysGit. After lots of searching and experimenting, I came up with a > solution that works for me. > > Note: Please see questions below. > > This method is for MSysGit 1.8.1, and is tested on Windows XP. I use Git > Extensions 2.44, but since the changes are at the Git level, they should work > for Git Gui as well. Steps: There has been a discussion about handling UTF-16 on the git ML a while back, see http://thread.gmane.org/gmane.comp.version-control.git/159708 As suggested there, I would try to use a clean/smudge filter (i.e. store UTF-16 files as UTF-8 in the repository and convert back to UTF-16 on checkout). That way git can treat your UTF-16 files as text in most cases (i.e. you can merge them, git-grep works, gitattributes work (eol-conversion, ident-replacement, built-in diff patterns...)). If you use a textconv filter, UTF-16 content will be treated as binary by most git operations. There's also an 'encoding' attribute and a 'gui.encoding' setting which in theory should solve your issue (i.e. specify encoding of files for display by GUI tools). I don't know if Git Extensions supports that, or whether its supposed to work for binary files at all. > 3) Modify the global ~/Git/etc/gitconfig or your local ~/.git/config file, > and add these lines: > > [diff "astextutf16"] > textconv = astextutf16 Why not simply "textconv = iconv -f utf-16 -t utf-8", without the extra script? > c) I had success with iconv, but is there any built-in UTF-16 to UTF-8 > converter that ships with msysGit? There are ready-to-use UTF-conversion functions in the codebase, but these are not accessible as a git command or built-in filter. > As a quick fix, how hard would it be to add a 'utf16' diff filter, similar to > cpp or |csharp? Or is this simply the wrong place to put in a work-around? As described above, I think a diff filter is not the right tool for the job. The only universal format for text content that works reasonably well with established text-based technologies (merge algorithms, regex etc.) is UTF-8. If we want to benefit from these technologies, git should store text files as UTF-8 and convert from / to platform-specific formats on checkin / checkout or for display. Bye, Karsten -- 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: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> > If branch.$name.remote is "when I am on this branch, I want to talk to
> > this remote", that rule is not be impacted by the presence of refspecs
> > at all.
>
> So running the above while on 'maint' will send master and next to
> the remote your "git push" would send to when run without any
> refspecs?
Exactly. The remote selection is orthogonal to the refspecs provided,
and only cares about which branch you are on.
Which is still kind of weird, because why should the branch you are on
affect the default push location? But that is how default "matching" has
always behaved, and we would remain consistent with that.
> That is internally consistent and understandable, and I have no
> objection to it. Certainly much better than basing the decision on
> branch.{master,next}.remote as I thought you were suggesting to do.
No, I am not suggesting that. I can see how such a command might be
useful (i.e. "push master to where it goes, next to where it goes",
where "goes" is defined by the upstream config). But that is not
remotely close to how "git push" works now, and would be inconsistent
with the other modes (e.g., matching, explicit refspecs, pushing
non-branches, etc).
-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
[PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB
key event, so that the gitk application window is brought
from bottom to top.
Signed-off-by: Tair Sabirgaliev
---
gitk | 13 +
1 file changed, 13 insertions(+)
diff --git a/gitk b/gitk
index 572f73f..60a87fc 100755
--- a/gitk
+++ b/gitk
@@ -11687,6 +11687,19 @@ if {[catch {package require Tk 8.4} err]} {
exit 1
}
+# On OSX workaround the Tcl/Tk windows going down the stack of Cmd-TAB
+if {[tk windowingsystem] eq "aqua"} {
+exec osascript -e {
+tell application "System Events"
+key down command
+key down shift
+keystroke tab
+key up shift
+key up command
+end tell+}
+}
+
# Unset GIT_TRACE var if set
if { [info exists ::env(GIT_TRACE)] } {
unset ::env(GIT_TRACE)
--
1.8.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
Currently, humanization of downloaded size is done in the same
function as text formatting in 'process.c'. This is an issue if anyone
else wants to use this.
Separate text formatting from size simplification and make the function
public in strbuf so that it can easily be used by other clients.
We now can use strbuf_humanize() for both downloaded size and download
speed calculation. One of the drawbacks is that speed will now look like
this when download is stalled: "0 bytes/s" instead of "0 KiB/s".
Signed-off-by: Antoine Pelisse
---
Documentation/technical/api-strbuf.txt |5
progress.c | 43 +++-
strbuf.c | 19 ++
strbuf.h |1 +
4 files changed, 40 insertions(+), 28 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt
b/Documentation/technical/api-strbuf.txt
index 2c59cb2..7b6ecda 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -230,6 +230,11 @@ which can be used by the programmer of the callback as she
sees fit.
destination. This is useful for literal data to be fed to either
strbuf_expand or to the *printf family of functions.
+`strbuf_humanize`::
+
+ Append the given byte size as a human-readable string (i.e. 12.23 KiB,
+ 3.50 MiB).
+
`strbuf_addf`::
Add a formatted string to the buffer.
diff --git a/progress.c b/progress.c
index 3971f49..8e09058 100644
--- a/progress.c
+++ b/progress.c
@@ -10,6 +10,7 @@
#include "git-compat-util.h"
#include "progress.h"
+#include "strbuf.h"
#define TP_IDX_MAX 8
@@ -112,34 +113,14 @@ static int display(struct progress *progress, unsigned n,
const char *done)
return 0;
}
-static void throughput_string(struct throughput *tp, off_t total,
+static void throughput_string(struct strbuf *buf, off_t total,
unsigned int rate)
{
- int l = sizeof(tp->display);
- if (total > 1 << 30) {
- l -= snprintf(tp->display, l, ", %u.%2.2u GiB",
- (int)(total >> 30),
- (int)(total & ((1 << 30) - 1)) / 10737419);
- } else if (total > 1 << 20) {
- int x = total + 5243; /* for rounding */
- l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
- x >> 20, ((x & ((1 << 20) - 1)) * 100) >> 20);
- } else if (total > 1 << 10) {
- int x = total + 5; /* for rounding */
- l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
- x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
- } else {
- l -= snprintf(tp->display, l, ", %u bytes", (int)total);
- }
-
- if (rate > 1 << 10) {
- int x = rate + 5; /* for rounding */
- snprintf(tp->display + sizeof(tp->display) - l, l,
-" | %u.%2.2u MiB/s",
-x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
- } else if (rate)
- snprintf(tp->display + sizeof(tp->display) - l, l,
-" | %u KiB/s", rate);
+ strbuf_addstr(buf, ", ");
+ strbuf_humanize(buf, total);
+ strbuf_addstr(buf, " | ");
+ strbuf_humanize(buf, rate * 1024);
+ strbuf_addstr(buf, "/s");
}
void display_throughput(struct progress *progress, off_t total)
@@ -183,6 +164,7 @@ void display_throughput(struct progress *progress, off_t
total)
misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
if (misecs > 512) {
+ struct strbuf buf = STRBUF_INIT;
unsigned int count, rate;
count = total - tp->prev_total;
@@ -197,7 +179,9 @@ void display_throughput(struct progress *progress, off_t
total)
tp->last_misecs[tp->idx] = misecs;
tp->idx = (tp->idx + 1) % TP_IDX_MAX;
- throughput_string(tp, total, rate);
+ throughput_string(&buf, total, rate);
+ strncpy(tp->display, buf.buf, sizeof(tp->display));
+ strbuf_release(&buf);
if (progress->last_value != -1 && progress_update)
display(progress, progress->last_value, NULL);
}
@@ -253,9 +237,12 @@ void stop_progress_msg(struct progress **p_progress, const
char *msg)
bufp = (len < sizeof(buf)) ? buf : xmalloc(len + 1);
if (tp) {
+ struct strbuf strbuf = STRBUF_INIT;
unsigned int rate = !tp->avg_misecs ? 0 :
tp->avg_bytes / tp->avg_misecs;
- throughput_string(tp, tp->curr_total, rate);
+ throughput_string(&strbuf, tp->curr_total, rate);
+ strncpy(tp->display, strbuf.buf, sizeof(tp->display));
+ strb
[PATCH 2/2] count-objects: add -H option to humanize sizes
Use the new humanize() function to print loose objects size, pack size,
and garbage size in verbose mode, or loose objects size in regular mode.
This patch doesn't change the way anything is displayed when the option
is not used.
Also update the documentation.
Signed-off-by: Antoine Pelisse
---
Documentation/git-count-objects.txt | 14 ---
builtin/count-objects.c | 46 +--
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-count-objects.txt
b/Documentation/git-count-objects.txt
index da6e72e..b300e84 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -8,7 +8,7 @@ git-count-objects - Count unpacked number of objects and their
disk consumption
SYNOPSIS
[verse]
-'git count-objects' [-v]
+'git count-objects' [-v] [-H | --human-readable]
DESCRIPTION
---
@@ -24,11 +24,11 @@ OPTIONS
+
count: the number of loose objects
+
-size: disk space consumed by loose objects, in KiB
+size: disk space consumed by loose objects, in KiB (unless -H is specified)
+
in-pack: the number of in-pack objects
+
-size-pack: disk space consumed by the packs, in KiB
+size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
+
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
@@ -36,7 +36,13 @@ the packs. These objects could be pruned using `git
prune-packed`.
garbage: the number of files in object database that are not valid
loose objects nor valid packs
+
-size-garbage: disk space consumed by garbage files, in KiB
+size-garbage: disk space consumed by garbage files, in KiB (unless -H is
+specified)
+
+-H::
+--human-readable::
+
+Print sizes in human readable format
GIT
---
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 0343e35..935ad9e 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -79,13 +79,13 @@ static void count_objects(DIR *d, char *path, int len, int
verbose,
}
static char const * const count_objects_usage[] = {
- N_("git count-objects [-v]"),
+ N_("git count-objects [-v] [-H | --human-readable]"),
NULL
};
int cmd_count_objects(int argc, const char **argv, const char *prefix)
{
- int i, verbose = 0;
+ int i, verbose = 0, human_readable = 0;
const char *objdir = get_object_directory();
int len = strlen(objdir);
char *path = xmalloc(len + 50);
@@ -93,6 +93,8 @@ int cmd_count_objects(int argc, const char **argv, const char
*prefix)
off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(&verbose, N_("be verbose")),
+ OPT_BOOLEAN('H', "human-readable", &human_readable,
+ N_("print sizes in human readable format")),
OPT_END(),
};
@@ -119,6 +121,9 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
struct packed_git *p;
unsigned long num_pack = 0;
off_t size_pack = 0;
+ struct strbuf loose_buf = STRBUF_INIT;
+ struct strbuf pack_buf = STRBUF_INIT;
+ struct strbuf garbage_buf = STRBUF_INIT;
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
@@ -130,17 +135,42 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
size_pack += p->pack_size + p->index_size;
num_pack++;
}
+
+ if (human_readable) {
+ strbuf_humanize(&loose_buf, loose_size);
+ strbuf_humanize(&pack_buf, size_pack);
+ strbuf_humanize(&garbage_buf, size_garbage);
+ }
+ else {
+ strbuf_addf(&loose_buf, "%lu",
+ (unsigned long)(loose_size / 1024));
+ strbuf_addf(&pack_buf, "%lu",
+ (unsigned long)(size_pack / 1024));
+ strbuf_addf(&garbage_buf, "%lu",
+ (unsigned long)(size_garbage / 1024));
+ }
+
printf("count: %lu\n", loose);
- printf("size: %lu\n", (unsigned long) (loose_size / 1024));
+ printf("size: %s\n", loose_buf.buf);
printf("in-pack: %lu\n", packed);
printf("packs: %lu\n", num_pack);
- printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
+ printf("size-pack: %s\n", pack_buf.buf);
printf("prune-packable: %lu\n", packed_loose);
printf("garbage: %lu\n", garbage);
- printf("size-garbage: %lu\n", (unsigned long) (size_garbage /
1024));
+ printf("size-garba
Re: segfault in git-remote-http
On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
> As for why dmesg reports git-remote-http, I'm not sure. If you "strace
> -f" the command, you can see that git is running git-remote-https. Why
> the kernel chooses to report "git-remote-http", I don't know; you'd have
> to look into how the kernel makes that decision. But I doubt it is
> related to the reason for the segfault in the first place.
Ah, I see. The hard links are a red herring. The kernel's message uses
task->comm, which is presumably set by truncating the basename of the
program to 15 characters (16 bytes with a trailing NUL).
3.6 /proc//comm & /proc//task//comm
These files provide a method to access a tasks comm value. It also
allows for a task to set its own or one of its thread siblings comm
value. The comm value is limited in size compared to the cmdline
value, so writing anything longer then the kernel's TASK_COMM_LEN
(currently 16 chars) will result in a truncated comm value.
Try:
$ echo 'int main() { sleep(5); *(int *)0=0; }' >foo.c
$ gcc -o 12345678901234567890 foo.c
$ ./123* &
$ cat /proc/$!/comm
123456789012345
$ sleep 5; dmesg | tail -n 1
[2602639.353584] 123456789012345[23062]: segfault at 0 ip 00400524 sp
7fff46bb0700 error 6 in 12345678901234567890[40+1000]
In both cases we only get the first 15 bytes of the program name. And
indeed, "git-remote-http" is exactly 15 bytes. So it is dumb luck that
the limit is such that truncating the name makes it look like another
program.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX
The prev message was garbled :( Here is the correct patch (I hope).
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB
key event, so that the gitk application window is brought
from bottom to top.
Signed-off-by: Tair Sabirgaliev
---
gitk | 13 +
1 file changed, 13 insertions(+)
diff --git a/gitk b/gitk
index 572f73f..60a87fc 100755
--- a/gitk
+++ b/gitk
@@ -11687,6 +11687,19 @@ if {[catch {package require Tk 8.4} err]} {
exit 1
}
+# On OSX workaround the Tcl/Tk windows going down the stack of Cmd-TAB
+if {[tk windowingsystem] eq "aqua"} {
+exec osascript -e {
+tell application "System Events"
+key down command
+key down shift
+keystroke tab
+key up shift
+key up command
+end tell
+}
+}
+
# Unset GIT_TRACE var if set
if { [info exists ::env(GIT_TRACE)] } {
unset ::env(GIT_TRACE)
--
1.8.2
--
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 08/20] remote-hg: split bookmark handling
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras wrote: > --- a/contrib/remote-helpers/git-remote-hg > +++ b/contrib/remote-helpers/git-remote-hg > @@ -731,6 +722,26 @@ def do_export(parser): > if peer: > parser.repo.push(peer, force=False) > > +# handle bookmarks > +for bmark, node in p_bmarks: > +ref = 'refs/heads' + bmark This should be: ref = 'refs/heads/' + bmark Should I reroll? -- 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 v3 12/20] remote-hg: push to the appropriate branch
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
wrote:
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -625,6 +625,10 @@ def parse_commit(parser):
> if merge_mark:
> get_merge_files(repo, p1, p2, files)
>
> +# Check if the ref is supposed to be a named branch
> +if ref.startswith('refs/heads/branches/'):
> +extra['branch'] = ref.replace('refs/heads/branches/', '')
This should be more consistent with the rest of the code:
branch = ref[len('refs/heads/branches/'):]
Should I reroll?
--
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: git rebase : knowing where I am...
Junio C Hamano writes: > Jeremy Rosen writes: > >> is there some way to know how far you are within a rebase when the >> rebase is interupted by a conflict other than the message given by >> git rebase when it was interrupted ? > > I do not think there is a "git $anything" command to do that, but in > the meantime you could "cat .git/rebase-*/git-rebase-todo" or > something. > > Recent trend is to teach "git status" more about these internal states, > so with time the command may learn to include this in its output. I actually often do this myself, not "cat anything" as I mentioned above: git show-branch $branch_I_am_rebasing HEAD -- 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: [ITCH] Specify refspec without remote
Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
>> > If branch.$name.remote is "when I am on this branch, I want to talk to
>> > this remote", that rule is not be impacted by the presence of refspecs
>> > at all.
>>
>> So running the above while on 'maint' will send master and next to
>> the remote your "git push" would send to when run without any
>> refspecs?
>
> Exactly. The remote selection is orthogonal to the refspecs provided,
> and only cares about which branch you are on.
>
> Which is still kind of weird, because why should the branch you are on
> affect the default push location? But that is how default "matching" has
> always behaved, and we would remain consistent with that.
git push -- master next; pushes to my current branch's
branch..pushremote? Isn't that a disaster?
>> That is internally consistent and understandable, and I have no
>> objection to it. Certainly much better than basing the decision on
>> branch.{master,next}.remote as I thought you were suggesting to do.
>
> No, I am not suggesting that. I can see how such a command might be
> useful (i.e. "push master to where it goes, next to where it goes",
> where "goes" is defined by the upstream config). But that is not
> remotely close to how "git push" works now, and would be inconsistent
> with the other modes (e.g., matching, explicit refspecs, pushing
> non-branches, etc).
Otherwise, I think we're consistent. git push master; pushes the
refspec master (with no explicit : counterpart) to the "default
place to push to" (either depending on which branch I am, or global).
I think Junio was mixing up refspecs with refs (branches, and hence
branch configuration) earlier. git push origin; pushes to "default
refspecs" on the remote origin. By extension, git push; should push
"default respecs" to the "default place to push to". The "default
refspecs" in this context is determined by push.default, which is the
problem.
--
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: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: > Otherwise, I think we're consistent. git push master; pushes the > refspec master (with no explicit : counterpart) to the "default > place to push to" (either depending on which branch I am, or global). > I think Junio was mixing up refspecs with refs (branches, and hence > branch configuration) earlier. git push origin; pushes to "default > refspecs" on the remote origin. By extension, git push; should push > "default respecs" to the "default place to push to". The "default > refspecs" in this context is determined by push.default, which is the > problem. Major thinko here. The problem is git push master; choosing the "default place to push to" depending on what branch I'm in. A plain git push; is just fine. -- 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] glossary: extend "detached HEAD" description
Jakub Narębski writes: > P.S. From some StackOverflow questions the connection between "(no > branch)" and detached HEAD is not clear for git newbies... If _that_ is the problem you are really trying to address, the output from recent Git already says "(detached from xx)" or something, so I suspect there is nothing to fix in the glossary. We are exposing the word "detached" more to the UI, so that people who do not know what it means can come to the glossary. >>> Should we also add that "git branch" output shows this situation >>> as "(no branch)"? I guess "(no branch)" is no longer necessarily what we output from there, so the updated description for "git branch" needs to be a bit different from "the command says (no branch) when detached", but I think it still is a good idea to mention what the user is expected to see. 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 v3 08/20] remote-hg: split bookmark handling
Felipe Contreras writes: > On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras > wrote: > >> --- a/contrib/remote-helpers/git-remote-hg >> +++ b/contrib/remote-helpers/git-remote-hg > >> @@ -731,6 +722,26 @@ def do_export(parser): >> if peer: >> parser.repo.push(peer, force=False) >> >> +# handle bookmarks >> +for bmark, node in p_bmarks: >> +ref = 'refs/heads' + bmark > > This should be: > > ref = 'refs/heads/' + bmark > > Should I reroll? I'd appreciate it if you can reroll the entire thing. That way, I do not have to keep careful track of which one can be reused and which need to be replaced. 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 1/2] strbuf: create strbuf_humanize() to show byte sizes
Antoine Pelisse wrote: > Separate text formatting from size simplification and make the function > public in strbuf so that it can easily be used by other clients. > > We now can use strbuf_humanize() for both downloaded size and download > speed calculation. Sounds like a good thing to do. >One of the drawbacks is that speed will now look like > this when download is stalled: "0 bytes/s" instead of "0 KiB/s". At first glance that is neither obviously a benefit nor obviously a drawback. Can you spell this out more? > --- a/Documentation/technical/api-strbuf.txt > +++ b/Documentation/technical/api-strbuf.txt > @@ -230,6 +230,11 @@ which can be used by the programmer of the callback as > she sees fit. > destination. This is useful for literal data to be fed to either > strbuf_expand or to the *printf family of functions. > > +`strbuf_humanize`:: > + > + Append the given byte size as a human-readable string (i.e. 12.23 KiB, > + 3.50 MiB). Based on the function name alone, it is not easy to guess what it will do (e.g., maybe it will paraphrase 3 to "three" and 1000 to "enormous"). How about something like strbuf_filesize? If I understand the code correctly, this jumps units each time it exceeds 1.0 of the next unit (bytes, KiB, MiB, GiB), which sounds like a fine behavior. Hope that helps, Jonathan -- 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: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote: > >> > If branch.$name.remote is "when I am on this branch, I want to talk to > >> > this remote", that rule is not be impacted by the presence of refspecs > >> > at all. > >> > >> So running the above while on 'maint' will send master and next to > >> the remote your "git push" would send to when run without any > >> refspecs? > > > > Exactly. The remote selection is orthogonal to the refspecs provided, > > and only cares about which branch you are on. > > > > Which is still kind of weird, because why should the branch you are on > > affect the default push location? But that is how default "matching" has > > always behaved, and we would remain consistent with that. > > git push -- master next; pushes to my current branch's > branch..pushremote? Isn't that a disaster? Maybe. But no more so than the current: git push which may also push master and next to the same remote. As I said in an earlier message, I would be OK with allowing both or neither, but allowing one but not the other is even more confusing. If we changed push.default=matching to ignore branch.*.remote, then that would be consistent, and would probably be safer over all. It is a regression, but I doubt that anybody was using branch.*.remote for this; it really only makes sense with the "upstream" mode. -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: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: > git push -- master next; pushes to my current branch's > branch..pushremote? Isn't that a disaster? Actually, branch..pushremote already breaks the current design in a way, as Junio pointed out in a different email: a push.default set to anything except "current" is already nonsensical. Why should "matching" branches be pushed to the remote that my current branch specifies? That might well have their own branch..pushremote configured, which should be respected. We should fix this now. I think the fault lies in the rather old design of push.default. Do you have any suggestions as what would make sense here? Ultimately, I think a git push; needs to pick remotes for each refspec separately. The orthogonal design is definitely not right in my opinion. As the author of branch..pushremote, I apologize for not having caught this earlier. I've been using push.default = current for a long time, and don't often think about the other settings. -- 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: segfault in git-remote-http
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote: > > > This returns no error on the command line and produced the segfault > > > reported by the kernel. git clone returns immediately. > > > > It does correctly report a failed exit code. The lack of message is > > because git assumes that the helper will produce a useful message > > before dying, but obviously it doesn't. There's already a patch[1] > > to fix this, but it hasn't been merged yet. > > Oh yeah, I didn't check $? but I got sidetracked seeing the segfault. I forgot to link to the patch, but it's: http://article.gmane.org/gmane.comp.version-control.git/220427 -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
Antoine Pelisse writes:
> Currently, humanization of downloaded size is done in the same
> function as text formatting in 'process.c'. This is an issue if anyone
> else wants to use this.
>
> Separate text formatting from size simplification and make the function
> public in strbuf so that it can easily be used by other clients.
>
> We now can use strbuf_humanize() for both downloaded size and download
> speed calculation. One of the drawbacks is that speed will now look like
> this when download is stalled: "0 bytes/s" instead of "0 KiB/s".
Personally, I do not think the "drawback" is so big an issue. If
the caller really cares, we could always add another parameter to
this formatter to tell it the minimum unit we care about (e.g. pass
1024 to say "Don't bother showing scale lower than kibi").
This is a bit late response, but if we ever want to count something
in a dimention other than "bytes", like time (e.g. "kiloseconds") or
number of commits (e.g. "centicommits"), etc., we cannot reuse this
formatter very easily. We may want to have "byte" somewhere in its
name for now to make sure the callers understand its limitation.
I'll tentatively rename it to "strbuf_humanize_bytes()" while queuing.
Thanks.
> Signed-off-by: Antoine Pelisse
> ---
> Documentation/technical/api-strbuf.txt |5
> progress.c | 43
> +++-
> strbuf.c | 19 ++
> strbuf.h |1 +
> 4 files changed, 40 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/technical/api-strbuf.txt
> b/Documentation/technical/api-strbuf.txt
> index 2c59cb2..7b6ecda 100644
> --- a/Documentation/technical/api-strbuf.txt
> +++ b/Documentation/technical/api-strbuf.txt
> @@ -230,6 +230,11 @@ which can be used by the programmer of the callback as
> she sees fit.
> destination. This is useful for literal data to be fed to either
> strbuf_expand or to the *printf family of functions.
>
> +`strbuf_humanize`::
> +
> + Append the given byte size as a human-readable string (i.e. 12.23 KiB,
> + 3.50 MiB).
> +
> `strbuf_addf`::
>
> Add a formatted string to the buffer.
> diff --git a/progress.c b/progress.c
> index 3971f49..8e09058 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -10,6 +10,7 @@
>
> #include "git-compat-util.h"
> #include "progress.h"
> +#include "strbuf.h"
>
> #define TP_IDX_MAX 8
>
> @@ -112,34 +113,14 @@ static int display(struct progress *progress, unsigned
> n, const char *done)
> return 0;
> }
>
> -static void throughput_string(struct throughput *tp, off_t total,
> +static void throughput_string(struct strbuf *buf, off_t total,
> unsigned int rate)
> {
> - int l = sizeof(tp->display);
> - if (total > 1 << 30) {
> - l -= snprintf(tp->display, l, ", %u.%2.2u GiB",
> - (int)(total >> 30),
> - (int)(total & ((1 << 30) - 1)) / 10737419);
> - } else if (total > 1 << 20) {
> - int x = total + 5243; /* for rounding */
> - l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
> - x >> 20, ((x & ((1 << 20) - 1)) * 100) >> 20);
> - } else if (total > 1 << 10) {
> - int x = total + 5; /* for rounding */
> - l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
> - x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
> - } else {
> - l -= snprintf(tp->display, l, ", %u bytes", (int)total);
> - }
> -
> - if (rate > 1 << 10) {
> - int x = rate + 5; /* for rounding */
> - snprintf(tp->display + sizeof(tp->display) - l, l,
> - " | %u.%2.2u MiB/s",
> - x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
> - } else if (rate)
> - snprintf(tp->display + sizeof(tp->display) - l, l,
> - " | %u KiB/s", rate);
> + strbuf_addstr(buf, ", ");
> + strbuf_humanize(buf, total);
> + strbuf_addstr(buf, " | ");
> + strbuf_humanize(buf, rate * 1024);
> + strbuf_addstr(buf, "/s");
> }
>
> void display_throughput(struct progress *progress, off_t total)
> @@ -183,6 +164,7 @@ void display_throughput(struct progress *progress, off_t
> total)
> misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
>
> if (misecs > 512) {
> + struct strbuf buf = STRBUF_INIT;
> unsigned int count, rate;
>
> count = total - tp->prev_total;
> @@ -197,7 +179,9 @@ void display_throughput(struct progress *progress, off_t
> total)
> tp->last_misecs[tp->idx] = misecs;
> tp->idx = (tp->idx + 1) % TP_IDX_MAX;
>
> - throughput_string(tp, total, rate);
> + throughput_string(&buf, total, rate);
> + strncpy(tp->display, buf.buf, sizeof(tp->displa
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
On Wed, Apr 10, 2013 at 9:43 PM, Jonathan Nieder wrote: > Antoine Pelisse wrote: >>One of the drawbacks is that speed will now look like >> this when download is stalled: "0 bytes/s" instead of "0 KiB/s". > > At first glance that is neither obviously a benefit nor obviously a > drawback. Can you spell this out more? The drawback to me is that it changes the user experience with no reason. But that's really a minor change, I agree. (maybe I should have put it as a comment/question after ---) >> --- a/Documentation/technical/api-strbuf.txt >> +++ b/Documentation/technical/api-strbuf.txt >> @@ -230,6 +230,11 @@ which can be used by the programmer of the callback as >> she sees fit. >> destination. This is useful for literal data to be fed to either >> strbuf_expand or to the *printf family of functions. >> >> +`strbuf_humanize`:: >> + >> + Append the given byte size as a human-readable string (i.e. 12.23 KiB, >> + 3.50 MiB). > > Based on the function name alone, it is not easy to guess what it will > do (e.g., maybe it will paraphrase 3 to "three" and 1000 to > "enormous"). How about something like strbuf_filesize? I think the suggestion from Junio makes more sense, as it can be used for download speed. > If I understand the code correctly, this jumps units each time it > exceeds 1.0 of the next unit (bytes, KiB, MiB, GiB), which sounds like > a fine behavior. The code has simply been extracted from the former function and kept unmodified. Thanks for the help ! 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: [PATCH] submodule: add verbose mode for add/update
Am 10.04.2013 20:24, schrieb Orgad Shaneh:
> Executes checkout without -q
Nice, looks like you picked the proposal I made last September:
http://permalink.gmane.org/gmane.comp.version-control.git/204747
The change is looking good, but you still need to document the
new option in Documentation/git-submodule.txt too please.
And the commit message is still too short, as I said in that
other thread:
On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann wrote:
> Before the "Signed-off-by" is the place where you should have
> explained why this would be a worthwhile change ;-)
And you answered to that with something that would really make
sense as first part of the commit message, because you explain
*why* you do that change:
Am 05.09.2012 13:42, schrieb Orgad and Raizel Shaneh:
> When I run 'git submodule update' I don't expect to be in the dark
> until the submodule/s finishes checkout, this sometimes can take a
> significant amount of time and feedback is expected.
Another paragraph after that should explain *how* you do it.
So what about the following as commit message:
--
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkout so the user sees progress output
from the checkout command.
--
I'm looking forward to your next iteration.
> ---
> git-submodule.sh | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 79bfaac..f7964ad 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -5,11 +5,11 @@
> # Copyright (c) 2007 Lars Hjemli
>
> dashless=$(basename "$0" | sed -e 's/-/ /')
> -USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
> ] [--] []
> +USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
> ] [-v|--verbose] [--] []
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
> or: $dashless [--quiet] init [--] [...]
> or: $dashless [--quiet] deinit [-f|--force] [--] ...
> - or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
> [-f|--force] [--rebase] [--reference ] [--merge] [--recursive]
> [--] [...]
> + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
> [-f|--force] [--rebase] [--reference ] [--merge] [--recursive]
> [-v|--verbose] [--] [...]
> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
> [commit] [--] [...]
> or: $dashless [--quiet] foreach [--recursive]
> or: $dashless [--quiet] sync [--recursive] [--] [...]"
> @@ -309,6 +309,9 @@ cmd_add()
> custom_name=$2
> shift
> ;;
> + -v|--verbose)
> + VERBOSE=1
> + ;;
> --)
> shift
> break
> @@ -408,11 +411,15 @@ Use -f if you really want to add it." >&2
> module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" ||
> exit
> (
> clear_local_git_env
> + if test -z "$VERBOSE"
> + then
> + subquiet=-q
> + fi
> cd "$sm_path" &&
> # ash fails to wordsplit ${branch:+-b "$branch"...}
> case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> + '') git checkout -f $subquiet ;;
> + ?*) git checkout -f $subquiet -B "$branch"
> "origin/$branch" ;;
> esac
> ) || die "$(eval_gettext "Unable to checkout submodule
> '\$sm_path'")"
> fi
> @@ -676,6 +683,9 @@ cmd_update()
> --checkout)
> update="checkout"
> ;;
> + -v|--verbose)
> + VERBOSE=1
> + ;;
> --)
> shift
> break
> @@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?")"
> must_die_on_failure=yes
> ;;
> *)
> - command="git checkout $subforce -q"
> + if test -z "$VERBOSE"
> + then
> + subquiet=-q
> + fi
> + command="git checkout $subforce $subquiet"
> die_msg="$(eval_gettext "Unable to checkout
> '\$sha1' in submodule path
Re: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: >> git push -- master next; pushes to my current branch's >> branch..pushremote? Isn't that a disaster? > > Actually, branch..pushremote already breaks the current design > in a way I don't see a big problem here, actually. What's so wrong with branch..remote affecting what "git push" does? If branch.crazy-feature.remote is my-personal-remote and I run git push and "[push] default = upstream", then it is obvious what the user wanted to happen. But what about when "[push] default = matching"? Which of the following behaviors is correct? a) Error: you didn't tell me which remote to push to. b) Just behave like "git push my-personal-remote :". c) Ignore which branch is the current branch and behave like "git push origin :". How about when "[push] default = current"? Except that people might have scripts or habits tied to the current behavior, any of (a), (b), and (c) sounds fine to me. (b) is the obvious choice for historical reasons. Now if I rely on the proposed DWIM and run git push master then the corresponding choices are: a) Error: you didn't tell me which remote to push to. b) Just behave like "git push my-personal-remote master". c) Behave like "git push origin master". (b) is not a good choice there, but (a) and (c) look equally fine. -- 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: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: > > git push -- master next; pushes to my current branch's > > branch..pushremote? Isn't that a disaster? > > Actually, branch..pushremote already breaks the current design > in a way, as Junio pointed out in a different email: a push.default > set to anything except "current" is already nonsensical. Why should > "matching" branches be pushed to the remote that my current branch > specifies? That might well have their own branch..pushremote > configured, which should be respected. I'm not sure that it should be respected. "master" is short for "refs/heads/master:refs/heads/master", and does not mean "push master to where I have it configured to go" at all. That may be what the user means, but changing how "git push" works is going to create inconsistency with other cases. > We should fix this now. I think the fault lies in the rather old > design of push.default. Do you have any suggestions as what would > make sense here? Ultimately, I think a git push; needs to pick > remotes for each refspec separately. The orthogonal design is > definitely not right in my opinion. Right, the example above might include multiple remotes if pushremote is respected. Or it might not come up with an answer at all for a tag. If you do: git push -- v1.2.3 master where does v1.2.3 go? To remote.pushdefault? That seems simple and consistent, as there is no ref-specific pushremote defined. But I'd guess that the user probably _wanted_ it to go to branch.master.pushremote. > As the author of branch..pushremote, I apologize for not having > caught this earlier. I've been using push.default = current for a > long time, and don't often think about the other settings. I don't think pushremote introduced the problem. It is much older than that, and dates back to respecting branch.*.remote at all for pushes, even though push.default=matching (and before we had push.default, it was always matching) does not have anything to do with the current branch. -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: [ITCH] Specify refspec without remote
Jeff King wrote: > Maybe. But no more so than the current: > > git push > > which may also push master and next to the same remote. I would argue that this was not really a problem in practice, until I introduced branch..pushremote. Let us imagine that I was working on artagnon/git.git (remote: ram), a fork of git/git.git (remote: origin) earlier. My fork contains the link and implicit-push branches in addition to the master, next and pu branches, which are present on both. When I push from my implicit-push branch with push.default = matching, I'm updating all the matching refs on the remote ram (since branch.implicit-push.remote is set to ram), which is fine. Now, I git push while on branch master. My push is simply rejected, as I don't have write access to the remote origin. This is designed exactly for the read-only upstream, read-write fork scenario. If I had write access to upstream (where we're essentially regression to a centralized model), we'd have some major confusion. > As I said in an > earlier message, I would be OK with allowing both or neither, but > allowing one but not the other is even more confusing. What is the point of allowing something internally consistent, but nonsensical? You should complain. -- 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] submodule: add verbose mode for add/update
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkout so the user sees progress output
from the checkout command.
Signed-off-by: Orgad Shaneh
---
Documentation/git-submodule.txt | 10 --
git-submodule.sh| 24 +++-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 74d5bdc..6abfd5d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,13 +10,13 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b ] [-f|--force] [--name ]
- [--reference ] [--] []
+ [--reference ] [-v|--verbose] [--]
[]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
'git submodule' [--quiet] init [--] [...]
'git submodule' [--quiet] deinit [-f|--force] [--] ...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ]
- [--merge] [--recursive] [--] [...]
+ [--merge] [--recursive] [-v|--verbose] [--] [...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]
[commit] [--] [...]
'git submodule' [--quiet] foreach [--recursive]
@@ -324,6 +324,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+-v::
+--verbose::
+ This option makes the checkout operation more verbose.
+ By default, a quiet checkout is performed. Specifying --verbose
+ provides progress information to the user.
+
...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
] [--] []
+USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference
] [-v|--verbose] [--] []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] deinit [-f|--force] [--] ...
- or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--]
[...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference ] [--merge] [--recursive]
[-v|--verbose] [--] [...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive]
or: $dashless [--quiet] sync [--recursive] [--] [...]"
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it." >&2
module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" ||
exit
(
clear_local_git_env
+ if test -z "$VERBOSE"
+ then
+ subquiet=-q
+ fi
cd "$sm_path" &&
# ash fails to wordsplit ${branch:+-b "$branch"...}
case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
+ '') git checkout -f $subquiet ;;
+ ?*) git checkout -f $subquiet -B "$branch"
"origin/$branch" ;;
esac
) || die "$(eval_gettext "Unable to checkout submodule
'\$sm_path'")"
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update="checkout"
;;
+ -v|--verbose)
+ VERBOSE=1
+ ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?")"
must_die_on_failure=yes
;;
*)
- command="git checkout $subforce -q"
+ if test -z "$VERB
Re: [ITCH] Specify refspec without remote
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
> I don't see a big problem here, actually. What's so wrong with
> branch..remote affecting what "git push" does? If
> branch.crazy-feature.remote is my-personal-remote and I run
>
> git push
>
> and "[push] default = upstream", then it is obvious what the user
> wanted to happen. But what about when "[push] default = matching"?
> Which of the following behaviors is correct?
>
> a) Error: you didn't tell me which remote to push to.
> b) Just behave like "git push my-personal-remote :".
> c) Ignore which branch is the current branch and behave like
> "git push origin :".
>
> How about when "[push] default = current"?
>
> Except that people might have scripts or habits tied to the current
> behavior, any of (a), (b), and (c) sounds fine to me. (b) is the
> obvious choice for historical reasons.
I think (b) could be quite surprising to a user. I suspect it hasn't
come up because people just don't work with a lot of different remotes
in practice.
> Now if I rely on the proposed DWIM and run
>
> git push master
>
> then the corresponding choices are:
>
> a) Error: you didn't tell me which remote to push to.
> b) Just behave like "git push my-personal-remote master".
> c) Behave like "git push origin master".
>
> (b) is not a good choice there, but (a) and (c) look equally fine.
My complaint with anything but (b) is that you can't use a relatively
simple rule ("if you do not specify a remote, we fallback to defaults,
in this order"). Now the rule is different depending on what is in the
refspecs. If I say "git push HEAD", where should it go? Does it respect
branch.*.remote or not?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: create strbuf_humanize() to show byte sizes
On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano wrote: > Antoine Pelisse writes: > >> Currently, humanization of downloaded size is done in the same >> function as text formatting in 'process.c'. This is an issue if anyone >> else wants to use this. >> >> Separate text formatting from size simplification and make the function >> public in strbuf so that it can easily be used by other clients. >> >> We now can use strbuf_humanize() for both downloaded size and download >> speed calculation. One of the drawbacks is that speed will now look like >> this when download is stalled: "0 bytes/s" instead of "0 KiB/s". > > Personally, I do not think the "drawback" is so big an issue. If > the caller really cares, we could always add another parameter to > this formatter to tell it the minimum unit we care about (e.g. pass > 1024 to say "Don't bother showing scale lower than kibi"). I thought about that, but decided it was not worth it (at least for the moment) > This is a bit late response, but if we ever want to count something > in a dimention other than "bytes", like time (e.g. "kiloseconds") or > number of commits (e.g. "centicommits"), etc., we cannot reuse this > formatter very easily. We may want to have "byte" somewhere in its > name for now to make sure the callers understand its limitation. I'm not in a hurry. But it look tough to make it generic: one is binary, another is sexagesimal, and the last is decimal > I'll tentatively rename it to "strbuf_humanize_bytes()" while queuing. I like the idea, 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
Fwd: [PATCH] submodule: add verbose mode for add/update
On Wed, Apr 10, 2013 at 11:00 PM, Jens Lehmann wrote: > > Am 10.04.2013 20:24, schrieb Orgad Shaneh: > > Executes checkout without -q > > Nice, looks like you picked the proposal I made last September: > http://permalink.gmane.org/gmane.comp.version-control.git/204747 Took me a while, but I finally got to it :) > The change is looking good, but you still need to document the > new option in Documentation/git-submodule.txt too please. > > And the commit message is still too short, as I said in that > other thread: > > On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann wrote: > > Before the "Signed-off-by" is the place where you should have > > explained why this would be a worthwhile change ;-) > > And you answered to that with something that would really make > sense as first part of the commit message, because you explain > *why* you do that change: > > Am 05.09.2012 13:42, schrieb Orgad and Raizel Shaneh: > > When I run 'git submodule update' I don't expect to be in the dark > > until the submodule/s finishes checkout, this sometimes can take a > > significant amount of time and feedback is expected. > > Another paragraph after that should explain *how* you do it. > > So what about the following as commit message: > -- > When 'git submodule add/update' is run there is no output during > checkout. This can take a significant amount of time and it would > be nice if user could enable some feedback to see what's going on. > > Add the -v/--verbose option to both add and update which suppresses > the -q normally given to checkout so the user sees progress output > from the checkout command. > > > -- > > I'm looking forward to your next iteration. Done quicker this time ;-) Thanks a lot for your review (previous and current). It was very helpful! - Orgad -- 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: [ITCH] Specify refspec without remote
Jeff King wrote: > On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote: > >> Ramkumar Ramachandra wrote: >> > git push -- master next; pushes to my current branch's >> > branch..pushremote? Isn't that a disaster? >> >> Actually, branch..pushremote already breaks the current design >> in a way, as Junio pointed out in a different email: a push.default >> set to anything except "current" is already nonsensical. Why should >> "matching" branches be pushed to the remote that my current branch >> specifies? That might well have their own branch..pushremote >> configured, which should be respected. > > I'm not sure that it should be respected. "master" is short for > "refs/heads/master:refs/heads/master", and does not mean "push master to > where I have it configured to go" at all. That may be what the user > means, but changing how "git push" works is going to create > inconsistency with other cases. Yes, I know "master" refers to the refspec in the above, not the ref (ie. branch). Hence branch configuration should have nothing to do with this. That's just the way things currently are: doesn't mean that it's perfect; and I'm just throwing ideas around. >> We should fix this now. I think the fault lies in the rather old >> design of push.default. Do you have any suggestions as what would >> make sense here? Ultimately, I think a git push; needs to pick >> remotes for each refspec separately. The orthogonal design is >> definitely not right in my opinion. > > Right, the example above might include multiple remotes if pushremote is > respected. Or it might not come up with an answer at all for a tag. > If you do: > > git push -- v1.2.3 master > > where does v1.2.3 go? To remote.pushdefault? That seems simple and > consistent, as there is no ref-specific pushremote defined. remote.pushdefault indeed. > But I'd > guess that the user probably _wanted_ it to go to > branch.master.pushremote. Huh, why? Simply because he specified master alongside it? How can we infer what you said in a consistent system? -- 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: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > Maybe. But no more so than the current: > > > > git push > > > > which may also push master and next to the same remote. > > I would argue that this was not really a problem in practice, until I > introduced branch..pushremote. > > Let us imagine that I was working on artagnon/git.git (remote: ram), a > fork of git/git.git (remote: origin) earlier. My fork contains the > link and implicit-push branches in addition to the master, next and pu > branches, which are present on both. When I push from my > implicit-push branch with push.default = matching, I'm updating all > the matching refs on the remote ram (since branch.implicit-push.remote > is set to ram), which is fine. Now, I git push while on branch > master. My push is simply rejected, as I don't have write access to > the remote origin. > > This is designed exactly for the read-only upstream, read-write fork > scenario. If I had write access to upstream (where we're essentially > regression to a centralized model), we'd have some major confusion. I don't see how pushremote changes that. It was already a problem with branch.*.remote, no? I have a similar remote setup in my git.git repository. But all of my branch.*.remote variables point to origin, because my branches are based off of Junio's master. A matching push goes to the wrong place (and I have screwed it up many times; it is nice that I do not have write access to Junio's repository). The is broken without having pushremote at all (and the proper fix is your remote.pushdefault). > > As I said in an > > earlier message, I would be OK with allowing both or neither, but > > allowing one but not the other is even more confusing. > > What is the point of allowing something internally consistent, but > nonsensical? You should complain. If I were designing it today, I definitely think complaining is the right thing to do. My only hesitation is the backwards compatibility. If we are not going to break the existing behavior, I think it can be argued that consistency and simplicity of the rules is important, so the user can predict what will happen. But the more we discuss, the more I think we should simply change the current behavior (to stop respecting branch.* config with "matching"), which just seems wrong to me. Then we can be simple and consistent, and do what the user probably intended. -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: [ITCH] Specify refspec without remote
Jeff King writes: > If we changed push.default=matching to ignore branch.*.remote, then that > would be consistent, and would probably be safer over all. It is a > regression, but I doubt that anybody was using branch.*.remote for this; > it really only makes sense with the "upstream" mode. True. -- 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: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: > > Right, the example above might include multiple remotes if pushremote is > > respected. Or it might not come up with an answer at all for a tag. > > If you do: > > > > git push -- v1.2.3 master > > > > where does v1.2.3 go? To remote.pushdefault? That seems simple and > > consistent, as there is no ref-specific pushremote defined. > > remote.pushdefault indeed. > > > But I'd > > guess that the user probably _wanted_ it to go to > > branch.master.pushremote. > > Huh, why? Simply because he specified master alongside it? How can > we infer what you said in a consistent system? That's kind of my point. Why would they put two refs together in a single push command? Did they mean "I am pushing up master, and since I just tagged it, send the tag along, too"? Or did they really mean to push them to two different places? If so, why not just run two separate push commands? I am not saying git should guess that the user wanted the tag to along with master. I am saying that the set of rules to come to that conclusion is going to be too baroque for the user to understand, and too often wrong in other cases, and that we should not go there. -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: [ITCH] Specify refspec without remote
Ramkumar Ramachandra writes: > As the author of branch..pushremote, I apologize for not having > caught this earlier. I've been using push.default = current for a > long time, and don't often think about the other settings. Possibly, but I do not know it is such a big issue. On the other hand, a good thing is that the remote.pushdefault makes perfect sense whether you use the upstream mode or the matching mode. I vaguely recall that I kept telling you that the overall default should be there and per-branch stuff can come later if/as needed, to which you resisted for a couple of rounds of reviews and I couldn't quite figure out where the resistance was coming from. Come to think of it, perhaps that might be rooted in the same reason of not thinking about users of "matching" mode. I dunno, and I do not think it matters. -- 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
Premerging topics (was: [RFD] annnotating a pair of commit objects?)
The goal is to propose a structure for storing and pre-merging pairs of commits. Data-structure == We could use a note ref to store the pre-merge information. Each commit would be annotated with a blob containing the list of pre-merges (one sha1 per line with sha1 pointing to a merge commit). The commit on the other side of a merge would also be annotated. The choice of the refname could be done like we do with notes: - Have a default value - Have a default value configured in config - Use a specific value when merging/creating the pre-merges Here are my concerns: Pros 1. Notes allow dynamic annotation a commit 2. If we manage to fix 4, we can easily download all pre-merges from a remote host by fetching the ref (or clean by deleting the ref). 3. Conflicts on pre-merge notes could probably be resolved by concatenation. Cons 4. Checking connectivity means opening the blob and parsing it 5. Regular notes and pre-merge notes have to be handled separately because of 4. I'm hoping we can keep the pros and avoid the cons, but I'm kind of stuck here. Help would be really appreciated (or maybe this is a totally wrong direction, and I would also like to know ;) Merging (Using what we saved) = The goal is to merge branches J and B using existing pre-merges. E0. Create an empty stack S E1. Create set of commits 'J..B' and 'B..J' (that is probably already done) E2. For each commit C in smallest(J..B, B..J), execute E3 E3. For each premerge P in notes-premerge(C), execute E4 E4. If one of both parents of P belongs to biggest(J..B, B..J), stack P in S E5. Merge J and B using all pre-merges from S Let's consider that |J..B| is smaller than |B..J|. E0 is executed only once E1 is O(|J..B| + |B..J|) E2 is O(|J..B|) E3 is O(|J..B| x the average number of pre-merge per commits P_avg) E4 is executed for each parent (let's say it's two/constant, after all the topic is "pair" of commits), so still O(|J..B| x P_avg) E5 I don't know (how it can be done, and what would be the resulting time complexity) So the time cost for steps E0 to E4 is O(|J..B| + |B..J| x P_avg) Tools (Save the pre-merges) === Of course we need several tools to maintain the list of premerges, and to easily compute them. For example, it would be nice to be able to do something like: $ git pre-merge topicA topicB topicC to find, resolve and store all interactions between the topics. We could then easily derive to something that would allow to pre-merge a new topic with all topics already merged in master..pu (for example). Anyway, this task is left for latter. -- 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: [ITCH] Specify refspec without remote
Jeff King wrote: > On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote: > >> Jeff King wrote: >> > Maybe. But no more so than the current: >> > >> > git push >> > >> > which may also push master and next to the same remote. >> >> I would argue that this was not really a problem in practice, until I >> introduced branch..pushremote. >> >> Let us imagine that I was working on artagnon/git.git (remote: ram), a >> fork of git/git.git (remote: origin) earlier. My fork contains the >> link and implicit-push branches in addition to the master, next and pu >> branches, which are present on both. When I push from my >> implicit-push branch with push.default = matching, I'm updating all >> the matching refs on the remote ram (since branch.implicit-push.remote >> is set to ram), which is fine. Now, I git push while on branch >> master. My push is simply rejected, as I don't have write access to >> the remote origin. >> >> This is designed exactly for the read-only upstream, read-write fork >> scenario. If I had write access to upstream (where we're essentially >> regression to a centralized model), we'd have some major confusion. > > I don't see how pushremote changes that. It was already a problem with > branch.*.remote, no? Technically, it changes nothing. pushremote is only an enabler for more complex scenarios where git push; breaking user expectations is magnified. According to me, what branch..pushremote suddenly starts supporting (apart from the use I intended for it) is each branch having different read/ write access. So, we're back to git.git where Junio has graciously given me write support to pu, but not next or master. So I set up branch.master.pushremote and branch.next.pushremote to ram and run git push; from pu. Disaster: the pu ref went through fine, but master and next failed to get pushed despite me specifying a proper pushremote for them. > I have a similar remote setup in my git.git repository. But all of my > branch.*.remote variables point to origin, because my branches are based > off of Junio's master. A matching push goes to the wrong place (and I > have screwed it up many times; it is nice that I do not have write > access to Junio's repository). The is broken without having pushremote > at all (and the proper fix is your remote.pushdefault). Yeah, I can't believe I lived without remote.pushdefault for this long. > If we are not going to break the existing behavior, I think it can be > argued that consistency and simplicity of the rules is important, so the > user can predict what will happen. But the more we discuss, the more I > think we should simply change the current behavior (to stop respecting > branch.* config with "matching"), which just seems wrong to me. Then we > can be simple and consistent, and do what the user probably intended. So there are some push.default options that respect branch.* config (ie. "current"), and others that don't (ie. "matching"). I would argue that push.default is badly designed to begin with, so the solution makes sense to me even if the patch is a bit of hack; we never guaranteed that the various push.default options respect the same configuration variables. -- 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-http-backend: anonymous read, authenticated write
On Tue, Apr 09, 2013 at 01:12:47PM -0400, Jeff King wrote:
> On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
>
>> I've been trying to set up git-http-backend+lighttpd. I've managed
>> to set up anonymous read-only access, and I then successfully
>> configured authentication for both read and write. Then I get
>> stuck. The man-page for git-http-backend says that the following
>> snippet can be used for Apache 2.x:
>>
>>
>> AuthType Basic
>> AuthName "Git Access"
>> Require group committers
>> ...
>>
>>
>> However, when I put in this match on location in my lighty config
>> and try to push I'm not asked for a password, instead I'm greeted
>> with
>>
>> % git push
>> error: The requested URL returned error: 403 Forbidden while accessing
>> http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack
>
> Something in your config is blocking access to info/refs there. It
> should not be the block shown above, which handles only the actual POST
> of the data. The sequence of http requests made is:
>
> 1. GET $repo/info/refs?service=git-receive-pack
>
> This makes initial contact and gets the ref information which push
> uses to decide what it is going to push. So it is read-only, and in
> an anonymous-read setup, does not need to be protected.
>
> 2. POST $repo/git-receive-pack
>
> This actually pushes up the objects and updates the refs, and
> must be protected.
>
> The setup listed above does work with apache; it is tested as part of
> our test suite (you can see the actual config in t/lib-httpd/apache.conf).
> So what in lighttpd is giving us the 403? Can you share your whole
> config?
I was putting together a *long* response, with my different
configurations when it suddenly hit me how to make it work.
So, this is the accesslog for a successful `git push`:
192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] "GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 401 351 "-"
"git/1.8.2.1"
192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] "GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 401 351 "-"
"git/1.8.2.1"
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:04 +0200] "GET
/git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 200 202 "-"
"git/1.8.2.1"
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:09 +0200] "POST
/git/foo.git/git-receive-pack HTTP/1.1" 200 73 "-" "git/1.8.2.1"
That is, *both* the GET and POST queries require a valid username
(trying to push without a valid user will fail with a 403 already on
the GET query). Maybe Apache 2.x simply behaves *very* differently
from lighttpd, but I still can't see how a rule to require a valid
user only on the POST can ever work.
>> AFAICS this means the man-page is wrong, and that I instead ought
>> to match on the "service=git-receive-pack" part. Is that a correct
>> conclusion?
>
> No. It is not a bad idea to _also_ match on info/refs, but I think
> it's a little trickier (you need to reliably match the query string
> to differentiate it from a fetch, which IIRC is a little hard in
> apache, at least).
This is what triggered me to find a working config. Matching on the
query string is actually *very* easy in lighttpd. Here's the relevant
bit of a working configuration[1]:
alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
$HTTP["querystring"] =~ "service=git-receive-pack" {
$HTTP["url"] =~ "^/git" {
cgi.assign = ( "" => "" )
setenv.add-environment = (
"GIT_PROJECT_ROOT" => "/srv/git",
"GIT_HTTP_EXPORT_ALL" => ""
)
include "trac-git-auth.conf"
}
} else $HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
cgi.assign = ( "" => "" )
setenv.add-environment = (
"GIT_PROJECT_ROOT" => "/srv/git",
"GIT_HTTP_EXPORT_ALL" => ""
)
include "trac-git-auth.conf"
} else $HTTP["url"] =~ "^/git" {
cgi.assign = ( "" => "" )
setenv.add-environment = (
"GIT_PROJECT_ROOT" => "/srv/git",
"GIT_HTTP_EXPORT_ALL" => ""
)
}
> But if you drop the protections on "/git-receive-pack$", then an
> attacker can just POST whatever they want into your repository.
This setup is for a server on the internal network, but still, your
comment holds. The reason for wanting to allow reading without
authentication is that then I can signal a CI server to pull without
having to give it credentials.
/M
[1]: The configuration for the authentication looks like this at the
moment, but it's only for testing:
auth.backend = "plain"
auth.backend.plain.userfile = "/srv/git/pwds.plain"
auth.require = (
"/" => (
"method" => "basic",
"realm" => "git",
"require" => "valid-user"
)
)
--
Magnus Therning
Re: git-http-backend: anonymous read, authenticated write
On Tue, Apr 09, 2013 at 02:24:26PM +0200, Jakub Narębski wrote: > On 09.04.2013, Magnus Therning wrote: > > > I've been trying to set up git-http-backend+lighttpd. I've managed to > > set up anonymous read-only access, and I then successfully configured > > authentication for both read and write. Then I get stuck. The > > man-page for git-http-backend says that the following snippet can be > > used for Apache 2.x: > > > > > > AuthType Basic > > AuthName "Git Access" > > Require group committers > > ... > > > > > > However, when I put in this match on location in my lighty config and > > try to push I'm not asked for a password, instead I'm greeted with > > > > % git push > > error: The requested URL returned error: 403 Forbidden while > > accessing > http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack > > > > AFAICS this means the man-page is wrong, and that I instead ought to > > match on the "service=git-receive-pack" part. Is that a correct > > conclusion? > > Yes, it is. > > I have tried to do the same anonymous read and authenticated write > in "smart HTTP" access in Apache. There are some proposals[1], > all I think which use mod_rewrite (as LocationMatch doesn't take > query string into account, unfortunately), but I haven't been able > to make it work. > > The problem is that both POST *and GET* (to get refs) must be authethicated. > > Nb. I thought that it was corrected... which git version do you use? 1.8.2 on the server, though 1.8.2.1 is available for the distro I'm using. The discussion you refer to took place in 2010, I doubt any improvement has been made to this in that point release, or am I wrong? > [1]: http://paperlined.org/apps/git/SmartHTTP_Ubuntu.html > > > In the end I have worked around this by allowing all registered users to > read with "require valid-user" (which in my situation might be even more > correct solution; the case being repositories for Computer Science class > lab work), and restricting write via pre-receive hook which checks > REMOTE_USER. I *really* want anonymous RO access so the CI server doesn't need any credentials. I could of course set up git-http-backend to be served on two different URLs, but that's just ugly ;) Luckily I did find a working configuration, which I posted in another email in this thread. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay pgp6Iw96ionh4.pgp Description: PGP signature
Re: [ITCH] Specify refspec without remote
Jeff King wrote: > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: >> Huh, why? Simply because he specified master alongside it? How can >> we infer what you said in a consistent system? > > That's kind of my point. Why would they put two refs together in a > single push command? Did they mean "I am pushing up master, and since I > just tagged it, send the tag along, too"? Or did they really mean to > push them to two different places? If so, why not just run two separate > push commands? I disagree. The protocol was built ground up to support updating multiple refs in the same git push. Running N separate push commands is _not_ the same thing at all; it running N times as slowly aside. Pushing multiple refs is a valid and cogent usecase (while multiple remotes is not). git is a distributed system: I make lots of changes to various branches, tags and decide to push only when I'm taking a break for lunch: at this point, I want to update all my refs on the remote. In other words, I batch up ref updates because git is _meant_ to do that: creating/ modifying/ moving/ deleting refs is super-fast (and happens all the time), while pushing is a slow and dangerous (because gc runs) operation. -- 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: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: > Jeff King wrote: >> If we are not going to break the existing behavior, I think it can be >> argued that consistency and simplicity of the rules is important, so the >> user can predict what will happen. But the more we discuss, the more I >> think we should simply change the current behavior (to stop respecting >> branch.* config with "matching"), which just seems wrong to me. Then we >> can be simple and consistent, and do what the user probably intended. > > So there are some push.default options that respect branch.* config > (ie. "current"), and others that don't (ie. "matching"). I would > argue that push.default is badly designed to begin with, so the > solution makes sense to me even if the patch is a bit of hack; we > never guaranteed that the various push.default options respect the > same configuration variables. If we're going to break "matching" anyway, let's break it fully. I propose that we make it respect each individual branch's branch..pushremote/ branch..remote and push the branch to that remote. That'll let us design a git push -- master implicit-push; that actually makes sense. -- 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: [ITCH] Specify refspec without remote
On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: > >> Huh, why? Simply because he specified master alongside it? How can > >> we infer what you said in a consistent system? > > > > That's kind of my point. Why would they put two refs together in a > > single push command? Did they mean "I am pushing up master, and since I > > just tagged it, send the tag along, too"? Or did they really mean to > > push them to two different places? If so, why not just run two separate > > push commands? > > I disagree. The protocol was built ground up to support updating > multiple refs in the same git push. Running N separate push commands > is _not_ the same thing at all; it running N times as slowly aside. But I think all of this discussion just reinforces my point. We do not have to agree on what the user intended. But the fact that we do not agree means that out of a sample size of 2 users, we have 2 different things the user expects to happen. If we choose a behavior and say "this makes sense", then the other half of the users are going to be confused or annoyed. -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
[PATCH v2 2/3] Teach mv to move submodules using a gitfile
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/ of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.
Achieve that by remembering which submodule uses a gitfile by storing the
result of read_gitfile() of each submodule. If that is not NULL the new
function connect_work_tree_and_git_dir() is called after renaming the
submodule's work tree which updates the two settings to the new values.
Signed-off-by: Jens Lehmann
---
Am 10.04.2013 18:59, schrieb Jens Lehmann:
> Am 10.04.2013 01:08, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> diff --git a/submodule.c b/submodule.c
>>> index 975bc87..eba9b42 100644
>>> --- a/submodule.c
>>> +++ b/submodule.c
>>> @@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const
>>> char *path,
>>> ...
>>> + if (!fp)
>>> + die(_("Could not create git link %s"), gitfile_name.buf);
>>> + fprintf(fp, gitfile_content.buf);
>>
>> Perhaps.
>>
>> fprintf(fp, "%s", gitfile_content.buf);
>
> Sure. Will fix in v2.
Here we go.
builtin/mv.c | 19 ++
submodule.c | 64 +++
submodule.h | 1 +
t/t7001-mv.sh | 19 ++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 361028d..609bbb8 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -9,6 +9,7 @@
#include "cache-tree.h"
#include "string-list.h"
#include "parse-options.h"
+#include "submodule.h"
static const char * const builtin_mv_usage[] = {
N_("git mv [options] ... "),
@@ -65,7 +66,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('k', NULL, &ignore_errors, N_("skip move/rename
errors")),
OPT_END(),
};
- const char **source, **destination, **dest_path;
+ const char **source, **destination, **dest_path, **submodule_gitfile;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
@@ -84,6 +85,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
source = copy_pathspec(prefix, argv, argc, 0);
modes = xcalloc(argc, sizeof(enum update_mode));
dest_path = copy_pathspec(prefix, argv + argc, 1, 0);
+ submodule_gitfile = xcalloc(argc, sizeof(char *));
if (dest_path[0][0] == '\0')
/* special case: "." was normalized to "" */
@@ -119,8 +121,14 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
else if (src_is_dir) {
int first = cache_name_pos(src, length);
if (first >= 0) {
+ struct strbuf submodule_dotgit = STRBUF_INIT;
if (!S_ISGITLINK(active_cache[first]->ce_mode))
die (_("Huh? Directory %s is in index
and no submodule?"), src);
+ strbuf_addf(&submodule_dotgit, "%s/.git", src);
+ submodule_gitfile[i] =
read_gitfile(submodule_dotgit.buf);
+ if (submodule_gitfile[i])
+ submodule_gitfile[i] =
xstrdup(submodule_gitfile[i]);
+ strbuf_release(&submodule_dotgit);
} else {
const char *src_w_slash = add_slash(src);
int last, len_w_slash = length + 1;
@@ -215,9 +223,12 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int pos;
if (show_only || verbose)
printf(_("Renaming %s to %s\n"), src, dst);
- if (!show_only && mode != INDEX &&
- rename(src, dst) < 0 && !ignore_errors)
- die_errno (_("renaming '%s' failed"), src);
+ if (!show_only && mode != INDEX) {
+ if (rename(src, dst) < 0 && !ignore_errors)
+ die_errno (_("renaming '%s' failed"), src);
+ if (submodule_gitfile[i])
+ connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
+ }
if (mode == WORKING_DIRECTORY)
continue;
diff --git a/submodule.c b/submodule.c
index 975bc87..9a3eb85 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const char
*path,
free(merges.objects);
return 0;
}
+
+/* Update gitfile and core.worktree setting to connect work tree and git dir */
+void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir)
+{
+ struct strbuf core_worktree_se
Re: [ITCH] Specify refspec without remote
Jeff King wrote: > But I think all of this discussion just reinforces my point. We do not > have to agree on what the user intended. But the fact that we do not > agree means that out of a sample size of 2 users, we have 2 different > things the user expects to happen. If we choose a behavior and say "this > makes sense", then the other half of the users are going to be confused > or annoyed. Yes, disagreement is healthy. My point is that we should have "sane" defaults, and fine-grained configurability so that uses who disagree can maintain their own configs. In this case, respecting a branch.*.remote for each branch is more fine-grained, while not doing so is coarse and makes me unhappy. Then again, we don't have to go overboard and design another ten configuration variables, but we can atleast improve on what we already have without breaking consistency (but we have to minimally break backward compatibility). -- 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 v5 0/2] reporting transport helper errors
I think this topic is close to being done, so I just wanted to move it along. [1/2]: transport-helper: report errors properly This is Felipe's v4 patch with the adjustments I suggested in review. It explains more in the commit message, and should fix Thomas's valgrind failures (it consumes fast-export's data before dying rather than sleeping and hoping that fast-export is done writing). [2/2]: transport-helper: mention helper name when it dies This changes the error message, to help with the issue raised by Sverre. -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
[PATCH 1/2] transport-helper: report errors properly
From: Felipe Contreras
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
helper has died while reading back the ref status from the
helper. However, we don't print any message. This is OK if
the helper itself printed a useful error message, but we
cannot count on that; let's let the user know that the
helper failed.
In the long run, it may make more sense to propagate the
error back up to push, so that it can present the usual
status table and give a nicer message. But this is a much
simpler fix that can help immediately.
While we're adding tests, let's also confirm that the
remote-helper dying is also detect when importing refs. We
currently do so robustly when the helper uses the "done"
feature (and that is what we test). We cannot do so
reliably when the helper does not use the "done" feature,
but it is not even worth testing; the right solution is for
the helper to start using "done".
Suggested-by: Jeff King
Signed-off-by: Felipe Contreras
Signed-off-by: Jeff King
---
Felipe,
Can you acknowledge that it's OK to stick your name on this, as it's not
exactly what you submitted before?
git-remote-testgit| 19 +++
t/t5801-remote-helpers.sh | 20
transport-helper.c| 2 +-
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index b395c8d..5fd09f9 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -61,12 +61,31 @@ do
echo "feature import-marks=$gitmarks"
echo "feature export-marks=$gitmarks"
fi
+
+ if test -n "$GIT_REMOTE_TESTGIT_FAILURE"
+ then
+ echo "feature done"
+ exit 1
+ fi
+
echo "feature done"
git fast-export "${testgitmarks_args[@]}" $refs |
sed -e "s#refs/heads/#${prefix}/heads/#g"
echo "done"
;;
export)
+ if test -n "$GIT_REMOTE_TESTGIT_FAILURE"
+ then
+ # consume input so fast-export doesn't get SIGPIPE;
+ # git would also notice that case, but we want
+ # to make sure we are exercising the later
+ # error checks
+ while read line; do
+ test "done" = "$line" && break
+ done
+ exit 1
+ fi
+
before=$(git for-each-ref --format='%(refname) %(objectname)')
git fast-import "${testgitmarks_args[@]}" --quiet
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index f387027..aafc46a 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -166,4 +166,24 @@ test_expect_success 'push ref with existing object' '
compare_refs local dup server dup
'
+test_expect_success 'proper failure checks for fetching' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ cd local &&
+ test_must_fail git fetch 2> error &&
+ cat error &&
+ grep -q "Error while running fast-import" error
+ )
+'
+
+test_expect_success 'proper failure checks for pushing' '
+ (GIT_REMOTE_TESTGIT_FAILURE=1 &&
+ export GIT_REMOTE_TESTGIT_FAILURE &&
+ cd local &&
+ test_must_fail git push --all 2> error &&
+ cat error &&
+ grep -q "Reading from remote helper failed" error
+ )
+'
+
test_done
diff --git a/transport-helper.c b/transport-helper.c
index cb3ef7d..96081cc 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer)
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
- exit(128);
+ die("Reading from remote helper failed");
}
if (debug)
--
1.8.2.rc0.33.gd915649
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] transport-helper: mention helper name when it dies
When we try to read from a remote-helper and get EOF or an
error, we print a message indicating that the helper died.
However, users may not know that a remote helper was in use
(e.g., when using git-over-http), or even what a remote
helper is.
Let's print the name of the helper (e.g., "git-remote-https");
this makes it more obvious what the program is for, and
provides a useful token for reporting bugs or searching for
more information (e.g., in manpages).
Signed-off-by: Jeff King
---
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index aafc46a..8b2cb68 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -182,7 +182,7 @@ test_expect_success 'proper failure checks for pushing' '
cd local &&
test_must_fail git push --all 2> error &&
cat error &&
- grep -q "Reading from remote helper failed" error
+ grep -q "Reading from helper .git-remote-testgit. failed" error
)
'
diff --git a/transport-helper.c b/transport-helper.c
index 96081cc..3fc43b9 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -46,7 +46,7 @@ static void sendline(struct helper_data *helper, struct
strbuf *buffer)
die_errno("Full write to remote helper failed");
}
-static int recvline_fh(FILE *helper, struct strbuf *buffer)
+static int recvline_fh(FILE *helper, struct strbuf *buffer, const char *name)
{
strbuf_reset(buffer);
if (debug)
@@ -54,7 +54,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer)
if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
- die("Reading from remote helper failed");
+ die("Reading from helper 'git-remote-%s' failed", name);
}
if (debug)
@@ -64,7 +64,7 @@ static int recvline(struct helper_data *helper, struct strbuf
*buffer)
static int recvline(struct helper_data *helper, struct strbuf *buffer)
{
- return recvline_fh(helper->out, buffer);
+ return recvline_fh(helper->out, buffer, helper->name);
}
static void xchgline(struct helper_data *helper, struct strbuf *buffer)
@@ -536,7 +536,7 @@ static int process_connect_service(struct transport
*transport,
goto exit;
sendline(data, &cmdbuf);
- recvline_fh(input, &cmdbuf);
+ recvline_fh(input, &cmdbuf, name);
if (!strcmp(cmdbuf.buf, "")) {
data->no_disconnect_req = 1;
if (debug)
--
1.8.2.rc0.33.gd915649
--
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: [ITCH] Specify refspec without remote
Junio C Hamano wrote: > On the other hand, a good thing is that the remote.pushdefault makes > perfect sense whether you use the upstream mode or the matching > mode. I vaguely recall that I kept telling you that the overall > default should be there and per-branch stuff can come later if/as > needed, to which you resisted for a couple of rounds of reviews and > I couldn't quite figure out where the resistance was coming from. > Come to think of it, perhaps that might be rooted in the same > reason of not thinking about users of "matching" mode. I dunno, and > I do not think it matters. remote.pushdefault is simple; it doesn't open up interesting possibilities like branch..pushremote does (I mentioned branch-specific r/w access somewhere else in the thread). Because of my obsession with "current", I never think of the repository as a whole but each branch separately tracking a remote. -- 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: [ITCH] Specify refspec without remote
Ramkumar Ramachandra wrote: >My point is that we should have "sane" > defaults, and fine-grained configurability so that uses who disagree > can maintain their own configs. I don't agree with this principle. I like a tool that behaves sanely with little work and that is flexible enough to do hard things when that's needed. Neither of those attributes implies configurability, except in those unfortunate cases where "behaving sanely with little work on the user's part" has to involve a different behavior from person to person. When people disagree about sane defaults, that's a sign that we didn't understand the problem well. Often more thinking can lead to a simpler answer. -- 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/2] transport-helper: report errors properly
On Wed, Apr 10, 2013 at 2:15 PM, Jeff King wrote: > From: Felipe Contreras > > If a push fails because the remote-helper died (with > fast-export), the user does not see any error message. We do > correctly die with a failed exit code, as we notice that the > helper has died while reading back the ref status from the > helper. However, we don't print any message. This is OK if > the helper itself printed a useful error message, but we > cannot count on that; let's let the user know that the > helper failed. > > In the long run, it may make more sense to propagate the > error back up to push, so that it can present the usual > status table and give a nicer message. But this is a much > simpler fix that can help immediately. > > While we're adding tests, let's also confirm that the > remote-helper dying is also detect when importing refs. We > currently do so robustly when the helper uses the "done" > feature (and that is what we test). We cannot do so > reliably when the helper does not use the "done" feature, > but it is not even worth testing; the right solution is for > the helper to start using "done". > > Suggested-by: Jeff King > Signed-off-by: Felipe Contreras > Signed-off-by: Jeff King The fixes you made to this patch make a lot of sense, glad to not have a 'sleep 1' in our tests. Acked-by: Sverre Rabbelier -- 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: [ITCH] Specify refspec without remote
Jeff King wrote: > On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote: >> git push >> >> and "[push] default = upstream", then it is obvious what the user >> wanted to happen. But what about when "[push] default = matching"? >> Which of the following behaviors is correct? >> >> a) Error: you didn't tell me which remote to push to. >> b) Just behave like "git push my-personal-remote :". >> c) Ignore which branch is the current branch and behave like >> "git push origin :". >> >> How about when "[push] default = current"? >> >> Except that people might have scripts or habits tied to the current >> behavior, any of (a), (b), and (c) sounds fine to me. (b) is the >> obvious choice for historical reasons. > > I think (b) could be quite surprising to a user. I suspect it hasn't > come up because people just don't work with a lot of different remotes > in practice. Yeah, I think you're right. I'll try writing a series to switch to (c) for [push] default = matching and (a) for default = simple (and one of the two for default = current. Not sure which yet). Thanks, Jonathan -- 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: [ITCH] Specify refspec without remote
Jonathan Nieder wrote: > When people disagree about sane defaults, that's a sign that we didn't > understand the problem well. Often more thinking can lead to a > simpler answer. Okay, let's see if we can all agree. In a different email, you wrote: >git push master > ... > a) Error: you didn't tell me which remote to push to. > b) Just behave like "git push my-personal-remote master". > c) Behave like "git push origin master". Here, I'd argue for (d): push to branch.master.pushremote/ branch.master.remote/ remote.pushdefault/ origin. If others agree on this, we can break "matching" appropriately, like I proposed earlier, to make everything consistent once again. -- 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
