Re: [PATCH][GSOC2014] install_branch_config: change logical chain to lookup table
On Fri, Mar 14, 2014 at 5:30 PM, TamerTas wrote:
> Signed-off-by: TamerTas
> ---
> Thanks again for the feedback it's been a great learning experience. Comments
> Below :)
>
> I have refactored the commit [1] to * suggested changes [2].
> format-patch was placing 2 hyphens instead of 3 but it's fixed now.
> I've turned the table into a multidimensional one and I didn't put
> the inner braces since this was used method in other multidimensional arrays
> throughout the project.
Thanks, this is looking better. A few minor comments below, but it's
probably not worth a re-roll. What is important is that you have had a
taste of the review process on this project, and the GSoC mentors have
had a chance to observe your abilities and reviewer interaction.
> I've also changed shortname to short_name since that seems to be how
> variables are named
> in this project.
This is a conceptually distinct change which should be done as a
separate "cleanup" patch since it otherwise adds noise which obscures
the "real" change (rewriting the if-chain). One of the goals of a
patch submitter is to make the review process as streamlined as
possible, so noise should be avoided.
Apart from that, unless the variable is really improperly named and
misleading, this sort of change (renaming "shortname" to "short_name")
is likely to be considered unnecessary code churn which will probably
be rejected. At any given time, there are many patch series in-flight
which Junio has to juggle, and code churn increases possibility of
conflict between them, which makes his job more difficult.
> It appears that table-driven code might be more readable after all.
>
> [1]http://git.661346.n2.nabble.com/PATCH-GSOC2014-install-branch-config-change-logical-chain-to-lookup-table-tp7605550.html
> [2]http://git.661346.n2.nabble.com/PATCH-GSOC2014-install-branch-config-change-logical-chain-to-lookup-table-tp7605550p7605605.html
> ---
> branch.c | 42 +-
> 1 file changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index 723a36b..eab6fa4 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -49,13 +49,27 @@ static int should_setup_rebase(const char *origin)
>
> void install_branch_config(int flag, const char *local, const char *origin,
> const char *remote)
> {
> - const char *shortname = remote + 11;
> + const char *short_name = remote + 11;
> + const char *setup_message[][2][2] = {
> + N_("Branch %s set up to track local ref %s."),
> + N_("Branch %s set up to track local branch %s."),
> + N_("Branch %s set up to track remote ref %s."),
> + N_("Branch %s set up to track remote branch %s from %s."),
> + N_("Branch %s set up to track local ref %s by rebasing."),
> + N_("Branch %s set up to track local branch %s by rebasing."),
> + N_("Branch %s set up to track remote ref %s by rebasing."),
> + N_("Branch %s set up to track remote branch %s from %s by
> rebasing.")
> + };
> +
> int remote_is_branch = starts_with(remote, "refs/heads/");
> struct strbuf key = STRBUF_INIT;
> int rebasing = should_setup_rebase(origin);
>
> + const char *remote_name = remote_is_branch? short_name : remote;
> + const char *message =
> setup_message[!!rebasing][!!origin][!!remote_is_branch];
In the previous review, it was suggested to pull this value out into
its own variable to make the code less noisy since it was being
accessed frequently in just a few lines of code. However, since you've
collapsed the code to a single printf_ln() invocation in this patch,
the separate variable may be not helping clarity (especially as the
assignment is divorced by some distance from the code which references
it). The same is probably true of 'remote_name' which is used in just
the one printf_ln() call.
> if (remote_is_branch
> - && !strcmp(local, shortname)
> + && !strcmp(local, short_name)
> && !origin) {
> warning(_("Not setting branch %s as its own upstream."),
> local);
> @@ -77,29 +91,7 @@ void install_branch_config(int flag, const char *local,
> const char *origin, cons
> strbuf_release(&key);
>
> if (flag & BRANCH_CONFIG_VERBOSE) {
> - if (remote_is_branch && origin)
> - printf_ln(rebasing ?
> - _("Branch %s set up to track remote branch
> %s from %s by rebasing.") :
> - _("Branch %s set up to track remote branch
> %s from %s."),
> - local, shortname, origin);
> - else if (remote_is_branch && !origin)
> - printf_ln(rebasing ?
> - _("Branch %s set up to track local branch
> %s by rebasing.") :
> - _("Branch %s set up t
Re: [PATCH] Documentation/git-am: Document supported --patch-format options
Chris Packham writes: > Ping? Hasn't it been already cooking in 'next' for a few days? -- 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: Using "-" for "previous branch" failing with rebase
Tim Chase writes: > Is this just an interface inconsistency or is there a some technical > reason this doesn't work (or, has it been addressed/fixed, and just > not pulled into Debian Stable's 1.7.10.4 version of git)? It is merely that nobody thought "rebase" would benefit from such a short-hand, I think. Teach more commands that operate on branch names about "-" shorthand for "the branch we were previously on", like we did for "git merge -" sometime after we introduced "git checkout -" has been sitting in my "leftover bits" list at http://git-blame.blogspot.com/p/leftover-bits.html for quite some time. Hint, hint... -- 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] mv: prevent mismatched data when ignoring errors.
Junio C Hamano writes:
> Would it make sense to go one step further to introduce two macros
> to make this kind of screw-up less likely?
> ...
> After letting my eyes coast over hits from "git grep memmove", there
> do seem to be some places that these would help readability, but not
> very many.
I see quite a many hits that follow this pattern
memmove(array + pos, array + pos + 1, sizeof(*array) * (nr - pos))
to make a single slot in a middle of array available, which would be
good candidates to use MOVE_DOWN(). Just to show a few:
builtin/mv.c:226: memmove(source + i, source + i + 1,
builtin/mv.c-227- (argc - i) * sizeof(char *));
builtin/mv.c:228: memmove(destination + i,
builtin/mv.c-229- destination + i + 1,
builtin/mv.c-230- (argc - i) * sizeof(char *));
cache-tree.c:92:memmove(it->down + pos + 1,
cache-tree.c-93-it->down + pos,
cache-tree.c-94-sizeof(down) * (it->subtree_nr - pos - 1));
Perhaps something like this patch to start off; I am not sure
MOVE_DOWN_BOUNDED is needed, though.
cache.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/cache.h b/cache.h
index b66cb49..b2615ab 100644
--- a/cache.h
+++ b/cache.h
@@ -455,6 +455,39 @@ extern int daemonize(void);
} \
} while (0)
+/*
+ * With an array "array" that currently holds "nr" elements, move
+ * elements at "at" and later down by "count" elements to make room to
+ * add in new elements. The caller is responsible for making sure
+ * that the array has enough room to hold "nr" + "count" slots.
+ */
+#define MOVE_DOWN(array, nr, at, count)\
+ memmove((array) + (at) + (count), \
+ (array) + (at), \
+ sizeof((array)[0]) * ((nr) - (at)))
+
+/*
+ * With an array "array" that has enough memory to hold "alloc"
+ * elements allocated and currently holds "nr" elements, move elements
+ * at "at" and later down by "count" elements to make room to add in
+ * new elements.
+ */
+#define MOVE_DOWN_BOUNDED(array, nr, at, count, alloc) \
+ do { \
+ if ((alloc) <= (nr) + (count)) \
+ BUG("MOVE_DOWN beyond the end of an array"); \
+ MOVE_DOWN((array), (nr), (at), (count)); \
+ } while (0)
+
+/*
+ * With an array "array" that curently holds "nr" elements, move elements
+ * at "at" + "count" and later down by "count" elements, removing the
+ * elements between "at" and "at" + "count".
+ */
+#define MOVE_UP(array, nr, at, count) \
+ memmove((array) + (at), (array) + (at) + (count), \
+ sizeof((array)[0]) * ((nr) - ((at) + (count
+
/* Initialize and use the cache information */
extern int read_index(struct index_state *);
extern int read_index_preload(struct index_state *, const struct pathspec
*pathspec);
--
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] GSoC Change multiple if-else statements to be table-driven
On Fri, Mar 14, 2014 at 12:54 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >> On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao wrote: >>> Subject: [PATCH] GSoC Change multiple if-else statements to be table-driven >> >> It's a good idea to let reviewers know that this is attempt 2. Do so >> by saying [PATCH v2]. Your next one will be [PATCH v3]. The -v option >> for "git format-email" can help. > > Yao, I think Eric meant "git format-patch". Correct. Sorry for the confusion. >> An alternate approach might be to use a multi-dimensional array, >> where the boolean values of rebasing, remote_is_branch, and origin >> are keys into the array. This would allow you to pick out the >> correct PRINT_LIST entry directly (no looping), thus eliminating >> the need for those b_rebasing, b_remote_is_branch, and b_origin >> members. > > Correct. > > After seeing so many "table driven" submissions, I however tend to > agree with your earlier comment on another thread on this same > micro, where you said an nested if-else cascade that was rewritten > in a clearer way (sorry, I do not remember whose submission it was It was Adam NoLastName [1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/243704 > offhand) may be the best answer to the "Would it make sense to make > the code table-driven?" question, even though I tentatively queued > d7ea7894 (install_branch_config(): simplify verbose messages logic, > 2014-03-13) from Paweł on 'pu'. Perhaps it is time to mark this microproject as "taken" on the GSoC page [2], along a fews others for which we have received multiple submissions. [2]: https://github.com/git/git.github.io/blob/master/SoC-2014-Microprojects.md -- 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] l10n: Fix misuses of "nor"
Thanks. I'll remove this patch from the queue. On Sun, Mar 16, 2014 at 6:45 PM, Jiang Xin wrote: > 2014-03-15 16:41 GMT+08:00 Justin Lebar : >> Signed-off-by: Justin Lebar >> --- >> po/bg.po| 6 +++--- >> po/de.po| 6 +++--- >> po/fr.po| 6 +++--- >> po/git.pot | 6 +++--- >> po/it.po| 2 +- >> po/pt_PT.po | 2 +- >> po/sv.po| 6 +++--- >> po/vi.po| 6 +++--- >> po/zh_CN.po | 6 +++--- >> 9 files changed, 23 insertions(+), 23 deletions(-) >> >> diff --git a/po/bg.po b/po/bg.po >> index fb450b2..983e575 100644 >> --- a/po/bg.po >> +++ b/po/bg.po >> @@ -3699,13 +3699,13 @@ msgstr "" >> >> #: builtin/clean.c:906 >> msgid "" >> -"clean.requireForce set to true and neither -i, -n nor -f given; refusing >> to " >> +"clean.requireForce set to true and neither -i, -n, nor -f given; refusing >> to " >> "clean" >> msgstr "" >> > > Hi Justin, > > All the msgids you patched are extracted from Git source code using gettext, > So please patch the original files where the msgids are came from, such as > builtin/clean.c. > > > -- > Jiang Xin -- 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] l10n: Fix misuses of "nor"
2014-03-15 16:41 GMT+08:00 Justin Lebar : > Signed-off-by: Justin Lebar > --- > po/bg.po| 6 +++--- > po/de.po| 6 +++--- > po/fr.po| 6 +++--- > po/git.pot | 6 +++--- > po/it.po| 2 +- > po/pt_PT.po | 2 +- > po/sv.po| 6 +++--- > po/vi.po| 6 +++--- > po/zh_CN.po | 6 +++--- > 9 files changed, 23 insertions(+), 23 deletions(-) > > diff --git a/po/bg.po b/po/bg.po > index fb450b2..983e575 100644 > --- a/po/bg.po > +++ b/po/bg.po > @@ -3699,13 +3699,13 @@ msgstr "" > > #: builtin/clean.c:906 > msgid "" > -"clean.requireForce set to true and neither -i, -n nor -f given; refusing to > " > +"clean.requireForce set to true and neither -i, -n, nor -f given; refusing > to " > "clean" > msgstr "" > Hi Justin, All the msgids you patched are extracted from Git source code using gettext, So please patch the original files where the msgids are came from, such as builtin/clean.c. -- Jiang Xin -- 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: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Philip Oakley wrote:
>> * po/everyday-doc (2014-01-27) 1 commit
>> - Make 'git help everyday' work
>>
>> This may make the said command to emit something, but the source is
>> not meant to be formatted into a manual pages to begin with, and
>> also its contents are a bit stale. It may be a good first step in
>> the right direction, but needs more work to at least get the
>> mark-up right before public consumption.
>
> I'm not sure what elements you feel need adjustment. At the moment the
> markup formats quite reasonably to my eyes, both as an HTML page and as a
> man page.
I sent you a small patch fixing some minor markup issues.
> That said, the (lack of) introduction could do with a paragraph to introduce
> the "guide". I have something in draft..
>
> I had a thought that it may be worth a slight rearrangement to add a section
> covering the setting up of one's remotes, depending whether it was forked,
> corporate, or independent, but the lack of resolution on the next
> {publish/push} topic makes such a re-write awkward at this stage. (Ram cc'd)
Before attempting to introduce remote.pushdefault and triangular
workflows, I'd first fix the main issue: stale content. I'm not sure
who uses git show-branch or mailx anymore, for instance.
--
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: Should 'git reset --hard' keep a stashed backup?
On Mon, Mar 17, 2014 at 5:17 AM, Philip Oakley wrote: > A bike-shedding thought: > Many inexperienced users do a 'git reset --hard' only to discover they have > deleted something important and want it back. (e.g. git-users yesterday [1]) > > One possible option is that Git could "stash" the current work-tree contents > (git stash create) into a commit and store its commit_id in a suitable > file/variable such as RESET_HARD_HEAD (or GIT_RESET_HARD_HEAD), similar to > FETCH_HEAD & MERGE_HEAD, so that it would be relatively easy to recover the > prior state. A while back I started to implement "undo" function for "git add". I think we could do the same here, when reset --hard is issued, store current SHA-1 in index to an index extension, also hash overwritten files in worktree and store it in the index extension as well. "reset --undo" can bring it back. Experienced user can turn this off via config variable, but it's default to on. > > By only storing the id in the file/env it would be overwritten on each > usage, and the loose commits would be garbage collected eventually. We have similar ideas, except I choose to store in the index instead. > > A suitable config variable would allow it to be enabled/disabled as > appropriate to the user. (Perhaps enabled by default eventually?) Yes. We could even bundle it to an advice.* knob. Experienced users will usually turn the advice off (and this behavior will be gone as the result). > Given the prevalence of 'git reset --hard' within internet forum advice, > would something like this be useful? It could even be wrapped into a GSoC > project. We could go further to provide "git undo" interface that covers other areas as well, easier to discover than "reset --undo", but I'm not sure how this interface should work.. -- Duy -- 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 pu] Documentation/giteveryday: fix some obvious problems
Fix a few minor things. Signed-off-by: Ramkumar Ramachandra --- Philip, I spotted a few obvious issues with your giteveryday patch in pu. Maybe Junio can squash this into your patch? Contents are still a bit stale, but I'm not sure what other markup problems are there. Documentation/giteveryday.txt | 78 +-- 1 file changed, 38 insertions(+), 40 deletions(-) diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt index 8dc298f..82ff8ec 100644 --- a/Documentation/giteveryday.txt +++ b/Documentation/giteveryday.txt @@ -35,8 +35,6 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch @@ -61,8 +59,8 @@ following commands. Examples -Use a tarball as a starting point for a new repository.:: -+ +Use a tarball as a starting point for a new repository: + $ tar zxf frotz.tar.gz $ cd frotz @@ -71,12 +69,12 @@ $ git add . <1> $ git commit -m "import of frotz source tree." $ git tag v2.43 <2> -+ + <1> add everything under the current directory. <2> make a lightweight, unannotated tag. -Create a topic branch and develop.:: -+ +Create a topic branch and develop: + $ git checkout -b alsa-audio <1> $ edit/compile/test @@ -95,7 +93,7 @@ $ git merge alsa-audio <10> $ git log --since='3 days ago' <11> $ git log v2.43.. curses/ <12> -+ + <1> create a new topic branch. <2> revert your botched changes in `curses/ux_audio_oss.c`. <3> you need to tell Git if you added a new file; removal and @@ -137,8 +135,8 @@ addition to the ones needed by a standalone developer. Examples -Clone the upstream and work on it. Feed changes to upstream.:: -+ +Clone the upstream and work on it. Feed changes to upstream: + $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 @@ -151,7 +149,7 @@ $ git reset --hard ORIG_HEAD <6> $ git gc <7> $ git fetch --tags <8> -+ + <1> repeat as needed. <2> extract patches from your branch for e-mail submission. <3> `git pull` fetches from `origin` by default and merges into the @@ -166,8 +164,8 @@ area we are interested in. and store them under `.git/refs/tags/`. -Push into another repository.:: -+ +Push into another repository: + satellite$ git clone mothership:frotz frotz <1> satellite$ cd frotz @@ -185,7 +183,7 @@ mothership$ cd frotz mothership$ git checkout master mothership$ git merge satellite/master <5> -+ + <1> mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine. @@ -200,8 +198,8 @@ as a back-up method. <5> on mothership machine, merge the work done on the satellite machine into the master branch. -Branch off of a specific tag.:: -+ +Branch off of a specific tag: + $ git checkout -b private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a @@ -209,7 +207,7 @@ $ git checkout master $ git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k <2> -+ + <1> create a private branch based on a well known (but somewhat behind) tag. <2> forward port all changes in `private2.6.14` branch to `master` branch @@ -240,8 +238,8 @@ commands in addition to the ones needed by participants. Examples -My typical Git day.:: -+ +My typical Git day: + $ git status <1> $ git show-branch <2> @@ -261,10 +259,10 @@ $ git cherry-pick master~4 <9> $ compile/test $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> $ git fetch ko && git show-branch master maint 'tags/ko-*' <11> -$ git push ko <12> -$ git push ko v0.99.9x <13> +$ git push ko +$ git push ko v0.99.9x -+ + <1> see what I was in the middle of doing, if any. <2> see what topic branches I have and think about how ready they are. @@ -282,7 +280,7 @@ master, nor exposed as a part of a stable branch. <11> make sure I did not accidentally rewind master beyond what I already pushed out. `ko` shorthand points at the repository I have at kernel.org, and looks like this: -+ + $ cat .git/remotes/ko URL: kernel.org:/pub/scm/git/git.git @@ -294,7 +292,7 @@ Push: next Push: +pu Push: maint -+ + In the output from `git show-branch`, `master` should have everything `ko-master` has, and `next` should have everything `ko-next` has. @@ -322,24 +320,24 @@ example of managing a shared central repository. Examples We assume the following in /etc/services:: -+ + $ grep 9418 /etc/services git9418/tcp# Git Version Control System -Run git-daemon to serve /pub/scm from inetd.:: -+ +Run git-daemon to serve /pub/scm from inetd: + $ grep git /etc/inetd.
Re: [PATCH 3/4] gc --aggressive: make --depth configurable
On Mon, Mar 17, 2014 at 12:10 AM, Jay Soffian wrote: > On Sun, Mar 16, 2014 at 9:35 AM, Nguyễn Thái Ngọc Duy > wrote: >> >> When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06) >> made --depth=250 the default value, it didn't really explain the >> reason behind, especially the pros and cons of --depth=250. >> >> An old mail from Linus below explains it at length. Long story short, >> --depth=250 is a disk saver and a performance killer. Not everybody >> agrees on that aggressiveness. Let the user configure it. > > > Suggestion to link to the email discussion(s) on gmane in the Documentation > or at least the commit message? If you mean the discussion back in 2007, there is a fake header "Gmane-URL" in Linus' mail in the commit message. -- Duy -- 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] Documentation/merge-strategies: avoid hyphenated commands
Replace git-pull and git-merge with the corresponding un-hyphenated
versions. While at it, use ` to mark it up instead of '.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/merge-strategies.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-strategies.txt
b/Documentation/merge-strategies.txt
index 12133b9..19f3a5d 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,10 +1,10 @@
MERGE STRATEGIES
-The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+The merge mechanism (`git merge` and `git pull` commands) allows the
backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-X`
-arguments to 'git-merge' and/or 'git-pull'.
+arguments to `git merge` and/or `git pull`.
resolve::
This can only resolve two heads (i.e. the current branch
--
1.9.0.431.g014438b
--
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
[GSoC 2014] git config API improvements
Hello, My name is Dragos Foianu and I am an undergraduate student at University Politehnica of Bucharest in Romania. This is my final year and I'm planning on doing something more exciting than the simple assignments I get from the university. I have been working with git for quite some time now and I'm currently using it for my diploma project. It was annoying at first but now I love it and it has helped me many times in the past. I wanted to contribute to the project and I feel that GSoC 2014 is the perfect opportunity for this. I am primarily interested in the "git config API improvements" project. I have glanced over the code in order to get an idea of how git-config currently works. The project idea page gives a very good description of what is desired. Caching and retrieving values by name sounds to me like a hint to use a hashtable-like data structure. Conveniently, there is already a hashmap implementation in git and even more conveniently, there is a cache implementation that uses that data structure. So that part is fairly straightforward. I have a question, however: how would I go about detecting when a cache invalidation is necessary? Considering I have read a configuration file and cached the configuration in memory, what can trigger one of the existing cache entries to be invalidated? That is all I have to ask for now. I will look over the code during the next few days to get the bigger picture and submit my application. At [1] you can find my microproject patch. I am eagerly awaiting for any questions you might have. All the best, Dragos [1] http://thread.gmane.org/gmane.comp.version-control.git/244210 -- 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
Should 'git reset --hard' keep a stashed backup?
A bike-shedding thought: Many inexperienced users do a 'git reset --hard' only to discover they have deleted something important and want it back. (e.g. git-users yesterday [1]) One possible option is that Git could "stash" the current work-tree contents (git stash create) into a commit and store its commit_id in a suitable file/variable such as RESET_HARD_HEAD (or GIT_RESET_HARD_HEAD), similar to FETCH_HEAD & MERGE_HEAD, so that it would be relatively easy to recover the prior state. By only storing the id in the file/env it would be overwritten on each usage, and the loose commits would be garbage collected eventually. A suitable config variable would allow it to be enabled/disabled as appropriate to the user. (Perhaps enabled by default eventually?) Given the prevalence of 'git reset --hard' within internet forum advice, would something like this be useful? It could even be wrapped into a GSoC project. -- Philip [1] https://groups.google.com/forum/#!topic/git-users/CwQyfwnzCVM -- 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] branch.c: simplify chain of if statements
This patch uses a table-driven approach in order to make the code
cleaner. Although not necessary, it helps code reability by not
forcing the user to read the print message when trying to
understand what the code does. The rebase check has been moved to
the verbose if statement to avoid making the same check in each of
the four if statements.
Signed-off-by: Dragos Foianu
---
branch.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..e2fe455 100644
--- a/branch.c
+++ b/branch.c
@@ -54,6 +54,14 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
+ const char *verbose_prints[4] = {
+ "Branch %s set up to track remote branch %s from %s%s",
+ "Branch %s set up to track local branch %s%s",
+ "Branch %s set up to track remote ref %s%s",
+ "Branch %s set up to track local ref %s%s"
+ };
+ char *verbose_rebasing = rebasing ? " by rebasing." : ".";
+
if (remote_is_branch
&& !strcmp(local, shortname)
&& !origin) {
@@ -78,25 +86,17 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
if (flag & BRANCH_CONFIG_VERBOSE) {
if (remote_is_branch && origin)
- printf_ln(rebasing ?
- _("Branch %s set up to track remote branch %s
from %s by rebasing.") :
- _("Branch %s set up to track remote branch %s
from %s."),
- local, shortname, origin);
+ printf_ln(_(verbose_prints[0]),
+ local, shortname, origin, verbose_rebasing);
else if (remote_is_branch && !origin)
- printf_ln(rebasing ?
- _("Branch %s set up to track local branch %s
by rebasing.") :
- _("Branch %s set up to track local branch
%s."),
- local, shortname);
+ printf_ln(_(verbose_prints[1]),
+ local, shortname, verbose_rebasing);
else if (!remote_is_branch && origin)
- printf_ln(rebasing ?
- _("Branch %s set up to track remote ref %s by
rebasing.") :
- _("Branch %s set up to track remote ref %s."),
- local, remote);
+ printf_ln(_(verbose_prints[2]),
+ local, remote, verbose_rebasing);
else if (!remote_is_branch && !origin)
- printf_ln(rebasing ?
- _("Branch %s set up to track local ref %s by
rebasing.") :
- _("Branch %s set up to track local ref %s."),
- local, remote);
+ printf_ln(_(verbose_prints[3]),
+ local, remote, verbose_rebasing);
else
die("BUG: impossible combination of %d and %p",
remote_is_branch, origin);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv: prevent mismatched data when ignoring errors.
Jeff King writes: > On Sat, Mar 15, 2014 at 05:05:29PM +0100, Thomas Rast wrote: > >> > diff --git a/builtin/mv.c b/builtin/mv.c >> > index f99c91e..b20cd95 100644 >> > --- a/builtin/mv.c >> > +++ b/builtin/mv.c >> > @@ -230,6 +230,11 @@ int cmd_mv(int argc, const char **argv, const char >> > *prefix) >> >memmove(destination + i, >> >destination + i + 1, >> >(argc - i) * sizeof(char *)); >> > + memmove(modes + i, modes + i + 1, >> > + (argc - i) * sizeof(char *)); >> >> This isn't right -- you are computing the size of things to be moved >> based on a type of char*, but 'modes' is an enum. >> >> (Valgrind spotted this.) > > Maybe using sizeof(*destination) and sizeof(*modes) would make this less > error-prone? > > -Peff Would it make sense to go one step further to introduce two macros to make this kind of screw-up less likely? 1. "array" is an array that holds "nr" elements. Move "count" elements starting at index "at" down to remove them. #define MOVE_DOWN(array, nr, at, count) The implementation should take advantage of sizeof(*array) to come up with the number of bytes to move. 2. "array" is an array that holds "nr" elements. Move "count" elements starting at index "at" up to make room to copy new elements in. #define MOVE_UP(array, nr, at, count) The implementation should take advantage of sizeof(*array) to come up with the number of bytes to move. Optionally, to make 2. even safer, these macros could take "alloc" to say that "array" has memory allocated to hold "alloc" elements, and the implementation may check "nr + count" does not overflow "alloc". This would make 1. and 2. asymmetric (move-down can do no validation using "alloc", but move-up would be helped), so I am not sure it is a good idea. After letting my eyes coast over hits from "git grep memmove", there do seem to be some places that these would help readability, but not very many. -- 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
[GSoC 2014] Refactoring git rebase --interactive
Hi again, Git community! My name is Quint Guvernator, and I am participating in the Google Summer of Code program. I am in university at the College of William and Mary in Williamsburg, VA and plan to major in Computer Science and Linguistics. I have been working on a microproject [1][2] to get the hang of submitting patches and working with the mailing list. I have just submitted my proposal for git rebase --interactive through the google-melange website. In brief, I plan to refactor the shell script, cleaning up parts where the code is incohesive or difficult to decipher; add functionality to the script; and improve documentation by describing the script in comments and improving our user docs. I think it is important not to rush into new features, however, and detail in my proposal the extent to which I will stay in contact with the community through this list and on IRC. Should the work on rebase --interactive not take all summer, I would work to improve the quality of Git documentation. I am a native English speaker and copy-edit a local newspaper, so I feel I am qualified to edit and extend the Git documentation. I am happy to receive private mail, so please send any issues or questions you may have either to the list or directly to my inbox. Thanks for your consideration for GSoC. --Quint [1]: http://thread.gmane.org/gmane.comp.version-control.git/243940 [2]: http://thread.gmane.org/gmane.comp.version-control.git/244159 -- 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
Credit Assistance / Financial Offer
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.com -- 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
[GSOC2014] History Repair Tools
Hello everyone, I'm Tamer Tas. I am studying computer engineering in Turkey. I'm about to complete my junior year in Middle East Technical University. After setting up my git development environment, I've submitted patches to a microproject [1][2][3]. I'm still getting feedbacks on the microproject. Feedback cycle has been very informative. I am interested in developing history repair tools for git. For the past days I've been learning about how git manages history, inspecting git fsck, replace, hash-object. Also I've learned how git filter-branch is used to rewrite history and the drawbacks of this approach. I've submitted the first draft of my proposal and I would love to get a feedback from Jeff King or Michael Haggarty (Mentors of the project) or the community so I can improve my proposal. If you have any questions please feel free to ask. Thanks in advance. Tamer Tas [1]http://git.661346.n2.nabble.com/PATCH-GSOC2014-changed-logical-chain-in-branch-c-to-lookup-tables-tt7605343.html [2]http://git.661346.n2.nabble.com/PATCH-GSOC2014-install-branch-config-change-logical-chain-to-lookup-table-tt7605550.html [3]http://git.661346.n2.nabble.com/PATCH-GSOC2014-install-branch-config-change-logical-chain-to-lookup-table-tt7605550.html#a7605663 -- 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: What's cooking in git.git (Mar 2014, #03; Fri, 14)
From: "Junio C Hamano"
--
[Stalled]
...
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
I'm not sure what elements you feel need adjustment. At the moment the
markup formats quite reasonably to my eyes, both as an HTML page and as
a man page.
That said, the (lack of) introduction could do with a paragraph to
introduce the "guide". I have something in draft..
I had a thought that it may be worth a slight rearrangement to add a
section covering the setting up of one's remotes, depending whether it
was forked, corporate, or independent, but the lack of resolution on the
next {publish/push} topic makes such a re-write awkward at this stage.
(Ram cc'd)
Some guidance would be a help.
Will hold.
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
- sha1_name: refactor upstream_mark
Give an easier access to the tracking branches from "other" side in
a triangular workflow by introducing B@{publish} that works in a
similar way to how B@{upstream} does.
Meant to be used as a basis for whatever Ram wants to build on.
To me 'publish' didn't fel right, though the later 'push' suggestion
felt honest.
(http://git.661346.n2.nabble.com/RFC-PATCH-format-patch-introduce-branch-forkedFrom-tp7601682p7603725.html)
Will hold.
--
[Cooking]
* po/git-help-user-manual (2014-02-18) 1 commit
- Provide a 'git help user-manual' route to the docbook
I am not sure if this is even needed.
My rhetorical question would be "what should 'git help user-manual' do?"
for the beginner, and do we have a sort of policy on ensuring that the
majority of user documentation should be available (or at least
referenced) via the 'git help' mechanism?
It feels odd to make the user-manual the one manual that can't be served
via the git man pages.
Will discard.
--
Philip
--
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] Removed subshell invocations in many of the tests when possible
I am David Tran a graduating CS/Math senior from Sonoma State University, United States. I would like to work with git for GSoC'14, specifically the line options for git rebase --interactive. I have used git for a few years and know how destructive but important rebase is to git. I have created a few shell scripts here and there to make life using bash/zsh easier. I would like to apply these skills and work with the best. I've submitted my application yesterday and my patch didn't send correctly. Signed-off-by: David Tran --- t/t1300-repo-config.sh| 17 +++- t/t1510-repo-setup.sh |4 +-- t/t3200-branch.sh | 12 +--- t/t3301-notes.sh | 24 ++ t/t3404-rebase-interactive.sh | 55 + t/t3413-rebase-hook.sh|6 +--- t/t4014-format-patch.sh | 14 ++ t/t5305-include-tag.sh|4 +-- t/t5602-clone-remote-exec.sh | 13 ++--- t/t5801-remote-helpers.sh |6 +--- t/t6006-rev-list-format.sh|3 +- t/t7006-pager.sh | 18 ++--- 12 files changed, 41 insertions(+), 135 deletions(-) diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh index c9c426c..3e3f77b 100755 --- a/t/t1300-repo-config.sh +++ b/t/t1300-repo-config.sh @@ -974,24 +974,15 @@ test_expect_success SYMLINKS 'symlinked configuration' ' ' test_expect_success 'nonexistent configuration' ' - ( - GIT_CONFIG=doesnotexist && - export GIT_CONFIG && - test_must_fail git config --list && - test_must_fail git config test.xyzzy - ) + test_must_fail env GIT_CONFIG=doesnotexist git config --list && + test_must_fail env GIT_CONFIG=doesnotexist git config test.xyzzy ' test_expect_success SYMLINKS 'symlink to nonexistent configuration' ' ln -s doesnotexist linktonada && ln -s linktonada linktolinktonada && - ( - GIT_CONFIG=linktonada && - export GIT_CONFIG && - test_must_fail git config --list && - GIT_CONFIG=linktolinktonada && - test_must_fail git config --list - ) + test_must_fail env GIT_CONFIG=linktonada git config --list && + test_must_fail env GIT_CONFIG=linktolinktonada git config --list ' test_expect_success 'check split_cmdline return' " diff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh index cf2ee78..d8025be 100755 --- a/t/t1510-repo-setup.sh +++ b/t/t1510-repo-setup.sh @@ -777,9 +777,7 @@ test_expect_success '#30: core.worktree and core.bare conflict (gitfile version) setup_repo 30 "$here/30" gitfile true && ( cd 30 && - GIT_DIR=.git && - export GIT_DIR && - test_must_fail git symbolic-ref HEAD 2>result + test_must_fail env GIT_DIR='.git' git symbolic-ref HEAD 2>result ) && grep "core.bare and core.worktree" 30/result ' diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index fcdb867..d45e95c 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -849,11 +849,7 @@ test_expect_success 'detect typo in branch name when using --edit-description' ' write_script editor <<-\EOF && echo "New contents" >"$1" EOF - ( - EDITOR=./editor && - export EDITOR && - test_must_fail git branch --edit-description no-such-branch - ) + test_must_fail env EDITOR=./editor git branch --edit-description no-such-branch ' test_expect_success 'refuse --edit-description on unborn branch for now' ' @@ -861,11 +857,7 @@ test_expect_success 'refuse --edit-description on unborn branch for now' ' echo "New contents" >"$1" EOF git checkout --orphan unborn && - ( - EDITOR=./editor && - export EDITOR && - test_must_fail git branch --edit-description - ) + test_must_fail env EDITOR=./editor git branch --edit-description ' test_expect_success '--merged catches invalid object names' ' diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh index 3bb79a4..ca1fea9 100755 --- a/t/t3301-notes.sh +++ b/t/t3301-notes.sh @@ -17,7 +17,7 @@ GIT_EDITOR=./fake_editor.sh export GIT_EDITOR test_expect_success 'cannot annotate non-existing HEAD' ' - (MSG=3 && export MSG && test_must_fail git notes add) + test_must_fail env MSG=3 git notes add ' test_expect_success setup ' @@ -32,22 +32,18 @@ test_expect_success setup ' ' test_expect_success 'need valid notes ref' ' - (MSG=1 GIT_NOTES_REF=/ && export MSG GIT_NOTES_REF && -test_must_fail git notes add) && - (MSG=2 GIT_NOTES_REF=/ && export MSG GIT_NOTES_REF && -test_must_fail git notes show) + test_must_fail env MSG=1 env GIT_NOTES_REF=/ git notes show && + test_must_fail env MSG=2 env GIT_NOTES_REF=/
[PATCH] Documentation/gitk: Document new config file location
User configuration file is now stored at $XDG_CONFIG_HOME/git/gitk Signed-off-by: Astril Hayato --- Documentation/gitk.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 1e9e38a..417a707 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -166,8 +166,8 @@ gitk --max-count=100 --all \-- Makefile:: Files - -Gitk creates the .gitk file in your $HOME directory to store preferences -such as display options, font, and colors. +User configuration and preferences are stored at $XDG_CONFIG_HOME/git/gitk or +$HOME/.config/git/gitk if $XDG_CONFIG_HOME is not set. History --- -- 1.9.0 -- 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: Trust issues with hooks and config files
On 03/09/2014 10:57 PM, Julian Brost wrote: On 07.03.2014 22:04, Jeff King wrote: Yes, this is a well-known issue. The only safe operation on a repository for which somebody else controls hooks and config is to fetch from it (upload-pack on the remote repository does not respect any dangerous config or hooks). I'm a little bit surprised that you and some other people I asked see this as such a low-priority problem as this makes social engineering attacks on multi-user systems, like they are common at universities, really easy (this is also how I noticed the problem). This, and a lot more control related issues, are solved by tools like gitolite (which I maintain) and Gerrit (from Google), and also many GUI based access control tools like gitlab, gitorious, etc. In these schemes the user does not have a "unix" account on the server, and any hooks that run will run as the "hosting user". Access is either via ssh pub keys (most commonly) or http auth. It is my belief that most multi-user systems have installed one of these systems, and therefore the situation you speak of does not arise. They probably didn't install them to solve *this* problem, but to keep some semblance of control over who can access what repo, but as a side-effect they solve this problem also. sitaram It has been discussed, but nobody has produced patches. I think that nobody is really interested in doing so because: 1. It introduces complications into previously-working setups (e.g., a daemon running as "nobody" serving repos owned by a "git" user needs to mark "git" as trusted). 2. In most cases, cross-server boundaries provide sufficient insulation (e.g., I might not push to an evil person's repo, but rather to a shared repo whose hooks and config are controlled by root on the remote server). If you want to work on it, I think it's an interesting area. But any development would need to think about the transition plan for existing sites that will be broken. I can understand the problem with backward compatibility but in my opinion the default behavior should definitely be to ignore untrusted config files and hooks as it would otherwise only protect users that are already aware of the issue anyways and manually enable this option. Are there any plans for some major release in the future that would allow introducing backward incompatible changes? I would definitely spend some time working on a patch but so far I have no idea of git's internals and never looked at the source before. At the very least, the current trust model could stand to be documented much better (I do not think the rule of "fetching is safe, everything else is not" is mentioned anywhere explicitly). Good point but not enough in my opinion as I haven't read every git manpage before running it for the first time. -- 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 signature.asc Description: OpenPGP digital signature
[PATCH 0/4] Better "gc --aggressive"
See [1] for the discussion that led to this series. It attempts to pack the repo with two different depths: old history tightly packed (smaller but also takes longer time to access) and recent history on the opposite. First draft, probably still some bugs lurking in pack_old_history(). It would be great if people could try it out on large repos and report back the results (pack size between the old and new aggressive, gc time, git log and blame speed...) [1] http://thread.gmane.org/gmane.comp.version-control.git/242277 Nguyễn Thái Ngọc Duy (4): environment.c: fix constness for odb_pack_keep() pack-objects: support --keep gc --aggressive: make --depth configurable gc --aggressive: three phase repacking Documentation/config.txt | 24 Documentation/git-gc.txt | 3 + Documentation/git-pack-objects.txt | 4 ++ builtin/gc.c | 113 - builtin/pack-objects.c | 26 + environment.c | 2 +- git-compat-util.h | 2 +- 7 files changed, 169 insertions(+), 5 deletions(-) -- 1.9.0.40.gaa8c3ea -- 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] index-pack: do not segfault when keep_name is NULL
keep_name is used to print error messages a couple lines down. Reset
it to the real path returned by odb_pack_keep() if it's set to NULL by
caller.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
One of these moments I will make git log and friends optionally recognize
"Diff-Options:" line in commit message. Adding -U14 in this case
should help the reviewer to see how those error messages are printed.
builtin/index-pack.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a6b1c17..d95c3dc 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1283,9 +1283,10 @@ static void final(const char *final_pack_name, const
char *curr_pack_name,
if (keep_msg) {
int keep_fd, keep_msg_len = strlen(keep_msg);
- if (!keep_name)
+ if (!keep_name) {
keep_fd = odb_pack_keep(name, sizeof(name), sha1);
- else
+ keep_name = name;
+ } else
keep_fd = open(keep_name, O_RDWR|O_CREAT|O_EXCL, 0600);
if (keep_fd < 0) {
--
1.9.0.40.gaa8c3ea
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] pack-objects: support --keep
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-pack-objects.txt | 4
builtin/pack-objects.c | 26 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/git-pack-objects.txt
b/Documentation/git-pack-objects.txt
index cdab9ed..8aae3b5 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -117,6 +117,10 @@ base-name::
has a .keep file to be ignored, even if it would have
otherwise been packed.
+--keep::
+ Before moving the index into its final destination
+ create an empty .keep file for the associated pack file.
+
--incremental::
This flag causes an object already in a pack to be ignored
even if it would have otherwise been packed.
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1fb972f..46c7a57 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -57,6 +57,7 @@ static int num_preferred_base;
static struct progress *progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
+static int keep_pack;
static struct packed_git *reuse_packfile;
static uint32_t reuse_packfile_objects;
@@ -745,6 +746,23 @@ static off_t write_reused_pack(struct sha1file *f)
return reuse_packfile_offset - sizeof(struct pack_header);
}
+static void write_keep_file(const unsigned char *sha1)
+{
+ const char *msg = "pack-objects --keep\n";
+ char name[PATH_MAX];
+ int keep_fd = odb_pack_keep(name, sizeof(name), sha1);
+ if (keep_fd < 0) {
+ if (errno != EEXIST)
+ die_errno(_("cannot write keep file '%s'"),
+ name);
+ return;
+ }
+ write_or_die(keep_fd, msg, strlen(msg));
+ if (close(keep_fd) != 0)
+ die_errno(_("cannot close written keep file '%s'"),
+ name);
+}
+
static void write_pack_file(void)
{
uint32_t i = 0, j;
@@ -805,6 +823,9 @@ static void write_pack_file(void)
struct stat st;
char tmpname[PATH_MAX];
+ if (keep_pack)
+ write_keep_file(sha1);
+
/*
* Packs are runtime accessed in their mtime
* order since newer packs are more likely to contain
@@ -2609,6 +2630,8 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
N_("use a bitmap index if available to speed up
counting objects")),
OPT_BOOL(0, "write-bitmap-index", &write_bitmap_index,
N_("write a bitmap index together with the pack
index")),
+ OPT_BOOL(0, "keep", &keep_pack,
+N_("create .keep for the new pack")),
OPT_END(),
};
@@ -2672,6 +2695,9 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
if (!pack_to_stdout && thin)
die("--thin cannot be used to build an indexable pack.");
+ if (pack_to_stdout && keep_pack)
+ die("--keep cannot be used with --stdout");
+
if (keep_unreachable && unpack_unreachable)
die("--keep-unreachable and --unpack-unreachable are
incompatible.");
--
1.9.0.40.gaa8c3ea
--
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 3/4] gc --aggressive: make --depth configurable
When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06) made --depth=250 the default value, it didn't really explain the reason behind, especially the pros and cons of --depth=250. An old mail from Linus below explains it at length. Long story short, --depth=250 is a disk saver and a performance killer. Not everybody agrees on that aggressiveness. Let the user configure it. -- 8< -- From: Linus Torvalds Subject: Re: [PATCH] gc --aggressive: make it really aggressive Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST) Message-ID: Gmane-URL: http://article.gmane.org/gmane.comp.gcc.devel/94637 On Thu, 6 Dec 2007, Harvey Harrison wrote: > > 7:41:25elapsed 86%CPU Heh. And this is why you want to do it exactly *once*, and then just export the end result for others ;) > -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 > pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack But yeah, especially if you allow longer delta chains, the end result can be much smaller (and what makes the one-time repack more expensive is the window size, not the delta chain - you could make the delta chains longer with no cost overhead at packing time) HOWEVER. The longer delta chains do make it potentially much more expensive to then use old history. So there's a trade-off. And quite frankly, a delta depth of 250 is likely going to cause overflows in the delta cache (which is only 256 entries in size *and* it's a hash, so it's going to start having hash conflicts long before hitting the 250 depth limit). So when I said "--depth=250 --window=250", I chose those numbers more as an example of extremely aggressive packing, and I'm not at all sure that the end result is necessarily wonderfully usable. It's going to save disk space (and network bandwidth - the delta's will be re-used for the network protocol too!), but there are definitely downsides too, and using long delta chains may simply not be worth it in practice. (And some of it might just want to have git tuning, ie if people think that long deltas are worth it, we could easily just expand on the delta hash, at the cost of some more memory used!) That said, the good news is that working with *new* history will not be affected negatively, and if you want to be _really_ sneaky, there are ways to say "create a pack that contains the history up to a version one year ago, and be very aggressive about those old versions that we still want to have around, but do a separate pack for newer stuff using less aggressive parameters" So this is something that can be tweaked, although we don't really have any really nice interfaces for stuff like that (ie the git delta cache size is hardcoded in the sources and cannot be set in the config file, and the "pack old history more aggressively" involves some manual scripting and knowing how "git pack-objects" works rather than any nice simple command line switch). So the thing to take away from this is: - git is certainly flexible as hell - .. but to get the full power you may need to tweak things - .. happily you really only need to have one person to do the tweaking, and the tweaked end results will be available to others that do not need to know/care. And whether the difference between 320MB and 500MB is worth any really involved tweaking (considering the potential downsides), I really don't know. Only testing will tell. Linus -- 8< -- Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 5 + Documentation/git-gc.txt | 3 +++ builtin/gc.c | 8 +++- 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 79e5768..5ce7f9a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1151,6 +1151,11 @@ filter..smudge:: object to a worktree file upon checkout. See linkgit:gitattributes[5] for details. +gc.aggressiveDepth:: + The depth parameter used in the delta compression + algorithm used by 'git gc --aggressive'. This defaults + to 250. + gc.aggressiveWindow:: The window size parameter used in the delta compression algorithm used by 'git gc --aggressive'. This defaults diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index e158a3b..273c466 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -124,6 +124,9 @@ the value, the more time is spent optimizing the delta compression. See the documentation for the --window' option in linkgit:git-repack[1] for more details. This defaults to 250. +Similarly, the optional configuration variable 'gc.aggressiveDepth' +controls --depth option in linkgit:git-repack[1]. This defaults to 250. + The optional configuration variable 'gc.pruneExpire' controls how old the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago". diff --git a/builtin/gc.c b/builtin/gc.c index 63d400b..72aa912 100644 --- a/builtin/gc.c
[PATCH 1/4] environment.c: fix constness for odb_pack_keep()
Signed-off-by: Nguyễn Thái Ngọc Duy
---
environment.c | 2 +-
git-compat-util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/environment.c b/environment.c
index c3c8606..5c4815d 100644
--- a/environment.c
+++ b/environment.c
@@ -237,7 +237,7 @@ int odb_mkstemp(char *template, size_t limit, const char
*pattern)
return xmkstemp_mode(template, mode);
}
-int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1)
+int odb_pack_keep(char *name, size_t namesz, const unsigned char *sha1)
{
int fd;
diff --git a/git-compat-util.h b/git-compat-util.h
index 585ef8a..adbfb5e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -533,7 +533,7 @@ extern FILE *xfdopen(int fd, const char *mode);
extern int xmkstemp(char *template);
extern int xmkstemp_mode(char *template, int mode);
extern int odb_mkstemp(char *template, size_t limit, const char *pattern);
-extern int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1);
+extern int odb_pack_keep(char *name, size_t namesz, const unsigned char *sha1);
static inline size_t xsize_t(off_t len)
{
--
1.9.0.40.gaa8c3ea
--
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 4/4] gc --aggressive: three phase repacking
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people usually work on recent history only,
we could keep recent history more loosely packed, so that repo access
is fast most of the time while the pack file remains small.
Three more configuration variables are used to make that happen. The
first one, gc.aggressiveCommitLimits covers the old history part,
which will be tightly packed. The remaining part will be packed with
gc.lessAggresiveWindow and gc.lessAggressiveDepth. If
gc.aggressiveCommitLimits is empty, everything will be tightly packed
as before.
The repack process becomes:
- repack -adf on old history (e.g. the default --before=1.year.ago)
mark to keep that pack
- repack the second time with lessAggressive settings, the kept pack
should be left untouched.
- remove .keep file and repack the final time, reusing all deltas
This process costs more time, but produce a more effecient pack. It is
assumed that people who do "gc --aggressive" do not do this often and
do not mind if it takes a bit longer.
git.git is not a great repo to test it because its size is modest but
so are my laptop's cpu and memory, so here are the timings and pack
sizes
size time
old aggr. 36MB 5m51
new aggr. 37MB 6m13
repack -adf 48MB 1m12
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 19 +
builtin/gc.c | 109 +--
2 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5ce7f9a..47979dc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1161,6 +1161,25 @@ gc.aggressiveWindow::
algorithm used by 'git gc --aggressive'. This defaults
to 250.
+gc.aggressiveCommitLimits::
+ This one parameter to linkgit:git-rev-list[1] to select
+ commits that are repacked with gc.aggressiveDepth and
+ gc.aggressiveWindow, while the remaining commits are repacked
+ with gc.lessAggressiveDepth and gc.lessAggressiveWindow.
++
+If this is an empty string, everything will be repacked with
+gc.aggressiveWindow and gc.aggressiveDepth.
+
+gc.lessAggressiveDepth::
+ The depth parameter used in the delta compression
+ algorithm used by 'git gc --aggressive' when
+ gc.aggressiveCommitLimits is set. This defaults to 50.
+
+gc.lessAggressiveWindow::
+ The window size parameter used in the delta compression
+ algorithm used by 'git gc --aggressive' when
+ gc.aggressiveCommitLimits is set. This defaults to 250.
+
gc.auto::
When there are approximately more than this many loose
objects in the repository, `git gc --auto` will pack them.
diff --git a/builtin/gc.c b/builtin/gc.c
index 72aa912..37fc603 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -28,10 +28,14 @@ static const char * const builtin_gc_usage[] = {
static int pack_refs = 1;
static int aggressive_depth = 250;
static int aggressive_window = 250;
+static const char *aggressive_rev_list = "--before=1.year.ago";
+static int less_aggressive_depth = 50;
+static int less_aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static int detach_auto = 1;
static const char *prune_expire = "2.weeks.ago";
+static int delta_base_offset = 1;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
static struct argv_array reflog = ARGV_ARRAY_INIT;
@@ -39,10 +43,13 @@ static struct argv_array repack = ARGV_ARRAY_INIT;
static struct argv_array prune = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
+static char *keep_file;
static char *pidfile;
static void remove_pidfile(void)
{
+ if (keep_file)
+ unlink_or_warn(keep_file);
if (pidfile)
unlink(pidfile);
}
@@ -54,6 +61,63 @@ static void remove_pidfile_on_signal(int signo)
raise(signo);
}
+static void pack_old_history(int quiet)
+{
+ struct child_process pack_objects;
+ struct child_process rev_list;
+ struct argv_array av_po = ARGV_ARRAY_INIT;
+ struct argv_array av_rl = ARGV_ARRAY_INIT;
+ char sha1[41];
+
+ argv_array_pushl(&av_rl, "rev-list", "--all", "--objects",
+"--reflog", NULL);
+ argv_array_push(&av_rl, aggressive_rev_list);
+
+ memset(&rev_list, 0, sizeof(rev_list));
+ rev_list.no_stdin = 1;
+ rev_list.out = -1;
+ rev_list.git_cmd = 1;
+ rev_list.argv = av_rl.argv;
+
+ if (start_command(&rev_list))
+ die(_("gc: unable to fork git-rev-list"));
+
+ argv_array_pushl(&av_po, "pack-objects", "--keep-true-parents",
+"--honor-pack-keep", "--non-empty", "--no-reuse-delta",
+"--keep", "--local", NULL);
+ if (delta_base_offset)
+ argv_array_p
[PATCH] Rewrite the diff-no-index.c
From: 沈承恩
I am sorry for that I send this agian.Last patch I have some error.(Maybe this
time will like the previous).It is apply for GSOC
Signed-off-by: 沈承恩
---
diff-no-index.c |5 +++--
dir.h |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 8e10bff..1fb0c0f 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -3,13 +3,14 @@
* Copyright (c) 2007 by Johannes Schindelin
* Copyright (c) 2008 by Junio C Hamano
*/
-
+#define EXIT
#include "cache.h"
#include "color.h"
#include "commit.h"
#include "blob.h"
#include "tag.h"
#include "diff.h"
+#include "dir.h"
#include "diffcore.h"
#include "revision.h"
#include "log-tree.h"
@@ -25,7 +26,7 @@ static int read_directory(const char *path, struct
string_list *list)
return error("Could not open directory %s", path);
while ((e = readdir(dir)))
- if (strcmp(".", e->d_name) && strcmp("..", e->d_name))
+ if (is_dot_or_dotdot(e->d_name))
string_list_insert(list, e->d_name);
closedir(dir);
diff --git a/dir.h b/dir.h
index 55e5345..c0e45c8 100644
--- a/dir.h
+++ b/dir.h
@@ -138,8 +138,9 @@ extern int match_pathspec(const struct pathspec *pathspec,
extern int within_depth(const char *name, int namelen, int depth, int
max_depth);
extern int fill_directory(struct dir_struct *dir, const struct pathspec
*pathspec);
+#ifndef EXIT
extern int read_directory(struct dir_struct *, const char *path, int len,
const struct pathspec *pathspec);
-
+#endif
extern int is_excluded_from_list(const char *pathname, int pathlen, const char
*basename,
int *dtype, struct exclude_list *el);
struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char
*pathname, int len);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make XDF_NEED_MINIMAL default in blame.
On Sunday, March 16, 2014 01:12:01 PM Thomas Rast wrote: > Michael Andreen writes: > > > The --minimal flag is still there, but didn't want to break scripts > > depending on it. > > If I specify --no-minimal, does that turn it off again? > Yes, that works. /Michael -- 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
Loan Assistance / Credit Offer
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.com -- 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] Make XDF_NEED_MINIMAL default in blame.
Michael Andreen writes: > The --minimal flag is still there, but didn't want to break scripts > depending on it. If I specify --no-minimal, does that turn it off again? -- Thomas Rast t...@thomasrast.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
Loan Assistance / Credit Offer
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.com -- 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] add: Use struct argv_array in run_add_interactive()
Fabian Ruch writes:
> run_add_interactive() in builtin/add.c manually computes array bounds
> and allocates a static args array to build the add--interactive command
> line, which is error-prone. Use the argv-array helper functions instead.
>
> Signed-off-by: Fabian Ruch
Thanks, this is a nicely done cleanup.
> ---
> builtin/add.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 4b045ba..459208a 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -15,6 +15,7 @@
> #include "diffcore.h"
> #include "revision.h"
> #include "bulk-checkin.h"
> +#include "argv-array.h"
>
> static const char * const builtin_add_usage[] = {
> N_("git add [options] [--] ..."),
> @@ -141,23 +142,21 @@ static void refresh(int verbose, const struct pathspec
> *pathspec)
> int run_add_interactive(const char *revision, const char *patch_mode,
> const struct pathspec *pathspec)
> {
> + int status, i;
> + struct argv_array argv = ARGV_ARRAY_INIT;
>
> - args = xcalloc(sizeof(const char *), (pathspec->nr + 6));
> - ac = 0;
> - args[ac++] = "add--interactive";
> + argv_array_push(&argv, "add--interactive");
> if (patch_mode)
> - args[ac++] = patch_mode;
> + argv_array_push(&argv, patch_mode);
> if (revision)
> - args[ac++] = revision;
> - args[ac++] = "--";
> + argv_array_push(&argv, revision);
> + argv_array_push(&argv, "--");
> for (i = 0; i < pathspec->nr; i++)
> /* pass original pathspec, to be re-parsed */
> - args[ac++] = pathspec->items[i].original;
> + argv_array_push(&argv, pathspec->items[i].original);
>
> - status = run_command_v_opt(args, RUN_GIT_CMD);
> - free(args);
> + status = run_command_v_opt(argv.argv, RUN_GIT_CMD);
> + argv_array_clear(&argv);
> return status;
> }
--
Thomas Rast
t...@thomasrast.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] Rewrite diff-no-index.c:read_directory() to use is_dot_or_dotdot() and rename it to read_dir()
Akshay Aurora writes: > Forgot to mention, this is one of the microprojects for GSoC this > year. Would be great to have some feedback. > > On Fri, Mar 14, 2014 at 6:09 PM, Akshay Aurora wrote: >> I have renamed diff-no-index.c:read_directory() to read_dir() to avoid name >> collision with dir.c:read_directory() >> >> Signed-off-by: Akshay Aurora Hmm, the original mail never made it through to me, and gmane doesn't seem to have it either. What happened here? The headers suggest you used git-send-email, which should avoid these problems. Can you dig up the command and configuration you used to send it (but be careful to not post your password!)? On the patch itself: > Subject: Re: [PATCH] Rewrite diff-no-index.c:read_directory() to use > is_dot_or_dotdot() and rename it to read_dir() The subject line is very long. Aim for 50 characters, but certainly no more than 72. You are also conflating two separate things into one patch. Try to avoid doing that. Furthermore I am unconvinced that renaming a function from read_directory() to read_dir() is a win. What are you trying to improve by the rename? Renames are good if they improve clarity and/or consistency, but read_dir() just risks confusion with readdir() and I cannot see any gain in consistency that would compensate for it. >> I have renamed diff-no-index.c:read_directory() to read_dir() to avoid name >> collision with dir.c:read_directory() Please stick to the style outlined in SubmittingPatches: The body should provide a meaningful commit message, which: . explains the problem the change tries to solve, iow, what is wrong with the current code without the change. . justifies the way the change solves the problem, iow, why the result with the change is better. . alternate solutions considered but discarded, if any. Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion. Also, please wrap your commit messages at 72 characters. >> --- >> diff-no-index.c | 9 + The microproject idea said Rewrite diff-no-index.c:read_directory() to use is_dot_or_dotdot(). Try to find other sites that can use that function. Are there any others? -- Thomas Rast t...@thomasrast.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
[PATCH] Make XDF_NEED_MINIMAL default in blame.
Currently git blame has a big problem finding copies and moves when you split up a big file into smaller ones. One example in the git repository is 2cf565c, which split the documentation into smaller files. In 582aa00 XDF_NEED_MINIMAL was removed as the default for performance reasons, mainly for diff and rebase, but blame was also changed. In 059a500 the problem with blame was noticed and the flag --minimal was introduced. However this flag is not documented and it is not possible to set when using "git gui blame". Setting XDF_NEED_MINIMAL as default has a small performance impact when you run on a file with few modifications. However, if you run it on a file with a bigger number of modifications, the performance impact is small enough to not be noticable. ((2cf565c...))$ time PAGER=cat git blame -C -M Documentation/git-ls-files.txt > /dev/null real0m0.003s user0m0.002s sys 0m0.000s ((2cf565c...))$ time PAGER=cat git blame --minimal -C -M Documentation/git-ls-files.txt > /dev/null real0m0.010s user0m0.009s sys 0m0.000s ((2cf565c...))$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m0.010s user0m0.010s sys 0m0.000s ((2cf565c...))$ time PAGER=cat git blame --minimal -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m0.028s user0m0.027s sys 0m0.000s (master)$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.338s user0m2.283s sys 0m0.056s (master)$ time PAGER=cat git blame --minimal -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.355s user0m2.285s sys 0m0.069s (master)$ time PAGER=cat git blame -C -M cache.h > /dev/null real0m1.755s user0m1.730s sys 0m0.024s (master)$ time PAGER=cat git blame --minimal -C -M cache.h > /dev/null real0m1.785s user0m1.770s sys 0m0.014s (master)$ time PAGER=cat git blame -C -C -C -M cache.h > /dev/null real0m31.515s user0m30.810s sys 0m0.684s (master)$ time PAGER=cat git blame --minimal -C -C -C -M cache.h > /dev/null real0m31.504s user0m30.885s sys 0m0.598s Signed-off-by: Michael Andreen --- Additional measurements attached, the variation is fairly small. The --minimal flag is still there, but didn't want to break scripts depending on it. builtin/blame.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/blame.c b/builtin/blame.c index e5b5d71..0e7ebd0 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -42,7 +42,7 @@ static int show_root; static int reverse; static int blank_boundary; static int incremental; -static int xdl_opts; +static int xdl_opts = XDF_NEED_MINIMAL; static int abbrev = -1; static int no_whole_file_rename; -- 1.8.3.2 (master)$ time PAGER=cat git blame -C -M cache.h > /dev/null real0m1.767s user0m1.747s sys 0m0.018s (master)$ time PAGER=cat git blame -C -M cache.h > /dev/null real0m1.755s user0m1.730s sys 0m0.024s (master)$ time PAGER=cat git blame -C -M cache.h > /dev/null real0m1.784s user0m1.757s sys 0m0.025s (master)$ time PAGER=cat git blame --minimal -C -M cache.h > /dev/null real0m1.813s user0m1.797s sys 0m0.014s (master)$ time PAGER=cat git blame --minimal -C -M cache.h > /dev/null real0m1.790s user0m1.770s sys 0m0.018s (master)$ time PAGER=cat git blame --minimal -C -M cache.h > /dev/null real0m1.785s user0m1.770s sys 0m0.014s (master)$ time PAGER=cat git blame --minimal -C -M cache.h > /dev/null real0m1.794s user0m1.770s sys 0m0.022s (master)$ time PAGER=cat git blame -C -C -C -M cache.h > /dev/null real0m31.515s user0m30.810s sys 0m0.684s (master)$ time PAGER=cat git blame -C -C -C -M cache.h > /dev/null real0m31.594s user0m30.879s sys 0m0.695s (master)$ time PAGER=cat git blame --minimal -C -C -C -M cache.h > /dev/null real0m31.666s user0m31.054s sys 0m0.591s (master)$ time PAGER=cat git blame --minimal -C -C -C -M cache.h > /dev/null real0m31.504s user0m30.885s sys 0m0.598s (master)$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.355s user0m2.319s sys 0m0.035s (master)$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.352s user0m2.292s sys 0m0.059s (master)$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.354s user0m2.312s sys 0m0.040s (master)$ time PAGER=cat git blame -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.338s user0m2.283s sys 0m0.056s (master)$ time PAGER=cat git blame --minimal -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.376s user0m2.302s sys 0m0.071s (master)$ time PAGER=cat git blame --minimal -C -C -C -M Documentation/git-ls-files.txt > /dev/null real0m2.362s user0m2.312s sys 0m0.049s (mast
[PATCH] index-pack: do not segfault when keep_name is NULL
keep_name is used to print error messages a couple lines down. Reset
it to the real path returned by odb_pack_keep() if it's set to NULL by
caller.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
One of these moments I will make git log and friends optionally recognize
"Diff-Options:" line in commit message. Adding -U14 in this case
should help the reviewer to see how those error messages are printed.
builtin/index-pack.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a6b1c17..d95c3dc 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1283,9 +1283,10 @@ static void final(const char *final_pack_name, const
char *curr_pack_name,
if (keep_msg) {
int keep_fd, keep_msg_len = strlen(keep_msg);
- if (!keep_name)
+ if (!keep_name) {
keep_fd = odb_pack_keep(name, sizeof(name), sha1);
- else
+ keep_name = name;
+ } else
keep_fd = open(keep_name, O_RDWR|O_CREAT|O_EXCL, 0600);
if (keep_fd < 0) {
--
1.9.0.40.gaa8c3ea
--
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 sending messages to stderr on MacOS 10.8
On Sun, Mar 16, 2014 at 4:15 PM, Thomas Robitaille
wrote:
> I am using git version 1.8.4.2 installed on Mac using MacPorts. When
> e.g. cloning a repository, the cloning message is being sent to
> stderr, but I think it should be sent to stdout:
>
> In [8]: p = subprocess.Popen('git clone
> git://github.com/embray/astropy'.split(), stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
>
> In [9]: p.stdout.read()
> Out[9]: ''
>
> In [10]: p.stderr.read()
> Out[10]: "Cloning into 'astropy'...\n"
>
> Is this expected behavior, or a bug?
It's expected behavior. See 68b939b (clone: send diagnostic messages
to stderr - 2013-09-18) for details.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git sending messages to stderr on MacOS 10.8
I am using git version 1.8.4.2 installed on Mac using MacPorts. When
e.g. cloning a repository, the cloning message is being sent to
stderr, but I think it should be sent to stdout:
In [8]: p = subprocess.Popen('git clone
git://github.com/embray/astropy'.split(), stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
In [9]: p.stdout.read()
Out[9]: ''
In [10]: p.stderr.read()
Out[10]: "Cloning into 'astropy'...\n"
Is this expected behavior, or a bug?
Thanks,
Tom
--
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] Documentation/git-am: Document supported --patch-format options
On 11/03/14 16:51, Chris Packham wrote: > The --patch-format option has been supported for a while but it is not > mentioned in the man page and the short help cannot tell the user what > the supported formats are. Add the option to the man page along with the > supported options. > > Signed-off-by: Chris Packham > --- > I've not bothered to actually explain what the options mean. I'm not > sure if readers will care aside from just trying them until one works > (that's all I did when I had a patch that failed detection). > > Documentation/git-am.txt | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt > index 54d8461..76bd359 100644 > --- a/Documentation/git-am.txt > +++ b/Documentation/git-am.txt > @@ -12,9 +12,9 @@ SYNOPSIS > 'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] >[--3way] [--interactive] [--committer-date-is-author-date] >[--ignore-date] [--ignore-space-change | --ignore-whitespace] > - [--whitespace=] [-C] [-p] [--directory=] > - [--exclude=] [--include=] [--reject] [-q | --quiet] > - [--[no-]scissors] > + [--whitespace=] [-C] [-p] [--patch-format=] > + [--directory=] [--exclude=] [--include=] > + [--reject] [-q | --quiet] [--[no-]scissors] >[( | )...] > 'git am' (--continue | --skip | --abort) > > @@ -97,6 +97,12 @@ default. You can use `--no-utf8` to override this. > program that applies > the patch. > > +--patch-format:: > + By default the command will try to detect the patch format > + automatically. This option allows the user to bypass the automatic > + detection and specify the patch format that the patch(es) should be > + intepreted as. Valid formats are mbox, stgit, stgit-series and hg. > + > -i:: > --interactive:: > Run interactively. > Ping? Actually now that I have the patch in a MUA I see the a simple s/intepreted/interpreted/ fixup is required. -- 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: difftool sends malformed path to exernal tool on Windows
On Fri, Mar 7, 2014 at 8:07 AM, Paul Lotz wrote:
> David,
>
> I investigated further and found that \"$LOCAL\" \"$REMOTE\" return the
> remote and local files (reversed). (One can easily see this in my 2/28
> e-mail.) Reversing these (\"$REMOTE\" \"$LOCAL\") does indeed reverse the
> output. It is easy to work around this issue, but how can this be?
>
> Paul
It's probably working as intended.
The $LOCAL and $REMOTE names come from "git mergetool", where they
have better defined semantics.
In the context of a diff, where we're really comparing "A" and "B"
they have a little less meaning, but the behavior is well-defined.
When you modify a file locally, the default behavior for "git diff" is
to compare your working tree against the index.
The diff will show the changes that will permute the index's copy into
the the worktree's copy. In a sense, your modifications are the
"remote" thing that is being compared against.
That's why you see a temporary file for $LOCAL ("A") and your
worktree's file for $REMOTE (B).
If compare two other things, e.g. "git difftool HEAD~3 HEAD~" then
$LOCAL is HEAD~3 and $REMOTE is HEAD~, and they'll all be temporary
files.
One analogy is that the $LOCAL thing is the starting point and the
$REMOTE thing is what was modified (by the merge) if you think of it
from the merging perspective.
Specific tools (e.g. lvcompare) may need the arguments to be specified
in a specific order for them to make sense, so it's perfectly
acceptable for specific tools to require that $LOCAL and $REMOTE are
swapped.
BTW.. we went through a lot of back-and-forth getting the difftool
setup correct for lvcompare. In the Git source tree there's a
mergetools/ directory where all of the built-in diff/merge tools are
defined. Do you think you might be able to contribute a scriptlet for
lvcompare so that it is natively supported? That'll save future poor
souls from needing to rediscover the correct recipe for getting
lvcompare working with difftool. Just a thought.
cheers,
--
David
--
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
