Re: wacom: Fixes for stylus pressure values for Thinkpad Yoga
Ping Cheng writes: > Thank you for the heads up. I believe Jason's patchset 4 of 4 > (http://www.spinics.net/lists/linux-input/msg29435.html) fixed the > issue for your device and for other's. The patch was submitted last > month. If you can test the set on your device and give us a Tested-by > here, it will help Dmitry to merge the patch upstream. > > Thank you for your effort. Thanks, Ping. Patches 2, 3 and 4 of Dmitry's series do everything that my series does, (and a bit more since he also fixes the "unsigned char" for cases besides the specific one I hit). So those all get my: Reviewed-by: Carl Worth I'll follow up more if I get a chance to test these as well. -Carl pgp2ADdO4Lkxl.pgp Description: PGP signature
Re: wacom: Fixes for stylus pressure values for Thinkpad Yoga
Ping Cheng pingli...@gmail.com writes: Thank you for the heads up. I believe Jason's patchset 4 of 4 (http://www.spinics.net/lists/linux-input/msg29435.html) fixed the issue for your device and for other's. The patch was submitted last month. If you can test the set on your device and give us a Tested-by here, it will help Dmitry to merge the patch upstream. Thank you for your effort. Thanks, Ping. Patches 2, 3 and 4 of Dmitry's series do everything that my series does, (and a bit more since he also fixes the unsigned char for cases besides the specific one I hit). So those all get my: Reviewed-by: Carl Worth cwo...@cworth.org I'll follow up more if I get a chance to test these as well. -Carl pgp2ADdO4Lkxl.pgp Description: PGP signature
[PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.
With Haswell, 5.4Gbps is supported. And almost all of the code was
already in place already. All that was missing was this tiny bit of
additional wiring.
Signed-off-by: Carl Worth
Reviewed-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 57552eb..ce9739e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -101,7 +101,11 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
case DP_LINK_BW_1_62:
case DP_LINK_BW_2_7:
break;
- case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */
+ case DP_LINK_BW_5_4:
+ /* XXX: But not HASWELL ULX. */
+ if (IS_HASWELL(intel_dp_to_dev(intel_dp)))
+ break;
+ /* Prior to HASWELL, maximum support is for 2.7 Gbps */
max_link_bw = DP_LINK_BW_2_7;
break;
default:
@@ -810,12 +814,24 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = encoder->new_crtc;
struct intel_connector *intel_connector = intel_dp->attached_connector;
- int lane_count, clock;
+ int lane_count;
int max_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
- int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
int bpp, mode_rate;
- static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
int link_avail, link_clock;
+ int max_link_bw;
+ /* The clock and max_clock values are an index into bws. */
+ int clock, max_clock = 0;
+ static int bws[3] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4};
+
+ max_link_bw = intel_dp_max_link_bw(intel_dp);
+
+ for (clock = 0; clock < ARRAY_SIZE(bws); clock++) {
+ if (bws[clock] == max_link_bw) {
+ max_clock = clock;
+ break;
+ }
+ }
+
if (HAS_PCH_SPLIT(dev) && !HAS_DDI(dev) && port != PORT_A)
pipe_config->has_pch_encoder = true;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.
With Haswell, 5.4Gbps is supported. And almost all of the code was
already in place already. All that was missing was this tiny bit of
additional wiring.
Signed-off-by: Carl Worth cwo...@cworth.org
Reviewed-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 57552eb..ce9739e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -101,7 +101,11 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
case DP_LINK_BW_1_62:
case DP_LINK_BW_2_7:
break;
- case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */
+ case DP_LINK_BW_5_4:
+ /* XXX: But not HASWELL ULX. */
+ if (IS_HASWELL(intel_dp_to_dev(intel_dp)))
+ break;
+ /* Prior to HASWELL, maximum support is for 2.7 Gbps */
max_link_bw = DP_LINK_BW_2_7;
break;
default:
@@ -810,12 +814,24 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)-port;
struct intel_crtc *intel_crtc = encoder-new_crtc;
struct intel_connector *intel_connector = intel_dp-attached_connector;
- int lane_count, clock;
+ int lane_count;
int max_lane_count = drm_dp_max_lane_count(intel_dp-dpcd);
- int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
int bpp, mode_rate;
- static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
int link_avail, link_clock;
+ int max_link_bw;
+ /* The clock and max_clock values are an index into bws. */
+ int clock, max_clock = 0;
+ static int bws[3] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4};
+
+ max_link_bw = intel_dp_max_link_bw(intel_dp);
+
+ for (clock = 0; clock ARRAY_SIZE(bws); clock++) {
+ if (bws[clock] == max_link_bw) {
+ max_clock = clock;
+ break;
+ }
+ }
+
if (HAS_PCH_SPLIT(dev) !HAS_DDI(dev) port != PORT_A)
pipe_config-has_pch_encoder = true;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
wacom: Fixes for stylus pressure values for Thinkpad Yoga
This series of patches fixes the pressure values reported for the wacom tablet built-in to a Lenovo ThinkPad Yoga laptop. Prior to this patch series, if I slowly increased stylus pressure, (expecting a gradual increase of values from 0 to 1023), I instead received values that increased slowly to 255, then reset to 0 and increased slowly again, etc. The buggy arithmetic that is updated here appears to exist in identical forms for other drivers. I did not update any code that I was not able to test directly. But it looks like wacom_pl_irq and wacom_dtu_irq potentially have similar bugs, (depending on the actual pressure_max values encountered in practice). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Input: wacom - EC tablet supports 1023 levels of pressure, not just 255
This was verified on a ThinkPad Yoga laptop with an integrated Wacom
tablet which reports itself with an ID of 0xEC.
Signed-off-by: Carl Worth
---
drivers/input/tablet/wacom_wac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 782c253..4958081 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -2109,7 +2109,7 @@ static const struct wacom_features wacom_features_0xE6 =
0, TABLETPC2FG, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
.touch_max = 2 };
static const struct wacom_features wacom_features_0xEC =
- { "Wacom ISDv4 EC", WACOM_PKGLEN_GRAPHIRE, 25710, 14500, 255,
+ { "Wacom ISDv4 EC", WACOM_PKGLEN_GRAPHIRE, 25710, 14500, 1023,
0, TABLETPC,WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0xED =
{ "Wacom ISDv4 ED", WACOM_PKGLEN_GRAPHIRE, 26202, 16325, 255,
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Input: wacom - Don't discard bits from upper byte of pressure value
The mask here previously discarded all but one bit of data from the upper byte of the pressure value. That would be correct for a tablet with at most 512 pressure values, but is incorrect for a tablet with 1024 or more pressure values. We can support as many tablets as possible by simply not discarding any of the bits from this byte. Signed-off-by: Carl Worth --- drivers/input/tablet/wacom_wac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c index 4958081..563f197 100644 --- a/drivers/input/tablet/wacom_wac.c +++ b/drivers/input/tablet/wacom_wac.c @@ -1037,7 +1037,7 @@ static int wacom_tpc_pen(struct wacom_wac *wacom) input_report_key(input, BTN_STYLUS2, data[1] & 0x10); input_report_abs(input, ABS_X, le16_to_cpup((__le16 *)[2])); input_report_abs(input, ABS_Y, le16_to_cpup((__le16 *)[4])); - pressure = ((data[7] & 0x01) << 8) | data[6]; + pressure = (data[7] << 8) | data[6]; if (pressure < 0) pressure = features->pressure_max + pressure + 1; input_report_abs(input, ABS_PRESSURE, pressure); -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Input: wacom - Avoid incorrect sign extension from pressure-value lower byte
Previously, whenever the lower byte was greater than 127, the sign
extension of the "char" during integer promotion would result in a
negative value for pressure. There was code in place to adjust a
negative value back to positive by subtracting from pressure_max, but
this code was only correct with a tablet with a maximum of 256
pressure values.
By switching from "char" to "unsigned char" we can avoid the sign
extension altogether, eliminate the code to adjust values, and obtain
correct pressure results.
With this code in place, I am now obtaining correct pressure results
from the Wacom tablet built into a ThinkPad Yoga laptop. (Prior to
this fix, gradual increases of pressure would result in pressure
values that would reset from 255 to 0 rathern than simply increasing.)
Signed-off-by: Carl Worth
---
drivers/input/tablet/wacom_wac.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 563f197..93f7440 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1018,8 +1018,7 @@ static int wacom_tpc_single_touch(struct wacom_wac
*wacom, size_t len)
static int wacom_tpc_pen(struct wacom_wac *wacom)
{
- struct wacom_features *features = >features;
- char *data = wacom->data;
+ unsigned char *data = wacom->data;
struct input_dev *input = wacom->input;
int pressure;
bool prox = data[1] & 0x20;
@@ -1038,8 +1037,6 @@ static int wacom_tpc_pen(struct wacom_wac *wacom)
input_report_abs(input, ABS_X, le16_to_cpup((__le16
*)[2]));
input_report_abs(input, ABS_Y, le16_to_cpup((__le16
*)[4]));
pressure = (data[7] << 8) | data[6];
- if (pressure < 0)
- pressure = features->pressure_max + pressure + 1;
input_report_abs(input, ABS_PRESSURE, pressure);
input_report_key(input, BTN_TOUCH, data[1] & 0x05);
input_report_key(input, wacom->tool[0], prox);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Input: wacom - Don't discard bits from upper byte of pressure value
The mask here previously discarded all but one bit of data from the upper byte of the pressure value. That would be correct for a tablet with at most 512 pressure values, but is incorrect for a tablet with 1024 or more pressure values. We can support as many tablets as possible by simply not discarding any of the bits from this byte. Signed-off-by: Carl Worth cwo...@cworth.org --- drivers/input/tablet/wacom_wac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c index 4958081..563f197 100644 --- a/drivers/input/tablet/wacom_wac.c +++ b/drivers/input/tablet/wacom_wac.c @@ -1037,7 +1037,7 @@ static int wacom_tpc_pen(struct wacom_wac *wacom) input_report_key(input, BTN_STYLUS2, data[1] 0x10); input_report_abs(input, ABS_X, le16_to_cpup((__le16 *)data[2])); input_report_abs(input, ABS_Y, le16_to_cpup((__le16 *)data[4])); - pressure = ((data[7] 0x01) 8) | data[6]; + pressure = (data[7] 8) | data[6]; if (pressure 0) pressure = features-pressure_max + pressure + 1; input_report_abs(input, ABS_PRESSURE, pressure); -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Input: wacom - Avoid incorrect sign extension from pressure-value lower byte
Previously, whenever the lower byte was greater than 127, the sign
extension of the char during integer promotion would result in a
negative value for pressure. There was code in place to adjust a
negative value back to positive by subtracting from pressure_max, but
this code was only correct with a tablet with a maximum of 256
pressure values.
By switching from char to unsigned char we can avoid the sign
extension altogether, eliminate the code to adjust values, and obtain
correct pressure results.
With this code in place, I am now obtaining correct pressure results
from the Wacom tablet built into a ThinkPad Yoga laptop. (Prior to
this fix, gradual increases of pressure would result in pressure
values that would reset from 255 to 0 rathern than simply increasing.)
Signed-off-by: Carl Worth cwo...@cworth.org
---
drivers/input/tablet/wacom_wac.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 563f197..93f7440 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1018,8 +1018,7 @@ static int wacom_tpc_single_touch(struct wacom_wac
*wacom, size_t len)
static int wacom_tpc_pen(struct wacom_wac *wacom)
{
- struct wacom_features *features = wacom-features;
- char *data = wacom-data;
+ unsigned char *data = wacom-data;
struct input_dev *input = wacom-input;
int pressure;
bool prox = data[1] 0x20;
@@ -1038,8 +1037,6 @@ static int wacom_tpc_pen(struct wacom_wac *wacom)
input_report_abs(input, ABS_X, le16_to_cpup((__le16
*)data[2]));
input_report_abs(input, ABS_Y, le16_to_cpup((__le16
*)data[4]));
pressure = (data[7] 8) | data[6];
- if (pressure 0)
- pressure = features-pressure_max + pressure + 1;
input_report_abs(input, ABS_PRESSURE, pressure);
input_report_key(input, BTN_TOUCH, data[1] 0x05);
input_report_key(input, wacom-tool[0], prox);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
wacom: Fixes for stylus pressure values for Thinkpad Yoga
This series of patches fixes the pressure values reported for the wacom tablet built-in to a Lenovo ThinkPad Yoga laptop. Prior to this patch series, if I slowly increased stylus pressure, (expecting a gradual increase of values from 0 to 1023), I instead received values that increased slowly to 255, then reset to 0 and increased slowly again, etc. The buggy arithmetic that is updated here appears to exist in identical forms for other drivers. I did not update any code that I was not able to test directly. But it looks like wacom_pl_irq and wacom_dtu_irq potentially have similar bugs, (depending on the actual pressure_max values encountered in practice). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Input: wacom - EC tablet supports 1023 levels of pressure, not just 255
This was verified on a ThinkPad Yoga laptop with an integrated Wacom
tablet which reports itself with an ID of 0xEC.
Signed-off-by: Carl Worth cwo...@cworth.org
---
drivers/input/tablet/wacom_wac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 782c253..4958081 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -2109,7 +2109,7 @@ static const struct wacom_features wacom_features_0xE6 =
0, TABLETPC2FG, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
.touch_max = 2 };
static const struct wacom_features wacom_features_0xEC =
- { Wacom ISDv4 EC, WACOM_PKGLEN_GRAPHIRE, 25710, 14500, 255,
+ { Wacom ISDv4 EC, WACOM_PKGLEN_GRAPHIRE, 25710, 14500, 1023,
0, TABLETPC,WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0xED =
{ Wacom ISDv4 ED, WACOM_PKGLEN_GRAPHIRE, 26202, 16325, 255,
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote: > Thanks for your comments; You're welcome. > the attached probably needs proofreading. In general, I like it. The git-branch documentation already talks about "remote-tracking branches" so I've rewritten a couple of sentence below to use that same terminology. Also there are a couple of grammar errors related to pluralization, (likely the fault of English being quite a bit less consistent than other languages with subject/verb number agreement, etc.). > + A repository with the separate remote layout starts with only > + one default branch, 'master', to be used for your own > + development. Unlike the traditional layout that copied all > + the upstream branches into your branch namespace (while > + renaming their 'master' to your 'origin'), they are not made > + into your branches. Instead, they are kept track of using > + 'refs/remotes/origin/$upstream_branch_name'. renaming remote 'master' to local 'origin'), the new approach puts upstream branches into local "remote-tracking branches" with their own namespace. These can be referenced with names such as "origin/$upstream_branch_name" and are stored in .git/refs/remotes rather than .git/refs/heads where normal branches are stored. > + This layout keeps your own branch namespace less cluttered, > + avoids name collision with your upstream, makes it possible > + to automatically track new branches created at the remote > + after you clone from it, and makes it easier to interact with > + more than one remote repositories. There might be some Should be "more than one remote repository.". Also I'd add, ", (see the new 'git remote' command)" before the end of that sentence. > + * 'git branch' does not show the branches from your upstream. Again to use the same terminology, "does not show the remote-tracking branches.". > + Repositories initialized with the traditional layout > + continues to work (and will continue to work). The 's' on "continues" is incorrect. Perhaps: continue to work (and will work in the future as well). or just drop the parenthetical phrase. -Carl pgpJ2CCBnd3h5.pgp Description: PGP signature
Re: [Announce] GIT v1.5.0-rc2
On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote: > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. Thanks, these are very good and really show how much great progress has gone into git recently. Congratulations to everyone who has helped with this! A few comments: > In general, you should not have to worry about incompatibility, > and there is no need to perform "repository conversion" if you > are updating to v1.5.0. However, some of the changes are > one-way street upgrades; once you use them your repository > can no longer be used with ancient git. This "one-way street upgrades" sentence makes the upgrade to 1.5 sound scarier than it really is. It's only after two more paragraphs of fairly dense technical content that the reader is told that none of this stuff is enabled by default yet. Maybe replace the second sentence with something like: As of git v1.5.0 there are some optional changes to the repository that allow data to be stored and transferred more efficiently. These changes are not enabled by default as they will make the repository unusable with git versions before v1.4.2. Specifically the available options are: or something along those lines. > - git-update-index is much less visible. It's not clear what this sentence means. Perhaps add something like: , (many mentions of update-index in git output and documentation have now been replaced by simpler commands such as "git add" or "git rm"). > - git-clone always uses what is known as "separate remote" >layout for a newly created repository with a working tree; >i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are >used to track branches from the origin. This change has some workflow impact that is not at all obvious from the above description. For example, after cloning git.git, things that used to work like "git checkout -b my-next next" now no longer work, (needing to use "origin/next" instead). And these branches also won't appear in "git branch" output, (without the new -r option). I think the release notes should spend a little more attention on an issue like this. Maybe a separate section on changes to existing interfaces, (as opposed to most of the other changes which are improvements in the implementation of existing interfaces or just plain new interfaces such as "git remote", "git gc", etc.) If there is a new section, the previous paragraphs describing the move of cloned origin information from .git/remotes/origin to .git/config might belong there as well, (depending on whether you consider those file contents a user-visible interface or not). > - git-branch and git-show-branch know remote tracking branches. Should mention "-r" here. > - git-push can now be used to delete a remote branch or a tag. >This requires the updated git on the remote side. What's the syntax for this? I know you don't want to turn the release notes into a user manual, but it'd be nice to have brief mentions of the new interfaces, (like the nice mention of "git add -i" for example). Even with a quick skim through the git-push documentation, I'm not immediately seeing how to delete a remote branch or tag. > - There is a toplevel garbage collector script, 'git-gc', that >is an easy way to run 'git-repack -a -d', 'git-reflog gc', >and 'git-prune'. I think it's definitely worthwhile to note the fix of race conditions, etc. here. It would be nice to have some short rule such as: "git gc" is free from any known race conditions with simultaneous git processes modifying the repository. So it's perfectly safe to run "git gc" from a cron job. Or a similarly succinct rule that's actually true, (I think the recent thread suggested "git gc" would only be safe with an extra option---I'd much rather see it be safe by default and make the user ask for extra unsafe pruning with an option). > - You can give non-branch to "git checkout" now. Rather than "non-branch" I think it would be nice to say something that mentioned tags. Maybe something like: You can now use 'git checkout' to checkout tags or any other revision, rather than just named branches." > - Repositories with hundreds of tags have been paying large >overhead, both in storage and in runtime, due to the >traditional one-ref-per-file format. A new command, >git-pack-refs, can be used to "pack" them in more efficient >representation. Is git-gc doing this housekeeping? If not, should it be? If so, should it be mentioned here (and in the description of git-gc above)? > - There is a partial support for 'shallow' repositories that >keeps only recent history. A 'shallow clone' is created by >specifying how deep that truncated history should be. Here's another description that could definitely benefit from a very short example command. -Carl
Re: [Announce] GIT v1.5.0-rc2
On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote: Also, in the same spirit of giving the release an early exposure, here is the current draft of 1.5.0 release notes. Thanks, these are very good and really show how much great progress has gone into git recently. Congratulations to everyone who has helped with this! A few comments: In general, you should not have to worry about incompatibility, and there is no need to perform repository conversion if you are updating to v1.5.0. However, some of the changes are one-way street upgrades; once you use them your repository can no longer be used with ancient git. This one-way street upgrades sentence makes the upgrade to 1.5 sound scarier than it really is. It's only after two more paragraphs of fairly dense technical content that the reader is told that none of this stuff is enabled by default yet. Maybe replace the second sentence with something like: As of git v1.5.0 there are some optional changes to the repository that allow data to be stored and transferred more efficiently. These changes are not enabled by default as they will make the repository unusable with git versions before v1.4.2. Specifically the available options are: or something along those lines. - git-update-index is much less visible. It's not clear what this sentence means. Perhaps add something like: , (many mentions of update-index in git output and documentation have now been replaced by simpler commands such as git add or git rm). - git-clone always uses what is known as separate remote layout for a newly created repository with a working tree; i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are used to track branches from the origin. This change has some workflow impact that is not at all obvious from the above description. For example, after cloning git.git, things that used to work like git checkout -b my-next next now no longer work, (needing to use origin/next instead). And these branches also won't appear in git branch output, (without the new -r option). I think the release notes should spend a little more attention on an issue like this. Maybe a separate section on changes to existing interfaces, (as opposed to most of the other changes which are improvements in the implementation of existing interfaces or just plain new interfaces such as git remote, git gc, etc.) If there is a new section, the previous paragraphs describing the move of cloned origin information from .git/remotes/origin to .git/config might belong there as well, (depending on whether you consider those file contents a user-visible interface or not). - git-branch and git-show-branch know remote tracking branches. Should mention -r here. - git-push can now be used to delete a remote branch or a tag. This requires the updated git on the remote side. What's the syntax for this? I know you don't want to turn the release notes into a user manual, but it'd be nice to have brief mentions of the new interfaces, (like the nice mention of git add -i for example). Even with a quick skim through the git-push documentation, I'm not immediately seeing how to delete a remote branch or tag. - There is a toplevel garbage collector script, 'git-gc', that is an easy way to run 'git-repack -a -d', 'git-reflog gc', and 'git-prune'. I think it's definitely worthwhile to note the fix of race conditions, etc. here. It would be nice to have some short rule such as: git gc is free from any known race conditions with simultaneous git processes modifying the repository. So it's perfectly safe to run git gc from a cron job. Or a similarly succinct rule that's actually true, (I think the recent thread suggested git gc would only be safe with an extra option---I'd much rather see it be safe by default and make the user ask for extra unsafe pruning with an option). - You can give non-branch to git checkout now. Rather than non-branch I think it would be nice to say something that mentioned tags. Maybe something like: You can now use 'git checkout' to checkout tags or any other revision, rather than just named branches. - Repositories with hundreds of tags have been paying large overhead, both in storage and in runtime, due to the traditional one-ref-per-file format. A new command, git-pack-refs, can be used to pack them in more efficient representation. Is git-gc doing this housekeeping? If not, should it be? If so, should it be mentioned here (and in the description of git-gc above)? - There is a partial support for 'shallow' repositories that keeps only recent history. A 'shallow clone' is created by specifying how deep that truncated history should be. Here's another description that could definitely benefit from a very short example command. -Carl pgpbnlQIvUfaj.pgp Description: PGP signature
Re: [Announce] GIT v1.5.0-rc2
On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote: Thanks for your comments; You're welcome. the attached probably needs proofreading. In general, I like it. The git-branch documentation already talks about remote-tracking branches so I've rewritten a couple of sentence below to use that same terminology. Also there are a couple of grammar errors related to pluralization, (likely the fault of English being quite a bit less consistent than other languages with subject/verb number agreement, etc.). + A repository with the separate remote layout starts with only + one default branch, 'master', to be used for your own + development. Unlike the traditional layout that copied all + the upstream branches into your branch namespace (while + renaming their 'master' to your 'origin'), they are not made + into your branches. Instead, they are kept track of using + 'refs/remotes/origin/$upstream_branch_name'. renaming remote 'master' to local 'origin'), the new approach puts upstream branches into local remote-tracking branches with their own namespace. These can be referenced with names such as origin/$upstream_branch_name and are stored in .git/refs/remotes rather than .git/refs/heads where normal branches are stored. + This layout keeps your own branch namespace less cluttered, + avoids name collision with your upstream, makes it possible + to automatically track new branches created at the remote + after you clone from it, and makes it easier to interact with + more than one remote repositories. There might be some Should be more than one remote repository.. Also I'd add, , (see the new 'git remote' command) before the end of that sentence. + * 'git branch' does not show the branches from your upstream. Again to use the same terminology, does not show the remote-tracking branches.. + Repositories initialized with the traditional layout + continues to work (and will continue to work). The 's' on continues is incorrect. Perhaps: continue to work (and will work in the future as well). or just drop the parenthetical phrase. -Carl pgpJ2CCBnd3h5.pgp Description: PGP signature
