[PATCH] revision: avoid work after --max-count is reached
During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revision_1
to get the next commit. This might involve looking at a
large number of commits if we have restricted the traversal
(e.g., we might traverse until we find the next commit whose
diff actually matches a pathspec).
There's no need to make this get_revision_1 call when our
counter runs out. If we are not in --boundary mode, we will
just throw away the result and immediately return NULL. If
we are in --boundary mode, then we will still throw away the
result, and then start showing the boundary commits.
However, as git_revision_1 does not impact the boundary
list, it should not have an impact.
In most cases, avoiding this work will not be especially
noticeable. However, in some cases, it can make a big
difference:
[before]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real0m0.301s
user0m0.280s
sys 0m0.016s
[after]
$ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt
8d141a1d562abb31f27f599dbf6e10a6c06ed73e
real0m0.010s
user0m0.008s
sys 0m0.000s
Note that the output is produced almost instantaneously in
the first case, and then git uselessly spends a long time
looking for the next commit to touch that file (but there
isn't one, and we traverse all the way down to the roots).
Signed-off-by: Jeff King
---
I'd really like more sets of eyes to make sure this won't
cause a weird regression. Calling get_revision_1 does tweak
the flags on objects as it traverses, so I'm worried about
some other code relying on this side effect of get_revision
in some way. That does seem a bit crazy to me, though.
revision.c | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/revision.c b/revision.c
index 5b81a92..7e39655 100644
--- a/revision.c
+++ b/revision.c
@@ -2361,29 +2361,28 @@ static struct commit *get_revision_internal(struct
rev_info *revs)
}
/*
-* Now pick up what they want to give us
+* If our max_count counter has reached zero, then we are done. We
+* don't simply return NULL because we still might need to show
+* boundary commits. But we want to avoid calling get_revision_1, which
+* might do a considerable amount of work finding the next commit only
+* for us to throw it away.
+*
+* If it is non-zero, then either we don't have a max_count at all
+* (-1), or it is still counting, in which case we decrement.
*/
- c = get_revision_1(revs);
- if (c) {
- while (0 < revs->skip_count) {
- revs->skip_count--;
- c = get_revision_1(revs);
- if (!c)
- break;
+ if (revs->max_count) {
+ c = get_revision_1(revs);
+ if (c) {
+ while (0 < revs->skip_count) {
+ revs->skip_count--;
+ c = get_revision_1(revs);
+ if (!c)
+ break;
+ }
}
- }
- /*
-* Check the max_count.
-*/
- switch (revs->max_count) {
- case -1:
- break;
- case 0:
- c = NULL;
- break;
- default:
- revs->max_count--;
+ if (revs->max_count > 0)
+ revs->max_count--;
}
if (c)
--
1.7.11.35.gbaf554e.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: avoid work after --max-count is reached
On Fri, Jul 13, 2012 at 03:50:23AM -0400, Jeff King wrote:
> revision.c | 39 +++
> 1 file changed, 19 insertions(+), 20 deletions(-)
BTW, the patch is slightly hard to read because of the re-indentation.
Here it is with "-w -U5":
diff --git a/revision.c b/revision.c
index 5b81a92..7e39655 100644
--- a/revision.c
+++ b/revision.c
@@ -2359,32 +2359,31 @@ static struct commit *get_revision_internal(struct
rev_info *revs)
c->object.flags |= SHOWN;
return c;
}
/*
-* Now pick up what they want to give us
+* If our max_count counter has reached zero, then we are done. We
+* don't simply return NULL because we still might need to show
+* boundary commits. But we want to avoid calling get_revision_1, which
+* might do a considerable amount of work finding the next commit only
+* for us to throw it away.
+*
+* If it is non-zero, then either we don't have a max_count at all
+* (-1), or it is still counting, in which case we decrement.
*/
+ if (revs->max_count) {
c = get_revision_1(revs);
if (c) {
while (0 < revs->skip_count) {
revs->skip_count--;
c = get_revision_1(revs);
if (!c)
break;
}
}
- /*
-* Check the max_count.
-*/
- switch (revs->max_count) {
- case -1:
- break;
- case 0:
- c = NULL;
- break;
- default:
+ if (revs->max_count > 0)
revs->max_count--;
}
if (c)
c->object.flags |= SHOWN;
--
1.7.11.35.gbaf554e.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git cloning paths
On Thu, Jul 12, 2012 at 03:17:09PM -0700, Douglas Garstang wrote: > I'm a relative newcomer to git and I've just inherited a setup where > all of the company's code is in a single git repository. Within this > repository are multiple projects. It seems that git doesn't natively > allow cloning/checking out of individual paths within the repo (ie > projects), which would seem to make integrating git with a continuous > build system rather difficult. That is, the build system has to clone > the entire repo, and therefore a change to any project will result in > the entire contents of the repo being built. > > Correct? Yes. The feature you are looking for is either "sparse checkout" (only check out a subset of the files in the repository databse to the working tree) or "sparse clone" (only copy a subset of the files into the local repository database during clone). Git v1.7.0 and later has sparse checkout (see the "sparse checkout" section in "git help read-tree"). There is no implementation for sparse clone (and not likely to be one any time soon, as it introduces a lot of complexity into the object negotiation phase). The usual advice is that you should break up your big repository into logical projects. You can do so with git-filter-branch, but beware that this involves rewriting history, which means a flag day for everybody switching to the new history (or dealing with migrating commits from the old history to the new history via rebase). Finally, if you have a build system which is cloning repeatedly, you may want to keep a repository on the build server all the time and just fetch the updates into it. This is much more efficient even if you do end up paring down your repository. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
Junio C Hamano writes:
> But is it really true that we want to error out on missing HOME if
> we have usable XDG stuff?
Anyone else have an opinion on this?
In short, the question is whether
export XDG_CONFIG_HOME=some-existing-dir
unset HOME
git config foo.baz boz
should die("$HOME is unset") or use the XDG config file.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
> Hi Uwe,
>
> > This series was tested on a Phytec pcm038 (mc13783 on spi) using
> > traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
> > i2c) using dt boot.
> >
> > Philippe's patches are already in next, they are just included here for
> > those who want to test the patches. The 'mfd/mc13xxx: drop modifying
> > driver's id_table in probe' was already sent out yesterday and is
> > included here because the last patch depends on it.
> >
>
> For all patches (that don't already have it):
> Acked-by: Marc Reilly
Thanks.
> If for some reason you do a V2:
> - In patch 6 moves line "#define MC13XXX_NUMREGS 0x3f" around, is this
> necessary?
It doesn't move it around, that's only how it looks. I removed enum
mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
(below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
mc13xxx_id and struct mc13xxx_variant respectively as context (together
with the following empty line).
(For the new readers, here is how git represented the relevant part:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
+#define MC13XXX_NUMREGS 0x3f
+
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
};
-#define MC13XXX_NUMREGS 0x3f
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
struct mc13xxx {
struct regmap *regmap;
...
)
The following would be an equivalent and (for humans) easier to review
patch:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
-};
-
#define MC13XXX_NUMREGS 0x3f
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
+};
+
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
+
struct mc13xxx {
struct regmap *regmap;
...
But as this touches 17 lines compared to only 15 using the way git
choosed to represent patch 6, git used the smaller representation. (I'm
not sure this is the correct reason, but at least it sounds sensible.)
Usually this metric is sane, but here it's not. I don't know if you can
do anything about it? E.g. take the number of +, - and context blocks
into account. Then it would be 5 for the patch above vs. 7 for the
way git did it.
Or weight a context line containing
#define MC13XXX_NUMREGS 0x3f
more than two lines one of which is empty and the other only contains a
}?
> - Patch 4 should come last, ie after "add support for mc34708"
Yeah, but it doesn't break bisectibility, and as the rtc patches go in via a
different tree (in fact akpm already took them) it doesn't matter much.
Best regards and thanks for your feedback
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] config: fix several access(NULL) calls
When $HOME is unset, home_config_paths fails and returns NULL pointers
for user_config and xdg_config. Valgrind complains with Syscall param
access(pathname) points to unaddressable byte(s).
Don't call blindly access() on these variables, but test them for
NULL-ness before.
The when the XDG configuration file can be found but not $HOME/.gitconfig
requires a bit of attention. We chose to error out in "git config --set"
if $HOME is unset anyway.
Signed-off-by: Matthieu Moy
---
Before I forget about it, here's the patch assuming people do want to
error out when $HOME is unset. It should be functionally equivalent to
the previous one, but the code should be clearer.
builtin/config.c | 15 +++
config.c | 4 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index e8e1c0a..f064d6e 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -387,12 +387,19 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
home_config_paths(&user_config, &xdg_config, "config");
- if (access(user_config, R_OK) && !access(xdg_config, R_OK))
+ if (!user_config)
+ /*
+* Don't even try to access the xdg_config, as
+* unset $HOME means something is really
+* broken and should be fixed. Silently
+* writing to xdg_config may be confusing.
+*/
+ die("$HOME not set");
+ else if (access(user_config, R_OK) &&
+xdg_config && !access(xdg_config, R_OK))
given_config_file = xdg_config;
- else if (user_config)
- given_config_file = user_config;
else
- die("$HOME not set");
+ given_config_file = user_config;
}
else if (use_system_config)
given_config_file = git_etc_gitconfig();
diff --git a/config.c b/config.c
index d28a499..6b97503 100644
--- a/config.c
+++ b/config.c
@@ -940,12 +940,12 @@ int git_config_early(config_fn_t fn, void *data, const
char *repo_config)
found += 1;
}
- if (!access(xdg_config, R_OK)) {
+ if (xdg_config && !access(xdg_config, R_OK)) {
ret += git_config_from_file(fn, xdg_config, data);
found += 1;
}
- if (!access(user_config, R_OK)) {
+ if (user_config && !access(user_config, R_OK)) {
ret += git_config_from_file(fn, user_config, data);
found += 1;
}
--
1.7.11.1.30.g7e1baf9.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Export from bzr / Import to git results in a deleted file re-appearing
Jeff King writes: > On Thu, Jul 12, 2012 at 08:00:17PM +0200, Felix Natter wrote: > >> I am trying to move freeplane's repository (GPL-project) from bzr to >> git, but when I do this: >> >> $ mkdir freeplane-git1 >> $ cd freeplane-git1 >> $ git init . >> $ bzr fast-export --export-marks=../marks.bzr ../trunk/ | git fast-import >> --export-marks=../marks.git >> $ git checkout >> >> then there are no errors, but the resulting working index is broken: >> freeplane-git1/freeplane_plugin_formula/src/org/freeplane/plugin/formula >> contains SpreadSheetUtils.java which belongs to package >> 'org.freeplane.plugin.spreadsheet' and which is no longer in the bzr >> trunk that I imported! > > If you run only the bzr half of your command and inspect the output, you > will see that the file in question is mentioned twice. Once in a commit > on "refs/heads/master" that renames into it from another file: > > R > freeplane_plugin_spreadsheet/src/org/freeplane/plugin/spreadsheet/SpreadSheetUtils.java > > freeplane_plugin_formula/src/org/freeplane/plugin/formula/SpreadSheetUtils.java That same revision also removes it, but is uses the original name for the deletion (the bzr revision actually renames the containing directory). That's probably what confuses git fast-import. Here is a test case: bzr init mkdir a bzr add a touch a/b bzr add a/b bzr ci -m a bzr mv a b bzr rm b/b bzr ci -m b bzr fast-export . The output contains these lines: R a/b b/b D a/b Changing the second line to D b/b fixes the bug. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > But is it really true that we want to error out on missing HOME if
> > we have usable XDG stuff?
>
> Anyone else have an opinion on this?
>
> In short, the question is whether
>
> export XDG_CONFIG_HOME=some-existing-dir
> unset HOME
> git config foo.baz boz
>
> should die("$HOME is unset") or use the XDG config file.
What did previous versions of git do? From my reading of 21cf32279, the
previous behavior was that if $HOME was not set, git would silently
avoid reading from $HOME/.gitconfig entirely. Wouldn't dying be a huge
regression?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Export from bzr / Import to git results in a deleted file re-appearing
On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote: > > If you run only the bzr half of your command and inspect the output, you > > will see that the file in question is mentioned twice. Once in a commit > > on "refs/heads/master" that renames into it from another file: > > > > R > > freeplane_plugin_spreadsheet/src/org/freeplane/plugin/spreadsheet/SpreadSheetUtils.java > > > > freeplane_plugin_formula/src/org/freeplane/plugin/formula/SpreadSheetUtils.java > > That same revision also removes it, but is uses the original name for > the deletion (the bzr revision actually renames the containing > directory). That's probably what confuses git fast-import. > [...] > The output contains these lines: > > R a/b b/b > D a/b > > Changing the second line to D b/b fixes the bug. Yeah, I agree that is problematic. But I do not think it is a fast-import bug, but rather bogus output generated by bzr fast-export (I am not clear from what you wrote above if you are considering it a bug that fast-import is confused). It seems nonsensical to mention a file both as a rename source and as deleted in the same revision, and certainly I would not expect an importer to deduce a link between the second line and b/b. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
Jeff King writes:
> On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
>
>> Junio C Hamano writes:
>>
>> > But is it really true that we want to error out on missing HOME if
>> > we have usable XDG stuff?
>>
>> Anyone else have an opinion on this?
>>
>> In short, the question is whether
>>
>> export XDG_CONFIG_HOME=some-existing-dir
>> unset HOME
>> git config foo.baz boz
>>
>> should die("$HOME is unset") or use the XDG config file.
>
> What did previous versions of git do? From my reading of 21cf32279, the
> previous behavior was that if $HOME was not set, git would silently
> avoid reading from $HOME/.gitconfig entirely.
Yes, and this is still the case for _reading_. But the current case is
about deciding which file to use when _writing_. Git was already dying
when writing with an unset $HOME. There is no behavior change in this
case.
With Junio's suggestion, we would have a behavior change in that we
would write to the XDG file if we can find it (using XDG_CONFIG_HOME,
obviously, since $HOME is unset in this case).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Export from bzr / Import to git results in a deleted file re-appearing
Jeff King writes: > On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote: > >> > If you run only the bzr half of your command and inspect the output, you >> > will see that the file in question is mentioned twice. Once in a commit >> > on "refs/heads/master" that renames into it from another file: >> > >> > R >> > freeplane_plugin_spreadsheet/src/org/freeplane/plugin/spreadsheet/SpreadSheetUtils.java >> > >> > freeplane_plugin_formula/src/org/freeplane/plugin/formula/SpreadSheetUtils.java >> >> That same revision also removes it, but is uses the original name for >> the deletion (the bzr revision actually renames the containing >> directory). That's probably what confuses git fast-import. >> [...] >> The output contains these lines: >> >> R a/b b/b >> D a/b >> >> Changing the second line to D b/b fixes the bug. > > Yeah, I agree that is problematic. But I do not think it is a > fast-import bug, but rather bogus output generated by bzr fast-export (I > am not clear from what you wrote above if you are considering it a bug > that fast-import is confused). It seems nonsensical to mention a file > both as a rename source and as deleted in the same revision, and > certainly I would not expect an importer to deduce a link between the > second line and b/b. IMHO fast-import should raise an error in this case, like it does when you switch the lines. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
Matthieu Moy writes:
> Jeff King writes:
>
>> On Fri, Jul 13, 2012 at 10:48:18AM +0200, Matthieu Moy wrote:
>>
>>> Junio C Hamano writes:
>>>
>>> > But is it really true that we want to error out on missing HOME if
>>> > we have usable XDG stuff?
>>>
>>> Anyone else have an opinion on this?
>>>
>>> In short, the question is whether
>>>
>>> export XDG_CONFIG_HOME=some-existing-dir
>>> unset HOME
>>> git config foo.baz boz
>>>
>>> should die("$HOME is unset") or use the XDG config file.
>>
>> What did previous versions of git do? From my reading of 21cf32279, the
>> previous behavior was that if $HOME was not set, git would silently
>> avoid reading from $HOME/.gitconfig entirely.
>
> Yes, and this is still the case for _reading_. But the current case is
> about deciding which file to use when _writing_. Git was already dying
> when writing with an unset $HOME.
Umm, are you sure? I may be somewhat confused about this, but the tests
I used to trigger the access(NULL) were IIRC
unset HOME
git config --get foo.bar
git config --global --get foo.bar
none of which is writing
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
Thomas Rast writes:
> Umm, are you sure? I may be somewhat confused about this, but the tests
> I used to trigger the access(NULL) were IIRC
>
> unset HOME
> git config --get foo.bar
> git config --global --get foo.bar
>
> none of which is writing
I was inaccurate, but that doesn't change the conclusion: the question
is not reading Vs writting, but use of --global Vs no use of it (and
most of the time, --global is used for writing, hence my confusion).
Both the patch that introduce the NULL bug and the one that fix it touch
two files: $git/config.c, and $git/builtin/config.c.
My changes to $git/config.c, are straightforward because they touch
positive tests for file existance. The controversial one is
$git/builtin/config.c, which is inside a "if (use_global_config)".
This piece of code was already dying on unset $HOME, and in my proposal
it still is.
The old code was:
if (use_global_config) {
char *home = getenv("HOME");
if (home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig",
home));
given_config_file = user_config;
} else {
die("$HOME not set");
}
}
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Don't share anything but those files
Greetings everyone, I'm wondering how to commit only selected files/folders on GIT, if even possible. Note, the ignore list is not a good option for me as I'd like to add a few files in a folder that contains many hundreds for instance. Basically, I'm looking for a way to say, don't share anything but those files. thx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Don't share anything but those files
Greetings everyone, I'm wondering how to commit only selected files/folders on GIT, if even possible. Note, the ignore list is not a good option for me as I'd like to add a few files in a folder that contains many hundreds for instance. Basically, I'm looking for a way to say, don't share anything but those files. thx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
On Fri, Jul 13, 2012 at 10:59:55AM -0400, Yves Perron wrote: > I'm wondering how to commit only selected files/folders on GIT, if even > possible. Just "git add" only the files you need. If you want git to ignore all the rest, you can write '*' in your .gitignore -- Edward "Hades" Toroshchin dr_lepper on irc.freenode.org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-am: indicate where a failed patch is to be found.
If git am fails to apply something, the end user may need to know where to find the patch. This is normally known for a single patch, but if the user is processing a mbox with many patches, they may not have a single broken out patch handy. So, provide a helpful hint as to where they can find the patch to do some sort of manual fixup, if we are processing a mbox with more than one patch in it. Signed-off-by: Paul Gortmaker --- [v2: drop text suggesting what to do with failed patch; only emit the help text if we are processing mbox with multi patches] git-am.sh |5 + 1 file changed, 5 insertions(+) diff --git a/git-am.sh b/git-am.sh index f8b7a0c..20b3b73 100755 --- a/git-am.sh +++ b/git-am.sh @@ -855,6 +855,11 @@ did you forget to use 'git add'?" if test $apply_status != 0 then eval_gettextln 'Patch failed at $msgnum $FIRSTLINE' + if test $patch_format = mbox && test "$last" -ne "1" + then + eval_gettextln "You can find the copy of the patch that failed here: + $dotest/patch" + fi stop_here_user_resolve $this fi -- 1.7.9.7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
On Fri, Jul 13, 2012 at 11:35:36AM -0400, Yves Perron wrote: > Oh I see, thank you for your response, > > Can I put all the folders/files I want to add in a config file so I > don't have to do this every time? > > Thx > You won't have to do this every time. Once you add a file and commit it, git will track it in the future. -- Edward "Hades" Toroshchin dr_lepper on irc.freenode.org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] config: fix several access(NULL) calls
Matthieu Moy writes:
> The old code was:
>
> if (use_global_config) {
> char *home = getenv("HOME");
> if (home) {
> char *user_config = xstrdup(mkpath("%s/.gitconfig",
> home));
> given_config_file = user_config;
> } else {
> die("$HOME not set");
> }
> }
I think the above is a good illustration of the crux of the issue,
as the natural way to introduce XDG that is used when the one at
$HOME/.gitconfig is not there seems at least to me to do this:
if (use_global_config) {
if (is $HOME/.gitconfig usable?) {
use it;
} else if (is $XDG/git/config usable?) {
use $XDG location;
} else {
die("Neither $XDG or $HOME is usable");
}
}
In other words, we are not trying to say "You do not have $HOME --
there is something wrong, so we will give up" in this codepath. We
were saying "Can we use _the_ place we place personal config? It is
an error if we cannot find it, so we die." and the above says "Can
we use this place? Can we use that place? If no place is found to
be usable, we die."
And the intent of the "NULL-buggy" version seems to want the same
"If we cannot use home/.gitconfig but xdg_config one is usable, use
xdg one" semantics to me.
if (access(user_config, R_OK) && !access(xdg_config, R_OK))
given_config_file = xdg_config;
else if (user_config)
given_config_file = user_config;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-am: indicate where a failed patch is to be found.
On 12-07-12 04:00 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
> This is _NOT_ fine, especially if you suggest "patch" the user may
> not have, and more importantly does not have a clue why "git apply"
> rejected it ("am" does _not_ use "patch" at all).
I'm not 100% sure I'm following what part here is not OK. If you
can help me understand that, I'll respin the change accordingly.
>>>
>>> Do not ever mention "patch -p1". It is not the command that "git
>>> am" uses, and it is not what detected the breakage in the patch.
>>
>> This may be true, but it _is_ the command that I (and others) have
>> defaulted to using, if for no other reason than ignorance.
>>>
>>> The command to guide the user to is "git apply".
>>
>> OK. But I don't see a "--dry-run" equivalent -- and "git apply --check"
>> just gives me a repeat of the same fail messages that "git am" did.
>>
>> With "patch -p1 --dry-run" I get information that immediately
>> lets me see whether the patch is viable or not.
>
> What do you mean by "viable"?
Sorry, that description was a bit context free. Two typical cases:
1) applying a series of commits (e.g. preempt RT feature) to a newer
baseline. Some of those commits may have been upstreamed and now
present in mainline. The "git am" failure doesn't really hint that
"already applied" may be the case -- e.g. consider and compare the
output when we extract and then intentionally try to re-apply something
already in tree, created with:
-
$git format-patch 50fb31cf~..50fb31cf
0001-tty-hvc_opal-Fix-debug-function-name.patch
-
With "git am":
--
$git am 0001-tty-hvc_opal-Fix-debug-function-name.patch
Applying: tty/hvc_opal: Fix debug function name
error: patch failed: drivers/tty/hvc/hvc_opal.c:401
error: drivers/tty/hvc/hvc_opal.c: patch does not apply
Patch failed at 0001 tty/hvc_opal: Fix debug function name
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
---
...versus
---
$patch -p1 --dry-run < 0001-tty-hvc_opal-Fix-debug-function-name.patch
patching file drivers/tty/hvc/hvc_opal.c
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/tty/hvc/hvc_opal.c.rej
---
...versus
---
$git apply -p1 0001-tty-hvc_opal-Fix-debug-function-name.patch
error: patch failed: drivers/tty/hvc/hvc_opal.c:401
error: drivers/tty/hvc/hvc_opal.c: patch does not apply
---
Maybe there is an easy way to teach git am/apply to detect "previously
applied" in a way similar to patch? The closest I could come to that
was "git apply --check -R ..." and seeing what it said (or didn't say).
2) In maintaining linux stable releases (esp older ones), the dry-run
output, if say it says something like 23/30 chunks failed, it tells me
that the underlying baseline has probably changed too much for a simple
backport. But if only 1/30 chunks fail or similar, I'll simply proceed
since the backport is viable and likely trivial.
Paul.
--
>
> Independent from the answer to that question...
>
> Running "git apply -p1" would by definition give you the same
> failure without --dry-run (because you know it already failed), no?
> Then you could ask for rejects or attempt to apply with reduced
> contexts to "git apply" all without having to say --dry-run, as
> unapplicable change will not be applied.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
Ok, let me rephrase, is there a way to edit a file where we can put every files/folders we need to add without the need of entering a command for each entry? On 7/13/2012 12:14 PM, Edward Toroshchin wrote: On Fri, Jul 13, 2012 at 11:35:36AM -0400, Yves Perron wrote: Oh I see, thank you for your response, Can I put all the folders/files I want to add in a config file so I don't have to do this every time? Thx You won't have to do this every time. Once you add a file and commit it, git will track it in the future. -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
Yves Perron, Fri 2012-07-13 @ 13:40:56-0400: > Ok, let me rephrase, is there a way to edit a file where we can put > every files/folders we need to add without the need of entering a > command for each entry? Sure, but you don't need functionality built in to Git to do this. Just list the paths you want to add in a file and then: xargs git add signature.asc Description: Digital signature
Re: [PATCH] git-am: indicate where a failed patch is to be found.
Paul Gortmaker writes: > Sorry, that description was a bit context free. Two typical cases: > > 1) applying a series of commits (e.g. preempt RT feature) to a newer > baseline. Some of those commits may have been upstreamed and now > present in mainline. The "git am" failure doesn't really hint that > "already applied" may be the case -- e.g. consider and compare the > output when we extract and then intentionally try to re-apply something > already in tree, created with: > > - > $git format-patch 50fb31cf~..50fb31cf > 0001-tty-hvc_opal-Fix-debug-function-name.patch > - > > With "git am": > -- > $git am 0001-tty-hvc_opal-Fix-debug-function-name.patch > Applying: tty/hvc_opal: Fix debug function name > error: patch failed: drivers/tty/hvc/hvc_opal.c:401 > error: drivers/tty/hvc/hvc_opal.c: patch does not apply > Patch failed at 0001 tty/hvc_opal: Fix debug function name > When you have resolved this problem run "git am --resolved". > If you would prefer to skip this patch, instead run "git am --skip". > To restore the original branch and stop patching run "git am --abort". > --- > > ...versus > > --- > $patch -p1 --dry-run < 0001-tty-hvc_opal-Fix-debug-function-name.patch > patching file drivers/tty/hvc/hvc_opal.c > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file > drivers/tty/hvc/hvc_opal.c.rej > --- "git am -3" will give you a message "already applied" and moves on, or if an already applied stuff is similar but not different would stop with conflict, or fail butd the latter two cases GNU patch would not say "reversed", so "am -3" would be a win 2 out of 3 cases and the remaining 1 out of 3 case would be a tie. > 2) In maintaining linux stable releases (esp older ones), the dry-run > output, if say it says something like 23/30 chunks failed, it tells me > that the underlying baseline has probably changed too much for a simple > backport. But if only 1/30 chunks fail or similar, I'll simply proceed > since the backport is viable and likely trivial. Perhaps "git apply" when stops upon unapplicable patch may want to be improved to give more detailed diagnostics (I think it stops upon first hunk per each file that is touched---it may be able to keep going and see if other hunks might apply). This is in "patches welcome" category ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
On 7/13/2012 8:21 AM, Edward Toroshchin wrote: > On Fri, Jul 13, 2012 at 10:59:55AM -0400, Yves Perron wrote: >> I'm wondering how to commit only selected files/folders on GIT, if even >> possible. > Just "git add" only the files you need. > > If you want git to ignore all the rest, you can write '*' in your > .gitignore As an alternative, you may be able to use negative patterns in your .gitignore or other ignore files. Like this: * !.gitignore !a_file_that_should_be_tracked !a_dir_to_track/ See "git help ignore" for more details. Illia Bobyr-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Don't share anything but those files
On 7/13/2012 2:08 PM, Illia Bobyr wrote: * !.gitignore !a_file_that_should_be_tracked !a_dir_to_track/ That is exactly what i was hoping for, thank you everyone! -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.
On 12-07-11 06:04 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> On 12-07-11 02:21 PM, Junio C Hamano wrote:
>>> marcn...@xiplink.com writes:
>>>
From: Marc Branchaud
The code now has a default_remote_name and an effective_remote_name:
- default_remote_name is set by remote.default in the config, or is
"origin"
if remote.default doesn't exist ("origin" was the fallback value before
this change).
- effective_remote_name is the name of the remote tracked by the current
branch, or is default_remote_name if the current branch doesn't have a
remote.
This has a minor side effect on the default behavior of "git push"
>>>
>>> Hrm, is this a _minor_ side effect?
>>
>> Well, I thought so... :)
>>
>> It's minor because of what you say:
>>
>>> Isn't that a natural and direct consequence of "now you can set
>>> remote.default configuration to name the remote you want to use in
>>> place of traditional 'origin'" feature? I think changing the
>>> behaviour of "git push" in such a way is the point (may not be the
>>> only but one of the important points) of this series.
>>
>> I agree. Phil Hord pointed out the change in behaviour and felt the commit
>> message should explain it.
>>
>> Should I just remove "minor"?
>
> Is it even a _side effect_? Isn't this one of the primary points of
> the series? I do not think this patch makes sense if we did not
> want that change to happen.
>
> Or am I missing something?
No, you're not -- I agree that this change in behaviour makes sense. I
simply hadn't anticipated this effect when I first did the work.
So should the commit message simply say "This changes the default behavior of
'git push' ..."? Or are you suggesting the message needn't mention it at all?
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb97cc1..fc17d39 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -27,10 +27,16 @@ documentation for linkgit:git-receive-pack[1].
OPTIONS[[OPTIONS]]
--
::
- The "remote" repository that is destination of a push
+ The "remote" repository that is the destination of the push
operation. This parameter can be either a URL
(see the section <> below) or the name
of a remote (see the section <> below).
+ If this parameter is omitted, git tries to use the remote
+ associated with the currently checked-out branch. If there
+ is no remote associated with the current branch, git uses
+ the remote named by the "remote.default" configuration variable.
+ If "remote.default" is not set, git uses the name "origin" even
+ if there is no actual remote named "origin".
>>>
>>> This comment applies to other changes to the documentation in this
>>> patch I didn't quote, but I think the phrasing 'even if there is no
>>> acutual remote named "origin"' needs to be rethought, because "we
>>> use it even if there is no such remote determined with this logic"
>>> applies equally to branch.$name.remote, remote.default or built-in
>>> default value of remote.default which happens to be "origin".
>>
>> I'm sorry, but I'm having trouble understanding what you mean. I don't see
>> how the "because ..." part of your sentence suggests what aspect needs
>> rephrasing.
>
> You say the remote is taken from three places (branch.$name.remote,
> remote.default, or 'origin').
>
> Imagine there is remote.origin.url at all. If remote.default is set
> to 'origin', or branch.$name.remote for the current branch is set to
> 'origin', the repository you will try to use is 'origin'. And you
> will fail the same way if you try to push there. It does not matter
> if the hardcoded default gave you 'origin' or configuration variable
> gave it to you. The name is used regardless, even if there is no
> actual remote under such name.
>
> So "If 'remote.default' is not set, git uses the name "origin" even
> if there is no actual remote", while is not untrue, is misleading.
> Even if there is no actual remote 'origin', if 'remote.default' is
> set to 'origin', git will use that name, and will fail the same way.
>
> Just saying "If 'remote.default' is not set, git uses 'origin'" or
> even "'remote.default', if unset, defaults to 'origin'" would be
> sufficient.
Thanks, I understand you now.
I feel it's rather surprising that git defaults to "origin". I think the
docs should explain that git in fact ignores whatever remotes are actually
configured in the repository, that git only looks in specific places for a
remote name. That's what I was trying to convey with the "even if" clause.
I'll try to rephrase.
M.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
Uwe Kleine-König writes:
> It doesn't move it around, that's only how it looks. I removed enum
> mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
> (below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
> mc13xxx_id and struct mc13xxx_variant respectively as context (together
> with the following empty line).
> (For the new readers, here is how git represented the relevant part:
>
> #include
> #include
>
> -enum mc13xxx_id {
> - MC13XXX_ID_MC13783,
> - MC13XXX_ID_MC13892,
> - MC13XXX_ID_INVALID,
> +#define MC13XXX_NUMREGS 0x3f
> +
> +struct mc13xxx;
> +
> +struct mc13xxx_variant {
> + const char *name;
> + void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
> };
>
> -#define MC13XXX_NUMREGS 0x3f
> +extern struct mc13xxx_variant
> + mc13xxx_variant_mc13783,
> + mc13xxx_variant_mc13892;
>
> struct mc13xxx {
> struct regmap *regmap;
> ...
> )
>
> The following would be an equivalent and (for humans) easier to review
> patch:
>
> #include
> #include
>
> -enum mc13xxx_id {
> - MC13XXX_ID_MC13783,
> - MC13XXX_ID_MC13892,
> - MC13XXX_ID_INVALID,
> -};
> -
> #define MC13XXX_NUMREGS 0x3f
>
> +struct mc13xxx;
> +
> +struct mc13xxx_variant {
> + const char *name;
> + void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
> +};
> +
> +extern struct mc13xxx_variant
> + mc13xxx_variant_mc13783,
> + mc13xxx_variant_mc13892;
> +
> struct mc13xxx {
> struct regmap *regmap;
> ...
>
> But as this touches 17 lines compared to only 15 using the way git
> choosed to represent patch 6, git used the smaller representation.
Yes. Useful information bits per line count is the primary thing
our default xdiff based output pays attention to (e.g. we coalesce
two adjacent hunks that are one missing context line apart into one
larger hunk by removing the "@@ linenum @@" line from the beginning
of the latter hunk for this reason).
> Usually this metric is sane, but here it's not. I don't know if you can
> do anything about it? E.g. take the number of +, - and context blocks
> into account. Then it would be 5 for the patch above vs. 7 for the
> way git did it.
> Or weight a context line containing
>
> #define MC13XXX_NUMREGS 0x3f
>
> more than two lines one of which is empty and the other only contains a
> }?
"GNU diff" gives the same output as ours, and "git diff --patience"
gives more redundant (it wasts lines by removing "};" and then later
adding "};" back) output. I think this is because "patience" pays
more attention to key off unique lines in the range (e.g. the line
"#define MC13XXX_NUMREGS 0x3f" appears only once in the preimage and
also in the postimage, so it must pair with each other).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Teach "git remote" about remote.default.
On 12-07-11 05:55 PM, Junio C Hamano wrote: > Marc Branchaud writes: > >> What about a warning displayed if "remote.default" is not set? Something >> like: >> >> This repository does not have an explicitly configured default >> remote. Selecting "origin" as the default remote repository. >> To suppress this warning, or if you wish to have a different >> default remote repository, run "git remote default ". >> In git X.Y, the default remote will be automatically configured >> as the first remote added to the repository. > > When do you plan to issue the above message? Any time we default to > 'origin' without remote.default? > > I do not see a value to it---if the user has been happily using > 'origin' as the default remote, there is no reason to give such a > noise. We will keep defaulting to 'origin' even in the version of > Git with this series in it. > > A warning is necessary if we plan to _later_ add the "first remote > created either by 'git clone' or 'git remote add' is automatically > set as the value for remote.default configuration" feature, and the > place to do so is "git clone" and "git remote add" that creates the > first remote for the repository. If the name of the remote created > by them is 'origin', then there is no need for warning, but if the > user called that first remote with a name that is _not_ 'origin', > later versions of Git will change the behaviour. > > I can see a transition plan that goes like this: I like your plan -- thanks for working it out in such detail! I'll re-roll the series to work like your plan's Step 0, and I'll post a separate RFC patch on top of it that initiates the transition, so folks can discuss it specifically. > Step 0. With this series but without the "first one becomes default" > > $ git init > $ git remote add upstream git://over.there.xz/git.git/ > hint: You may want to run "git remote default upstream" now so that > hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream' > hint: repository, instead of 'origin' (which you do not yet have). > > $ git config --global advice.settingDefaultRemote false > $ git remote rm upstream > $ git remote add upstream git://over.there.xz/git.git/ > ... nothing, as the user declined the advice ... > > Step 1. "First one becomes default" as an opt-in feature > > $ git config --global --unset advice.settingDefaultRemote > $ git init > $ git remote add upstream git://over.there.xz/git.git/ > hint: You may want to run "git remote default upstream" now so that > hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream' > hint: repository, instead of 'origin' (which you do not yet have). > hint: "git config --global remote.firstRemoteBecomesDefault true" can be > hint: used to make the first remote added to the repository the default > hint: remote automatically. > $ git remote default > origin > > $ git config --global remote.firstRemoteBecomesDefault true > $ git remote rm upstream > $ git remote add upstream git://over.there.xz/git.git/ > ... nothing; user already knows about remote.firstRemoteBecomesDefault > $ git remote default > upstream > > Step 2. Start warning the default change for "First one becomes default" > > $ git config --global --unset advice.settingDefaultRemote > $ git config --global --unset remote.firstRemoteBecomesDefault > $ git init > $ git remote add upstream git://over.there.xz/git.git/ > hint: You may want to run "git remote default upstream" now so that > hint: a lazy 'git push' and 'git fetch' defaults to this 'upstream' > hint: repository, instead of 'origin' (which you do not yet have). > hint: "git config --global remote.firstRemoteBecomesDefault true" can be > hint: used to make the first remote added to the repository the default > hint: remote automatically. > hint: > hint: In future versions of Git, this will happen automatically. > hint: If you do not want the first remote to become default, run > hint: "git config --global remote.firstRemoteBecomesDefault false" now. > > Step 3. "First one becomes default" is now default > > $ git config --global --unset advice.settingDefaultRemote > $ git config --global --unset remote.firstRemoteBecomesDefault > $ git init > $ git remote add upstream git://over.there.xz/git.git/ > warning: Made 'upstream' the default remote for this repository. > $ git remote default > upstream > > $ git remote rm upstream > $ git config --global remote.firstRemoteBecomesDefault true > $ git init > $ git remote add upstream git://over.there.xz/git.git/ > ... nothing; the user explicitly told us what to do > $ git remote default > upstream > > $ git remote rm upstream > $ git config --global remote.firstRemoteBecomesDefault false > $ git init > $ git remote
Re: [PATCH v2] git-am: indicate where a failed patch is to be found.
Paul Gortmaker writes: > If git am fails to apply something, the end user may need > to know where to find the patch. This is normally known for > a single patch, but if the user is processing a mbox with > many patches, they may not have a single broken out patch > handy. So, provide a helpful hint as to where they can > find the patch to do some sort of manual fixup, if we > are processing a mbox with more than one patch in it. I would rather see this done even for a single patch mbox. The patch that was fed to "git apply" by "git am" and failed to apply is that one, not the one in the mbox you gave "git am". The latter may be ungrokkable with GNU patch or "git apply", if the original was sent in Quoted-Printable and such MIME funnies, which is the whole point of having a separate file there for "git am", instead of feeding the original. I am not sure if we should limit $patch_format to mbox, but I think showing this unconditionally regardless of mbox/stgit/hg will teach the user only one location to remember, so perhaps like this? Documentation/config.txt | 3 +++ git-am.sh| 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 0e1168c..b1f0a75 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -143,6 +143,9 @@ advice.*:: Advice shown when you used linkgit:git-checkout[1] to move to the detach HEAD state, to instruct how to create a local branch after the fact. + amWorkDir:: + Advice that shows the location of the patch file when + linkgit:git-am[1] fails to apply it. -- core.fileMode:: diff --git a/git-am.sh b/git-am.sh index dc48f87..f1ae932 100755 --- a/git-am.sh +++ b/git-am.sh @@ -834,9 +834,9 @@ did you forget to use 'git add'?" if test $apply_status != 0 then eval_gettextln 'Patch failed at $msgnum $FIRSTLINE' - if test $patch_format = mbox && test "$last" -ne "1" + if test "$(git config --bool advice.amworkdir)" != false then - eval_gettextln "You can find the copy of the patch that failed here: + eval_gettextln "The copy of the patch that failed is found in: $dotest/patch" fi stop_here_user_resolve $this -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.
Marc Branchaud writes: >> Is it even a _side effect_? Isn't this one of the primary points of >> the series? I do not think this patch makes sense if we did not >> want that change to happen. >> >> Or am I missing something? > > No, you're not -- I agree that this change in behaviour makes sense. I > simply hadn't anticipated this effect when I first did the work. > > So should the commit message simply say "This changes the default behavior of > 'git push' ..."? Or are you suggesting the message needn't mention it at all? It is one of the more important behaviour changes we are making on purpose with this series; it deserves to be described in the log, I would think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: avoid work after --max-count is reached
Jeff King writes:
> There's no need to make this get_revision_1 call when our
> counter runs out. If we are not in --boundary mode, we will
> just throw away the result and immediately return NULL. If
> we are in --boundary mode, then we will still throw away the
> result, and then start showing the boundary commits.
>
> However, as git_revision_1 does not impact the boundary
> list, it should not have an impact.
We used to reset 'c' to NULL ("throw away the result"), run
create_boundary_commit_list(), and ask ourselves to pop the boundary
it computed.
Now we don't call get_revision_1() and leave 'c' to NULL as
initialized ("avoid work"), and do the same.
The state create_boundary_commit_list() sees would slightly be
different, as we used to dig one level deeper, smudging more commits
with bits, but the only bits that may be smudged by this digging
that may matter in create_commit_list() is CHILD_SHOWN and SHOWN,
but by definition the commits around the commit the extra call to
get_revision_1() would have returned are marked with neither during
that extra call, so I think this conversion does not affect the
boundary list.
So I think I like this change. If anything, it makes the loop
structure simpler and a bit easier to understand.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: avoid work after --max-count is reached
On Fri, Jul 13, 2012 at 02:10:54PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There's no need to make this get_revision_1 call when our
> > counter runs out. If we are not in --boundary mode, we will
> > just throw away the result and immediately return NULL. If
> > we are in --boundary mode, then we will still throw away the
> > result, and then start showing the boundary commits.
> >
> > However, as git_revision_1 does not impact the boundary
> > list, it should not have an impact.
>
> We used to reset 'c' to NULL ("throw away the result"), run
> create_boundary_commit_list(), and ask ourselves to pop the boundary
> it computed.
>
> Now we don't call get_revision_1() and leave 'c' to NULL as
> initialized ("avoid work"), and do the same.
Right.
> The state create_boundary_commit_list() sees would slightly be
> different, as we used to dig one level deeper, smudging more commits
> with bits, but the only bits that may be smudged by this digging
> that may matter in create_commit_list() is CHILD_SHOWN and SHOWN,
> but by definition the commits around the commit the extra call to
> get_revision_1() would have returned are marked with neither during
> that extra call, so I think this conversion does not affect the
> boundary list.
Yeah, this was my analysis, too. Though reading get_revision-1, it seems
like we can actually set SHOWN, but I wasn't able to trigger any change
of behavior in practice. I think it is because we must set both SHOWN
and BOUNDARY to have an effect, and we do not do so.
So the only questionable thing would be: are there commits with BOUNDARY
set but not SHOWN that could be affected by calling get_revision_1? For
that matter, if such a commit existed, would the current behavior even
be correct? We would not have actually shown the commit, so if such a
case did exist, I wonder if we would be fixing a bug.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: avoid work after --max-count is reached
Jeff King writes: > Yeah, this was my analysis, too. Though reading get_revision-1, it seems > like we can actually set SHOWN, but I wasn't able to trigger any change > of behavior in practice. I think it is because we must set both SHOWN > and BOUNDARY to have an effect, and we do not do so. In principle, SHOWN is only given when get_revision_internal gives the commit back to be shown, and the parents of the returned commit are painted CHILD_SHOWN. This should be the only place to paint commit as CHILD_SHOWN. A handful of places set the bit to commits that would be shown if some options that further limit what is shown by topological property (e.g. --left-only, --cherry-pick), which may cause that a parent of a commit that was omitted due to these conditions may later be marked incorrectly as a boundary inside create_boundary_commit_list(). BOUNDARY is only given in create_boundary_commit_list() using CHILD_SHOWN and SHOWN, and that should happen only once when get_revision_1() runs out of the commits. By the way, cherry_pick_list() pays attention to BOUNDARY, but I think it is written overly defensively to protect itself from future callsites. With the current code structure, it is only called from limit_list() and get_revision_*() functions are never called until limit_list() returns (and again create_boundary_commit_list() that is called from get_revision_internal() is the only place that sets BOUNDARY, so the commits cherry_pick_list() sees would never have that bit set. > So the only questionable thing would be: are there commits with BOUNDARY > set but not SHOWN that could be affected by calling get_revision_1? For > that matter, if such a commit existed, would the current behavior even > be correct? We would not have actually shown the commit, so if such a > case did exist, I wonder if we would be fixing a bug. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] git-am: indicate where a failed patch is to be found.
On 12-07-13 03:58 PM, Junio C Hamano wrote: > Paul Gortmaker writes: > >> If git am fails to apply something, the end user may need >> to know where to find the patch. This is normally known for >> a single patch, but if the user is processing a mbox with >> many patches, they may not have a single broken out patch >> handy. So, provide a helpful hint as to where they can >> find the patch to do some sort of manual fixup, if we >> are processing a mbox with more than one patch in it. > > I would rather see this done even for a single patch mbox. The OK, I got the opposite impression from your prev. mail when you mentioned that I hadn't limited the message output at all. I'm fine with the changes you've proposed below, and can squash that into a v3 and resend again. Paul. -- > patch that was fed to "git apply" by "git am" and failed to apply is > that one, not the one in the mbox you gave "git am". The latter may > be ungrokkable with GNU patch or "git apply", if the original was > sent in Quoted-Printable and such MIME funnies, which is the whole > point of having a separate file there for "git am", instead of > feeding the original. > > I am not sure if we should limit $patch_format to mbox, but I think > showing this unconditionally regardless of mbox/stgit/hg will teach > the user only one location to remember, so perhaps like this? > > Documentation/config.txt | 3 +++ > git-am.sh| 4 ++-- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 0e1168c..b1f0a75 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -143,6 +143,9 @@ advice.*:: > Advice shown when you used linkgit:git-checkout[1] to > move to the detach HEAD state, to instruct how to create > a local branch after the fact. > + amWorkDir:: > + Advice that shows the location of the patch file when > + linkgit:git-am[1] fails to apply it. > -- > > core.fileMode:: > diff --git a/git-am.sh b/git-am.sh > index dc48f87..f1ae932 100755 > --- a/git-am.sh > +++ b/git-am.sh > @@ -834,9 +834,9 @@ did you forget to use 'git add'?" > if test $apply_status != 0 > then > eval_gettextln 'Patch failed at $msgnum $FIRSTLINE' > - if test $patch_format = mbox && test "$last" -ne "1" > + if test "$(git config --bool advice.amworkdir)" != false > then > - eval_gettextln "You can find the copy of the patch that > failed here: > + eval_gettextln "The copy of the patch that failed is > found in: > $dotest/patch" > fi > stop_here_user_resolve $this > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mini bug report origin/pu: t1512 failed on Mac OS X (commit 957d74062c1f0e ?)
On 07/12/2012 01:30 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I think the other tests in t/ prefer to unquote it so that we would >> ignore spaces around "wc -l" output, i.e. >> >> test $(wc -l > >> Thanks for a report. > > -- >8 -- > Subject: [PATCH] t1512: ignore whitespaces in wc -l output > > Some implementations of sed (e.g. MacOS X) > 'sed'? Shouldn't this read 'wc'? > have whitespaces in the output of "wc -l" that reads from the standard > input. > FYI, the extra space is present with Solaris wc as well: $ wc -l http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] git-am: indicate where a failed patch is to be found.
Paul Gortmaker writes: > I'm fine with the changes you've proposed below,... Here is what I committed for today's integration run. Will be pushed out on 'pu'. Thanks. -- >8 -- From: Paul Gortmaker Date: Fri, 13 Jul 2012 11:51:30 -0400 Subject: [PATCH] am: indicate where a failed patch is to be found If "git am" fails to apply something, the end user may need to know where to find the patch that failed to apply, so that the user can do other things (e.g. trying "GNU patch" on it, running "diffstat" to see what it tried to change, etc.) The input to "am" may have contained more than one patch, or the message may have been MIME encoded, and knowing what the user fed to "am" does not help very much for this purpose. Also introduce advice.amworkdir configuration to allow people who learned where to look to squelch this message. Signed-off-by: Paul Gortmaker Signed-off-by: Junio C Hamano --- Documentation/config.txt | 3 +++ git-am.sh| 5 + 2 files changed, 8 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 0e1168c..b1f0a75 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -143,6 +143,9 @@ advice.*:: Advice shown when you used linkgit:git-checkout[1] to move to the detach HEAD state, to instruct how to create a local branch after the fact. + amWorkDir:: + Advice that shows the location of the patch file when + linkgit:git-am[1] fails to apply it. -- core.fileMode:: diff --git a/git-am.sh b/git-am.sh index cb833e2..f1ae932 100755 --- a/git-am.sh +++ b/git-am.sh @@ -834,6 +834,11 @@ did you forget to use 'git add'?" if test $apply_status != 0 then eval_gettextln 'Patch failed at $msgnum $FIRSTLINE' + if test "$(git config --bool advice.amworkdir)" != false + then + eval_gettextln "The copy of the patch that failed is found in: + $dotest/patch" + fi stop_here_user_resolve $this fi -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mini bug report origin/pu: t1512 failed on Mac OS X (commit 957d74062c1f0e ?)
Stefano Lattarini writes: > On 07/12/2012 01:30 AM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> I think the other tests in t/ prefer to unquote it so that we would >>> ignore spaces around "wc -l" output, i.e. >>> >>> test $(wc -l >> >>> Thanks for a report. >> >> -- >8 -- >> Subject: [PATCH] t1512: ignore whitespaces in wc -l output >> >> Some implementations of sed (e.g. MacOS X) >> > 'sed'? Shouldn't this read 'wc'? Heh, funny typo. I don't know what I was thinking. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jul 2012, #04; Fri, 13)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The sixth batch of topics are now in 'master'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * jc/refactor-diff-stdin (2012-06-28) 3 commits (merged to 'next' on 2012-07-09 at ef407ee) + diff-index.c: "git diff" has no need to read blob from the standard input + diff-index.c: unify handling of command line paths + diff-index.c: do not pretend paths are pathspecs Due to the way "git diff --no-index" is bolted onto by touching the low level code that is shared with the rest of the "git diff" code, even though it has to work in a very different way, any comparison that involves a file "-" at the root level incorrectly tried to read from the standard input. This cleans up the no-index codepath further to remove code that reads from the standard input from the core side, which is never necessary when git is running its usual diff operation. * jn/vcs-svn (2012-07-05) 12 commits (merged to 'next' on 2012-07-09 at 1d97a8f) + vcs-svn: allow 64-bit Prop-Content-Length + vcs-svn: suppress a signed/unsigned comparison warning + vcs-svn: suppress a signed/unsigned comparison warning + vcs-svn: suppress signed/unsigned comparison warnings + vcs-svn: use strstr instead of memmem + vcs-svn: use constcmp instead of prefixcmp + vcs-svn: simplify cleanup in apply_one_window + vcs-svn: avoid self-assignment in dummy initialization of pre_off + vcs-svn: drop no-op reset methods + vcs-svn: suppress -Wtype-limits warning + vcs-svn: allow import of > 4GiB files + vcs-svn: rename check_overflow and its arguments for clarity Reroll of db/vcs-svn. * mm/mediawiki-file-attachments (2012-07-04) 6 commits (merged to 'next' on 2012-07-09 at 4b85fa2) + git-remote-mediawiki: improve support for non-English Wikis (merged to 'next' on 2012-07-03 at 90f2f45) + git-remote-mediawiki: import "File:" attachments + git-remote-mediawiki: split get_mw_pages into smaller functions + git-remote-mediawiki: send "File:" attachments to a remote wiki + git-remote-mediawiki: don't "use encoding 'utf8';" + git-remote-mediawiki: don't compute the diff when getting commit message (this branch is used by mm/mediawiki-tests.) "mediawiki" remote helper (in contrib/) learned to handle file attachments. * mm/mediawiki-tests (2012-07-06) 12 commits (merged to 'next' on 2012-07-09 at 4d874e8) + git-remote-mediawiki: be more defensive when requests fail + git-remote-mediawiki: more efficient 'pull' in the best case + git-remote-mediawiki: extract revision-importing loop to a function + git-remote-mediawiki: refactor loop over revision ids + git-remote-mediawiki: change return type of get_mw_pages + git-remote-mediawiki (t9363): test 'File:' import and export + git-remote-mediawiki: support for uploading file in test environment + git-remote-mediawiki (t9362): test git-remote-mediawiki with UTF8 characters + git-remote-mediawiki (t9361): test git-remote-mediawiki pull and push + git-remote-mediawiki (t9360): test git-remote-mediawiki clone + git-remote-mediawiki: test environment of git-remote-mediawiki + git-remote-mediawiki: scripts to install, delete and clear a MediaWiki (this branch uses mm/mediawiki-file-attachments.) * mz/rebase-no-mbox (2012-06-26) 4 commits (merged to 'next' on 2012-07-03 at 5bf5c12) + am: don't call mailinfo if $rebasing + am --rebasing: get patch body from commit, not from mailbox + rebase --root: print usage on too many args + rebase: don't source git-sh-setup twice Teach "am --rebasing" codepath to grab authorship, log message and the patch text directly out of existing commits. This will help rebasing commits that have confusing "diff" output in their log messages. * tb/sanitize-decomposed-utf-8-pathname (2012-07-08) 1 commit (merged to 'next' on 2012-07-09 at 61b12c2) + git on Mac OS and precomposed unicode Teaches git to normalize pathnames read from readdir(3) and all arguments from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8) to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * tg/ce-namelen (2012-07-08) 1 commit (merged to 'next' on 2012-07-10 at 87755d8) + Replace strlen() with ce_namelen() Trivially correct clean-up and micro optimization. * tr/maint-show-walk (2012-06-19) 2 commits (merged to 'next' on 2012-07-09 at c8e0e06) + show: fix "range implies walking" + Demonstrate git-show is broken with ranges Fixes "git show"'s auto-walking behaviour, and make it behave just like "git log" does when it walks. Note tha
Support of '^' as alias for 'HEAD^'
Hi, Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Garbage Collect Error.
On Thursday 12 July 2012 05:32:21 Jeff King wrote: > [...] which means you are probably not even getting to use all 4Gb of your > address space (my impression is that without special flags, 32-bit Windows > processes are limited to 2Gb of address space). Indeed, that's how windows partitions memory on 32-Bit Systems. See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366912.aspx As it's always with that strange company, they don't spend a word about how they do it in the emulated 32 bit environment. However, a short testing reveals that a 32 bit process running on 64 bit Windows 7 with 6 GiB memory is not able to malloc() more than 1 GiB at once (which is not a big suprise at all - as malloc'ed memory has to be continuous inside the address space). So one might guess that there is no difference in memory partitioning for 32 bit processes running on 64 bit OS. SaCu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
