Re: Google Summer of Code 2013 (GSoC13)
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). Hold on a second. I'm not remembering such a grim outcome with 100% failure from prior summers of code as you're describing. Before I start beating myself up, I guess I'd like a little more information --- is there some specific project or statistic that you're thinking of that brings you to that conclusion? In retrospect, I might have been unnecessarily harsh there. One of the main measures of a mentor's success, in my opinion, is having his student stick around after the Summer of Code: the mentor is the student's primary link to the community. There have been 4~5 students every year, times 6 years (is that how long we've been participating?). How many of those students have felt part of the community? -- 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: Google Summer of Code 2013 (GSoC13)
Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: ... I think the real issue is everybody in the GSoC mentor candidate pool grossly underestimates the scope of suggested projects, does not encourage students to send early drafts to the public from the beginning, and perhaps overestimates the ability of total beginners. After seeing my index-thing is too big in scope warning repeatedly ignored for the last year's GSoC, I am not very hopeful unless the attitude towards GSoC and its students drastically changes on our mentors' end. The short undiplomatic version of that is that our mentors suck (I'm not pointing fingers, but that's what I infer from failing projects). I was conflating between people who add suggested project and who act as mentors. I do not think mentors are primarily responsible for bad suggested projects. Why do mentors pick badly sketched-out projects to mentor? They're free to pick anything they want/ propose what they want. Our mentors may be wonderful but I do not have enough evidence to judge either way. They are mostly student-facing and I as a bystander to GSoC process didn't see much of their involvement in their students' work---maybe that is how it is supposed to work, maybe not. The only failing of them observable from my point of view was that we repeatedly saw the initial round of patches come very late. Ideally, the initial round of patches should come in well before the GSoC even starts, I think (the initial round might just be doing some minor surrounding work though). I propose that we have one thread for every proposal where we can all discuss the implementation outline- this will serve as authoritative source of information for students, and for picking mentors (the people who contribute most to the discussion). Students should be matched with mentors on an individual basis. You are being unreasonable and/or unrealistic. A topic that needs a large discussion thread to pre-discuss design and outline by many existing members of community and mentor candidates is a sure sign that the topic is too big for a beginner. A topic that needs only a small enough discussion thread on the other hand will come to a polished conclusion before even the student shows up. I that case, projects like inotify support that Duy suggested in a nearby thread are not realistic candidates. No, I wouldn't like huge discussion threads on each proposal either: but a ~10 email thread with everyone's thoughts on it would be useful, I think. If the size of the thread exceeds a certain threshold, the project is deemed un-doable automatically. This is exactly why I suggested doable as a private, at most two-weekend hack by an experienced as a quick and dirty way to measure the size of a project. Yes, that's a good measure. -- 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] shell-prompt: clean up nested if-then
On 19/02/13 00:07, Junio C Hamano wrote: I think you are misreading a suggestion that is somewhat misguided (yes [ condition another ] does not make sense, but that is not applicable to test conditon test another); ignore it. It is fine to write test condition test another and that works portably to even pre-posix systems. (that's like doing ls file rm file ) But the existing code the patch touches favors [] over test consistently; that alone is a good reason to stick with [] in _this_ script, even though it is against Git's overall shell script style. I suppose it would be fine if a patch was sent to update the entire git-prompt.sh code to be more in line with the Git shell script style... My original gripe was just with doing it in one place while leaving all the others unchanged. It makes for messy reading and leads to confusion. Cheers Simon -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes:
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing. Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?
In retrospect, I might have been unnecessarily harsh there.
One of the main measures of a mentor's success, in my opinion, is
having his student stick around after the Summer of Code: the mentor
is the student's primary link to the community. There have been 4~5
students every year, times 6 years (is that how long we've been
participating?). How many of those students have felt part of the
community?
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
--
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: Google Summer of Code 2013 (GSoC13)
Jeff King wrote: On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote: Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? I think you are spot-on. Those are the things that students need to learn to do, and what mentors should be pushing them towards. But it seems like we have the same problems with it year after year, and I know mentors have worked on it. I'm not sure where the problem is. I essentially have a couple of suggestions: - Be more thorough about discussing proposals; pick mentors from those who are deeply involved in the discussion, and are interested in the student. - Increase the visibility of every GSoC project in the community. Like I suggested earlier, a set of GSoC branches in-tree would be a great start: it's easy to go through the `log`, and tell if the student has been idle for a while. We can put up links to the GitHub graphs for each of these branches. I very much agree with you here. One problem is that those smaller projects often do not sound as grand or as interesting, and so students do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. True. I think we can bear some of the blame in the proposal writing. But if you look at the applications each year, they tend to cluster around one or two projects, and most projects get no hits at all. It could be because they're badly written. But I think it is also that they are not in areas that are as flashy (and the flashiness often correlates with complexity). We need to collaborate on proposal writing, I think (which is why I suggested one-thread-per-proposal in a different email). In the past, it has mostly been one person writing the entire thing. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. I'd be totally fine with that. You'd need to pick a static generator framework (I don't think it is a good idea for everybody to be writing raw html). I suspect kernel.org would be happy to host the static pages, but if not, GitHub can pick up the hosting tab (and we could probably do it as a subdomain under git-scm.com, too, if people want). Ofcourse. Nobody wants to write raw HTML. Additionally, I'd love it if we could post new posts via email, since we already have the habit of writing emails. -- 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: [RFC/PATCH] Introduce branch.name.pushremote
Blind wrote: If I understand correctly, in your scenario the branches with branch.name.pushremote will be still included in the $git push remote --all? Yes, this is correct. Are you considering some way to exclude a branch from push --all (branch.name.push = always, explicit, never... for example)? No. I don't see why push.default is limiting. Or maybe, if the branch is already marked as special with branch.name.pushremote, then it could be logical to push it only when is explicitly specified on the command line (excluded from --all)? Huh? Why would I treat this as a special case? -- 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: Is this a bug?
Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m #ifdef ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? Thanks! David Wade Analyst, Seismic Imaging Development ITC SUB RES Statoil ASA Mobile: +47 97572157 Email: da...@statoil.com Visitor address: Vassbotnen 23, Forus, Norway Incorporation number: NO 923 609 016 MVA www.statoil.com Please consider the environment before printing this e-mail. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] User manual updates
On Mon, Feb 18, 2013 at 07:27:50AM -0500, W. Trevor King wrote: On Mon, Feb 18, 2013 at 12:56:07AM -0800, Junio C Hamano wrote: I've taken the following to 'maint'… Should I rebase v4 onto maint so I don't accidentally collide with any of the previous patches which have already been merged there? I tried this, but the backtick patch shouldn't move to maint due to: On Sun, Feb 10, 2013 at 05:36:32PM -0500, W. Trevor King wrote: I based my changes on `master` to avoid colliding with 2de9b711 (Documentation: the name of the system is 'Git', not 'git', 2013-01-21), but if you shifted them already I suppose you've fixed any conflicts ;). I'll drop it for now, and revive it after the next release syncs master and maint. I've rebased the remaining patches onto `maint`. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Is this a bug?
On 02/19/2013 10:32 AM, David Wade wrote: Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m #ifdef ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? Lines starting with a hash sign are considered comments by git commit. If you fire it up without '-m' you'll see that git puts all its own notes about the commit in commented-out lines. While empty commit messages aren't really unacceptable by git's model, they're considered almost certainly user errors. I expect the -m flag being present when running 'git commit' causes the check for empty message to be skipped, which isn't the case when amending the commit. Btw, when I write messages probably similar to the one you just did, I tend to write: Use compat-layer __builtin_clz() #ifndef __GNUC__ precisely to avoid this issue. It also puts the imperative first, which I find makes for smoother reading. Putting the condition first screams for a comma and a slight stagger in reading flow, like so: Unless built with gcc, use compat-layer __builtin_clz() -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
On Tue, Feb 19, 2013 at 10:32 AM, David Wade da...@statoil.com wrote: Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m #ifdef ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? The problem is that when doing interactive editing of messages (like 'git commit --amend' does), git considers '#' as a comment-character. You can disable this by using the --cleanup=verbatim switch (or some other suiting cleanup-setting, see 'git help commit'). -- 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: inotify to minimize stat() calls
Karsten Blees wrote:
Am 11.02.2013 04:53, schrieb Duy Nguyen:
On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Karsten Blees has done something similar-ish on Windows, and he posted
the results here:
https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
The new hashtable implementation in fscache [1] supports O(1) removal and has
no mingw dependencies - might come in handy for anyone trying to implement an
inotify daemon.
[1] https://github.com/kblees/git/commit/f7eb85c2
Thanks! I'm cherry-picking this. Why didn't you propose replacing
hash.{c,h} with this in git.git though?
I also seem to remember he doing a ReadDirectoryChangesW version, but
I don't remember what happened with that.
Thanks. I came across that but did not remember. For one thing, we
know the inotify alternative for Windows: ReadDirectoryChangesW.
I dropped ReadDirectoryChangesW because maintaining a 'live' file system
cache became more and more complicated. For example, according to MSDN docs,
ReadDirectoryChangesW *may* report short DOS 8.3 names (i.e. PROGRA~1
instead of Program Files), so a correct and fast cache implementation would
have to be indexed by long *and* short names...
Another problem was that the 'live' cache had quite negative performance
impact on mutating git commands (checkout, reset...). An inotify daemon
running as a background process (not in-process as fscache) will probably
affect everyone that modifies the working copy, e.g. running 'make' or the
test-suite. This should be considered in the design.
Yes, an external daemon would report creation of *.o files, from the
compile, for instance. We need a way for it to be filtered at the
daemon itself, so git isn't burdened with the filtering.
--
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: inotify to minimize stat() calls
Robert Zeh wrote: On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen pclo...@gmail.com wrote: On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh robert.allan@gmail.com wrote: On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano gits...@pobox.com wrote: Ramkumar Ramachandra artag...@gmail.com writes: This is much better than Junio's suggestion to study possible implementations on all platforms and designing a generic daemon/ communication channel. That's no weekend project. It appears that you misunderstood what I wrote. That was not here is a design; I want it in my system. Go implemment it. It was If somebody wants to discuss it but does not know where to begin, doing a small experiment like this and reporting how well it worked here may be one way to do so., nothing more. What if instead of communicating over a socket, the daemon dumped a file containing all of the lstat information after git wrote a file? By definition the daemon should know about file writes. There would be no network communication, which I think would make things more secure. It would simplify the rendezvous by insisting on well known locations in $GIT_DIR. We need some sort of interactive communication to the daemon anyway, to validate that the information is uptodate. Assume that a user makes some changes to his worktree before starting the daemon, git needs to know that what the daemon provides does not represent a complete file-change picture and it better refreshes the index the old way once, then trust the daemon. I think we could solve that by storing a session id, provided by the daemon, in .git/index. If the session id is not present (or does not match what the current daemon gives), refresh the old way. After refreshing, it may ask the daemon for new session id and store it. Next time if the session id is still valid, trust the daemon's data. This session id should be different every time the daemon restarts for this to work. I think we could do this without interactive communication, if we did the following: 1) The Daemon waits to see $GIT_DIR/lstat_request, and atomically writes out $GIT_DIR/lstat_cache. By atomically I mean that it writes things out to a temporary file, and then does a rename. 2) The client erases $GIT_DIR/lstat_cache, and writes $GIT_DIR/lstat_request I think this is better than socket based communication because there are fewer places to check for failures. My main problem with file-based solutions is this: how will the daemon accumulate inotify change events over time, and report it in a batch to a git application that is spawned? Will it append to the .git/inotify_changes file everytime there's a change? Wouldn't you prefer to accumulate the events in-memory and report it over a socket upon explicit request, to minimize IO? -- 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
Feature idea : notes to track status of a commit, which remotes it is shared to
Hi, This is my first time on this list (and by the way, I'm not subscribed, so please Cc me to the replies). I have an idea that could be useful to make rewriting history safer and easier to new users (I'm training some of them). I thought I could share this idea, but perhaps someone already thought about it. And I'm not providing code. The idea is to basically track automatically (in notes, either in the notes namespace or in another namespace) which repository/remote contains a commit. When doing git log, we'd see lines with each commit, something like: commit b044e6d0f1a1782820b052348ab0db314e2db3ca Author: Myself myself@localhost.localdomain Date: Tue Nov 20 16:46:38 2012 +0100 This is the commit description Published on: origin g...@git.host.com:pub/repo.git Then, we could have all the history rewriting commands (such as rebase or pull --rebase) die when rewriting commits that are already published anywhere. We could make an exception for a --force/-f flag or configuration option, or commits published in another local repository owned by the same user. In most setups, it could be useful to tell users they can safely rebase without worrying about published commits as Git is tracking it for them. Of course this is not an absolute security, but it's a good start. What do you think? Mildred -- 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: Proposal: sharing .git/config
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only certain bits of the config, as
otherwise there are big security headaches.
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break pretty much every script that uses git-diff?
--
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
[PATCH v4 0/3] User manual updates
From: W. Trevor King wk...@tremily.us Changes since v3 (v3 numbering): * 1: user-manual: Use 'remote add' to setup push URLs - Dropped (graduated into 'maint', e9b4908) * 2: user-manual: Reorganize the reroll sections, adding 'git rebase -i' - Added some comments giving example uses of 'commit --amend'. This should make the section less lonely. - Fix s/preferred/needed/ - Call interactive rebase commands instructions and steps - Reworded interactive rebase return-to-shell description following Junio's suggestions. * 3: user-manual: Give 'git push -f' as an alternative to +master - Dropped (graduated into 'maint', d1471e0) * 4: user-manual: Mention 'git remote add' for remote branch config - Dropped (graduated into 'maint', 47adb8a) * 5: user-manual: Standardize backtick quoting - Temporarily dropped (not rebased onto maint, due to conflicts with 2de9b71 (Documentation: the name of the system is 'Git', not 'git', 2013-01-21)) * 6: user-manual: Use 'git config --global user.*' for setup - Dropped (graduated into 'maint', 632cc3e) * 7: user-manual: Use request-pull to generate please pull text - Reworded request-pull introduction based on Junio's suggestions. * 8: user-manual: Flesh out uncommitted changes and submodule updates - Adopt Junio's “did not commit” → “have uncommitted changes” rephrasing. * 9: user-manual: Use -o latest.tar.gz to create a gzipped tarball - Dropped (graduated into 'maint', 7ed1690) W. Trevor King (3): user-manual: Reorganize the reroll sections, adding 'git rebase -i' user-manual: Use request-pull to generate please pull text user-manual: Flesh out uncommitted changes and submodule updates Documentation/user-manual.txt | 133 -- 1 file changed, 77 insertions(+), 56 deletions(-) -- 1.8.1.336.g94702dd -- 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 v4 2/3] user-manual: Use request-pull to generate please pull text
From: W. Trevor King wk...@tremily.us Less work and more error checking (e.g. does a merge base exist?). Add an explicit push before request-pull to satisfy request-pull, which checks to make sure the references are publically available. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index a4dbd9e..3aab106 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2305,17 +2305,13 @@ branch and then merge into each of the test and release branches. For these changes, just apply directly to the release branch, and then merge that into the test branch. -To create diffstat and shortlog summaries of changes to include in a please -pull request to Linus you can use: +After pushing your work to `mytree`, you can use +linkgit:git-request-pull[1] to prepare a please pull request message +to send to Linus: - -$ git diff --stat origin..release -- - -and - -- -$ git log -p origin..release | git shortlog +$ git push mytree +$ git request-pull origin mytree release - Here are some of the scripts that simplify all this even further. -- 1.8.1.336.g94702dd -- 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 v4 3/3] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King wk...@tremily.us If you try and update a submodule with a dirty working directory, you get an error message like: $ git submodule update error: Your local changes to the following files would be overwritten by checkout: ... Please, commit your changes or stash them before you can switch branches. Aborting ... Mention this in the submodule notes. The previous phrase was short enough that I originally thought it might have been referring to the reflog note (obviously, uncommitted changes will not show up in the reflog either ;). Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 3aab106..df7524a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3739,7 +3739,9 @@ module a NOTE: The changes are still visible in the submodule's reflog. -This is not the case if you did not commit your changes. +If you have uncommitted changes in your submodule working tree, `git +submodule update` will not overwrite them. Instead, you get the usual +warning about not being able switch from a dirty branch. [[low-level-operations]] Low-level git operations -- 1.8.1.336.g94702dd -- 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 v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: W. Trevor King wk...@tremily.us I think this interface is often more convenient than extended cherry picking or using 'git format-patch'. In fact, I removed the cherry-pick section entirely. The entry-level suggestions for rerolling are now: 1. git commit --amend 2. git format-patch origin git reset --hard origin ...edit and reorder patches... git am *.patch 3. git rebase -i origin Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 115 +- 1 file changed, 69 insertions(+), 46 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 52c8523..a4dbd9e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2556,6 +2556,12 @@ return mywork to the state it had before you started the rebase: $ git rebase --abort - +If you need to reorder or edit a number of commits in a branch, it may +be easier to use `git rebase -i`, which allows you to reorder and +squash commits, as well as marking them for individual editing during +the rebase. See interactive-rebase for details, and +reordering-patch-series for alternatives. + [[rewriting-one-commit]] Rewriting a single commit - @@ -2569,72 +2575,89 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. +This is useful for fixing typos in your last commit, or for adjusting +the patch contents of a poorly staged commit. -You can also use a combination of this and linkgit:git-rebase[1] to -replace a commit further back in your history and recreate the -intervening changes on top of it. First, tag the problematic commit -with - -- -$ git tag bad mywork~5 -- +If you need to amend commits from deeper in your history, you should +use interactive-rebase,interactive rebase's `edit` instruction. -(Either gitk or `git log` may be useful for finding the commit.) +[[reordering-patch-series]] +Reordering or selecting from a patch series +--- -Then check out that commit, edit it, and rebase the rest of the series -on top of it (note that we could check out the commit on a temporary -branch, but instead we're using a detached-head,detached head): +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - -$ git checkout bad -$ # make changes here and update the index -$ git commit --amend -$ git rebase --onto HEAD bad mywork +$ git format-patch origin +$ git reset --hard origin - -When you're done, you'll be left with mywork checked out, with the top -patches on mywork reapplied on top of your modified commit. You can -then clean up with +Then modify, reorder, or eliminate patches as needed before applying +them again with linkgit:git-am[1]: - -$ git tag -d bad +$ git am *.patch - -Note that the immutable nature of git history means that you haven't really -modified existing commits; instead, you have replaced the old commits with -new commits having new object names. +[[interactive-rebase]] +Using interactive rebases +- -[[reordering-patch-series]] -Reordering or selecting from a patch series +You can also edit a patch series with an interactive rebase. This is +the same as reordering-patch-series,reordering a patch series using +`format-patch`, so use whichever interface you like best. -Given one existing commit, the linkgit:git-cherry-pick[1] command -allows you to apply the change introduced by that commit and create a -new commit that records it. So, for example, if mywork points to a -series of patches on top of origin, you might do something like: +Rebase your current HEAD on the last commit you want to retain as-is. +For example, if you want to reorder the last 5 commits, use: - -$ git checkout -b mywork-new origin -$ gitk origin..mywork +$ git rebase -i HEAD~5 - -and browse through the list of patches in the mywork branch using gitk, -applying them (possibly in a different order) to mywork-new using -cherry-pick, and possibly modifying them as you go using `git commit --amend`. -The linkgit:git-gui[1] command may also help as it allows you to -individually select diff hunks for inclusion in the index (by -right-clicking on the diff hunk and choosing Stage Hunk for Commit). - -Another technique is to
Re: Feature idea : notes to track status of a commit, which remotes it is shared to
Mildred Ki'Lya mildred...@mildred.fr writes:
The idea is to basically track automatically (in notes, either in the
notes namespace or in another namespace) which repository/remote
contains a commit. When doing git log, we'd see lines with each
commit, something like:
commit b044e6d0f1a1782820b052348ab0db314e2db3ca
Author: Myself myself@localhost.localdomain
Date: Tue Nov 20 16:46:38 2012 +0100
This is the commit description
Published on:
origin
g...@git.host.com:pub/repo.git
The problem here is that doing this in notes is unreliable: you'd have
to identify all places where the set of publishes can change for any
commit, and update them there.
It's much easier, if a bit slower, to just run
git branch -r --contains $commit
--
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: Proposal: sharing .git/config
Thomas Rast wrote: Ramkumar Ramachandra artag...@gmail.com writes: I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. Note that you need to carefully pick only certain bits of the config, as otherwise there are big security headaches. Right. So, we can just start with remotes for the moment? Ideally, there should be a way to specify which configuration options to publish. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) Because that would break pretty much every script that uses git-diff? diff.c already makes a differentiation between git_diff_ui_config() and git_diff_basic_config(); there are configuration options that should only be applied when the command is called interactively. -- 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] Feature idea : notes to track status of a commit, which remotes it is shared to
On Tue, Feb 19, 2013 at 10:38:09AM +0100, Mildred Ki'Lya wrote: Then, we could have all the history rewriting commands (such as rebase or pull --rebase) die when rewriting commits that are already published anywhere. We could make an exception for a --force/-f flag or configuration option, or commits published in another local repository owned by the same user. You might want to look into extending the sample pre-rebase hook, which prevents topic branches that are already merged to 'next' branch from getting rebased. You'd just have to loop over all remote references instead of only checking the local 'next' branch. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Feature idea : notes to track status of a commit, which remotes it is shared to
On Tue, Feb 19, 2013 at 11:13:19AM +0100, Thomas Rast wrote: It's much easier, if a bit slower, to just run git branch -r --contains $commit Ah, this would be better than looping in your hook ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? If you check out the config file, then include.path should work. You could add include.ref to point to a ref, but you need to deal with the attached security implications. This has been proposed before (and turned down, I think). -- 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
Re: Proposal: sharing .git/config
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break pretty much every script that uses git-diff?
diff.c already makes a differentiation between git_diff_ui_config()
and git_diff_basic_config(); there are configuration options that
should only be applied when the command is called interactively.
It still breaks every other use of diff unless you make the diff output
depend on whether the user runs directly at the terminal (possibly using
git's own paging).
For example, if you just say something like 'git diff file' for
inclusion in an email, you expect that to be a git-apply compatible
diff.
--
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/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
Nguyễn Thái Ngọc Duy pclouds at gmail.com writes: I just realized that many of my big repos are still on index v2 while v4 should reduce its size significantly (3.8M - 2.9M for linux-2.6 and 25M - 14M for webkit, for example). I wanted to propose index v4 as the new default version, because I guess that not many people outside git at vger are aware of it, but perhaps this approach is less drastic. It only suggest index v4 when the index size after clone hits 512K limit. Is V4 really recommended for general use? Default seems to be V3 and all I found in the docs is the coresponding release not describing V4 as experimental. (I have repos with index files 40MiB (!) which will shrink to approx. 20MiB with V4 so using V4 would be an interessting option for me.) --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
On Tue, Feb 19, 2013 at 5:45 PM, Thomas Ackermann th.ac...@arcor.de wrote: Nguyễn Thái Ngọc Duy pclouds at gmail.com writes: I just realized that many of my big repos are still on index v2 while v4 should reduce its size significantly (3.8M - 2.9M for linux-2.6 and 25M - 14M for webkit, for example). I wanted to propose index v4 as the new default version, because I guess that not many people outside git at vger are aware of it, but perhaps this approach is less drastic. It only suggest index v4 when the index size after clone hits 512K limit. Is V4 really recommended for general use? Default seems to be V3 and all I found in the docs is the coresponding release not describing V4 as experimental. (I have repos with index files 40MiB (!) which will shrink to approx. 20MiB with V4 so using V4 would be an interessting option for me.) The default could be either v2 or v3, depending on whether you use some extra features. v4 is basically v3 with pathname compression. Yes, I think it's ok for general use. -- 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
Re: Is this a bug?
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Tue, Feb 19, 2013 at 10:32 AM, David Wade da...@statoil.com wrote: Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m #ifdef ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? The problem is that when doing interactive editing of messages (like 'git commit --amend' does), git considers '#' as a comment-character. You can disable this by using the --cleanup=verbatim switch (or some other suiting cleanup-setting, see 'git help commit'). Nobody is always conscious about the leading # in commit message to do that. I once edited a commit message and the auto-wrap feature put '#' at the beginning of the line. I saved and went on without noticing one line was lost until much later :( Perhaps we should change the comment signature a bit to reduce accidents, like only recognize '#' lines as comments after a special line like # this is not a comment ### START OF COMMENT ### # this is a comment -- 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/githooks: Explain pre-rebase parameters
From: W. Trevor King wk...@tremily.us
Descriptions borrowed from templates/hooks--pre-rebase.sample.
Signed-off-by: W. Trevor King wk...@tremily.us
---
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase ${1+$@}
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
$ man bash | grep '\${.*[+]'
(${BASH_SOURCE[$i+1]}) where ${FUNCNAME[$i]} was called (or
${BASH_SOURCE[$i+1]}.
${BASH_SOURCE[$i+1]} at line number ${BASH_LINENO[$i]}. The
${parameter:+word}
In my local tests, it seems equivalent to $@.
Also, it appears that the `git-rebase--*.sh` handlers don't use the
pre-rebase hook. Is this intentional?
Cheers,
Trevor
Documentation/githooks.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..bc837c6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -140,9 +140,10 @@ the outcome of 'git commit'.
pre-rebase
~~
-This hook is called by 'git rebase' and can be used to prevent a branch
-from getting rebased.
-
+This hook is called by 'git rebase' and can be used to prevent a
+branch from getting rebased. The hook takes two parameters: the
+upstream the series was forked from and the branch being rebased. The
+second parameter will be empty when rebasing the current branch.
post-checkout
~
--
1.8.1.336.g94702dd
--
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: [RFC/PATCH] Introduce branch.name.pushremote
2013/2/19 Ramkumar Ramachandra: No. I don't see why push.default is limiting. I just want to find a way to exclude a branch (or infact a group of branches) from $git push --all. so when I read your thing, I thought for a second that it could be a possibility... But seems its not the case. ... or branch.name.pushremote can support some kind of a none value? Blind. -- 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] Bugfix: undefined htmldir in config.mak.autogen
Html documents will be installed to root dir (/) no matter what prefix is set, if run these commands before `make` and `make install-html`: $ make configure $ ./configure --prefix=PREFIX After the installation, all the html documents will copy to rootdir (/), and: $ git --html-path PREFIX $ git help -w something fatal: 'PREFIX': not a documentation directory. This is because the variable htmldir points to a undefined variable $(docdir) in file config.mak.autogen, which is generated by running `./configure`. This bug comes from commit fc1c541 (Honor configure's htmldir switch), since v1.8.1.3-537-g1d321. Add the required two variables PACKAGE_TARNAME and docdir to file config.mak.in will resolve this problem. Signed-off-by: Jiang Xin worldhello@gmail.com --- config.mak.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mak.in b/config.mak.in index d7c49..fa02bd 100644 --- a/config.mak.in +++ b/config.mak.in @@ -8,6 +8,7 @@ LDFLAGS = @LDFLAGS@ AR = @AR@ TAR = @TAR@ DIFF = @DIFF@ +PACKAGE_TARNAME = @PACKAGE_TARNAME@ #INSTALL = @INSTALL@ # needs install-sh or install.sh in sources prefix = @prefix@ @@ -17,6 +18,7 @@ gitexecdir = @libexecdir@/git-core datarootdir = @datarootdir@ template_dir = @datadir@/git-core/templates sysconfdir = @sysconfdir@ +docdir = @docdir@ mandir = @mandir@ htmldir = @htmldir@ -- 1.8.2.rc0.18.g63af42f.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: [RFC/PATCH] Introduce branch.name.pushremote
Blind wrote: 2013/2/19 Ramkumar Ramachandra: No. I don't see why push.default is limiting. I just want to find a way to exclude a branch (or infact a group of branches) from $git push --all. so when I read your thing, I thought for a second that it could be a possibility... But seems its not the case. What is your usecase? If you have a local branch with the same name as on the remote, why wouldn't you want to push-to-update it when you make changes in the branch? In other words, why doesn't push.default = matching suffice for most practical purposes. ... or branch.name.pushremote can support some kind of a none value? Not a bad idea at all, provided you tell me your usecase. -- 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: [RFC/PATCH] Introduce branch.name.pushremote
2013/2/19 Ramkumar Ramachandra: What is your usecase? If you have a local branch with the same name as on the remote, why wouldn't you want to push-to-update it when you make changes in the branch? In other words, why doesn't push.default = matching suffice for most practical purposes. ... or branch.name.pushremote can support some kind of a none value? Not a bad idea at all, provided you tell me your usecase. The question is infact about branches who are not on the remote. push.default=matching wouldn't upload the branches which are not there already. push --all on other hand pushes .. all (as expected :-))... Its difficult for me to manage quickly, lets say, news-to-push/* and crazy-ideas/* branches ... Blind. -- 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 0/3] contrib/subtree: Store subtree sources in .gitsubtree
Thanks to Jonathan for the constructive criticism of the tests. Here is the latest version. I suspect I'll need to leave it until after David's changes to the tests are merged into master, unless anyone thinks I should rebase elsewhere. I think my tests only need a minor update to accommodate those changes. -- Paul [W] Campbell -- 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 1/3] contrib/subtree: Store subtree sources in .gitsubtree
Add the prefix, repository and refspec in the file .gitsubtree when
git subtree add is used. Then when a git subtree push or pull is needed
the repository and refspec from .gitsubtree are used as the default
values.
Having to remember what subtree came from what source is a waste of
developer memory and doesn't transfer easily to other developers.
git subtree push/pull operations would typically be to/from the same
source that the original subtree was cloned from with git subtree add.
The repository and refspec, or commit, used in the git subtree add
operation are stored in .gitsubtree. One line each, delimited by a space:
prefix repository refspec or prefix . commit.
Subsequent git subtree push/pull operations now default to the values
stored in .gitsubtree, unless overridden from the command line.
The .gitsubtree file should be tracked as part of the repo as it
describes where parts of the tree came from and can be used to update
to and from that source.
Signed-off-by: Paul Campbell pcampb...@kemitix.net
---
contrib/subtree/git-subtree.sh | 75 +++---
1 file changed, 64 insertions(+), 11 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..1d0bf35 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -11,8 +11,8 @@ OPTS_SPEC=\
git subtree add --prefix=prefix commit
git subtree add --prefix=prefix repository commit
git subtree merge --prefix=prefix commit
-git subtree pull --prefix=prefix repository refspec...
-git subtree push --prefix=prefix repository refspec...
+git subtree pull --prefix=prefix [repository refspec...]
+git subtree push --prefix=prefix [repository refspec...]
git subtree split --prefix=prefix commit...
--
h,helpshow the help
@@ -489,6 +489,28 @@ ensure_clean()
fi
}
+add_subtree () {
+ if ( grep ^$dir .gitsubtree 2/dev/null )
+ then
+ # remove $dir from .gitsubtree - there's probably a clever way
to
do this with sed
+ grep -v ^$dir .gitsubtree .gitsubtree.temp
+ rm .gitsubtree
+ mv .gitsubtree.temp .gitsubtree
+ fi
+ if test $# -eq 1
+ then
+ # Only a commit provided, thus use the current repository
+ echo $dir . $@ .gitsubtree
+ elif test $# -eq 2
+ then
+ echo $dir $@ .gitsubtree
+ fi
+}
+
+get_subtree () {
+ grep ^$dir .gitsubtree || die Subtree not found in .gitsubtree:
$dir
+}
+
cmd_add()
{
if [ -e $dir ]; then
@@ -497,6 +519,8 @@ cmd_add()
ensure_clean
+ add_subtree $@
+
if [ $# -eq 1 ]; then
git rev-parse -q --verify $1^{commit} /dev/null ||
die '$1' does not refer to a commit
@@ -700,7 +724,23 @@ cmd_merge()
cmd_pull()
{
ensure_clean
- git fetch $@ || exit $?
+ if test $# -eq 0
+ then
+ subtree=($(get_subtree))
+ repository=${subtree[1]}
+ refspec=${subtree[2]}
+ if test $repository == .
+ then
+ echo Pulling into $dir from branch $refspec
+ else
+ echo Pulling into $dir from $repository $refspec
+ fi
+ echo git fetch using: $repository $refspec
+ git fetch $repository $refspec || exit $?
+ else
+ echo git fetch using: $@
+ git fetch $@ || exit $?
+ fi
revs=FETCH_HEAD
set -- $revs
cmd_merge $@
@@ -708,16 +748,29 @@ cmd_pull()
cmd_push()
{
- if [ $# -ne 2 ]; then
- die You must provide repository refspec
+ repository=$1
+ refspec=$2
+ if test $# -eq 0
+ then
+ subtree=($(get_subtree))
+ repository=${subtree[1]}
+ refspec=${subtree[2]}
+ if test $repository == .
+ then
+ echo Pushing from $dir into branch $refspec
+ else
+ echo Pushing from $dir into $repository $refspec
+ fi
+ elif test $# -ne 2
+ then
+ die You must provide repository refspec, or a prefix
listed
in .gitsubtree
fi
- if [ -e $dir ]; then
- repository=$1
- refspec=$2
- echo git push using: $repository $refspec
- git push $repository $(git subtree split
--prefix=$prefix):refs/heads/$refspec
+ if test -e $dir
+ then
+ echo git push using: $repository $refspec
+ git push $repository $(git subtree split
--prefix=$prefix):refs/heads/$refspec
else
- die '$dir' must already exist. Try 'git subtree add'.
+ die '$dir' must already exist. Try 'git subtree add'.
fi
}
--
1.8.2.rc0.16.g20a599e
--
To unsubscribe from this list: send the line
[PATCH v2 2/3] contrib/subtree/t: Added tests for .gitsubtree support
add: ensure details are added to .gitsubtree push: check for a SHA1 update line pull: add a file on one subtree, push it to a branch, then pull into another subtree containing the same branch and confirm the files match add: ensure stale .gitsubtree entry is replaced Signed-off-by: Paul Campbell pcampb...@kemitix.net --- contrib/subtree/t/t7900-subtree.sh | 42 ++ 1 file changed, 42 insertions(+) diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index 80d3399..f1a24cf 100755 --- a/contrib/subtree/t/t7900-subtree.sh +++ b/contrib/subtree/t/t7900-subtree.sh @@ -465,4 +465,46 @@ test_expect_success 'verify one file change per commit' ' )) ' +# return to mainline +cd ../.. + +# .gitsubtree +test_expect_success 'added repository appears in .gitsubtree' ' + git subtree add --prefix=copy0 sub1 + grep ^copy0 \. sub1$ .gitsubtree +' + +test_expect_success 'change in subtree is pushed okay' ' + ( + cd copy0 + create new_file + git commit -mAdded new_file + ) + git ls-tree refs/heads/sub1 output + ! grep new_file$ output + git subtree push --prefix=copy0 + git ls-tree refs/heads/sub1 output + grep new_file$ output +' + +test_expect_success 'pull into subtree okay' ' + git subtree add --prefix=copy1 sub1 + git subtree add --prefix=copy2 sub1 + ( + cd copy1 + create new_file_in_copy1 + git commit -mAdded new_file_in_copy1 + ) + git subtree push --prefix=copy1 + git subtree pull --prefix=copy2 output + grep ^ create mode 100644 copy2/new_file_in_copy1$ output +' + +test_expect_success 'replace outdated entry in .gitsubtree' ' + echo copy3 . sub2 .gitsubtree + git subtree add --prefix=copy3 sub1 + ! grep ^copy3 . sub2$ .gitsubtree + grep ^copy3 . sub1$ .gitsubtree +' + test_done -- 1.8.2.rc0.16.g20a599e -- 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 3/3] contrib/subtree: update documentation
Indicate that repository and refspec are now optional on push and pull. Add notes to add, push and pull about storing values in .gitsubtree and their use as default values. Signed-off-by: Paul Campbell pcampb...@kemitix.net --- contrib/subtree/git-subtree.txt | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index 7ba853e..2ad9278 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -11,8 +11,8 @@ SYNOPSIS [verse] 'git subtree' add -P prefix refspec 'git subtree' add -P prefix repository refspec -'git subtree' pull -P prefix repository refspec... -'git subtree' push -P prefix repository refspec... +'git subtree' pull -P [prefix repository refspec...] +'git subtree' push -P [prefix repository refspec...] 'git subtree' merge -P prefix commit 'git subtree' split -P prefix [OPTIONS] [commit] @@ -72,7 +72,9 @@ add:: A new commit is created automatically, joining the imported project's history with your own. With '--squash', imports only a single commit from the subproject, rather than its - entire history. + entire history. Details of the prefix are added to the + .gitsubtree file, where they will be used as defaults for + 'push' and 'pull'. merge:: Merge recent changes up to commit into the prefix @@ -91,13 +93,16 @@ merge:: pull:: Exactly like 'merge', but parallels 'git pull' in that it fetches the given commit from the specified remote - repository. + repository. Default values for repository and refspec + are taken from the .gitsubtree file. push:: Does a 'split' (see below) using the prefix supplied and then does a 'git push' to push the result to the repository and refspec. This can be used to push your subtree to different branches of the remote repository. + Default values for repository and refspec are taken + from the .gitsubtree file. split:: Extract a new, synthetic project history from the -- 1.8.2.rc0.16.g20a599e -- 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: inotify to minimize stat() calls
On Sun, Feb 10, 2013 at 12:24 AM, Duy Nguyen pclo...@gmail.com wrote: On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Finn notes in the commit message that it offers no speedup, because .gitignore files in every directory still have to be read. I think this is silly: we really should be caching .gitignore, and touching it only when lstat() reports that the file has changed. ... Really, the elephant in the room right now seems to be .gitignore. Until that is fixed, there is really no use of writing this inotify daemon, no? Can someone enlighten me on how exactly .gitignore files are processed? .gitignore is a different issue. I think it's mainly used with read_directory/fill_directory to collect ignored files (or not-ignored files). And it's not always used (well, status and add does, but diff should not). I think wee need to measure how much mass lstat elimination gains us (especially on big repos) and how much .gitignore/.gitattributes caching does. I don't think .gitignore has such a big impact though. strace on git.git tells me git status issues about 2500 lstat calls, and just 740 open+getdents calls (on total 3800 syscalls). I will think if we can do something about .gitignore/.gitattributes. -- Duy Duy, Did your testing turn up anything about the amount of time spent parsing the .gitignore/.gitattributes files? Not the syscall count, but the actual time spent running the parser (which I presume is largely CPU-bound). The other notable bit of information to know would be how much time is spent applying what has been parsed out of those files to the content of the tree. Both will give a clear signal of the prominence of those segments of code versus others elsewhere in the git stat flow path. That information will tell us more clearly what, if anything, it is worth keeping a cache of and what form that cache should take. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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/githooks: Explain pre-rebase parameters
W. Trevor King wk...@tremily.us writes:
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase ${1+$@}
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
[...]
In my local tests, it seems equivalent to $@.
It's definitely in the bash manual and POSIX[1]: it's a special case of
the ${parameter+word} expansion.
${parameter:+word}
Use Alternate Value. If parameter is null or unset, nothing is
substituted, otherwise the expansion of word is substituted.
plus
... bash tests for a parameter that is unset or null. Omitting the
colon results in a test only for a parameter that is unset.
IIRC this particular usage was designed to suppress warnings about unset
variables.
Footnotes:
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
--
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] Documentation/githooks: Explain pre-rebase parameters
On Tue, Feb 19, 2013 at 02:17:43PM +0100, Thomas Rast wrote:
W. Trevor King wk...@tremily.us writes:
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
[...]
In my local tests, it seems equivalent to $@.
It's definitely in the bash manual and POSIX[1]: it's a special case of
the ${parameter+word} expansion.
I need to read more carefully ;). There's even a nice table in the
POSIX specs…
Thanks,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [BUG] git-check-ignore: Segmentation fault
On Tue, Feb 19, 2013 at 5:24 AM, Zoltan Klinger zoltan.klin...@gmail.com wrote: Hi there, The new git-check-ignore command seg faults when (1) it is called with single dot path name at $GIT_DIR level _AND_ (2) and .gitignore has at least one directory pattern. Git version: 1.8.2.rc0.16.g20a599e Reproduce the bug: $ git --version git version 1.8.2.rc0.16.g20a599e $ mkdir test $ cd test $ git init $ git check-ignore . # All good, no errors here $ echo dirpattern/ .gitignore $ git check-ignore . Segmentation fault (core dumped) The segmentation fault is actually caused by hash_name(const char *name, int namelen) function in name-hash.c when the 'name' argument is an empty stringi and namelen is 0. The empty string comes from a call to the prefix_path(prefix, len, path) function in setup.c. In this instance arguments 'prefix' is NULL, 'len' is 0 and 'path' is . . Good catch! Thanks for the very helpful bug report. I can reproduce this, and have a fix - see follow-up mail to follow shortly. -- 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: inotify to minimize stat() calls
On Tue, Feb 19, 2013 at 8:16 PM, Drew Northup n1xim.em...@gmail.com wrote:
Did your testing turn up anything about the amount of time spent
parsing the .gitignore/.gitattributes files? Not the syscall count,
but the actual time spent running the parser (which I presume is
largely CPU-bound). The other notable bit of information to know would
be how much time is spent applying what has been parsed out of those
files to the content of the tree. Both will give a clear signal of the
prominence of those segments of code versus others elsewhere in the
git stat flow path. That information will tell us more clearly what,
if anything, it is worth keeping a cache of and what form that cache
should take.
Not specifically parsing, but we do waste CPU on
.gitignore/.gitattributes stuff. See
http://thread.gmane.org/gmane.comp.version-control.git/216347/focus=216381
Other measurements (which led to the above patch):
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=215900
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=216029
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=216195
So far we could reduce lstat, {open,read,close}dir syscalls with the
help of inotify, which saves time. I'm not sure if we should cache the
list of untracked-but-not-ignored files. It cuts down cpu time on
.gitignore but invalidation could be complicated.
--
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 2/2] check-ignore.c: fix segfault with '.' argument from repo root
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored, but of
course it should not segfault in this case.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/check-ignore.c | 2 +-
t/t0008-ignores.sh | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..b0dd7c2 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char
**pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] path[0]) {
+ if (!seen[i] full_path[0]) {
exclude = last_exclude_matching_path(check, full_path,
-1, dtype);
if (exclude) {
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat -\EOF .gitignore
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore 128
stderr_contains fatal: no path specified
--
1.8.1.291.g0730ed6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] t0008: document test_expect_success_multi
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t0008-ignores.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index d7df719..ebe7c70 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -75,6 +75,16 @@ test_check_ignore () {
stderr_empty_on_success $expect_code
}
+# Runs the same code with 3 different levels of output verbosity,
+# expecting success each time. Takes advantage of the fact that
+# check-ignore --verbose output is the same as normal output except
+# for the extra first column.
+#
+# Arguments:
+# - (optional) prereqs for this test, e.g. 'SYMLINKS'
+# - test name
+# - output to expect from -v / --verbose mode
+# - code to run (should invoke test_check_ignore)
test_expect_success_multi () {
prereq=
if test $# -eq 4
--
1.8.1.291.g0730ed6
--
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: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? I handle these kinds of configuration tasks out of band using mr, and it works pretty well: https://github.com/aspiers/mr-config/#readme https://github.com/aspiers/mr-config/blob/master/sh.d/git-remotes Food for thought ... -- 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] l10n: de.po: translate 35 new messages
Ralf Thielow venit, vidit, dixit 18.02.2013 19:22: Translate 35 new messages came from git.pot update in 9caaf23 (l10n: Update git.pot (35 new, 14 removed messages)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 140 +++ 1 file changed, 68 insertions(+), 72 deletions(-) diff --git a/po/de.po b/po/de.po index df98a0f..9690cd7 100644 --- a/po/de.po +++ b/po/de.po @@ -358,14 +358,14 @@ msgid gpg failed to sign the data msgstr gpg beim Signieren der Daten fehlgeschlagen #: gpg-interface.c:112 -#, fuzzy, c-format +#, c-format msgid could not create temporary file '%s': %s -msgstr konnte Datei '%s' nicht erstellen +msgstr konnte temporäre Datei '%s' nicht erstellen: %s #: gpg-interface.c:115 -#, fuzzy, c-format +#, c-format msgid failed writing detached signature to '%s': %s -msgstr Fehler beim Erstellen des Pfades '%s'%s +msgstr Fehler beim Schreiben der Signatur nach '%s': %s #: grep.c:1622 #, c-format @@ -1443,9 +1443,8 @@ msgid failed to unlink '%s' msgstr Konnte '%s' nicht entfernen Maybe a . at the end, or begin with lower case. #: builtin/add.c:20 -#, fuzzy msgid git add [options] [--] pathspec... -msgstr git add [Optionen] [--] [Dateimuster...] +msgstr git add [Optionen] [--] [Pfadspezifikation...] #: builtin/add.c:63 #, c-format @@ -1601,6 +1600,21 @@ msgid With the current Git version, the command is restricted to the current directory. msgstr +Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n +einem Unterverzeichnis aus, wird in Git 2.0 geändert und sollte nicht\n There should be no , here because there is no subclause. +mehr verwendet werden.\n +Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n There can be a comma here, it is a (shortened subclause). +\n + git add %s :/\n + (oder git add %s :/)\n +\n +Zur Einschränkung auf das aktuelle Verzeichnis, führen Sie aus:\n There should be no , here because there is no subclause. Rest looks fine (Thomas mentioned the missed rename already). +\n + git add %s .\n + (oder git add %s .)\n +\n +Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n +Verzeichnis beschränkt. #: builtin/add.c:381 msgid -A and -u are mutually incompatible @@ -2412,16 +2426,16 @@ msgstr [%d voraus, %d hinterher] #: builtin/branch.c:469 msgid invalid ref -msgstr +msgstr ungültige Referenz #: builtin/branch.c:560 msgid (no branch) msgstr (kein Zweig) #: builtin/branch.c:593 -#, fuzzy, c-format +#, c-format msgid object '%s' does not point to a commit -msgstr '%s' zeigt auf keine Version +msgstr Objekt '%s' zeigt auf keine Version #: builtin/branch.c:625 msgid some refs could not be read @@ -2571,33 +2585,30 @@ msgid --column and --verbose are incompatible msgstr Die Optionen --column und --verbose sind inkompatibel. #: builtin/branch.c:845 -#, fuzzy msgid branch name required -msgstr Kein Zweigname spezifiziert +msgstr Zweigname erforderlich #: builtin/branch.c:860 -#, fuzzy msgid Cannot give description to detached HEAD -msgstr Kann Hauptzweig des externen Projektarchivs nicht bestimmen +msgstr zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden #: builtin/branch.c:865 -#, fuzzy msgid cannot edit description of more than one branch -msgstr bearbeitet die Beschreibung für den Zweig +msgstr Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden #: builtin/branch.c:872 -#, fuzzy, c-format +#, c-format msgid No commit on branch '%s' yet. -msgstr Kein solcher Zweig '%s' +msgstr Noch keine Version in Zweig '%s'. #: builtin/branch.c:875 -#, fuzzy, c-format +#, c-format msgid No branch named '%s'. -msgstr Ungültiger Zweig-Name: '%s' +msgstr Zweig '%s' nicht vorhanden. #: builtin/branch.c:888 msgid too many branches for a rename operation -msgstr +msgstr zu viele Zweige angegeben #: builtin/branch.c:893 #, c-format @@ -2731,28 +2742,24 @@ msgid suppress progress reporting msgstr unterdrückt Fortschrittsanzeige #: builtin/check-ignore.c:151 -#, fuzzy msgid cannot specify pathnames with --stdin -msgstr kann -a nicht mit -d benutzen +msgstr Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden #: builtin/check-ignore.c:154 msgid -z only makes sense with --stdin -msgstr +msgstr Die Option -z kann nur mit --stdin verwendet werden. #: builtin/check-ignore.c:156 -#, fuzzy msgid no path specified -msgstr kein externes Projektarchiv angegeben +msgstr kein Pfad angegeben #: builtin/check-ignore.c:160 -#, fuzzy msgid --quiet is only valid with a single pathname -msgstr verwendet [PATCH n/m] auch mit einzelnem Patch +msgstr Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig. #: builtin/check-ignore.c:162
Re: Proposal: sharing .git/config
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) on the repository. The only problem is that I have no clue how to implement this: I'm currently thinking a special remote ref? If you check out the config file, then include.path should work. You could add include.ref to point to a ref, but you need to deal with the attached security implications. This has been proposed before (and turned down, I think). Here's the patch: http://article.gmane.org/gmane.comp.version-control.git/189144 The basic argument against it is that you would _not_ want to do: $ git config include.ref origin/config because it's unsafe (you immediately start using config fetched from the remote, before you even get a chance to inspect it). So the recommended way to use it is: $ git config include.ref config $ git show origin/config ;# make sure it looks reasonable $ git update-ref refs/config origin/config [time passes...] $ git fetch $ git diff config origin/config ;# inspect changes $ git update-ref refs/config origin/config But it was pointed out that you could also just do: $ git config include.ref upstream-config $ git show origin/config ;# make sure it looks reasonable $ git show origin/config .git/upstream-config and so forth. There are some ways that a pure ref can be more convenient (e.g., if you are carrying local changes on top of the upstream config and want to merge), but ultimately, you can replicate any include.ref workflow with include.path by adding a deploy step where you copy the file into $GIT_DIR. -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: Git Merge 2013 Conference, Berlin
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Scott Chacon venit, vidit, dixit 18.02.2013 22:29: Right now we have: Dev day: 50 User day: 295 Hack day: 200 I'm not sure what the actual turnout will be, but it looks like it's going to be pretty massive. I wanted to go through the Dev day signups and figure out if everyone really belongs there (is an actual contributor to a core git project) but it's basically on the honor system now. If anyone on this list that should be there (Junio, Shawn, etc) wants to attend and would like sponsorship for the flight/lodging, please let me know. We would love to have as many of the core people there as possible. I will also try to record everything and summarize as much as I can after the fact, so if you can't attend it should still be possible to get the general idea of what occurred and was discussed. I'm going to try doing something similar in the SF area in maybe 6-8 months from this, assuming it's a success. Scott On Mon, Feb 18, 2013 at 1:17 PM, Jeff King p...@peff.net wrote: On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote: Scott Chacon scha...@gmail.com writes: We're starting off in Berlin, May 9-11th. GitHub has secured conference space at the Radisson Blu Berlin for those days. I have a smaller room for the first day so we can get 30-40 Git implementors together to talk about the future of Git and whatnot. [...] http://git-merge.com/ So this has been fairly quiet -- is anyone else coming? :-) I am. I think Scott may have actual numbers, but my third-hand impression was that there have been a lot of signups. -Peff Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? I do plan to come (unless I'm out due to lack of an eventbrite ticket) but will stay with family rather than at the Radisson Blu. Michael BTW: Is it OK to add that event as an event on our Git community page? Just wanted to ask Scott and Junio before doing it myself. 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
Re: Git Merge 2013 Conference, Berlin
Hey, On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? No, it's because 300 people signed up and that's all the venue has room for. I'm sure we can fit one more if you come. I do plan to come (unless I'm out due to lack of an eventbrite ticket) but will stay with family rather than at the Radisson Blu. BTW: Is it OK to add that event as an event on our Git community page? Just wanted to ask Scott and Junio before doing it myself. Yes, this is fine. Scott -- 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: Can git restrict source files ?
Juan Pablo juanpablo8...@gmail.com writes: Hi, I have a question, can i control the access to specific files or folders ?? I need that some developers can't see some source files, thank you very much for your time No, you can't. You can use e.g. gitolite to set up access control for a branch, but Git needs access to the complete tree. -- 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] shell-prompt: clean up nested if-then
Simon Oosthoek s.oosth...@xs4all.nl writes: I suppose it would be fine if a patch was sent to update the entire git-prompt.sh code to be more in line with the Git shell script style... Please don't. We do not want a style conversion for the sole purpose of conversion, especially when a subsystem is already internally consistent. Besides, the git-prompt.sh thing needs to be fairly bash specific so the usual Git Porcelain scripts targetted for POSIX/Bourne shells rules does not apply there. My original gripe was just with doing it in one place while leaving all the others unchanged. It makes for messy reading and leads to confusion. Yes, it is always preferred to match the _local_ convention. -- 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: Google Summer of Code 2013 (GSoC13)
Thomas Rast tr...@inf.ethz.ch writes: In defense of Thomas, whose project was mentioned earlier as a prime example of something that is too big: He's in fact still working on the index-API angle, as part of a thesis at university. That is probably a good indicator that it was too big for a summer student. It also is good to hear that the topic is being looked at ;-). -- 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: Google Summer of Code 2013 (GSoC13)
Ramkumar Ramachandra artag...@gmail.com writes: I was conflating between people who add suggested project and who act as mentors. I do not think mentors are primarily responsible for bad suggested projects. Why do mentors pick badly sketched-out projects to mentor? They're free to pick anything they want/ propose what they want. I've had an impression that these Wiki entries were written by people with names of mentors (who are different from the proposers) already assigned to them, and if an unfortunate student picked an unrealistic one, these mentor candidates were too nice to push back and decline, saying it is unrealistic, leaving the student and proposal without any mentor. -- 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: Google Summer of Code 2013 (GSoC13)
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
That is probably a good indicator that it was too big for a summer
student. It also is good to hear that the topic is being looked at
;-).
Not really: the API angle was never part of the proposal. The timeline
was [1 if you have access]:
24/04 - 01/05: Document the new index format.
02/05 - 11/05: Create a converter of the old index format to the new format.
12/05 - 18/06: Parse the index from disk to the current in-memory format. The
old index format shall still be readable.
19/06 - 09/07: Implement the re-reading of a single record, if the crc32
doesn't
match (Meaning the record has been changed under the reader).
10/07 - 21/07: Map the current internal structure to the new index format.
22/07 - 31/07: Change the current in-memory structure to keep track of the
changed files.
01/08 - 13/08: Write the index to disk in both the old and the new format
depending on the choice of the user and make sure only the changed parts are
really written to disk in the new format.
11/08 - 13/08: Test the new index and profile the gains compared to the old
format.
/* Development work will be a bit slower from 18/06 to 21/07 because at my
* University there are exams in this period. I probably will only be able to
* work half the hours. I'll be back up to full speed after that. */
I think this case is somewhat symptomatic for one possible cause of
dragged-out non-inclusions _after_ GSoC: there's a certain scope creep
caused by striving for the perfect, long-term maintainable code.
The solution IMHO is to _both_ recognize such possibilities for scope
creep, and cut down the proposals to a size where a student has a
reasonable chance of achieving the code quality required for inclusion.
(The latter option has been mentioned a few times, but I wanted to make
people aware that the scope creep is happening, too.)
Footnotes:
[1]
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1
--
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
[PATCHv2] l10n: de.po: translate 35 new messages
Translate 35 new messages came from git.pot update in 9caaf23 (l10n: Update git.pot (35 new, 14 removed messages)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com Acked-by: Thomas Rast tr...@inf.ethz.ch --- Thanks Thomas and Michael for review. po/de.po | 142 +++ 1 file changed, 69 insertions(+), 73 deletions(-) diff --git a/po/de.po b/po/de.po index df98a0f..cd2d116 100644 --- a/po/de.po +++ b/po/de.po @@ -358,14 +358,14 @@ msgid gpg failed to sign the data msgstr gpg beim Signieren der Daten fehlgeschlagen #: gpg-interface.c:112 -#, fuzzy, c-format +#, c-format msgid could not create temporary file '%s': %s -msgstr konnte Datei '%s' nicht erstellen +msgstr konnte temporäre Datei '%s' nicht erstellen: %s #: gpg-interface.c:115 -#, fuzzy, c-format +#, c-format msgid failed writing detached signature to '%s': %s -msgstr Fehler beim Erstellen des Pfades '%s'%s +msgstr Fehler beim Schreiben der Signatur nach '%s': %s #: grep.c:1622 #, c-format @@ -1440,12 +1440,11 @@ msgstr , hinterher #: compat/precompose_utf8.c:58 builtin/clone.c:341 #, c-format msgid failed to unlink '%s' -msgstr Konnte '%s' nicht entfernen +msgstr Konnte '%s' nicht entfernen. #: builtin/add.c:20 -#, fuzzy msgid git add [options] [--] pathspec... -msgstr git add [Optionen] [--] [Dateimuster...] +msgstr git add [Optionen] [--] [Pfadspezifikation...] #: builtin/add.c:63 #, c-format @@ -1601,6 +1600,21 @@ msgid With the current Git version, the command is restricted to the current directory. msgstr +Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n +einem Unterverzeichnis aus wird in Git 2.0 geändert und sollte nicht\n +mehr verwendet werden.\n +Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n +\n + git add %s :/\n + (oder git add %s :/)\n +\n +Zur Einschränkung auf das aktuelle Verzeichnis führen Sie aus:\n +\n + git add %s .\n + (oder git add %s .)\n +\n +Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n +Verzeichnis beschränkt. #: builtin/add.c:381 msgid -A and -u are mutually incompatible @@ -2412,16 +2426,16 @@ msgstr [%d voraus, %d hinterher] #: builtin/branch.c:469 msgid invalid ref -msgstr +msgstr ungültige Referenz #: builtin/branch.c:560 msgid (no branch) msgstr (kein Zweig) #: builtin/branch.c:593 -#, fuzzy, c-format +#, c-format msgid object '%s' does not point to a commit -msgstr '%s' zeigt auf keine Version +msgstr Objekt '%s' zeigt auf keine Version #: builtin/branch.c:625 msgid some refs could not be read @@ -2571,33 +2585,30 @@ msgid --column and --verbose are incompatible msgstr Die Optionen --column und --verbose sind inkompatibel. #: builtin/branch.c:845 -#, fuzzy msgid branch name required -msgstr Kein Zweigname spezifiziert +msgstr Zweigname erforderlich #: builtin/branch.c:860 -#, fuzzy msgid Cannot give description to detached HEAD -msgstr Kann Hauptzweig des externen Projektarchivs nicht bestimmen +msgstr zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden #: builtin/branch.c:865 -#, fuzzy msgid cannot edit description of more than one branch -msgstr bearbeitet die Beschreibung für den Zweig +msgstr Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden #: builtin/branch.c:872 -#, fuzzy, c-format +#, c-format msgid No commit on branch '%s' yet. -msgstr Kein solcher Zweig '%s' +msgstr Noch keine Version in Zweig '%s'. #: builtin/branch.c:875 -#, fuzzy, c-format +#, c-format msgid No branch named '%s'. -msgstr Ungültiger Zweig-Name: '%s' +msgstr Zweig '%s' nicht vorhanden. #: builtin/branch.c:888 msgid too many branches for a rename operation -msgstr +msgstr zu viele Zweige für eine Umbenennen-Operation angegeben #: builtin/branch.c:893 #, c-format @@ -2731,28 +2742,24 @@ msgid suppress progress reporting msgstr unterdrückt Fortschrittsanzeige #: builtin/check-ignore.c:151 -#, fuzzy msgid cannot specify pathnames with --stdin -msgstr kann -a nicht mit -d benutzen +msgstr Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden #: builtin/check-ignore.c:154 msgid -z only makes sense with --stdin -msgstr +msgstr Die Option -z kann nur mit --stdin verwendet werden. #: builtin/check-ignore.c:156 -#, fuzzy msgid no path specified -msgstr kein externes Projektarchiv angegeben +msgstr kein Pfad angegeben #: builtin/check-ignore.c:160 -#, fuzzy msgid --quiet is only valid with a single pathname -msgstr verwendet [PATCH n/m] auch mit einzelnem Patch +msgstr Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig. #: builtin/check-ignore.c:162 -#, fuzzy msgid cannot have both --quiet and --verbose -msgstr Kann den aktuellen Zustand der Bereitstellung nicht speichern +msgstr Die Optionen --quiet und --verbose können nicht gemeinsam verwendet werden. #: builtin/checkout-index.c:126 msgid git
Re: [PATCH] Documentation/githooks: Explain pre-rebase parameters
Thomas Rast tr...@student.ethz.ch writes:
$GIT_DIR/hooks/pre-rebase ${1+$@}
...
IIRC this particular usage was designed to suppress warnings about unset
variables.
This is an old-timer's habit to work around buggy implementations of
Bourne shells where they failed to expand $@ to nothing when there
is no parameters, feeding a single empty argument to the command.
By explicitly writing ${1+...}, the construct makes sure that when
we have no parameter (i.e. $1 is unset) we do not even look at $@.
It is equivalent to $@ in correctly implemented shells.
--
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] l10n: de.po: translate 5 new messages
Translate 5 new messages came from git.pot update in 235537a (l10n: git.pot: v1.8.2 round 3 (5 new)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/po/de.po b/po/de.po index ed813ef..c0e5398 100644 --- a/po/de.po +++ b/po/de.po @@ -731,7 +731,7 @@ msgstr %s #: parse-options.c:548 msgid -NUM -msgstr +msgstr -NUM #: pathspec.c:83 #, c-format @@ -1271,9 +1271,9 @@ msgstr wiederherzustellen) #: wt-status.c:879 wt-status.c:896 -#, fuzzy, c-format +#, c-format msgid You are currently rebasing branch '%s' on '%s'. -msgstr Sie sind gerade beim Neuaufbau. +msgstr Sie sind gerade beim Neuaufbau von Zweig '%s' auf '%s'. #: wt-status.c:884 wt-status.c:901 msgid You are currently rebasing. @@ -1300,10 +1300,11 @@ msgid (all conflicts fixed: run \git rebase --continue\) msgstr (alle Konflikte behoben: führen Sie \git rebase --continue\ aus) #: wt-status.c:908 -#, fuzzy, c-format +#, c-format msgid You are currently splitting a commit while rebasing branch '%s' on '%s'. -msgstr Sie teilen gerade eine Version während eines Neuaufbaus auf. +msgstr Sie teilen gerade eine Version auf, während ein Neuaufbau von Zweig +'%s' auf '%s' im Gange ist. #: wt-status.c:913 msgid You are currently splitting a commit during a rebase. @@ -1316,9 +1317,10 @@ msgstr continue\ aus) #: wt-status.c:920 -#, fuzzy, c-format +#, c-format msgid You are currently editing a commit while rebasing branch '%s' on '%s'. -msgstr Sie editieren gerade eine Version während eines Neuaufbaus. +msgstr Sie editieren gerade eine Version während eines Neuaufbaus von Zweig +'%s' auf '%s'. #: wt-status.c:925 msgid You are currently editing a commit during a rebase. @@ -1345,9 +1347,9 @@ msgid (all conflicts fixed: run \git commit\) msgstr (alle Konflikte behoben: führen Sie \git commit\ aus) #: wt-status.c:958 -#, fuzzy, c-format +#, c-format msgid You are currently bisecting branch '%s'. -msgstr Sie sind gerade beim Halbieren. +msgstr Sie sind gerade beim Halbieren in Zweig '%s'. #: wt-status.c:962 msgid You are currently bisecting. -- 1.8.2.rc0.16.g20a599e -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] t/t7502: compare entire commit message with what was expected
Jonathan Nieder jrnie...@gmail.com writes:
The downside (not a new problem, but a downside nonetheless) is that
it means the test doesn't demonstrate what --cleanup=verbatim --status
will do.
How about something like this?
Can't we be a bit more robust by not using a hardcoded block of
lines as the expect string? You could for example use what you
would see in your editor when git commit is run without the -t
option to form the expected pattern, no?
In any case, I think (1) a test for 'verbatim with status' is worth
doing, and (2) it would be cleaner to do this as a separate step,
perhaps on top of Brandon's 4-patch series.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
diff --git i/t/t7502-commit.sh w/t/t7502-commit.sh
index cbd7a459..64162fce 100755
--- i/t/t7502-commit.sh
+++ w/t/t7502-commit.sh
@@ -180,15 +180,37 @@ test_expect_success 'verbose respects diff config' '
test_expect_success 'cleanup commit messages (verbatim option,-t)' '
echo negative
- { echo;echo # text;echo; } expect
- git commit --cleanup=verbatim -t expect -a
- git cat-file -p HEAD |sed -e 1,/^\$/d |head -n 3 actual
+ {
+ echo
+ echo # text
+ echo
+ } template
+ {
+ cat template
+ cat -\EOF
+
+ # Please enter the commit message for your changes. Lines
starting
+ # with '\''#'\'' will be kept; you may remove them yourself if
you want to.
+ # An empty message aborts the commit.
+ #
+ # Author:A U Thor aut...@example.com
+ #
+ EOF
+ git commit -a --dry-run
+ } expect
+ git commit --cleanup=verbatim -t template -a
+ git cat-file -p HEAD |sed -e 1,/^\$/d actual
test_cmp expect actual
'
test_expect_success 'cleanup commit messages (verbatim option,-F)' '
+ {
+ echo
+ echo # text
+ echo
+ } expect
echo negative
git commit --cleanup=verbatim -F expect -a
git cat-file -p HEAD |sed -e 1,/^\$/dactual
--
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 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
Jonathan Nieder jrnie...@gmail.com writes: Brandon Casey wrote: Hmm, I think the original text was more confusing than I realized. I think we should reorder the cleanup modes, placing default last, and then describe default in terms of either strip or whitespace depending on whether an editor will be spawned. Sounds good to me. :) Will take 1-3 of the series for now, as the above seems to indicate that I'll see a quick reroll of 4/4. Thanks both for patches and review. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t0008: document test_expect_success_multi
Adam Spiers g...@adamspiers.org writes:
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Good. I vaguely recall saying why I hate these mini-frameworks
invented in individual tests, but with comments like this, they
become much more palatable.
Thanks.
t/t0008-ignores.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index d7df719..ebe7c70 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -75,6 +75,16 @@ test_check_ignore () {
stderr_empty_on_success $expect_code
}
+# Runs the same code with 3 different levels of output verbosity,
+# expecting success each time. Takes advantage of the fact that
+# check-ignore --verbose output is the same as normal output except
+# for the extra first column.
+#
+# Arguments:
+# - (optional) prereqs for this test, e.g. 'SYMLINKS'
+# - test name
+# - output to expect from -v / --verbose mode
+# - code to run (should invoke test_check_ignore)
test_expect_success_multi () {
prereq=
if test $# -eq 4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored, but of
course it should not segfault in this case.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Please step back a bit and explain why the original had check for
path[0] in the first place?
If the answer is the code wanted to special case the question 'is
the top-level excluded?', but used a wrong variable to implement the
check, and this patch is a fix to that, then the proposed commit
log message looks incomplete. The cause of the segv is not that
prefix_path() returns an empty string, but because the function
called inside the if block was written without expecting to be fed
the path that refers to the top-level of the working tree, no?
While this change certainly will prevent the check the top-level
request to last-exclude-matching-path, I have to wonder if it is a
good idea to force the caller of the l-e-m-p function to even care.
In other words, would it be a cleaner approach to fix the l-e-m-p
function so that the caller can ask check the top-level and give a
sensible answer (perhaps the answer may be nothing matches), and
remove the path[0] (or full_path[0]) special case from
this call site?
The last sentence It doesn't make much sense... in the proposed
log message would become a good justification for such a special
case at the beginning of l-e-m-p function, I would think.
builtin/check-ignore.c | 2 +-
t/t0008-ignores.sh | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..b0dd7c2 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char
**pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] path[0]) {
+ if (!seen[i] full_path[0]) {
exclude = last_exclude_matching_path(check, full_path,
-1, dtype);
if (exclude) {
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat -\EOF .gitignore
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore 128
stderr_contains fatal: no path specified
--
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: Can git restrict source files ?
On Tue, Feb 19, 2013 at 5:06 PM, Juan Pablo juanpablo8...@gmail.com wrote: I have a question, can i control the access to specific files or folders ?? I need that some developers can't see some source files, thank you very much for your time No, but what you can do is to split these up into different repositories. E.g. where I work we have a puppet.git and a secrets.git, the latter contains passwords and other secret data, the former just uses macros to include that and is accessible to 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
[PATCH v2 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- Ok, here's the updated text. I am not set up to build the documentation, so I hope someone will test, but looks right to me. -Brandon Documentation/git-commit.txt | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 0eb79cc..992c219 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -172,16 +172,24 @@ OPTIONS linkgit:git-commit-tree[1]. --cleanup=mode:: - This option sets how the commit message is cleaned up. - The 'mode' can be one of 'verbatim', 'whitespace', 'strip', - and 'default'. The 'default' mode will strip leading and - trailing empty lines and #commentary from the commit message - only if the message is to be edited. Otherwise only whitespace - removed. The 'verbatim' mode does not change message at all, - 'whitespace' removes just leading/trailing whitespace lines - and 'strip' removes both whitespace and commentary. The default - can be changed by the 'commit.cleanup' configuration variable - (see linkgit:git-config[1]). + This option determines how the supplied commit message should be + cleaned up before committing. The 'mode' can be `strip`, + `whitespace`, `verbatim`, or `default`. ++ +-- +strip:: + Strip leading and trailing empty lines, trailing whitespace, and + #commentary and collapse consecutive empty lines. +whitespace:: + Same as `strip` except #commentary is not removed. +verbatim:: + Do not change the message at all. +default:: + `strip` if the message is to be edited. Otherwise `whitespace`. +-- ++ + The default can be changed by the 'commit.cleanup' configuration + variable (see linkgit:git-config[1]). -e:: --edit:: -- 1.8.1.3.566.gaa39828 -- 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 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- [RESEND] I originally specified Junio's address as gits...@pobox.org. Ok, here's the updated text. I am not set up to build the documentation, so I hope someone will test, but looks right to me. -Brandon Documentation/git-commit.txt | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 0eb79cc..992c219 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -172,16 +172,24 @@ OPTIONS linkgit:git-commit-tree[1]. --cleanup=mode:: - This option sets how the commit message is cleaned up. - The 'mode' can be one of 'verbatim', 'whitespace', 'strip', - and 'default'. The 'default' mode will strip leading and - trailing empty lines and #commentary from the commit message - only if the message is to be edited. Otherwise only whitespace - removed. The 'verbatim' mode does not change message at all, - 'whitespace' removes just leading/trailing whitespace lines - and 'strip' removes both whitespace and commentary. The default - can be changed by the 'commit.cleanup' configuration variable - (see linkgit:git-config[1]). + This option determines how the supplied commit message should be + cleaned up before committing. The 'mode' can be `strip`, + `whitespace`, `verbatim`, or `default`. ++ +-- +strip:: + Strip leading and trailing empty lines, trailing whitespace, and + #commentary and collapse consecutive empty lines. +whitespace:: + Same as `strip` except #commentary is not removed. +verbatim:: + Do not change the message at all. +default:: + `strip` if the message is to be edited. Otherwise `whitespace`. +-- ++ + The default can be changed by the 'commit.cleanup' configuration + variable (see linkgit:git-config[1]). -e:: --edit:: -- 1.8.1.3.566.gaa39828 -- 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 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- [RESEND] I originally specified Junio's address as gits...@pobox.org. [RESEND] Sorry, now with the correct address. Ok, here's the updated text. I am not set up to build the documentation, so I hope someone will test, but looks right to me. -Brandon Documentation/git-commit.txt | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 0eb79cc..992c219 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -172,16 +172,24 @@ OPTIONS linkgit:git-commit-tree[1]. --cleanup=mode:: - This option sets how the commit message is cleaned up. - The 'mode' can be one of 'verbatim', 'whitespace', 'strip', - and 'default'. The 'default' mode will strip leading and - trailing empty lines and #commentary from the commit message - only if the message is to be edited. Otherwise only whitespace - removed. The 'verbatim' mode does not change message at all, - 'whitespace' removes just leading/trailing whitespace lines - and 'strip' removes both whitespace and commentary. The default - can be changed by the 'commit.cleanup' configuration variable - (see linkgit:git-config[1]). + This option determines how the supplied commit message should be + cleaned up before committing. The 'mode' can be `strip`, + `whitespace`, `verbatim`, or `default`. ++ +-- +strip:: + Strip leading and trailing empty lines, trailing whitespace, and + #commentary and collapse consecutive empty lines. +whitespace:: + Same as `strip` except #commentary is not removed. +verbatim:: + Do not change the message at all. +default:: + `strip` if the message is to be edited. Otherwise `whitespace`. +-- ++ + The default can be changed by the 'commit.cleanup' configuration + variable (see linkgit:git-config[1]). -e:: --edit:: -- 1.8.1.3.566.gaa39828 -- 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 v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@tremily.us I think this interface is often more convenient than extended cherry picking or using 'git format-patch'. In fact, I removed the cherry-pick section entirely. The entry-level suggestions for rerolling are now: 1. git commit --amend 2. git format-patch origin git reset --hard origin ...edit and reorder patches... git am *.patch 3. git rebase -i origin Signed-off-by: W. Trevor King wk...@tremily.us --- Thanks. +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - +$ git format-patch origin +$ git reset --hard origin - Technically speaking, this does not reset to before the patches. You would need git reset --hard $(git merge-base origin HEAD) or something like that. I think this is fine as-is in the flow of text, where we haven't taught the readers the use of merge-base to find the fork point. -- 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 v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
On Tue, Feb 19, 2013 at 10:47:04AM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - +$ git format-patch origin +$ git reset --hard origin - Technically speaking, this does not reset to before the patches. You would need git reset --hard $(git merge-base origin HEAD) or something like that. They'll be fine if they haven't fetched since they started their branch ;). It does look like I've got an extra comma an a missing “and”. What about: …create series of patches and then reset… Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Feature idea : notes to track status of a commit, which remotes it is shared to
Thomas Rast tr...@student.ethz.ch writes: Mildred Ki'Lya mildred...@mildred.fr writes: The idea is to basically track automatically (in notes, either in the notes namespace or in another namespace) which repository/remote contains a commit. When doing git log, we'd see lines with each commit, something like: commit b044e6d0f1a1782820b052348ab0db314e2db3ca Author: Myself myself@localhost.localdomain Date: Tue Nov 20 16:46:38 2012 +0100 This is the commit description Published on: origin g...@git.host.com:pub/repo.git The problem here is that doing this in notes is unreliable: you'd have to identify all places where the set of publishes can change for any commit, and update them there. Unreliable you can fix with effort. But I think a bigger problem is that it is a pointless false economy to attempt to record and try to maintain this note for each and every commit. When you push out a tip of the branch to a new location, you would have to update notes to all commits from that tip down to where in the history to record that new location? To the root? Also your upstream may fetch from your published place and you may fetch it back (you will notice that now the commit appears in your 'origin'). Would you do the traversal and update all notes? It is both much easier and cheaper to compute this on demand as you pointed out. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
Thomas Ackermann th.ac...@arcor.de writes: Is V4 really recommended for general use? If you stick to C-git, I do not think there is any reason to avoid it. It is already a mature technology, the difference between 2 and 4 are so trivial that it is very unlikely for a latent bug to be hiding in corner cases. It is a different matter if various reimplementations already support the format. You can try it out, and if you find that other tools based on reimplementations of Git you use do not understand the format, you can safely go back with git update-index --index-version 2 after you upgraded to version 4. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
On Tue, Feb 19, 2013 at 5:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: Fix a corner case where check-ignore would segfault when run with the '.' argument from the top level of a repository, due to prefix_path() converting '.' into the empty string. It doesn't make much sense to call check-ignore from the top level with '.' as a parameter, since the top-level directory would never typically be ignored, but of course it should not segfault in this case. Signed-off-by: Adam Spiers g...@adamspiers.org --- Please step back a bit and explain why the original had check for path[0] in the first place? I can't remember to be honest. If the answer is the code wanted to special case the question 'is the top-level excluded?', Yes, I think that's the most likely explanation. Maybe it got missed in a variable renaming refactoring. but used a wrong variable to implement the check, and this patch is a fix to that, then the proposed commit log message looks incomplete. The cause of the segv is not that prefix_path() returns an empty string, but because the function called inside the if block was written without expecting to be fed the path that refers to the top-level of the working tree, no? While this change certainly will prevent the check the top-level request to last-exclude-matching-path, I have to wonder if it is a good idea to force the caller of the l-e-m-p function to even care. In other words, would it be a cleaner approach to fix the l-e-m-p function so that the caller can ask check the top-level and give a sensible answer (perhaps the answer may be nothing matches), and remove the path[0] (or full_path[0]) special case from this call site? Yes, that did cross my mind. I also wondered whether hash_name() should do stricter input validation, but I guess that could have an impact on performance. The last sentence It doesn't make much sense... in the proposed log message would become a good justification for such a special case at the beginning of l-e-m-p function, I would think. Fair enough. I'll reply to this with a new version.[0] [0] I wish there was a clean way to include the new version inline, but as I've noted before, there doesn't seem to be: http://article.gmane.org/gmane.comp.version-control.git/146110 -- 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/githooks: Explain pre-rebase parameters
W. Trevor King wk...@tremily.us writes:
From: W. Trevor King wk...@tremily.us
Descriptions borrowed from templates/hooks--pre-rebase.sample.
Signed-off-by: W. Trevor King wk...@tremily.us
---
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase ${1+$@}
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
$ man bash | grep '\${.*[+]'
(${BASH_SOURCE[$i+1]}) where ${FUNCNAME[$i]} was called (or
${BASH_SOURCE[$i+1]}.
${BASH_SOURCE[$i+1]} at line number ${BASH_LINENO[$i]}. The
${parameter:+word}
In my local tests, it seems equivalent to $@.
Also, it appears that the `git-rebase--*.sh` handlers don't use the
pre-rebase hook. Is this intentional?
The codeflow of git-rebase front-end, when you start rebasing, will
call run_pre_rebase_hook before calling run_specific_rebase. It
will be redundant for handlers to then call it again, no?
In rebase --continue and later steps, you would not want to see
the hook trigger.
Documentation/githooks.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..bc837c6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -140,9 +140,10 @@ the outcome of 'git commit'.
pre-rebase
~~
-This hook is called by 'git rebase' and can be used to prevent a branch
-from getting rebased.
-
+This hook is called by 'git rebase' and can be used to prevent a
+branch from getting rebased. The hook takes two parameters: the
+upstream the series was forked from and the branch being rebased. The
+second parameter will be empty when rebasing the current branch.
Technically this is incorrect.
We call it with one or two parameters, and sometimes the second
parameter is _missing_, which is different from calling with an
empty string. For a script written in some scripting languages like
shell and perl, the distinction may not matter (i.e. $2 and $ARGV[1]
will be an empty string when stringified) but not all (accessing
sys.argv[2] may give you an IndexError in Python).
--
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] Bugfix: undefined htmldir in config.mak.autogen
Jiang Xin worldhello@gmail.com writes: Html documents will be installed to root dir (/) no matter what prefix is set, if run these commands before `make` and `make install-html`: $ make configure $ ./configure --prefix=PREFIX After the installation, all the html documents will copy to rootdir (/), and: $ git --html-path PREFIX $ git help -w something fatal: 'PREFIX': not a documentation directory. This is because the variable htmldir points to a undefined variable $(docdir) in file config.mak.autogen, which is generated by running `./configure`. This bug comes from commit fc1c541 (Honor configure's htmldir switch), since v1.8.1.3-537-g1d321. Add the required two variables PACKAGE_TARNAME and docdir to file config.mak.in will resolve this problem. Signed-off-by: Jiang Xin worldhello@gmail.com --- Who references PACKAGE_TARNAME and how is the symbol used? config.mak.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mak.in b/config.mak.in index d7c49..fa02bd 100644 --- a/config.mak.in +++ b/config.mak.in @@ -8,6 +8,7 @@ LDFLAGS = @LDFLAGS@ AR = @AR@ TAR = @TAR@ DIFF = @DIFF@ +PACKAGE_TARNAME = @PACKAGE_TARNAME@ #INSTALL = @INSTALL@ # needs install-sh or install.sh in sources prefix = @prefix@ @@ -17,6 +18,7 @@ gitexecdir = @libexecdir@/git-core datarootdir = @datarootdir@ template_dir = @datadir@/git-core/templates sysconfdir = @sysconfdir@ +docdir = @docdir@ mandir = @mandir@ htmldir = @htmldir@ -- 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 Merge 2013 Conference, Berlin
Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? No, it's because 300 people signed up and that's all the venue has room for. I'm sure we can fit one more if you come. Hmph. git shortlog -s -n --since=18.months master tells me that we have 284 contributors to my tree during the said period. I do not remember if I signed-up for the dev-day or any other days myself. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] check-ignore.c, dir.c: fix segfault with '.' argument from repo root
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored, but of
course it should not segfault in this case. The existing code
attempted to check for this case but failed due to using the wrong
variable. Instead we move the check to last_exclude_matching_path(),
in case other callers present or future have a similar issue.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/check-ignore.c | 2 +-
dir.c | 8
t/t0008-ignores.sh | 5 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..0240f99 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char
**pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] path[0]) {
+ if (!seen[i]) {
exclude = last_exclude_matching_path(check, full_path,
-1, dtype);
if (exclude) {
diff --git a/dir.c b/dir.c
index 57394e4..1ae0b90 100644
--- a/dir.c
+++ b/dir.c
@@ -828,6 +828,14 @@ struct exclude *last_exclude_matching_path(struct
path_exclude_check *check,
struct exclude *exclude;
/*
+* name could be the empty string, e.g. if check-ignore was
+* invoked from the top level with '.', prefix_path() will
+* convert it into .
+*/
+ if (!*name)
+ return NULL;
+
+ /*
* we allow the caller to pass namelen as an optimization; it
* must match the length of the name, as we eventually call
* is_excluded() on the whole name string.
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat -\EOF .gitignore
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore 128
stderr_contains fatal: no path specified
--
1.8.2.rc0.18.g543d1e4
--
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 Merge 2013 Conference, Berlin
Hey, On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote: Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? No, it's because 300 people signed up and that's all the venue has room for. I'm sure we can fit one more if you come. Hmph. git shortlog -s -n --since=18.months master tells me that we have 284 contributors to my tree during the said period. I do not remember if I signed-up for the dev-day or any other days myself. 300 is the number of people signed up for the User Day. There is a Dev Day, for contributors, which has 50 signed up. If anyone on this list or any other core Git devs want to attend and did not sign up, or would like financial assistance getting to or staying in Germany, please let me know. The second day is a User Day, which is when 300 people will be there. This is a day for short talks, idea generation and feedback. The third day is Hack Day, which will have about 200. This is a day for working on stuff. Scott -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re* [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
Adam Spiers g...@adamspiers.org writes:
Fair enough. I'll reply to this with a new version.[0]
[0] I wish there was a clean way to include the new version inline,
but as I've noted before, there doesn't seem to be:
http://article.gmane.org/gmane.comp.version-control.git/146110
I find it easier to later find the patch if you made it a separate
follow-up like you did, but you can do it this way if you really
want to, using a scissors line, like so. Please do not try to be
creative and change the shape of scissors just for the sake of
chaning it.
-- 8 --
Subject: name-hash: allow hashing an empty string
Usually we do not pass an empty string to the function hash_name()
because we almost always ask for hash values for a path that is a
candidate to be added to the index. However, check-ignore (and most
likely check-attr, but I didn't check) apparently has a callchain
to ask the hash value for an empty path when it was given a . from
the top-level directory to ask Is the path . excluded by default?
Make sure that hash_name() does not overrun the end of the given
pathname even when it is empty.
Also remove a sweep-the-issue-under-the-rug conditional in
check-ignore that avoided to pass an empty string to the callchain.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/check-ignore.c | 2 +-
name-hash.c| 4 ++--
t/t0008-ignores.sh | 5 +
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..0240f99 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char
**pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] path[0]) {
+ if (!seen[i]) {
exclude = last_exclude_matching_path(check, full_path,
-1, dtype);
if (exclude) {
diff --git a/name-hash.c b/name-hash.c
index d8d25c2..942c459 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -24,11 +24,11 @@ static unsigned int hash_name(const char *name, int namelen)
{
unsigned int hash = 0x123;
- do {
+ while (namelen--) {
unsigned char c = *name++;
c = icase_hash(c);
hash = hash*101 + c;
- } while (--namelen);
+ }
return hash;
}
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat -\EOF .gitignore
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore 128
stderr_contains fatal: no path specified
--
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 2/2] check-ignore.c, dir.c: fix segfault with '.' argument from repo root
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string.
The description does not match what I understand is happening from
the original report, though. The above is more like this, no?
When check-ignore is run with the '.' argument from the top level of
a repository, it fed an empty string to hash_name() in name-hash.c
and caused a segfault, as the function kept reading forever past the
end of the string.
A point to note is that it is not cleaer why it is a corner case to
ask about a pathspec .. It is a valid question Is the whole tree
ignored by default?, isn't it?
It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored,
And this sounds like a really bad excuse. If it were it does not
make *any* sense ... because the top level is *never* ignored, then
the patch is a perfectly fine optimization that happens to work
around the problem, but the use of much and typically is a sure
sign that the design of the fix is iffy. It also shows that the
patch is not a fix, but is sweeping the problem under the rug, if
there were a valid use case to set the top level to be ignored.
I wonder what would happen if we removed that path[0] check
from the caller, not add the assume the top is never ignored
workaround, and do something like this to the location that causes
segv, so that it can give an answer when asked to hash an empty
string?
Does the callchain that goes down to this function have other places
that assume they will never see an empty string, like this function
does, which I _think_ is the real issue?
name-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/name-hash.c b/name-hash.c
index d8d25c2..942c459 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -24,11 +24,11 @@ static unsigned int hash_name(const char *name, int namelen)
{
unsigned int hash = 0x123;
- do {
+ while (namelen--) {
unsigned char c = *name++;
c = icase_hash(c);
hash = hash*101 + c;
- } while (--namelen);
+ }
return hash;
}
--
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] l10n: de.po: translate 5 new messages
Ralf Thielow ralf.thie...@gmail.com writes:
msgid You are currently bisecting branch '%s'.
-msgstr Sie sind gerade beim Halbieren.
+msgstr Sie sind gerade beim Halbieren in Zweig '%s'.
I know this one is already in other messages (and also in the Glossary),
but I still find it iffy and I might finally have a better idea:
Sie sind gerade an einer binären Suche in Zweig '%s'.
[note to English speakers: I'm just using binary search instead of
bisect]
That makes it quite a bit harder to use it in a verbed[1] form, but I
think it gets the concept across much better. (And in all the usage I
know in CS, the two things refer to the same.)
ACK on the rest.
Footnotes:
[1] Verbing weirds language. -- Calvin
--
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
[PATCH] fixup! Documentation/git-commit.txt: rework the --cleanup section
Hi, Brandon Casey wrote: Signed-off-by: Brandon Casey draf...@gmail.com This renders as --cleanup=mode This option determines how the supplied commit message should be cleaned up before committing. The mode can be strip, whitespace, verbatim, or default. strip Strip leading and trailing empty lines, trailing whitespace, and #commentary and collapse consecutive empty lines. whitespace Same as strip except #commentary is not removed. verbatim Do not change the message at all. default strip if the message is to be edited. Otherwise whitespace. The default can be changed by the 'commit.cleanup' config variable (see linkgit:git-config[1]). Problems: * There's a weird extra blank line after default * Wrong indentation for the final paragraph. * The linkgit isn't resolved for some reason. The following fixes it for me. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Documentation/git-commit.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 992c219..24a99cc 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -185,11 +185,12 @@ whitespace:: verbatim:: Do not change the message at all. default:: - `strip` if the message is to be edited. Otherwise `whitespace`. + Same as `strip` if the message is to be edited. + Otherwise `whitespace`. -- + - The default can be changed by the 'commit.cleanup' configuration - variable (see linkgit:git-config[1]). +The default can be changed by the 'commit.cleanup' configuration +variable (see linkgit:git-config[1]). -e:: --edit:: -- 1.8.1.3 -- 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] fixup! Documentation/git-commit.txt: rework the --cleanup section
On Tue, Feb 19, 2013 at 12:28 PM, Jonathan Nieder jrnie...@gmail.com wrote: Hi, Brandon Casey wrote: Problems: * There's a weird extra blank line after default * Wrong indentation for the final paragraph. * The linkgit isn't resolved for some reason. The following fixes it for me. Thanks Jonathan. -Brandon -- 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 4/4] Documentation/git-commit.txt: rework the --cleanup section
Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- [RESEND] I originally specified Junio's address as gits...@pobox.org. [RESEND] Sorry, now with the correct address. Ok, here's the updated text. I am not set up to build the documentation, so I hope someone will test, but looks right to me. Thanks for marking this as unverified. Jonathan, thanks for the fixup. -- 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 v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
W. Trevor King wk...@tremily.us writes: On Tue, Feb 19, 2013 at 10:47:04AM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - +$ git format-patch origin +$ git reset --hard origin - Technically speaking, this does not reset to before the patches. You would need git reset --hard $(git merge-base origin HEAD) or something like that. They'll be fine if they haven't fetched since they started their branch ;). It does look like I've got an extra comma an a missing “and”. What about: …create series of patches and then reset… The original doesn't look too odd to me, but I'll amend to what you just wrote. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Merge 2013 Conference, Berlin
Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote: Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? No, it's because 300 people signed up and that's all the venue has room for. I'm sure we can fit one more if you come. ... 300 is the number of people signed up for the User Day. There is a Dev Day, for contributors, which has 50 signed up. Ah, sorry I misunderstood. So your 300 above was about the user day, and Dev day has different capacity but has already sold out at 50 seats. -- 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-p4: Importing a Git repository into Perforce without rebasing
Hi, On Tue, Feb 19, 2013 at 3:40 AM, Russell Myers mez...@russellmyers.com wrote: I'm trying to take a Git repository which has never been in Perforce and push it to Perforce and having difficulty. [...] I know that I could create another Git repository that has some commits in it cloned from Perforce and rebase on top of that; however, the repository I'm trying to import is rather large and rebasing would require me to change many merge commits. I'd like to avoid doing this. The repository has many thousands of commits in it. So your history is not linear and contains merges. In short my question is this: Using git-p4, is there a way to push a Git repository into Perforce without rebasing on top of commits coming from Perforce? No, this is not supported. Non-linear history would be a problem for git-p4 too, so that alone wouldn't solve your problem. git-p4 does not have the logic needed to submit merges back to Perforce. - Thomas -- 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 2/2] check-ignore.c, dir.c: fix segfault with '.' argument from repo root
Junio C Hamano gits...@pobox.com writes:
And this sounds like a really bad excuse. If it were it does not
make *any* sense ... because the top level is *never* ignored, then
the patch is a perfectly fine optimization that happens to work
around the problem, but the use of much and typically is a sure
sign that the design of the fix is iffy. It also shows that the
patch is not a fix, but is sweeping the problem under the rug, if
there were a valid use case to set the top level to be ignored.
I wonder what would happen if we removed that path[0] check
from the caller, not add the assume the top is never ignored
workaround, and do something like this to the location that causes
segv, so that it can give an answer when asked to hash an empty
string?
Does the callchain that goes down to this function have other places
that assume they will never see an empty string, like this function
does, which I _think_ is the real issue?
I started to suspect that may be the right approach. Why not do this?
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Tue, 19 Feb 2013 11:56:44 -0800
Subject: [PATCH] name-hash: allow hashing an empty string
Usually we do not pass an empty string to the function hash_name()
because we almost always ask for hash values for a path that is a
candidate to be added to the index. However, check-ignore (and most
likely check-attr, but I didn't check) apparently has a callchain
to ask the hash value for an empty path when it was given a . from
the top-level directory to ask Is the path . excluded by default?
Make sure that hash_name() does not overrun the end of the given
pathname even when it is empty.
Remove a sweep-the-issue-under-the-rug conditional in check-ignore
that avoided to pass an empty string to the callchain while at it.
It is a valid question to ask for check-ignore if the top-level is
set to be ignored by default, even though the answer is most likely
no, if only because there is currently no way to specify such an
entry in the .gitignore file. But it is an unusual thing to ask and
it is not worth optimizing for it by special casing at the top level
of the call chain.
Signed-off-by: Adam Spiers g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/check-ignore.c | 2 +-
name-hash.c| 4 ++--
t/t0008-ignores.sh | 5 +
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..0240f99 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char
**pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] path[0]) {
+ if (!seen[i]) {
exclude = last_exclude_matching_path(check, full_path,
-1, dtype);
if (exclude) {
diff --git a/name-hash.c b/name-hash.c
index d8d25c2..942c459 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -24,11 +24,11 @@ static unsigned int hash_name(const char *name, int namelen)
{
unsigned int hash = 0x123;
- do {
+ while (namelen--) {
unsigned char c = *name++;
c = icase_hash(c);
hash = hash*101 + c;
- } while (--namelen);
+ }
return hash;
}
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat -\EOF .gitignore
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore 128
stderr_contains fatal: no path specified
--
1.8.2.rc0.89.g6e4b41d
--
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: feature request
On Mon, Feb 18, 2013 at 12:45 PM, Jeff King p...@peff.net wrote: The thing that makes 2FA usable in the web browser setting is that you authenticate only occasionally, and get a token (i.e., a cookie) from the server that lets you have a longer session without re-authenticating. Right, otherwise you spend all day typing in your credentials and syncing with the 2nd factor device. I suspect a usable 2FA scheme for http pushes would involve a special credential helper that did the 2FA auth to receive a cookie on the first use, cached the cookie, and then provided it for subsequent auth requests. That would not necessarily involve changing git, but it would mean writing the appropriate helper (and the server side to match). I seem to recall Shawn mentioning that Google does something like this internally, but I don't know the details[1]. ... [1] I don't know if Google's system is based on the Google Authenticator system. But it would be great if there could be an open, standards-based system for doing 2FA+cookie authentication like this. I'd hate to have the GitHub credential helper and the Google credential helper. I'm not well-versed enough in the area to know what's feasible and what the standards are. Yes, it is based on the Google Authenticator system, but that's not relevant to how Git works with it. :-) We have a special git-remote-sso helper we install onto corporate workstations. This allows Git to understand the sso:// protocol. git-remote-sso is a small application that: - reads the URL from the command line, - makes sure a Netscape style cookies file has a current cookie for the named host, - acquires or updates cookie if necessary - rewrites the URL to be https:// - execs `git -c http.cookiefile=$cookiefile remote-https $URL` The way 2FA works is the user authenticates to a special internal SSO management point in their web browser once per period (I decline to say how often but its tolerable). Users typically are presented this SSO page anyway by other applications they visit, or they bookmark the main entry point. A Chrome or Firefox extension has been installed and authorized to steal cookies from this host. The extension writes the user's cookie to a local file on disk. Our git-remote-sso tool uses this cookie file to setup per-host cookies on demand within the authentication period. Horrifically hacky. It would be nice if this was more integrated into Git itself, where the cookies could be acquired/refreshed through the credential helper system rather than wrapping git-remote-https with a magical URL. I am a fan of the way our extension manages to get the token conveyed automatically for me. Much easier than the OAuth flows[2], but harder to replicate in the wild. Our IT group makes sure the extension is installed on workstations as part of the base OS image. [2] https://developers.google.com/storage/docs/gsutil_install#authenticate -- 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 Merge 2013 Conference, Berlin
Hey, On Tue, Feb 19, 2013 at 1:26 PM, Junio C Hamano gits...@pobox.com wrote: Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote: Scott Chacon scha...@gmail.com writes: On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Michael J Gruber venit, vidit, dixit 19.02.2013 16:20: Well, all days are listed as sold out on the eventbrite site. Maybe it's because eventbrite has trouble connecting to facebook because I don't have facebook? No, it's because 300 people signed up and that's all the venue has room for. I'm sure we can fit one more if you come. ... 300 is the number of people signed up for the User Day. There is a Dev Day, for contributors, which has 50 signed up. Ah, sorry I misunderstood. So your 300 above was about the user day, and Dev day has different capacity but has already sold out at 50 seats. Yes. There is only so much room and I didn't want to overload the dev day. Those of you who want to come on any of these days are still welcome, I just don't want more random people signing up. If you still wish to attend, simply email me personally and I will add you. Junio, are you interested in attending? Scott -- 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] Bugfix: undefined htmldir in config.mak.autogen
Jiang Xin worldhello@gmail.com writes:
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=PREFIX
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
PREFIX
$ git help -w something
fatal: 'PREFIX': not a documentation directory.
I am not sure if this description is correct. The generated configure
seems to set
datarootdir='${prefix}/share'
htmldir='${docdir}'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
so it is likely you would get not PREFIX but PREFIX/share, no?
In the main Makefile, we set htmldir to share/doc/git-doc and that
is supposed to be relative to PREFIX, so the above will be wrong in
multiple ways (it is an absolute path with PREFIX/ in front, and
it ends not with share/doc/git-doc but with share/doc/git).
And the worst part is that having to know that the file needs to
export docdir and PACKAGE_TARNAME feels to me that we are tying
ourselves to too much detail in the internal implementation detail
of versions of autoconf we happen to have for testing this change.
I am inclined to suggest that we probably should
* revert fc1c5415d69d (Honor configure's htmldir switch,
2013-02-02); and
* fix generated ./configure --help not to suggest that --htmldir
can be overriden from its command line;
instead of piling on a broken fix like this one top of it.
--
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 2/2] check-ignore.c, dir.c: fix segfault with '.' argument from repo root
On Tue, Feb 19, 2013 at 7:59 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string.
The description does not match what I understand is happening from
the original report, though.
Why not?
The above is more like this, no?
When check-ignore is run with the '.' argument from the top level of
a repository, it fed an empty string to hash_name() in name-hash.c
and caused a segfault, as the function kept reading forever past the
end of the string.
The only difference I can see between the two is that yours has
changed the phrase order and gives a bit more information. I don't
see any disagreement between them though.
A point to note is that it is not cleaer why it is a corner case to
ask about a pathspec .. It is a valid question Is the whole tree
ignored by default?, isn't it?
It's probably valid, but I'm not the best judge of that. It doesn't
make much sense to me why anyone would do that, and it seems very
unlikely it would be a common use case, therefore it's a corner case.
The next sentence then qualifies that:
It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored,
And this sounds like a really bad excuse.
An excuse for what? The final part of that sentence which you trimmed
made it clear that it was not an excuse for the segfault. Your choice
of wording here sounds more like a personal attack than a technical
discussion - presumably unintentional, so I'll choose not to take
offense.
If it were it does not
make *any* sense ... because the top level is *never* ignored, then
the patch is a perfectly fine optimization that happens to work
around the problem, but the use of much and typically is a sure
sign that the design of the fix is iffy. It also shows that the
patch is not a fix, but is sweeping the problem under the rug, if
there were a valid use case to set the top level to be ignored.
There *may* be a valid use case to set the top level to be ignored.
*I* can't think of one personally, therefore it doesn't make sense to
me to do so, but my intention was to avoid imposing my own personal
judgement on everyone else by preventing people from doing that.
However, in that case I now realise that check-ignore should report a
match, and my proposed patches do not do that. Perhaps that is what
you meant by sweeping the problem under the rug?
I wonder what would happen if we removed that path[0] check
from the caller, not add the assume the top is never ignored
workaround, and do something like this to the location that causes
segv, so that it can give an answer when asked to hash an empty
string?
name-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/name-hash.c b/name-hash.c
index d8d25c2..942c459 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -24,11 +24,11 @@ static unsigned int hash_name(const char *name, int
namelen)
{
unsigned int hash = 0x123;
- do {
+ while (namelen--) {
unsigned char c = *name++;
c = icase_hash(c);
hash = hash*101 + c;
- } while (--namelen);
+ }
return hash;
}
Yep, that makes sense - that's what I meant when I said I was
wondering whether hash_name() should do stricter input validation.
Does the callchain that goes down to this function have other places
that assume they will never see an empty string, like this function
does, which I _think_ is the real issue?
Good question. In the absence of a proper audit for similar issues,
it definitely makes sense to defensively program hash_name() (and any
other low-level functions which accept path strings).
--
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] Bugfix: undefined htmldir in config.mak.autogen
2013/2/20 Junio C Hamano gits...@pobox.com:
Junio C Hamano gits...@pobox.com writes:
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
PREFIX
$ git help -w something
fatal: 'PREFIX': not a documentation directory.
I am not sure if this description is correct. The generated configure
seems to set
datarootdir='${prefix}/share'
htmldir='${docdir}'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
so it is likely you would get not PREFIX but PREFIX/share, no?
This was a mis-diag; without docdir mentioned in config.mak.in, we
do not even get that far, and htmldir will end up being empty, and
the runtime code adds PREFIX to it in system_path(). What I was
describing was what happens when you only mention @docdir@ but not
PACKAGE_TARNAME in the file.
I also doubt about it after sleep, so I check it again:
## gettext is installed in non-standard location on Mac
$ export CFLAGS=-I/usr/local/include; export LDFLAGS=-L/usr/local/lib
$ make config
$ ./configure --prefix=/opt/git/v1.8.2
$ make sudo make install
## already symlink /opt/git/v1.8.2/bin/* to /usr/local/bin/
$ git --html-path
/opt/git/v1.8.2/
$ git help -w help
fatal: '/opt/git/v1.8.2/': not a documentation directory.
And the worst part is that having to know that the file needs to
export docdir and PACKAGE_TARNAME feels to me that we are tying
ourselves to too much detail in the internal implementation detail
of versions of autoconf we happen to have for testing this change.
I am not familiar with autoconf. After clone autoconf and check,
I cannot find a neat way to change htmldir default location to
use ${datarootdir} (just like mandir).
In file lib/autoconf/general.m4, there are:
AC_SUBST([docdir], [m4_ifset([AC_PACKAGE_TARNAME],
['${datarootdir}/doc/${PACKAGE_TARNAME}'],
['${datarootdir}/doc/${PACKAGE}'])])dnl
...
AC_SUBST([htmldir],['${docdir}'])dnl
...
AC_SUBST([pdfdir], ['${docdir}'])dnl
...
AC_SUBST([mandir], ['${datarootdir}/man'])dnl
This still stands. It really feels wrong that this file has to be
aware of such an implementation detail of autoconf. But as an
interim workaround, setting these two otherwise unused variables may
be the best we could do.
I am not sure if such a layout can be actually used for installing,
though. Didn't we see some issues around the relativeness of
htmldir and mandir vs passing them down to Documentation/Makefile,
or is it not an issue when ./configure and config.mak.autogen is
used?
--
蒋鑫
北京群英汇信息技术有限公司
邮件: worldhello@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 010-51262007, 18601196889
--
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 2/2] check-ignore.c, dir.c: fix segfault with '.' argument from repo root
On Tue, Feb 19, 2013 at 02:03:01PM -0800, Junio C Hamano wrote: I started to suspect that may be the right approach. Why not do this? -- 8 -- From: Junio C Hamano gits...@pobox.com Date: Tue, 19 Feb 2013 11:56:44 -0800 Subject: [PATCH] name-hash: allow hashing an empty string Usually we do not pass an empty string to the function hash_name() because we almost always ask for hash values for a path that is a candidate to be added to the index. However, check-ignore (and most likely check-attr, but I didn't check) apparently has a callchain to ask the hash value for an empty path when it was given a . from the top-level directory to ask Is the path . excluded by default? According to a single gdb run, 'git check-attr -a .' does not hit hash_name() for me. However that naive experiment doesn't rule out the possibility of it happening if the right attributes are set, but I don't know enough about that code to comment. Make sure that hash_name() does not overrun the end of the given pathname even when it is empty. Remove a sweep-the-issue-under-the-rug conditional in check-ignore that avoided to pass an empty string to the callchain while at it. It is a valid question to ask for check-ignore if the top-level is set to be ignored by default, even though the answer is most likely Hmm, I see very little difference between the use of most likely and the use of the words much and typically which you previously considered a sure sign that the design of the fix is iffy. no, if only because there is currently no way to specify such an entry in the .gitignore file. But it is an unusual thing to ask and it is not worth optimizing for it by special casing at the top level of the call chain. Although I agree with your proposed patch's sentiment of avoiding sweeping this corner case under the rug, 'check-ignore .' still wouldn't match anything if for example './' was a supported mechanism for ignoring the top level. So, modulo the obvious advantages that defensive coding in hash_name() bring, I'm struggling to see a significant difference between any of the three patches proposed so far. All of them fix the segfault, and all would require the same amount of extra work in order to support matching against './'. But I don't have any strong objections either, so you have my approval for whichever patch you prefer to take. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re* [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
On Tue, Feb 19, 2013 at 11:56:44AM -0800, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: Fair enough. I'll reply to this with a new version.[0] [0] I wish there was a clean way to include the new version inline, but as I've noted before, there doesn't seem to be: http://article.gmane.org/gmane.comp.version-control.git/146110 I find it easier to later find the patch if you made it a separate follow-up like you did, but you can do it this way if you really want to, using a scissors line, like so. Please do not try to be creative and change the shape of scissors just for the sake of chaning it. [snipped] OK, thanks for the information. IMHO it would be nice if 'git format-patch' and 'git am' supported this style of inline patch inclusion, but maybe there are good reasons to discourage it? -- 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: Re* [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
Adam Spiers g...@adamspiers.org writes: OK, thanks for the information. IMHO it would be nice if 'git format-patch' and 'git am' supported this style of inline patch inclusion, but maybe there are good reasons to discourage it? git am --scissors is a way to process such e-mail where the patch submitter continues discussion in the top part of a message, concludes the message with: A patch to do so is attached. -- 8 -- and then tells the MUA to read in an output from format-patch into the e-mail buffer. You still need to strip out unneeded headers like the From , From: and Date: lines when you add the scissors anyway, and this is applicable only for a single-patch series, so the feature does not fit well as a format-patch option. -- 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 1/4] difftool: silence uninitialized variable warning
Git::config() returns `undef` when given keys that do not exist.
Check that the $guitool value is defined to prevent a noisy
Use of uninitialized variable $guitool in length warning.
Signed-off-by: David Aguilar dav...@gmail.com
---
Unchanged from last time but included in the series for convenience.
git-difftool.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 0a90de4..12231fb 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -336,7 +336,7 @@ sub main
}
if ($opts{gui}) {
my $guitool = Git::config('diff.guitool');
- if (length($guitool) 0) {
+ if (defined($guitool) length($guitool) 0) {
$ENV{GIT_DIFF_TOOL} = $guitool;
}
}
--
1.8.2.rc0.20.gf548dd7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] t7800: update copyright notice
Signed-off-by: David Aguilar dav...@gmail.com --- t/t7800-difftool.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh index eb1d3f8..5b5939b 100755 --- a/t/t7800-difftool.sh +++ b/t/t7800-difftool.sh @@ -1,6 +1,6 @@ #!/bin/sh # -# Copyright (c) 2009, 2010 David Aguilar +# Copyright (c) 2009, 2010, 2012, 2013 David Aguilar # test_description='git-difftool -- 1.8.2.rc0.20.gf548dd7 -- 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 3/4] t7800: modernize tests
Eliminate a lot of redundant work by using test_config().
Catch more return codes by more use of temporary files
and test_cmp.
The original tests relied upon restore_test_defaults()
from the previous test to provide the next test with a sane
environment. Make the tests do their own setup so that they
are not dependent on the success of the previous test.
The end result is shorter tests and better test isolation.
Signed-off-by: David Aguilar dav...@gmail.com
---
We no longer export variables into the environment per Jonathan's
suggestion. This covers all of the review notes.
t/t7800-difftool.sh | 360
1 file changed, 165 insertions(+), 195 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 5b5939b..b577c01 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -10,29 +10,11 @@ Testing basic diff tool invocation
. ./test-lib.sh
-remove_config_vars()
+difftool_test_setup()
{
- # Unset all config variables used by git-difftool
- git config --unset diff.tool
- git config --unset diff.guitool
- git config --unset difftool.test-tool.cmd
- git config --unset difftool.prompt
- git config --unset merge.tool
- git config --unset mergetool.test-tool.cmd
- git config --unset mergetool.prompt
- return 0
-}
-
-restore_test_defaults()
-{
- # Restores the test defaults used by several tests
- remove_config_vars
- unset GIT_DIFF_TOOL
- unset GIT_DIFFTOOL_PROMPT
- unset GIT_DIFFTOOL_NO_PROMPT
- git config diff.tool test-tool
- git config difftool.test-tool.cmd 'cat $LOCAL'
- git config difftool.bogus-tool.cmd false
+ test_config diff.tool test-tool
+ test_config difftool.test-tool.cmd 'cat $LOCAL'
+ test_config difftool.bogus-tool.cmd false
}
prompt_given()
@@ -65,249 +47,237 @@ test_expect_success PERL 'setup' '
# Configure a custom difftool.tool.cmd and use it
test_expect_success PERL 'custom commands' '
- restore_test_defaults
- git config difftool.test-tool.cmd cat \$REMOTE
+ difftool_test_setup
+ test_config difftool.test-tool.cmd cat \$REMOTE
+ echo master expect
+ git difftool --no-prompt branch actual
+ test_cmp expect actual
- diff=$(git difftool --no-prompt branch)
- test $diff = master
-
- restore_test_defaults
- diff=$(git difftool --no-prompt branch)
- test $diff = branch
+ test_config difftool.test-tool.cmd cat \$LOCAL
+ echo branch expect
+ git difftool --no-prompt branch actual
+ test_cmp expect actual
'
-# Ensures that a custom difftool.tool.cmd overrides built-ins
-test_expect_success PERL 'custom commands override built-ins' '
- restore_test_defaults
- git config difftool.defaults.cmd cat \$REMOTE
-
- diff=$(git difftool --tool defaults --no-prompt branch)
- test $diff = master
-
- git config --unset difftool.defaults.cmd
+test_expect_success PERL 'custom tool commands override built-ins' '
+ test_config difftool.defaults.cmd cat \$REMOTE
+ echo master expect
+ git difftool --tool defaults --no-prompt branch actual
+ test_cmp expect actual
'
-# Ensures that git-difftool ignores bogus --tool values
test_expect_success PERL 'difftool ignores bad --tool values' '
- diff=$(git difftool --no-prompt --tool=bad-tool branch)
- test $? = 1
- test $diff =
+ : expect
+ test_expect_code 1 \
+ git difftool --no-prompt --tool=bad-tool branch actual
+ test_cmp expect actual
'
test_expect_success PERL 'difftool forwards arguments to diff' '
+ difftool_test_setup
for-diff
git add for-diff
echo changesfor-diff
git add for-diff
- diff=$(git difftool --cached --no-prompt -- for-diff)
- test $diff =
+ : expect
+ git difftool --cached --no-prompt -- for-diff actual
+ test_cmp expect actual
git reset -- for-diff
rm for-diff
'
test_expect_success PERL 'difftool honors --gui' '
- git config merge.tool bogus-tool
- git config diff.tool bogus-tool
- git config diff.guitool test-tool
-
- diff=$(git difftool --no-prompt --gui branch)
- test $diff = branch
+ difftool_test_setup
+ test_config merge.tool bogus-tool
+ test_config diff.tool bogus-tool
+ test_config diff.guitool test-tool
- restore_test_defaults
+ echo branch expect
+ git difftool --no-prompt --gui branch actual
+ test_cmp expect actual
'
test_expect_success PERL 'difftool --gui last setting wins' '
- git config diff.guitool bogus-tool
- git difftool --no-prompt --gui --no-gui
+ difftool_test_setup
+ : expect
+ git difftool --no-prompt --gui --no-gui actual
+ test_cmp expect actual
[PATCH v2 4/4] t7800: defaults is no longer a builtin tool name
073678b8e6324a155fa99f40eee0637941a70a34 reworked the mergetools/ directory so that every file corresponds to a difftool-supported tool. When this happened the defaults file went away as it was no longer needed by mergetool--lib. t7800 tests that configured commands can override builtins, but this test was not adjusted when the defaults file was removed because the test continued to pass. Adjust the test to use the everlasting vimdiff tool name instead of defaults so that it correctly tests against a tool that is known by mergetool--lib. Signed-off-by: David Aguilar dav...@gmail.com --- Rebased for the new parent patch. t/t7800-difftool.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh index b577c01..18df2c8 100755 --- a/t/t7800-difftool.sh +++ b/t/t7800-difftool.sh @@ -60,9 +60,9 @@ test_expect_success PERL 'custom commands' ' ' test_expect_success PERL 'custom tool commands override built-ins' ' - test_config difftool.defaults.cmd cat \$REMOTE + test_config difftool.vimdiff.cmd cat \$REMOTE echo master expect - git difftool --tool defaults --no-prompt branch actual + git difftool --tool vimdiff --no-prompt branch actual test_cmp expect actual ' -- 1.8.2.rc0.20.gf548dd7 -- 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] l10n: de.po: translate 5 new messages
Hi,
2013/2/19 Thomas Rast tr...@inf.ethz.ch:
Ralf Thielow ralf.thie...@gmail.com writes:
msgid You are currently bisecting branch '%s'.
-msgstr Sie sind gerade beim Halbieren.
+msgstr Sie sind gerade beim Halbieren in Zweig '%s'.
I know this one is already in other messages (and also in the Glossary),
but I still find it iffy and I might finally have a better idea:
Sie sind gerade an einer binären Suche in Zweig '%s'.
[note to English speakers: I'm just using binary search instead of
bisect]
That makes it quite a bit harder to use it in a verbed[1] form, but I
think it gets the concept across much better. (And in all the usage I
know in CS, the two things refer to the same.)
Very good idea! Thank you. I'll create a patch on top and update the
glossary.
ACK on the rest.
Thanks for review.
Footnotes:
[1] Verbing weirds language. -- Calvin
--
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: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 9:02 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 18.02.2013 20:34, schrieb Jonathan Nieder: That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). That's my experience too. Also I think it really makes sense to have a co-mentor so you can balance the load a bit. I'd be happy to help on a project with 1 or 2 co-mentors. Same here. I am ok to be mentor or co-mentor. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
On 10/29/2012 01:10 AM, Michael Haggerty wrote: How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a slowdown? Sorry to bring up this old thread again, but I just realized why my computer has been acting so slow when I’m not connected to the network. I put various network filesystem paths in $GIT_CEILING_DIRECTORIES, such as /afs/athena.mit.edu/user/a/n/andersk (to avoid hitting its parents /afs/athena.mit.edu, /afs/athena.mit.edu/user/a, and /afs/athena.mit.edu/user/a/n which all live in different AFS volumes). Now when I’m not connected to the network, every invocation of Git, including the __git_ps1 in my shell prompt, waits for AFS to timeout. Obviously I’m going to stop using $GIT_CEILING_DIRECTORIES now that I know what the problem is, but I figured you might want to know why this feature is now useless for me. Anders -- 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: Google Summer of Code 2013 (GSoC13)
On Mon, Feb 18, 2013 at 9:42 AM, Jeff King p...@peff.net wrote: On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote: * We need an org admin. AFAIK this was done by Peff and Shawn in tandem last year. Would you do it again? I will do it again, if people feel strongly about Git being a part of it. However, I have gotten a little soured on the GSoC experience. Not because of anything Google has done; it's a good idea, and I think they do a fine of administering the program. But I have noticed that the work that comes out of GSoC the last few years has quite often not been merged, or not made a big impact in the codebase, and nor have the participants necessarily stuck around. This. I actually think Git should take a year off from GSoC and not participate. Consequently I will not be volunteering as backup org admin. Git has been involved since 2007. In all of that time we have had very few student projects merge successfully into their upstream project (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer students have stuck around and remained active contributors. When I look at the amount of effort we contributors put into GSoC, I think we are misusing our limited time and resources. The intention of the GSoC program is to grow new open source developers, and increase our community of contributors. Somehow I think Git is falling well short of its potential here. This is especially true if you compare Git's GSoC program to some other equally long-running GSoC programs. And I do not want to blame the students here (some of whom are on the cc list :) ). They are certainly under no obligation to stick around after GSoC ends, and I know they have many demands on their time. But I am also thinking about what Git wants to get out of GSoC (and to my mind, the most important thing is contributors). I agree, our students have been pretty terrific. I think the shortcomings in our GSoC program are on the mentoring side. Our program has not really had much success with keeping students active and engaged post GSoC. I see that primarily as a mentoring failure. And its one we keep repeating each year. As far as merged code, I think part of the problem is that git is fairly mature at this point. The most interesting projects are of a bigger scope than a student with no experience in the code base can do in a summer project. Maybe that means we need to do a better job of breaking projects down into reasonably sized sub-components. Or maybe it means the project is hitting a point of diminishing returns for GSoC. I don't know. Let me repeat myself. I think our GSoC program has plenty of room for improvement on the mentoring side. Project scope and size is one of our most common failure modes. Resumable clone keeps winding up on the GSoC project idea list. Nobody who knows what they are talking about has any idea how to approach this feature[1]. Suggesting it to a GSoC student is just irresponsible[2]. I don't think Git's maturity is a road block for successful GSoC projects. Peff's toy to insert Lua so `git log` could do fancy formatting is an interesting one. I suspect there are still fun archeology sorts of projects that could further improve the type of data we can mine through log and blame. But touching the core file formats on disk or the wire protocol is probably far too large for a GSoC project. [1] Android's repo tool and its /clone.bundle hack on HTTP transports might work. Peff has talked about putting this into Git itself one day. Maybe. But its still full of a ton of shortcomings and somewhat hated by those that have to build the bundles and manage the server infrastructure. So its probably still outside of the scope of a successful GSoC project. [2] I recognize and accept my share of blame for putting it on the list a few times. There are a few counterpoints I can think of: - Even though not all projects are winners, _some_ are. I see Carlos and Ram on the cc list, two people who started as GSoC students and stuck around. I think these interesting cases like Carlos and Ram are places where the student was able to succeed almost despite our mentoring program. I am very glad they did. - There is also the angle that even if _Git_ doesn't benefit directly from people sticking around, those people may float into other open source projects and work on them. Which makes the world a better place on the whole. Yes, sure, OK. But if Git doesn't participate in GSoC this year another org will, and this same benefit will still be had by the greater open source community. -- 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
