* Re: pull/push inconsistencies
From: Jeff King @ 2007-05-16 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <7vtzudhayr.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 05:24:28PM -0700, Junio C Hamano wrote:
> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
>
> The standard answer is not to push into a live repository
> without understanding what you are doing.
My impression here is that Martin is saying that pushing does not update
the remote tracking branch in the local repository (as, e.g., cogito has
always done). But I thought somebody (Ted?) recently submitted a patch
to change that.
> git-push without parameters and configuration pushes matching
> branches. This has been true from day one. Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.
I had done a patch in that direction (actually, it just avoided pushing
refs/remotes/) and have been planning to follow up with restricting
git-push to just refs/heads/. I'll try to work on that in the next day
or so.
-Peff
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-16 12:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070516071130.GB7453@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
On 16/05/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-15 21:01:43 +0100, Catalin Marinas wrote:
>
> > What is the impact on the bash completion for calling StGIT rather
> > than reading those files? Is it visible?
>
> Yes, it's visible, but not annoying (to me anyway). The overhead is
> akin to the overhead we used to have when "stg help" generated the
> command names -- on the order of 100-200 ms, when StGIT is in the
> cache. The expensive part is to start stgit; the git calls are cheap.
> So theoretically the completion script could duplicate the logic in
> StGIT and avoid most of the overhead, if someone wanted it badly
> enough.
I did a quick test of 'stg series' with the DAG patches applied, on a
Linux kernel repository ('du -sh .git' is 285M) with 42 patches (only
25 applied). It constantly takes over 2 seconds to complete (compared
to < 200ms without the DAG patches). The problem is that this delay
will happen for bash completion as well.
It seems that most of the time is spent in git._output_lines() called
from stack.read_refs() (for git-show-ref). I attach the profiling
output generated by stg-prof.
--
Catalin
[-- Attachment #2: prof.txt --]
[-- Type: text/plain, Size: 38609 bytes --]
+ cross-arm
+ init-err
+ ll-printk
+ compressed-head-stack
+ armv7-uncompress
+ armv7-tlb
+ armv7-xenon
+ armv7-vfpv3
+ armv7-neon
+ armv7-thumb2-user
+ pb926-pci-io
+ mpcore-smsc911x
+ smsc911x-driver
+ realview-eb-pci-mem
+ realview-eb-pci-io
+ nommu-consistent-api
+ nommu-fault
+ nommu-page-tlb
+ nommu-context-id
+ nommu-integrator
+ nommu-realview-eb
+ nommu-kconfig
+ nommu-ptrace
+ nommu-armv6
> nommu-armv7
- per-cpu-asids
- arch-dsb-mmiowb
- t2-arch-arm-clone
- t2-function-type
- t2-exception-handling
- t2-unified-syntax
- t2-exception-handling-alternative
- t2-srs-variant
- thumb2-kernel-port
- errata-arm1136-364296
- errata-arm1136-411920
- pipt-icache-flush
- smp-writealloc
3150 function calls (3112 primitive calls) in 2.229 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 2.229 2.229 <string>:1(?)
1 0.000 0.000 0.000 0.000 ConfigParser.py:105(Error)
1 0.000 0.000 0.000 0.000 ConfigParser.py:117(NoSectionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:124(DuplicateSectionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:131(NoOptionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:140(InterpolationError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:148(InterpolationMissingOptionError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:161(InterpolationSyntaxError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:165(InterpolationDepthError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:176(ParsingError)
1 0.000 0.000 0.000 0.000 ConfigParser.py:188(MissingSectionHeaderError)
1 0.000 0.000 0.009 0.009 ConfigParser.py:202(RawConfigParser)
1 0.000 0.000 0.000 0.000 ConfigParser.py:487(ConfigParser)
1 0.000 0.000 0.002 0.002 ConfigParser.py:570(SafeConfigParser)
1 0.000 0.000 0.011 0.011 ConfigParser.py:88(?)
1 0.000 0.000 0.000 0.000 UserDict.py:19(__getitem__)
1 0.000 0.000 0.000 0.000 UserDict.py:62(__contains__)
1 0.000 0.000 0.000 0.000 basedir.py:2(?)
1 0.007 0.007 0.007 0.007 basedir.py:23(__output)
1 0.000 0.000 0.007 0.007 basedir.py:33(get)
1 0.003 0.003 0.011 0.011 common.py:2(?)
1 0.000 0.000 0.000 0.000 common.py:32(CmdException)
1 0.000 0.000 0.000 0.000 common.py:37(RevParseException)
1 0.000 0.000 0.006 0.006 config.py:125(config_setup)
1 0.000 0.000 0.000 0.000 config.py:134(ConfigOption)
2 0.000 0.000 0.000 0.000 config.py:137(__init__)
1 0.000 0.000 0.000 0.000 config.py:2(?)
1 0.000 0.000 0.000 0.000 config.py:24(GitConfigException)
1 0.000 0.000 0.000 0.000 config.py:27(GitConfig)
1 0.006 0.006 0.006 0.006 config.py:65(get)
1 0.005 0.005 0.023 0.023 git.py:180(_output_one_line)
2 2.029 1.015 2.067 1.034 git.py:192(_output_lines)
1 0.002 0.002 0.003 0.003 git.py:2(?)
1 0.000 0.000 0.023 0.023 git.py:288(get_head_file)
1 0.000 0.000 0.000 0.000 git.py:30(GitException)
1 0.000 0.000 0.000 0.000 git.py:39(Person)
1 0.000 0.000 0.000 0.000 git.py:71(Commit)
1 0.000 0.000 0.000 0.000 gitmergeonefile.py:2(?)
1 0.000 0.000 0.000 0.000 gitmergeonefile.py:27(GitMergeException)
1 0.001 0.001 2.228 2.228 main.py:197(main)
1 0.000 0.000 0.000 0.000 main.py:32(canonical_cmd)
1 0.000 0.000 0.015 0.015 main.py:51(__getitem__)
1 0.000 0.000 0.000 0.000 optparse.py:1007(_create_option_list)
1 0.000 0.000 0.001 0.001 optparse.py:1012(_populate_option_list)
1 0.000 0.000 0.000 0.000 optparse.py:1022(_init_parsing_state)
1 0.000 0.000 0.000 0.000 optparse.py:1036(set_usage)
1 0.000 0.000 0.000 0.000 optparse.py:1059(get_default_values)
1 0.000 0.000 0.000 0.000 optparse.py:1091(_get_args)
1 0.000 0.000 0.000 0.000 optparse.py:1097(parse_args)
1 0.000 0.000 0.000 0.000 optparse.py:1136(check_values)
1 0.000 0.000 0.000 0.000 optparse.py:1149(_process_args)
1 0.000 0.000 0.000 0.000 optparse.py:140(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:247(__init__)
12 0.001 0.000 0.002 0.000 optparse.py:413(__init__)
12 0.000 0.000 0.000 0.000 optparse.py:432(_check_opt_strings)
12 0.000 0.000 0.000 0.000 optparse.py:441(_set_opt_strings)
12 0.000 0.000 0.000 0.000 optparse.py:462(_set_attrs)
12 0.000 0.000 0.000 0.000 optparse.py:480(_check_action)
12 0.000 0.000 0.000 0.000 optparse.py:486(_check_type)
12 0.000 0.000 0.000 0.000 optparse.py:504(_check_choice)
12 0.000 0.000 0.000 0.000 optparse.py:517(_check_dest)
12 0.000 0.000 0.000 0.000 optparse.py:528(_check_const)
12 0.000 0.000 0.000 0.000 optparse.py:534(_check_nargs)
12 0.000 0.000 0.000 0.000 optparse.py:543(_check_callback)
1 0.000 0.000 0.000 0.000 optparse.py:662(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:748(__init__)
1 0.000 0.000 0.000 0.000 optparse.py:759(_create_option_mappings)
1 0.000 0.000 0.000 0.000 optparse.py:775(set_conflict_handler)
1 0.000 0.000 0.000 0.000 optparse.py:780(set_description)
13 0.000 0.000 0.000 0.000 optparse.py:786(_check_conflict)
13 0.000 0.000 0.001 0.000 optparse.py:815(add_option)
1 0.000 0.000 0.001 0.001 optparse.py:845(add_options)
1 0.000 0.000 0.001 0.001 optparse.py:975(__init__)
1 0.000 0.000 0.000 0.000 os.py:444(__setitem__)
4 0.000 0.000 0.000 0.000 popen2.py:21(_cleanup)
1 0.000 0.000 0.000 0.000 popen2.py:25(Popen3)
4 0.064 0.016 0.064 0.016 popen2.py:31(__init__)
1 0.000 0.000 0.000 0.000 popen2.py:7(?)
3 0.000 0.000 0.000 0.000 popen2.py:87(wait)
1 0.000 0.000 0.000 0.000 popen2.py:97(Popen4)
1 0.000 0.000 0.000 0.000 posixpath.py:110(basename)
5 0.000 0.000 0.000 0.000 posixpath.py:184(isdir)
4 0.000 0.000 0.000 0.000 posixpath.py:197(isfile)
8 0.000 0.000 0.000 0.000 posixpath.py:56(join)
1 0.000 0.000 0.000 0.000 posixpath.py:74(split)
1 0.000 0.000 2.229 2.229 profile:0(main())
0 0.000 0.000 profile:0(profiler)
1 0.001 0.001 2.163 2.163 series.py:111(func)
1 0.001 0.001 0.015 0.015 series.py:2(?)
38 0.001 0.000 0.001 0.000 series.py:88(__print_patch)
46 0.000 0.000 0.000 0.000 sets.py:119(__iter__)
1 0.000 0.000 0.000 0.000 sets.py:356(_update)
1 0.000 0.000 0.000 0.000 sets.py:393(ImmutableSet)
1 0.001 0.001 0.001 0.001 sets.py:41(?)
1 0.000 0.000 0.000 0.000 sets.py:418(Set)
72 0.001 0.000 0.001 0.000 sets.py:425(__init__)
89 0.001 0.000 0.001 0.000 sets.py:515(add)
25 0.000 0.000 0.000 0.000 sets.py:528(remove)
1 0.000 0.000 0.000 0.000 sets.py:564(_TemporarilyImmutableSet)
1 0.000 0.000 0.000 0.000 sets.py:83(BaseSet)
26 0.000 0.000 0.000 0.000 sets.py:99(__len__)
1 0.000 0.000 0.000 0.000 shutil.py:16(Error)
1 0.000 0.000 0.000 0.000 shutil.py:5(?)
896 0.017 0.000 0.028 0.000 sre.py:129(match)
4 0.000 0.000 0.013 0.003 sre.py:177(compile)
900 0.012 0.000 0.025 0.000 sre.py:216(_compile)
5 0.000 0.000 0.001 0.000 sre_compile.py:151(_compile_charset)
5 0.000 0.000 0.000 0.000 sre_compile.py:180(_optimize_charset)
17/4 0.001 0.000 0.002 0.001 sre_compile.py:24(_compile)
7 0.000 0.000 0.000 0.000 sre_compile.py:324(_simple)
4 0.000 0.000 0.001 0.000 sre_compile.py:331(_compile_info)
12 0.000 0.000 0.000 0.000 sre_compile.py:42(<lambda>)
8 0.000 0.000 0.000 0.000 sre_compile.py:440(isstring)
4 0.000 0.000 0.004 0.001 sre_compile.py:446(_code)
4 0.000 0.000 0.013 0.003 sre_compile.py:461(compile)
32 0.000 0.000 0.000 0.000 sre_parse.py:133(__len__)
51 0.000 0.000 0.000 0.000 sre_parse.py:137(__getitem__)
7 0.000 0.000 0.000 0.000 sre_parse.py:139(__setitem__)
7 0.000 0.000 0.000 0.000 sre_parse.py:141(__getslice__)
44 0.000 0.000 0.000 0.000 sre_parse.py:145(append)
24/11 0.001 0.000 0.001 0.000 sre_parse.py:147(getwidth)
4 0.000 0.000 0.000 0.000 sre_parse.py:183(__init__)
125 0.001 0.000 0.001 0.000 sre_parse.py:187(__next)
59 0.001 0.000 0.001 0.000 sre_parse.py:200(match)
98 0.002 0.000 0.003 0.000 sre_parse.py:206(get)
23 0.000 0.000 0.000 0.000 sre_parse.py:215(isident)
4 0.000 0.000 0.001 0.000 sre_parse.py:221(isname)
2 0.000 0.000 0.000 0.000 sre_parse.py:240(_class_escape)
6 0.000 0.000 0.000 0.000 sre_parse.py:269(_escape)
10/4 0.000 0.000 0.008 0.002 sre_parse.py:312(_parse_sub)
10/4 0.003 0.000 0.008 0.002 sre_parse.py:367(_parse)
4 0.000 0.000 0.009 0.002 sre_parse.py:614(parse)
4 0.000 0.000 0.000 0.000 sre_parse.py:75(__init__)
6 0.000 0.000 0.000 0.000 sre_parse.py:80(opengroup)
6 0.000 0.000 0.000 0.000 sre_parse.py:91(closegroup)
17 0.000 0.000 0.000 0.000 sre_parse.py:98(__init__)
1 0.000 0.000 0.000 0.000 stack.py:112(StgitObject)
1 0.000 0.000 0.000 0.000 stack.py:115(_set_dir)
6 0.000 0.000 0.000 0.000 stack.py:117(_dir)
1 0.000 0.000 0.000 0.000 stack.py:142(Patch)
1 0.004 0.004 0.008 0.008 stack.py:2(?)
1 0.000 0.000 0.000 0.000 stack.py:277(PatchorderCache)
1 0.000 0.000 0.000 0.000 stack.py:280(__init__)
1 0.000 0.000 0.000 0.000 stack.py:283(__invalidate)
59 0.001 0.000 0.001 0.000 stack.py:286(__cache)
2 0.000 0.000 0.000 0.000 stack.py:293(read_file)
1 0.000 0.000 0.000 0.000 stack.py:30(StackException)
59 0.005 0.000 0.007 0.000 stack.py:315(cmp)
1 0.014 0.014 0.110 0.110 stack.py:327(read_refs)
1 0.000 0.000 0.000 0.000 stack.py:33(FilterUntil)
1 0.002 0.002 2.006 2.006 stack.py:342(unapplied_patches)
1 0.026 0.026 0.037 0.037 stack.py:358(sort_applied_patches)
1 0.000 0.000 0.000 0.000 stack.py:382(AppliedCache)
1 0.000 0.000 0.000 0.000 stack.py:385(__init__)
2 0.000 0.000 2.161 1.080 stack.py:389(get_applied)
1 0.000 0.000 0.000 0.000 stack.py:392(get_unapplied)
1 0.000 0.000 0.000 0.000 stack.py:417(__invalidate)
3 0.000 0.000 0.000 0.000 stack.py:420(__cached)
3 0.001 0.000 2.161 0.720 stack.py:422(__cache)
1 0.000 0.000 0.000 0.000 stack.py:434(Series)
1 0.000 0.000 0.031 0.031 stack.py:437(__init__)
1 0.000 0.000 0.000 0.000 stack.py:479(get_branch)
1 0.000 0.000 0.000 0.000 stack.py:497(get_current)
2 0.000 0.000 2.161 1.080 stack.py:507(get_applied)
1 0.000 0.000 0.000 0.000 stack.py:510(get_unapplied)
1 0.000 0.000 0.000 0.000 stack.py:513(get_hidden)
2 0.000 0.000 0.000 0.000 stack.py:646(is_initialised)
8 0.000 0.000 0.000 0.000 stat.py:29(S_IFMT)
5 0.000 0.000 0.000 0.000 stat.py:45(S_ISDIR)
3 0.000 0.000 0.000 0.000 stat.py:54(S_ISREG)
1 0.000 0.000 0.000 0.000 templates.py:2(?)
1 0.000 0.000 0.000 0.000 utils.py:107(strip_prefix)
1 0.000 0.000 0.000 0.000 utils.py:153(EditorException)
1 0.001 0.001 0.001 0.001 utils.py:2(?)
Ordered by: standard name
Function called...
<string>:1(?) main.py:197(main)(1) 2.228
ConfigParser.py:105(Error) --
ConfigParser.py:117(NoSectionError) --
ConfigParser.py:124(DuplicateSectionError) --
ConfigParser.py:131(NoOptionError) --
ConfigParser.py:140(InterpolationError) --
ConfigParser.py:148(InterpolationMissingOptionError) --
ConfigParser.py:161(InterpolationSyntaxError) --
ConfigParser.py:165(InterpolationDepthError) --
ConfigParser.py:176(ParsingError) --
ConfigParser.py:188(MissingSectionHeaderError) --
ConfigParser.py:202(RawConfigParser) sre.py:177(compile)(2) 0.013
ConfigParser.py:487(ConfigParser) --
ConfigParser.py:570(SafeConfigParser) sre.py:177(compile)(1) 0.013
ConfigParser.py:88(?) ConfigParser.py:105(Error)(1) 0.000
ConfigParser.py:117(NoSectionError)(1) 0.000
ConfigParser.py:124(DuplicateSectionError)(1) 0.000
ConfigParser.py:131(NoOptionError)(1) 0.000
ConfigParser.py:140(InterpolationError)(1) 0.000
ConfigParser.py:148(InterpolationMissingOptionError)(1) 0.000
ConfigParser.py:161(InterpolationSyntaxError)(1) 0.000
ConfigParser.py:165(InterpolationDepthError)(1) 0.000
ConfigParser.py:176(ParsingError)(1) 0.000
ConfigParser.py:188(MissingSectionHeaderError)(1) 0.000
ConfigParser.py:202(RawConfigParser)(1) 0.009
ConfigParser.py:487(ConfigParser)(1) 0.000
ConfigParser.py:570(SafeConfigParser)(1) 0.002
UserDict.py:19(__getitem__) --
UserDict.py:62(__contains__) --
basedir.py:2(?) --
basedir.py:23(__output) --
basedir.py:33(get) UserDict.py:62(__contains__)(1) 0.000
basedir.py:23(__output)(1) 0.007
common.py:2(?) common.py:32(CmdException)(1) 0.000
common.py:37(RevParseException)(1) 0.000
stack.py:2(?)(1) 0.008
utils.py:2(?)(1) 0.001
common.py:32(CmdException) --
common.py:37(RevParseException) --
config.py:125(config_setup) config.py:65(get)(1) 0.006
os.py:444(__setitem__)(1) 0.000
config.py:134(ConfigOption) --
config.py:137(__init__) --
config.py:2(?) basedir.py:2(?)(1) 0.000
config.py:24(GitConfigException)(1) 0.000
config.py:27(GitConfig)(1) 0.000
config.py:134(ConfigOption)(1) 0.000
config.py:24(GitConfigException) --
config.py:27(GitConfig) --
config.py:65(get) --
git.py:180(_output_one_line) popen2.py:31(__init__)(1) 0.064
popen2.py:87(wait)(1) 0.000
git.py:192(_output_lines) popen2.py:31(__init__)(2) 0.064
popen2.py:87(wait)(2) 0.000
git.py:2(?) git.py:30(GitException)(1) 0.000
git.py:39(Person)(1) 0.000
git.py:71(Commit)(1) 0.000
gitmergeonefile.py:2(?)(1) 0.000
sets.py:41(?)(1) 0.001
shutil.py:5(?)(1) 0.000
git.py:288(get_head_file) git.py:180(_output_one_line)(1) 0.023
utils.py:107(strip_prefix)(1) 0.000
git.py:30(GitException) --
git.py:39(Person) --
git.py:71(Commit) --
gitmergeonefile.py:2(?) config.py:137(__init__)(2) 0.000
gitmergeonefile.py:27(GitMergeException)(1) 0.000
gitmergeonefile.py:27(GitMergeException) --
main.py:197(main) ConfigParser.py:88(?)(1) 0.011
UserDict.py:19(__getitem__)(1) 0.000
config.py:125(config_setup)(1) 0.006
main.py:32(canonical_cmd)(1) 0.000
main.py:51(__getitem__)(1) 0.015
optparse.py:975(__init__)(1) 0.001
optparse.py:1097(parse_args)(1) 0.000
posixpath.py:110(basename)(1) 0.000
series.py:111(func)(1) 2.163
stack.py:437(__init__)(1) 0.031
main.py:32(canonical_cmd) --
main.py:51(__getitem__) series.py:2(?)(1) 0.015
optparse.py:1007(_create_option_list) optparse.py:759(_create_option_mappings)(1) 0.000
optparse.py:1012(_populate_option_list) optparse.py:815(add_option)(1) 0.001
optparse.py:845(add_options)(1) 0.001
optparse.py:1022(_init_parsing_state) --
optparse.py:1036(set_usage) --
optparse.py:1059(get_default_values) optparse.py:662(__init__)(1) 0.000
optparse.py:1091(_get_args) --
optparse.py:1097(parse_args) optparse.py:1059(get_default_values)(1) 0.000
optparse.py:1091(_get_args)(1) 0.000
optparse.py:1136(check_values)(1) 0.000
optparse.py:1149(_process_args)(1) 0.000
optparse.py:1136(check_values) --
optparse.py:1149(_process_args) --
optparse.py:140(__init__) --
optparse.py:247(__init__) optparse.py:140(__init__)(1) 0.000
optparse.py:413(__init__) optparse.py:432(_check_opt_strings)(12) 0.000
optparse.py:441(_set_opt_strings)(12) 0.000
optparse.py:462(_set_attrs)(12) 0.000
optparse.py:480(_check_action)(12) 0.000
optparse.py:486(_check_type)(12) 0.000
optparse.py:504(_check_choice)(12) 0.000
optparse.py:517(_check_dest)(12) 0.000
optparse.py:528(_check_const)(12) 0.000
optparse.py:534(_check_nargs)(12) 0.000
optparse.py:543(_check_callback)(12) 0.000
optparse.py:432(_check_opt_strings) --
optparse.py:441(_set_opt_strings) --
optparse.py:462(_set_attrs) --
optparse.py:480(_check_action) --
optparse.py:486(_check_type) --
optparse.py:504(_check_choice) --
optparse.py:517(_check_dest) --
optparse.py:528(_check_const) --
optparse.py:534(_check_nargs) --
optparse.py:543(_check_callback) --
optparse.py:662(__init__) --
optparse.py:748(__init__) optparse.py:775(set_conflict_handler)(1) 0.000
optparse.py:780(set_description)(1) 0.000
optparse.py:1007(_create_option_list)(1) 0.000
optparse.py:759(_create_option_mappings) --
optparse.py:775(set_conflict_handler) --
optparse.py:780(set_description) --
optparse.py:786(_check_conflict) --
optparse.py:815(add_option) optparse.py:786(_check_conflict)(13) 0.000
optparse.py:845(add_options) optparse.py:815(add_option)(12) 0.001
optparse.py:975(__init__) optparse.py:247(__init__)(1) 0.000
optparse.py:748(__init__)(1) 0.000
optparse.py:1012(_populate_option_list)(1) 0.001
optparse.py:1022(_init_parsing_state)(1) 0.000
optparse.py:1036(set_usage)(1) 0.000
os.py:444(__setitem__) --
popen2.py:21(_cleanup) --
popen2.py:25(Popen3) --
popen2.py:31(__init__) popen2.py:21(_cleanup)(4) 0.000
popen2.py:7(?) popen2.py:25(Popen3)(1) 0.000
popen2.py:97(Popen4)(1) 0.000
popen2.py:87(wait) --
popen2.py:97(Popen4) --
posixpath.py:110(basename) posixpath.py:74(split)(1) 0.000
posixpath.py:184(isdir) stat.py:45(S_ISDIR)(5) 0.000
posixpath.py:197(isfile) stat.py:54(S_ISREG)(3) 0.000
posixpath.py:56(join) --
posixpath.py:74(split) --
profile:0(main()) <string>:1(?)(1) 2.229
profile:0(profiler) profile:0(main())(1) 2.229
series.py:111(func) series.py:88(__print_patch)(38) 0.001
stack.py:497(get_current)(1) 0.000
stack.py:507(get_applied)(1) 2.161
stack.py:510(get_unapplied)(1) 0.000
stack.py:513(get_hidden)(1) 0.000
series.py:2(?) common.py:2(?)(1) 0.011
optparse.py:413(__init__)(12) 0.002
series.py:88(__print_patch) --
sets.py:119(__iter__) --
sets.py:356(_update) --
sets.py:393(ImmutableSet) --
sets.py:41(?) sets.py:83(BaseSet)(1) 0.000
sets.py:393(ImmutableSet)(1) 0.000
sets.py:418(Set)(1) 0.000
sets.py:564(_TemporarilyImmutableSet)(1) 0.000
sets.py:418(Set) --
sets.py:425(__init__) sets.py:356(_update)(1) 0.000
sets.py:515(add) --
sets.py:528(remove) --
sets.py:564(_TemporarilyImmutableSet) --
sets.py:83(BaseSet) --
sets.py:99(__len__) --
shutil.py:16(Error) --
shutil.py:5(?) shutil.py:16(Error)(1) 0.000
sre.py:129(match) sre.py:216(_compile)(896) 0.025
sre.py:177(compile) sre.py:216(_compile)(4) 0.025
sre.py:216(_compile) sre_compile.py:440(isstring)(4) 0.000
sre_compile.py:461(compile)(4) 0.013
sre_compile.py:151(_compile_charset) sre_compile.py:42(<lambda>)(6) 0.000
sre_compile.py:180(_optimize_charset)(5) 0.000
sre_compile.py:180(_optimize_charset) sre_compile.py:42(<lambda>)(6) 0.000
sre_compile.py:24(_compile) sre_compile.py:24(_compile)(13) 0.002
sre_compile.py:151(_compile_charset)(5) 0.001
sre_compile.py:324(_simple)(7) 0.000
sre_parse.py:137(__getitem__)(27) 0.000
sre_compile.py:324(_simple) sre_parse.py:137(__getitem__)(7) 0.000
sre_parse.py:147(getwidth)(7) 0.001
sre_compile.py:331(_compile_info) sre_parse.py:133(__len__)(4) 0.000
sre_parse.py:137(__getitem__)(3) 0.000
sre_parse.py:147(getwidth)(4) 0.001
sre_compile.py:42(<lambda>) --
sre_compile.py:440(isstring) --
sre_compile.py:446(_code) sre_compile.py:24(_compile)(4) 0.002
sre_compile.py:331(_compile_info)(4) 0.001
sre_compile.py:461(compile) sre_compile.py:440(isstring)(4) 0.000
sre_compile.py:446(_code)(4) 0.004
sre_parse.py:614(parse)(4) 0.009
sre_parse.py:133(__len__) --
sre_parse.py:137(__getitem__) --
sre_parse.py:139(__setitem__) --
sre_parse.py:141(__getslice__) sre_parse.py:98(__init__)(7) 0.000
sre_parse.py:145(append) --
sre_parse.py:147(getwidth) sre_parse.py:147(getwidth)(13) 0.001
sre_parse.py:183(__init__) sre_parse.py:187(__next)(4) 0.001
sre_parse.py:187(__next) --
sre_parse.py:200(match) sre_parse.py:187(__next)(23) 0.001
sre_parse.py:206(get) sre_parse.py:187(__next)(98) 0.001
sre_parse.py:215(isident) --
sre_parse.py:221(isname) sre_parse.py:215(isident)(23) 0.000
sre_parse.py:240(_class_escape) --
sre_parse.py:269(_escape) --
sre_parse.py:312(_parse_sub) sre_parse.py:200(match)(16) 0.001
sre_parse.py:367(_parse)(10) 0.008
sre_parse.py:367(_parse) sre_parse.py:80(opengroup)(6) 0.000
sre_parse.py:91(closegroup)(6) 0.000
sre_parse.py:98(__init__)(10) 0.000
sre_parse.py:133(__len__)(28) 0.000
sre_parse.py:137(__getitem__)(14) 0.000
sre_parse.py:139(__setitem__)(7) 0.000
sre_parse.py:141(__getslice__)(7) 0.000
sre_parse.py:145(append)(44) 0.000
sre_parse.py:200(match)(43) 0.001
sre_parse.py:206(get)(94) 0.003
sre_parse.py:221(isname)(4) 0.001
sre_parse.py:240(_class_escape)(2) 0.000
sre_parse.py:269(_escape)(6) 0.000
sre_parse.py:312(_parse_sub)(6) 0.008
sre_parse.py:614(parse) sre_parse.py:75(__init__)(4) 0.000
sre_parse.py:183(__init__)(4) 0.000
sre_parse.py:206(get)(4) 0.003
sre_parse.py:312(_parse_sub)(4) 0.008
sre_parse.py:75(__init__) --
sre_parse.py:80(opengroup) --
sre_parse.py:91(closegroup) --
sre_parse.py:98(__init__) --
stack.py:112(StgitObject) --
stack.py:115(_set_dir) --
stack.py:117(_dir) --
stack.py:142(Patch) --
stack.py:2(?) git.py:2(?)(1) 0.003
popen2.py:7(?)(1) 0.000
stack.py:30(StackException)(1) 0.000
stack.py:33(FilterUntil)(1) 0.000
stack.py:112(StgitObject)(1) 0.000
stack.py:142(Patch)(1) 0.000
stack.py:277(PatchorderCache)(1) 0.000
stack.py:382(AppliedCache)(1) 0.000
stack.py:434(Series)(1) 0.000
templates.py:2(?)(1) 0.000
stack.py:277(PatchorderCache) --
stack.py:280(__init__) stack.py:283(__invalidate)(1) 0.000
stack.py:283(__invalidate) --
stack.py:286(__cache) posixpath.py:56(join)(3) 0.000
posixpath.py:197(isfile)(3) 0.000
stack.py:117(_dir)(3) 0.000
stack.py:293(read_file)(2) 0.000
stack.py:293(read_file) --
stack.py:30(StackException) --
stack.py:315(cmp) stack.py:286(__cache)(59) 0.001
stack.py:327(read_refs) git.py:192(_output_lines)(1) 2.067
sre.py:129(match)(896) 0.028
sre.py:177(compile)(1) 0.013
stack.py:33(FilterUntil) --
stack.py:342(unapplied_patches) git.py:192(_output_lines)(1) 2.067
sets.py:119(__iter__)(19) 0.000
sets.py:425(__init__)(46) 0.001
sets.py:515(add)(64) 0.001
stack.py:358(sort_applied_patches) popen2.py:31(__init__)(1) 0.064
sets.py:99(__len__)(26) 0.000
sets.py:119(__iter__)(25) 0.000
sets.py:425(__init__)(26) 0.001
sets.py:515(add)(25) 0.001
sets.py:528(remove)(25) 0.000
stack.py:382(AppliedCache) --
stack.py:385(__init__) stack.py:280(__init__)(1) 0.000
stack.py:417(__invalidate)(1) 0.000
stack.py:389(get_applied) stack.py:422(__cache)(2) 2.161
stack.py:392(get_unapplied) stack.py:422(__cache)(1) 2.161
stack.py:417(__invalidate) --
stack.py:420(__cached) --
stack.py:422(__cache) sets.py:119(__iter__)(2) 0.000
stack.py:315(cmp)(59) 0.007
stack.py:327(read_refs)(1) 0.110
stack.py:342(unapplied_patches)(1) 2.006
stack.py:358(sort_applied_patches)(1) 0.037
stack.py:420(__cached)(3) 0.000
stack.py:479(get_branch)(1) 0.000
stack.py:434(Series) --
stack.py:437(__init__) basedir.py:33(get)(1) 0.007
git.py:288(get_head_file)(1) 0.023
posixpath.py:56(join)(5) 0.000
posixpath.py:184(isdir)(3) 0.000
stack.py:115(_set_dir)(1) 0.000
stack.py:117(_dir)(3) 0.000
stack.py:385(__init__)(1) 0.000
stack.py:646(is_initialised)(2) 0.000
stack.py:479(get_branch) --
stack.py:497(get_current) stack.py:507(get_applied)(1) 2.161
stack.py:507(get_applied) stack.py:389(get_applied)(2) 2.161
stack.py:510(get_unapplied) stack.py:392(get_unapplied)(1) 0.000
stack.py:513(get_hidden) posixpath.py:197(isfile)(1) 0.000
stack.py:646(is_initialised) posixpath.py:184(isdir)(2) 0.000
stat.py:29(S_IFMT) --
stat.py:45(S_ISDIR) stat.py:29(S_IFMT)(5) 0.000
stat.py:54(S_ISREG) stat.py:29(S_IFMT)(3) 0.000
templates.py:2(?) --
utils.py:107(strip_prefix) --
utils.py:153(EditorException) --
utils.py:2(?) config.py:2(?)(1) 0.000
utils.py:153(EditorException)(1) 0.000
^ permalink raw reply
* Re: newby question about merge.
From: Christian MICHON @ 2007-05-16 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705161241560.6410@racer.site>
On 5/16/07, Johannes Schindelin wrote:
> > You can just do "git cat-file -p :2:filename > filename", then "git add
> > filename" (or "git update-index filename") to resolve conflict.
>
> Do we really want to advertise this obscure-looking plumbing? Wouldn't it
> be better to teach people to use "git show" instead?
>
> I mean, people can get intimidated by that...
>
> Ciao,
> Dscho
>
I could be wrong, but git-show works in this way only after version 1.5, right ?
As far as I can tell, using git-1.4.4.4 or ealier, you would still need
git-cat-file -p... to fix this merge conflict.
--
Christian
^ permalink raw reply
* Re: newby question about merge.
From: Johannes Schindelin @ 2007-05-16 14:45 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660705160721u24e43f7bmb5171555158089fb@mail.gmail.com>
Hi,
[please, Christian, do not cut the Cc: list. In particular, do _not_ cut
the person you are _responding_ to from the Cc: list]
On Wed, 16 May 2007, Christian MICHON wrote:
> On 5/16/07, Johannes Schindelin wrote:
> > > You can just do "git cat-file -p :2:filename > filename", then "git
> > > add filename" (or "git update-index filename") to resolve conflict.
> >
> > Do we really want to advertise this obscure-looking plumbing? Wouldn't
> > it be better to teach people to use "git show" instead?
> >
> > I mean, people can get intimidated by that...
>
> I could be wrong, but git-show works in this way only after version 1.5,
> right ?
Yes. So what?
> As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> git-cat-file -p... to fix this merge conflict.
If you are using pre-1.5 Git, you should really, really upgrade.
If you do not want to do that, then _at least_ you should not confuse
newbies, who _should_ use Git 1.5+.
And most importantly: if you suggest a change in the man pages, it should
reflect the new Git versions, _not_ the old ones.
Okay?
Ciao,
Dscho
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Brian Gernhardt @ 2007-05-16 14:46 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
On May 16, 2007, at 6:38 AM, Andy Parkins wrote:
> That is - just commit a fix or, commit the fix, "F", directly on
> "B" then
> merge that fix back to HEAD with "M".
>
> I quite like option 2 because it records intent - i.e. "I wish I
> could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
>
> What do people think?
I just encountered this myself with one of my repos. I'm developing
solo so I could just rebase if I felt like it, but don't like
developing that habit, so I'm probably going with the second one.
But that's because of how I'm developing it. My master has undergone
serious changes recently (since the bug commit), so I'm going back
and checking out the bug commit to focus on that issue without
anything else that's been changed since then.
My personal feeling is that the commit should reflect how the fix was
developed. If it's simple fix that you simply wrote on top of the
full branch, commit it that way. If you had to (or wanted to) go
back and develop on top of the original commit, commit it that way.
Usually I'll just commit on top of master, but if either I need to
remove other complications from the fix or need to introduce the fix
(but not everything else) into multiple branches, I'll do the merge.
~~ Brian
^ permalink raw reply
* [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Johannes Schindelin @ 2007-05-16 16:22 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git, spearce
In-Reply-To: <6efbd9b70705111308v47a76b04n9328ebf393a209e6@mail.gmail.com>
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.
Noticed by Chris Riddoch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 11 May 2007, Chris Riddoch wrote:
> I believe I've uncovered an issue in fast-import, but I don't
> know the code well enough yet to debug it. So, I'll produce my
> evidence and let others work on finding the solution. It should
> be pretty easy to reproduce.
It was easy. Thanks.
The problem is -- again -- that a directory is overwritten, since
it is not recognized as a directory. Earlier, I tried to use the
trailing "/" for that. Which fails with your example.
I actually took the time to research in Wikipedia what should be
the correct way to find out if the current item is a directory...
contrib/fast-import/import-tars.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 1e6fa5a..23aeb25 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -75,7 +75,7 @@ foreach my $tar_file (@ARGV)
$mode = oct $mode;
$size = oct $size;
$mtime = oct $mtime;
- next if $mode & 0040000;
+ next if $typeflag == 5; # directory
print FI "blob\n", "mark :$next_mark\n", "data $size\n";
while ($size > 0 && read(I, $_, 512) == 512) {
--
1.5.2.rc3.2506.ge455
^ permalink raw reply related
* [PATCHv3] connect: display connection progress
From: Michael S. Tsirkin @ 2007-05-16 17:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git, Linus Torvalds, Alex Riesen
Make git notify the user about host resolution/connection attempts.
This is useful both as a progress indicator on slow links, and helps
reassure the user there are no firewall problems.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
Tried to incorporate most of the feedback on v2.
Once some commands get -vv flag, we'll be able to add
CONNECT_EXTRA_VERBOSE and print out address information etc,
but this is outside the scope of this patch.
diff --git a/builtin-archive.c b/builtin-archive.c
index 7f4e409..187491b 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -45,7 +45,7 @@ static int run_remote_archiver(const char *remote, int argc,
}
url = xstrdup(remote);
- pid = git_connect(fd, url, exec);
+ pid = git_connect(fd, url, exec, 0);
if (pid < 0)
return pid;
diff --git a/cache.h b/cache.h
index aaeb04a..206bbe4 100644
--- a/cache.h
+++ b/cache.h
@@ -463,7 +463,8 @@ struct ref {
#define REF_HEADS (1u << 1)
#define REF_TAGS (1u << 2)
-extern pid_t git_connect(int fd[2], char *url, const char *prog);
+#define CONNECT_VERBOSE (1u << 0)
+extern pid_t git_connect(int fd[2], char *url, const char *prog, int flags);
extern int finish_connect(pid_t pid);
extern int path_match(const char *path, int nr, char **match);
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
diff --git a/connect.c b/connect.c
index da89c9c..2a26fdb 100644
--- a/connect.c
+++ b/connect.c
@@ -394,7 +394,7 @@ static enum protocol get_protocol(const char *name)
/*
* Returns a connected socket() fd, or else die()s.
*/
-static int git_tcp_connect_sock(char *host)
+static int git_tcp_connect_sock(char *host, int flags)
{
int sockfd = -1, saved_errno = 0;
char *colon, *end;
@@ -425,10 +425,16 @@ static int git_tcp_connect_sock(char *host)
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "Looking up %s ... ", host);
+
gai = getaddrinfo(host, port, &hints, &ai);
if (gai)
die("Unable to look up %s (port %s) (%s)", host, port, gai_strerror(gai));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\nConnecting to %s (port %s) ... ", host, port);
+
for (ai0 = ai; ai; ai = ai->ai_next) {
sockfd = socket(ai->ai_family,
ai->ai_socktype, ai->ai_protocol);
@@ -450,6 +456,9 @@ static int git_tcp_connect_sock(char *host)
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(saved_errno));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\n");
+
return sockfd;
}
@@ -458,7 +467,7 @@ static int git_tcp_connect_sock(char *host)
/*
* Returns a connected socket() fd, or else die()s.
*/
-static int git_tcp_connect_sock(char *host)
+static int git_tcp_connect_sock(char *host, int flags)
{
int sockfd = -1, saved_errno = 0;
char *colon, *end;
@@ -485,6 +494,9 @@ static int git_tcp_connect_sock(char *host)
port = colon + 1;
}
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "Looking up %s ... ", host);
+
he = gethostbyname(host);
if (!he)
die("Unable to look up %s (%s)", host, hstrerror(h_errno));
@@ -497,6 +509,9 @@ static int git_tcp_connect_sock(char *host)
nport = se->s_port;
}
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\nConnecting to %s (port %s) ... ", host, port);
+
for (ap = he->h_addr_list; *ap; ap++) {
sockfd = socket(he->h_addrtype, SOCK_STREAM, 0);
if (sockfd < 0) {
@@ -521,15 +536,18 @@ static int git_tcp_connect_sock(char *host)
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(saved_errno));
+ if (flags & CONNECT_VERBOSE)
+ fprintf(stderr, "done.\n");
+
return sockfd;
}
#endif /* NO_IPV6 */
-static void git_tcp_connect(int fd[2], char *host)
+static void git_tcp_connect(int fd[2], char *host, int flags)
{
- int sockfd = git_tcp_connect_sock(host);
+ int sockfd = git_tcp_connect_sock(host, flags);
fd[0] = sockfd;
fd[1] = dup(sockfd);
@@ -646,7 +664,7 @@ static void git_proxy_connect(int fd[2], char *host)
*
* Does not return a negative value on error; it just dies.
*/
-pid_t git_connect(int fd[2], char *url, const char *prog)
+pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
{
char *host, *path = url;
char *end;
@@ -719,7 +737,7 @@ pid_t git_connect(int fd[2], char *url, const char *prog)
if (git_use_proxy(host))
git_proxy_connect(fd, host);
else
- git_tcp_connect(fd, host);
+ git_tcp_connect(fd, host, flags);
/*
* Separate original protocol components prog and path
* from extended components with a NUL byte.
diff --git a/fetch-pack.c b/fetch-pack.c
index 06f4aec..aa59043 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -733,7 +733,7 @@ int main(int argc, char **argv)
}
if (!dest)
usage(fetch_pack_usage);
- pid = git_connect(fd, dest, uploadpack);
+ pid = git_connect(fd, dest, uploadpack, verbose ? CONNECT_VERBOSE : 0);
if (pid < 0)
return 1;
if (heads && nr_heads)
diff --git a/peek-remote.c b/peek-remote.c
index 96bfac4..ceb7871 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
if (!dest || i != argc - 1)
usage(peek_remote_usage);
- pid = git_connect(fd, dest, uploadpack);
+ pid = git_connect(fd, dest, uploadpack, 0);
if (pid < 0)
return 1;
ret = peek_remote(fd, flags);
diff --git a/send-pack.c b/send-pack.c
index d5b5162..83ee87d 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -393,7 +393,7 @@ int main(int argc, char **argv)
usage(send_pack_usage);
verify_remote_names(nr_heads, heads);
- pid = git_connect(fd, dest, receivepack);
+ pid = git_connect(fd, dest, receivepack, verbose ? CONNECT_VERBOSE : 0);
if (pid < 0)
return 1;
ret = send_pack(fd[0], fd[1], nr_heads, heads);
--
MST
^ permalink raw reply related
* Re: [PATCHv3] connect: display connection progress
From: Linus Torvalds @ 2007-05-16 17:19 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git, Alex Riesen
In-Reply-To: <20070516170941.GA19449@mellanox.co.il>
On Wed, 16 May 2007, Michael S. Tsirkin wrote:
>
> Make git notify the user about host resolution/connection attempts.
> This is useful both as a progress indicator on slow links, and helps
> reassure the user there are no firewall problems.
Looks fine to me. Ack.
Linus
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Junio C Hamano @ 2007-05-16 17:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I quite like option 2 because it records intent - i.e. "I wish I could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
>
> What do people think?
I think that largely depends on your taste and what other things
you have between B and the tip when you contemplate on the fix.
If you ever have a forkpoint (e.g. maybe soon after B you had a
tagged release, and maintenance track for that forked from it),
then the latter is much more manageable in the long run. That
is how 'master' and 'maint' in git.git are managed. An old bug
is fixed as close to the introduction of bug as practical (so I
would _not_ fork a fix on top of B itself, but apply fix to the
tip of 'maint'), and then all newer development track that
contain breakage B merges the fix from that branch (i.e. 'maint'
is then merged into 'master' to propagate the fix forward).
The way 'next' and 'master' works in git.git looks a bit
different from it, but you will realize that the idea is the
same if you look at individual topic branches. Each topic is
forked from 'master', gain its own commits and merged to 'next'.
Its bugs may be discovered later while it still hasn't been
merged to 'master'. I'd _never_ commit a fix to 'next'
directly, but a fix goes to the tip of the topic branch that
introduces the bug, and then merged to 'next'. When the topic
is reasonably bug-free, it then is merged to 'master' -- at that
point, the history of the topic has all the relevant fixes.
If you think of your straight single strand of pearls (the first
picture) as a degenerated case that has a topic that includes B
and ends with the tip, "merged" to 'master' in a fast forward
fashion (i.e. the rightmost commit in the picture is the tip of
the topic and at the same time the tip of the 'master'), then
having a fix on top of the 'master' like in your first solution
is perfectly fine -- it is in line with how topic branches in my
repository gets fixed and how the fix is propagated to 'next'
and then eventually to 'master'.
On the other hand, if your commits between B and the tip of your
master contain enhancements and fixes to random issues (iow, it
is not a degenerated merge of a single topic into 'master', but
just a random set of development), I think your latter approach
to have only the fix as a separate (temporary) topic and merge
that to the tip is inconsistent with your current practice to
begin with, and I do not see much merit in it by itself. If you
prefer the latter solution (and I obviously do, as that is the
way git.git repository is maintained), you would also want to
have topic branches, where all the enhancements, advances _and_
fixes related to a single theme go to and then merged to the
mainline. That's the history of a theme. Having branch and
merge only for fixes but not for advancement may be "the history
of a bug", but it probably would not buy you much by itself.
^ permalink raw reply
* Re: [PATCHv3] connect: display connection progress
From: Junio C Hamano @ 2007-05-16 18:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Linus Torvalds, Alex Riesen
In-Reply-To: <20070516170941.GA19449@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Make git notify the user about host resolution/connection attempts.
> This is useful both as a progress indicator on slow links, and helps
> reassure the user there are no firewall problems.
Nicely done. Thanks.
^ permalink raw reply
* Re: [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Junio C Hamano @ 2007-05-16 18:24 UTC (permalink / raw)
To: spearce; +Cc: Chris Riddoch, git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0705161659530.6410@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Earlier, we used the mode to determine if a name was associated with
> a directory. This fails, since some tar programs do not set the mode
> correctly. However, the link indicator _has_ to be set correctly.
> The problem is -- again -- that a directory is overwritten, since
> it is not recognized as a directory. Earlier, I tried to use the
> trailing "/" for that. Which fails with your example.
>
> I actually took the time to research in Wikipedia what should be
> the correct way to find out if the current item is a directory...
This matches my reading of GNU tar as well. The patch would not
break a correctly made tar archive, would fix importing archives
created by a broken tar that does not do mode right (but uses the
correct typeflag), _and_ would _break_ archives created by tar
that is broken in a different way, sets the mode right but uses
a wrong typeflag.
I do not know which breakages are more common, and this one
being in contrib/ I do not think it really matters in practice,
but as a principle, I think we should try to adhere to the same
"no regression" policy the kernel folks try to adhere to. If
something used to work, even if its was by accident or a bug, we
had better have a pretty good reason to break it by a change
that fixes things for other people, _even_ when that other
people outnumber the people who are affected by the regression.
I'd first ask GNU tar maintainer if he knows of existing
implementations of tar that are broken in the latter sense (iow,
sets modes correctly but typeflag incorrectly), as the tarball
extraction codepath would have the exact same issue.
^ permalink raw reply
* MinGW port status
From: Alon Ziv @ 2007-05-16 18:24 UTC (permalink / raw)
To: git
Hi all,
What is the current status of the MinGW port? Are there any plans to
marge it into the Git main repository anytime soon?
Regards,
-az
^ permalink raw reply
* Re: [PATCH] import-tars: Use the "Link indicator" to identify directories
From: Junio C Hamano @ 2007-05-16 18:49 UTC (permalink / raw)
To: spearce; +Cc: Chris Riddoch, git, Johannes Schindelin
In-Reply-To: <7vsl9weie0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Earlier, we used the mode to determine if a name was associated with
>> a directory. This fails, since some tar programs do not set the mode
>> correctly. However, the link indicator _has_ to be set correctly.
Nah, what was I smoking. Even gtar seems to give mode="0000775"
(with NUL termination) for directories, so there is no way there
were regressions. Patch looks good.
Acked-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* MinGW port: some questions
From: Alon Ziv @ 2007-05-16 18:52 UTC (permalink / raw)
To: git
Hi,
I am looking at the MinGW port, and I see some rather strange changes
included in the port; "strange" in the sense that they do not appear to
have anything to do with MinGW.
I am referring, for example, to the changes from commit dc380d6, which
were reverted in Git mainline (actually in "next", they never reached
Git's "master"). Or to the changes from 4493e36, which had the same
fate.
Are these intentional? Or are they the result of some strange mismerge?
-az
^ permalink raw reply
* Re: MinGW port: some questions
From: Junio C Hamano @ 2007-05-16 19:09 UTC (permalink / raw)
To: Alon Ziv; +Cc: git
In-Reply-To: <1179341520.31213.38.camel@bruno.nolaviz.org>
Alon Ziv <alonz@nolaviz.org> writes:
> I am referring, for example, to the changes from commit dc380d6, which
> were reverted in Git mainline (actually in "next", they never reached
> Git's "master"). Or to the changes from 4493e36, which had the same
> fate.
MinGW repository bases its work on my 'next', so it will not be
pulled wholesale to my 'master'. The plan is to trickle down
the platform independent bits of fixes and refactoring to the
mainline, as well as #ifdef __MINGW32__ and $(findstring MINGW)
parts, but that will most likely happen as a series of bite
sized patch series to the list with public reviews.
I do not know if you mistyped dc380d6 (I do not find it there),
but reverting 4493e36 (merge of jc/3way) was intentional. The
work in that commit that deviates from the mainline is the
jc/3way topic, which turned out to be incomplete and not very
usable. MinGW tree might not have synchronized with the latest
from the mainline in which case it might not have merged the
revert from me yet, and that may be why you are seeing the
differences.
^ permalink raw reply
* Re: newby question about merge.
From: Christian MICHON @ 2007-05-16 19:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705161542540.6410@racer.site>
On 5/16/07, Johannes Schindelin wrote:
> [please, Christian, do not cut the Cc: list. In particular, do _not_ cut
> the person you are _responding_ to from the Cc: list]
[ oops. I thought some of us sometimes receive doublets of emails,
being in reply_to and cc of git@vger.kernel.org. point *taken* ]
> > I could be wrong, but git-show works in this way only after version 1.5,
> > right ?
>
> Yes. So what?
I also sometimes use old git versions (I still consider 1.4.4.4 as a reference).
I know the API changes frequently. But engineers don't like too many changes
usually, and like to carry a portable/stable way. "git cat-file" at
least behaves
as it was in 1.4.x :)
> > As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> > git-cat-file -p... to fix this merge conflict.
>
> If you are using pre-1.5 Git, you should really, really upgrade.
While in principle I'd agree, in practice I do not. Git API changes
increased learning curve for people who actually started with git a
year ago.
Note this is a git user feedback, not a git developer feedback.
>
> If you do not want to do that, then _at least_ you should not confuse
> newbies, who _should_ use Git 1.5+.
hey, I'm not a newbie anymore! :)
it's just that today, on a machine I only had git-1.4.4.4 to play with,
I had to do a merge of 2 private branches ( aufs and squashfs) on
linux-2.6.21... I had 3 smalls conflicts to fix and I saw this thread...
and decided to stick with git-cat-file on this fix.
> And most importantly: if you suggest a change in the man pages, it should
> reflect the new Git versions, _not_ the old ones.
nope, I would not dare to suggest. I'm not a git developer: just a git user :)
> Okay?
yep
--
Christian
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 19:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0705160507h2b3c4a34xe9895d007c41d91a@mail.gmail.com>
On 2007-05-16 13:07:14 +0100, Catalin Marinas wrote:
> I did a quick test of 'stg series' with the DAG patches applied, on
> a Linux kernel repository ('du -sh .git' is 285M) with 42 patches
> (only 25 applied). It constantly takes over 2 seconds to complete
> (compared to < 200ms without the DAG patches). The problem is that
> this delay will happen for bash completion as well.
This is more than ten times as expensive as in my measurement.
Curious. And the algorithm is designed so that it shouldn't take time
proportional to the repository size, just proportional to the number
of patches.
There are three git calls involved:
* List the references. There can't be more than a few hundred of
them.
* rev-list all patches, subtracting everything that's reachable from
the branch head. This set of commits should not be much larger
than the number of unapplied patches.
* rev-list the branch head, but stop walking as soon as all applied
patches have been seen. This set of commits should not be much
larger than the number of applied patches.
None of the calls should be expensive.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: MinGW port: some questions
From: Alon Ziv @ 2007-05-16 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejlgegb9.fsf@assigned-by-dhcp.cox.net>
On Wed, 2007-05-16 at 12:09 -0700, Junio C Hamano wrote:
> I do not know if you mistyped dc380d6 (I do not find it there),
I did; it was dc3806d. I don't know how it slipped... I usually
cut'n'paste commit IDs :-/
> but reverting 4493e36 (merge of jc/3way) was intentional. The
> work in that commit that deviates from the mainline is the
> jc/3way topic, which turned out to be incomplete and not very
> usable.
I know it was intentional; but the revert happened on Feb 13, and the
MinGW port is supposed to be merged up to v1.5.1. The revert of dc3806d
("in_merge_bases(): optimization") and 40e0e66 ("merge_base(): move
traversal into a separate function.") also happened on Feb 13, and both
of there commits are still present in the MinGW master branch.
Maybe I'll just try cherry-picking the port's commits on top of the
latest master, and see if anything breaks :)
-az
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 20:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070516194002.GA17805@diana.vm.bytemark.co.uk>
On 2007-05-16 21:40:02 +0200, Karl Hasselström wrote:
> On 2007-05-16 13:07:14 +0100, Catalin Marinas wrote:
>
> > I did a quick test of 'stg series' with the DAG patches applied,
> > on a Linux kernel repository ('du -sh .git' is 285M) with 42
> > patches (only 25 applied). It constantly takes over 2 seconds to
> > complete (compared to < 200ms without the DAG patches). The
> > problem is that this delay will happen for bash completion as
> > well.
>
> This is more than ten times as expensive as in my measurement.
> Curious. And the algorithm is designed so that it shouldn't take
> time proportional to the repository size, just proportional to the
> number of patches.
I set up a kernel repository with 100 applied and 100 unapplied
patches:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ cd linux-2.6/
$ stg init
$ for ((i=0;i<200;i++)); do stg new p$(printf '%03d' $i) -m "Patch $i"; done
$ stg goto p099
Then repeatedly:
$ time stg series >/dev/null
This gives times such as
real 0m0.247s
user 0m0.156s
sys 0m0.060s
real 0m0.147s
user 0m0.088s
sys 0m0.036s
real 0m0.153s
user 0m0.088s
sys 0m0.032s
real 0m0.144s
user 0m0.104s
sys 0m0.024s
Tab completion also feels like it takes 0.1-0.2 seconds -- which it
should, since it's implemented with series, applied, and unapplied,
allow which do the same amount of work.
But my kernel repository is _much_ smaller than yours:
$ du -sh .git
183M .git
Do you perchance have a bunch of loose objects in there?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Andy Parkins @ 2007-05-16 21:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v1whgfybe.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2007, May 16, Junio C Hamano wrote:
> I think that largely depends on your taste and what other things
> you have between B and the tip when you contemplate on the fix.
As always, thank you for the detailed response. I appreciate the
thought that goes into answering these questions that flit into my
mind :-)
> is fixed as close to the introduction of bug as practical (so I
> would _not_ fork a fix on top of B itself, but apply fix to the
> tip of 'maint'), and then all newer development track that
> contain breakage B merges the fix from that branch (i.e. 'maint'
> is then merged into 'master' to propagate the fix forward).
The above method is almost a necessity when using git. If the bug fix
is committed to master, there is no way to apply that same commit to
the maint branch without also grabbing commits you don't want in maint.
> The way 'next' and 'master' works in git.git looks a bit
> different from it, but you will realize that the idea is the
> same if you look at individual topic branches. Each topic is
> forked from 'master', gain its own commits and merged to 'next'.
I've noticed flows like that when looking at git history. I always
think that it demonstrates the power of git's strong-on-branches stance
because you can almost feel the story of the development without having
to read any of the commits themselves. I wonder if other DVCSs
encourage creation of such a strong narrative?
> Its bugs may be discovered later while it still hasn't been
> merged to 'master'. I'd _never_ commit a fix to 'next'
> directly, but a fix goes to the tip of the topic branch that
> introduces the bug, and then merged to 'next'. When the topic
> is reasonably bug-free, it then is merged to 'master' -- at that
> point, the history of the topic has all the relevant fixes.
What is your preference when, for example, you have already merged a
topic to next but then a bug fix appears?
* -- * -- * -- M -- F * -- * -- * -- M -- m (next)
/ or / /
B -- * -- * B -- * -- * -- F (topic)
F is certainly most appropriate to be on the topic branch, but we create
a perhaps excessively verbose extra merge, m.
> just a random set of development), I think your latter approach
> to have only the fix as a separate (temporary) topic and merge
> that to the tip is inconsistent with your current practice to
> begin with, and I do not see much merit in it by itself. If you
> prefer the latter solution (and I obviously do, as that is the
I'm not sure I've understood what you mean here. Which "latter" are you
talking about - you've said that you find the latter inconsistent but
also that you prefer the latter solution. I'm lost :-)
> way git.git repository is maintained), you would also want to
> have topic branches, where all the enhancements, advances _and_
> fixes related to a single theme go to and then merged to the
> mainline. That's the history of a theme. Having branch and
> merge only for fixes but not for advancement may be "the history
> of a bug", but it probably would not buy you much by itself.
It's not so much a matter of it buying you something, it is more that
when you find that bug fix commit in history you can see, by following
the fix-branch back to its source, all the revisions that contained
that bug at a glance; if you just commit on the end, you have to do the
digging yourself, and hope that someone mentioned in the commit message
which commit introduced the bug that that commit fixes.
The fact that git makes it so easy to branch and merge from a previous
point is the thing that even makes this a possibility. Perhaps I'm
spoilt now :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Martin Langhoff @ 2007-05-16 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0705161232120.6410@racer.site>
On 5/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 16 May 2007, Martin Langhoff wrote:
> > Do the indexes have enough info to use them with http ranges? It'd be
> > chunkier than a smart protocol, but it'd still work with dumb servers.
> It would not be really performant, would it? Besides, not all Web servers
> speak HTTP/1.1...
Performant compared to downloading a huge packfile to get 10% of it?
Sure! It'd probably take a few trips, and you'd end up fetching 20% of
the file, still better than 100%.
> Besides, not all Web servers speak HTTP/1.1...
Are there any interesting webservers out there that don't? Hand-rolled
purpose-built webservers often don't but those don't serve files, they
serve web apps. When it comes to serving files, any webserver that is
supported (security-wise) these days is HTTP/1.1.
And for services like SF.net it'd be a safe low-cpu way of serving git
files. 'cause the git protocol is quite expensive server-side (io+cpu)
as we've seen with kernel.org. Being really smart with a cgi is
probably going to be expensive too.
cheers,
m
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Shawn O. Pearce @ 2007-05-16 21:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200705162220.15417.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> What is your preference when, for example, you have already merged a
> topic to next but then a bug fix appears?
>
> * -- * -- * -- M -- F * -- * -- * -- M -- m (next)
> / or / /
> B -- * -- * B -- * -- * -- F (topic)
>
> F is certainly most appropriate to be on the topic branch, but we create
> a perhaps excessively verbose extra merge, m.
Look at the history of the next branch; the diagram on the right is
exactly what Junio does. When topic finally graduates to master,
only F is merged to master, making master's own history not show
that "verbose extra merge" m. Or M really for that matter, as
master gets its own M'.
--
Shawn.
^ permalink raw reply
* [PATCH] gitweb: Change base font size to "small"
From: Jakub Narebski @ 2007-05-16 10:51 UTC (permalink / raw)
To: git; +Cc: Jan Hudec, David Kågedal, Petr Baudis
In-Reply-To: <20070515150912.GA3653@efreet.light.src>
Commit 63fcbe00a66d7cb7d8bce9a36120a19a809a33b8 by Peter "Pasky" Baudis
"gitweb: Do not use absolute font sizes"
made gitweb use default font size, the font size you have configured
your browser to use, as a basis; other font sizes are given as
percentage.
David Kågedal noticed problem with this approach: too many web sites
explicitly select extra small font sizes, which means that you have to
select a "standard" font size in your browser that is a bit larger
than one would actually like.
Additionally, as Jan Hudec noticed, gitweb should explicitely request
being somewhat smaller than normal, because it has good use for long
lines. Normally one would usually want to set font so large, that
more than ~120 characters won't fit on the screen, since otherwise
pages that don't use margins are simply unreadable. However gitweb
presents a table with several columns, so having wider line is OK for
it.
Jan Hudec proposed to use 'font-size: small' to take above issues into
account. This avoid using "brain-damaged" explicit-pixel sizes, while
taking into account nature of gitweb output.
Thanks to mentioned commit by Pasky we need to add 'font-size: small'
in only one place, for BODY element.
See the original messages:
Message-ID: <87odkmgaj5.fsf@morpheus.local>
Message-ID: <20070515150912.GA3653@efreet.light.src>
Proposed-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is commit wich has commit message larger than patch itself, but
I think the explanation is as important as patch itself, perhaps even
more important.
gitweb/gitweb.css | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index b57c8be..02623cb 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,5 +1,6 @@
body {
font-family: sans-serif;
+ font-size: small;
border: solid #d9d8d1;
border-width: 1px;
margin: 10px;
--
1.5.1.4
^ permalink raw reply related
* Re: Smart fetch via HTTP?
From: Jakub Narebski @ 2007-05-16 21:54 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90705161426n3b928086t2d3e68749557f866@mail.gmail.com>
Martin Langhoff wrote:
> On 5/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Wed, 16 May 2007, Martin Langhoff wrote:
>> > Do the indexes have enough info to use them with http ranges? It'd be
>> > chunkier than a smart protocol, but it'd still work with dumb servers.
>> It would not be really performant, would it? Besides, not all Web servers
>> speak HTTP/1.1...
>
> Performant compared to downloading a huge packfile to get 10% of it?
> Sure! It'd probably take a few trips, and you'd end up fetching 20% of
> the file, still better than 100%.
That's why you should have something akin to backup policy for pack files,
like daily packs, weekly packs, ..., and the rest, just for the dumb
protocols.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Martin Langhoff @ 2007-05-16 21:51 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705161138.30134.andyparkins@gmail.com>
On 5/16/07, Andy Parkins <andyparkins@gmail.com> wrote:
> I quite like option 2 because it records intent - i.e. "I wish I could have
> gone back and changed this revision, but I can't", but it makes a more
> complicated history.
I prefer just letting history show what happened, rather than try to
get too smart about it ;-) -- and use branches and merges for
experimental or feature work. Once a feature or experimental branch is
merged into master, further work happens on master (unless there are
other reasons for it to be maintained).
Bugfixes are part of the life of the maint and master branches.
Imagine your "option 2" being used to maintain git's maint branch.
Some bugs live in the code for 6 months. The merge graph would be
unreadable... and generally the project history would be really hard
to make sense of.
Most "special" practices around branches kind-of work in the
minimalistic case, but break down badly in real-life sized projects...
cheers,
martin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox