* [PATCH 7/8] contrib/subtree: Remove --annotate
From: David A. Greene @ 2013-02-18 20:56 UTC (permalink / raw)
To: git, Techlive Zheng, James Nylen; +Cc: David A. Greene
In-Reply-To: <1361221013-12756-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Remove --annotate. This obviates the need for an --unannotate
command. We really want a more generalized commit message rewrite
mechanism.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 6 +----
contrib/subtree/t/t7900-subtree.sh | 50 ++++++++++++++++++------------------
2 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 1b3df99..2aceadc 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,7 +21,6 @@ d show debug messages
P,prefix= the name of the subdir to split out
m,message= use the given message as the commit message for the merge commit
options for 'split'
-annotate= add a prefix to commit message of new commits
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,7 +42,6 @@ command=
onto=
rejoin=
ignore_joins=
-annotate=
squash=
message=
@@ -79,8 +77,6 @@ while [ $# -gt 0 ]; do
case "$opt" in
-q) quiet=1 ;;
-d) debug=1 ;;
- --annotate) annotate="$1"; shift ;;
- --no-annotate) annotate= ;;
-b) branch="$1"; shift ;;
-P) prefix="${1%/}"; shift ;;
-m) message="$1"; shift ;;
@@ -311,7 +307,7 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n "$annotate"; cat ) |
+ (echo -n ""; cat ) |
git commit-tree "$2" $3 # reads the rest of stdin
) || die "Can't copy commit $1"
}
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index 5c6c73d..fa2a6c3 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -338,8 +338,8 @@ test_expect_success 'split subdir/ with --rejoin' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*") &&
- git subtree split --prefix=subdir --annotate="*" --rejoin &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --rejoin &&
test_equal "$(last_commit_message)" "Split '\''subdir/'\'' into commit '\''$split_hash'\''"
)
'
@@ -363,7 +363,7 @@ test_expect_success 'split subdir/ with --rejoin and --message' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --message="Split & rejoin" --annotate="*" --rejoin &&
+ git subtree split --prefix=subdir --message="Split & rejoin" --rejoin &&
test_equal "$(last_commit_message)" "Split & rejoin"
)
'
@@ -387,8 +387,8 @@ test_expect_success 'split subdir/ with --branch' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*") &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --branch subproj-br &&
test_equal "$(git rev-parse subproj-br)" "$split_hash"
)
'
@@ -413,8 +413,8 @@ test_expect_success 'split subdir/ with --branch for an existing branch' '
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- split_hash=$(git subtree split --prefix=subdir --annotate="*") &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br &&
+ split_hash=$(git subtree split --prefix=subdir) &&
+ git subtree split --prefix=subdir --branch subproj-br &&
test_equal "$(git rev-parse subproj-br)" "$split_hash"
)
'
@@ -466,7 +466,7 @@ test_expect_success 'make sure exactly the right set of files ends up in the sub
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -477,12 +477,12 @@ test_expect_success 'make sure exactly the right set of files ends up in the sub
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
@@ -517,7 +517,7 @@ test_expect_success 'make sure the subproj *only* contains commits that affect t
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -528,12 +528,12 @@ test_expect_success 'make sure the subproj *only* contains commits that affect t
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
@@ -568,7 +568,7 @@ test_expect_success 'make sure exactly the right set of files ends up in the mai
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -579,12 +579,12 @@ test_expect_success 'make sure exactly the right set of files ends up in the mai
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
@@ -623,7 +623,7 @@ test_expect_success 'make sure each filename changed exactly once in the entire
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -634,12 +634,12 @@ test_expect_success 'make sure each filename changed exactly once in the entire
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
@@ -682,7 +682,7 @@ test_expect_success 'make sure the --rejoin commits never make it into subproj'
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -693,12 +693,12 @@ test_expect_success 'make sure the --rejoin commits never make it into subproj'
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
@@ -731,7 +731,7 @@ test_expect_success 'make sure no "git subtree" tagged commits make it into subp
cd "$subtree_test_count" &&
git fetch ./subproj master &&
git subtree merge --prefix=subdir FETCH_HEAD &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count/subproj" sub3 &&
test_create_commit "$subtree_test_count" subdir/main-sub3 &&
@@ -742,12 +742,12 @@ test_expect_success 'make sure no "git subtree" tagged commits make it into subp
test_create_commit "$subtree_test_count/subproj" sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
test_create_commit "$subtree_test_count" subdir/main-sub4 &&
(
cd "$subtree_test_count" &&
- git subtree split --prefix=subdir --annotate="*" --branch subproj-br --rejoin
+ git subtree split --prefix=subdir --branch subproj-br --rejoin
) &&
(
cd "$subtree_test_count/subproj" &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH 8/8] Remove test artifaces from clean rule
From: David A. Greene @ 2013-02-18 20:56 UTC (permalink / raw)
To: git, Techlive Zheng, James Nylen; +Cc: David A. Greene
In-Reply-To: <1361221013-12756-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
There should be no need to remove 'mainline' nd 'subproj'
in the Makefile as these should always be created under the
test directory.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index b507505..09f4c9d 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -50,4 +50,3 @@ test:
clean:
rm -f *~ *.xml *.html *.1
- rm -rf subproj mainline
--
1.7.10.4
^ permalink raw reply related
* Re: Google Summer of Code 2013 (GSoC13)
From: Jeff King @ 2013-02-18 21:07 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jonathan Nieder, Thomas Rast, git, Shawn Pearce, Jakub Narebski,
Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com>
On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote:
> > - assimilating the distro builds: "make deb-pkg", "make rpm-pkg",
> > etc along the same lines as the linux kernel's script/package/,
> > to help people get recent git installed when they want it
>
> Overkill. I just symlink to bin-wrapper/git from a place high up in
> my $PATH. If anything, we should be making it easier for ourselves to
> run different versions of git right from $HOME, much like rbenv.
> System-wide installs are taken care of by the distribution package
> managers, and I doubt they need any help from us.
This is not related to GSoC anymore, but I think handling multiple
versions is already pretty easy. You can just install to
"$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git"
binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
already takes care of the messy bits, like making sure sub-programs are
invoked from the same git version.
I already do this automagically with this script:
https://github.com/peff/git/blob/meta/install/prefix
I just set "prefix" in the Makefile based on the script, and when I
"make install" tags or topic branches, they go to the right place (and
the "links" script in the same directory maintains the symlinks for me).
I never bothered to even submit those scripts to contrib, because I
figured they were so specific to my setup, and to keeping dozens of git
versions around (when debugging, it's nice to be able to check an old
version's behavior without even having to build it).
Of course that has nothing to do with Jonathan's proposal. I do agree
that it is pretty straightforward to just put $BUILD_DIR/bin-wrappers in
your PATH and be done. I guess that doesn't cover manpages, though (but
Real Programmers just read the source anyway, right?).
-Peff
^ permalink raw reply
* Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))
From: Jonathan Nieder @ 2013-02-18 21:11 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jeff King, Thomas Rast, git, Shawn Pearce, Jakub Narebski,
Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0mKZLotuu7pEM_3Of3i6JzU12QV_pHxOZTUr22TOq3PeQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> - cross-compilable git
>
> Why, exactly? Git for embedded devices?
My personal motivation would be building Git for Windows while
spending as little time on Windows as possible. People deploying git
to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also
find it handy.
>> - incorporation of the cgit web interface, or formalizing a subset of
>> libgit.a to export as a stable library to it
>
> I didn't understand this: you want cgit in-tree?
Yes, or a stable API that cgit out-of-tree can use.
>> - moving forward on a project that was the subject of a previous
>> gsoc project: line-level logging, "rebase --interactive" on top of
>> sequencer, usable svn remote helper
>
> I can't see a roadmap for gradually phasing out `rebase -i` as more
> and more of its functionality is built into the sequencer.
It's a break-the-world thing. "rebase -i --experimental".
[...]
> For usable svn remote helper, the major TODO is a git -> svn bridge.
There are other major TODOs, too.
[...]
>> - drag-and-drop cherry-pick in gitk
>
> You expect someone to write Tcl/Tk today?
Sure, why not? Tcl is not actually too unpleasant of a language.
Maybe it has a prerequisite, though:
- "modular gitk" (splitting gitk into digestible pieces)
[...]
>> - assimilating the distro builds:
[...]
> Overkill.
My itch is that it would let me send packaging patches to the list
and get the usual high-quality feedback. Oh well. ;-)
[...]
>> - collaborative notes editing: fix the default notes refspec,
>> make sure the "notes pull" workflow works well and is documented
>> well, offer an easy way to hide private notes after the fact
>> without disrupting public history
>
> I personally don't care for notes much, because I can't see practical
> usecases.
Are you sure that's not because of the poor current state of
collaborative notes editing?
Some example use cases:
- marking regressions discovered later, to warn people bisecting or
cherry-picking
- matching up to corresponding commits in another repository
- link to corresponding mailing list discussion, blog post, or
related patches
- a wiki-like document storing review comments
- marking which CVE this fixes, once the CVE number has been
allocated
- "a tour of the project" for new contributors, using explanatory
notes that end with a mention the next commit to look at
I'm not married to the current implementation, but I think the basic
idea of "git notes" is a promising feature that could use some polish.
Jonathan
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jeff King @ 2013-02-18 21:13 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0kFYP4k5=237PZ3XHhxkzF-RWwwe=3+Thb_xU2Jw5tg2g@mail.gmail.com>
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 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).
> No, I'm against using the GitHub Wiki for neutrality reasons.
Fair enough. I have the same reservations.
> 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).
-Peff
^ permalink raw reply
* Re: Git Merge 2013 Conference, Berlin
From: Jeff King @ 2013-02-18 21:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: Scott Chacon, git list
In-Reply-To: <87mwv1uyy5.fsf@pctrast.inf.ethz.ch>
On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
> Scott Chacon <schacon@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
^ permalink raw reply
* Re: [PATCHv2 04/10] pkt-line: change error message for oversized packet
From: Junio C Hamano @ 2013-02-18 21:25 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git, Shawn O. Pearce
In-Reply-To: <20130218094959.GA16408@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it's easy to do (1), and it starts the clock ticking for
> the 1000-byte readers to become obsolete.
Yup, I agree with that goal.
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: Junio C Hamano @ 2013-02-18 21:26 UTC (permalink / raw)
To: Drew Northup; +Cc: W. Trevor King, Git
In-Reply-To: <CAM9Z-nm1WbJ0ZCVGuSuuC8kJADXUD3e-tjB51kAEerSfFxVVLQ@mail.gmail.com>
Drew Northup <n1xim.email@gmail.com> writes:
> This looks safe to me, with the minor nit that "ofthe" ("of the")
> isn't one word.
Thanks; typo corrected.
^ permalink raw reply
* Re: Git Merge 2013 Conference, Berlin
From: Scott Chacon @ 2013-02-18 21:29 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, git list
In-Reply-To: <20130218211703.GE27308@sigill.intra.peff.net>
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 <peff@peff.net> wrote:
> On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
>
>> Scott Chacon <schacon@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
^ permalink raw reply
* Re: [PATCHv2 04/10] pkt-line: change error message for oversized packet
From: Jeff King @ 2013-02-18 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Shawn O. Pearce
In-Reply-To: <7v1ucdb9gw.fsf@alter.siamese.dyndns.org>
On Mon, Feb 18, 2013 at 01:25:35PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > But it's easy to do (1), and it starts the clock ticking for
> > the 1000-byte readers to become obsolete.
>
> Yup, I agree with that goal.
Having just looked at the pkt-line callers a lot, I think most of them
could go for something like:
char *packet_read(int fd, unsigned *len_p)
{
static char buffer[LARGE_PACKET_MAX];
int len;
len = packet_read_to_buf(fd, buffer, sizeof(buffer));
if (len < 0)
return NULL;
*len_p = len;
return buffer;
}
That would actually simplify the callers a bit, and would harmonize the
buffer sizes at the same time. I'll look into doing a series tonight.
-Peff
^ permalink raw reply
* Re: git clone tag shallow
From: Junio C Hamano @ 2013-02-18 21:49 UTC (permalink / raw)
To: Thibault Kruse; +Cc: Duy Nguyen, git
In-Reply-To: <CAByu6UVfArRXGLTKgM=nw0fzij1urcVdzxx6xdoHihODD-LtRA@mail.gmail.com>
Thibault Kruse <tibokruse@googlemail.com> writes:
>> I am not sure why you meant to treat (2) and (3) differently,
>> though. Care to elaborate?
>
> As in my example, git clone --branch <branch> does not accept all of (3).
That is a prime example of outside "checkout" we give a white lie to
show the most common <branch> to help beginners, I think.
> That's fair enough, I guess, I am not sure either. If I understand you
> right, the Synopsis and
> description are supposed to explain the non-hackish usage of commands,
> whereas documentation after the OPTIONS headline is supposed to be
> more of a complete description.
It would go more like
SYNOPSIS
git foo <branch>
DESCRIPTION
"git foo" distims doshes in <branch>.
ARGUMENTS
* <branch>: the branch to distim doshes in.
While it is most common to name a branch, you
can give any <committ-ish> to it.
if and only if use is <branch> is the most common and using
arbitrary commit is a rare case. In other cases, we would be better
to say <committish> on the SYNOPSIS part. That commonness/rareness
is a case-by-case matter, I would think.
^ permalink raw reply
* Re: Git bundles for backup and cloning: the Zaphod Beeblebrox thread
From: Philip Oakley @ 2013-02-18 22:30 UTC (permalink / raw)
To: Alain Kalker; +Cc: Git List
In-Reply-To: <kfrb11$ugv$2@ger.gmane.org>
From: "Alain Kalker" <a.c.kalker@gmail.com>
Sent: Sunday, February 17, 2013 7:28 PM
> From the current documentation for git-bundle(1), it may not be clear
> for
> users unfamilliar with Git, how to create a bundle which can be used
> for
> backup purposes, or, more generally, to clone to a completely new
> repository.
>
> Philip Oakley has posted a documentation patch some time ago, but
> Junio
> has pointed out several concerns.
> Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/
> focus=205897
>
> Here's my attempt to summarize the concerns, adding some of my own,
> and a
> possible solution.
>
> 1. "Missing HEAD syndrome"
> $ git bundle create <bundle> master
> -or-
> $ git bundle create <bundle> <branchname...>
> -or-
> $ git bundle create <bundle> --branches
> -then-
> $ git clone <bundle> <dir>
>
> will be unable to checkout any files due to a missing ref for HEAD.
> Though this can be fixed by going into <dir> and doing `git checkout
> <ref>`, this is not very user-friendly.
>
> 2. "Detached HEAD syndrome"
> $ git bundle create <bundle> HEAD
> $ git clone <bundle> <dir>
> will checkout files alright, but leaves one in a "detached HEAD"
> state.
>
> 3. "Exploding HEAD syndrome"
> $ git bundle create <bundle> --all
> will add the HEAD, but will add refs from refs/remotes/* too, which is
> not desirable when cloning, unless one sets up all the remotes (e.g.
> by
> restoring .git/config) as well.
>
> Finally, my solution for backing up only the local branches of a
> repository:
> $ git bundle create <bundle> --branches HEAD
> but this may not be very easy for new users to figure out on their own
> unless well documented (perhaps a new flag?)
Perhaps if you draft up a documentation patch that would fit in the
Examples section it could be discussed. The Example section allows that
the various caveats can stated and be covered.
It would also be worth linking to 'git rev-parse' under the
<git-rev-list-args> so folk would actually look it up.
It may be that the example(s) needs to include
--branches[=pattern]
--tags[=pattern]
rather than --all. to cover Junio's points.
The --all 'question/solution' has come up a number of times so it does
look worth having something in the documentation. This would be
something ;-)
>
> Any comments or suggestions (including HHGTTG references!) are very
> welcome.
>
> -Alain
Do use Reply-All - include any Cc's in replies.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-18 22:32 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Matthieu Moy, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> [corrected David Barr's email address]
>
> Jeff King wrote:
>> 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).
>>
>> 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.
>
> Also, we need more projects that will scratch everyday itches. A
> collection of related tiny features might not be a bad idea. Often,
> we risk erring on the side of too-big-for-one-summer when it comes to
> specifying projects. What's the harm of including something estimated
> to take 80% of a summer?
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.
We have solicited "suggested projects" entries via wiki in the past,
letting anybody to put anything there, and I think that was a major
source of our past failures. The practice lets irresponsive people
who think they know what they are talking about to place unrealistic
pie-in-the-sky there. I wonder if we can somehow come up with a way
to limit them to realisitic ones in a sane way. One possibility may
be to require the proposer to already have an 80% answer, not to be
shared with students. A project that a GSoC student who is not
familiar with our codebase and culture (e.g. our no regressions
policy and requiring solid transition plan for disruptive changes)
is expected to finish in a summer should not be bigger than what a
mentor familiar with our project can do a rough outline design and
implementation as a two-weekend hack at most, I think.
Such a requirement on the proposer's end may be a reasonable sanity
check to make sure we do not suggest sure-to-fail projects to the
students.
It is ironic that I have to point out that the best "let's get
students exposed to the OSS process using Git community's reviewing
bandwidth" last year from my point of view happened outside the
GSoC. Matthieu's school projects were not structured to the GSoC
standard (they assigned multiple students working together on each
topic), but the size of the projects seemed more manageable. It was
a joy to work with these students during the term of the project. We
had a meaningful number of review iterations, unlike a typical GSoC
project where a student and her mentors sit in a dark cave for a
long time, send out the first draft too late, and the participant do
not get enough time to do meaningful iterations of reviews (it was
also a huge plus from our project's point of view that there were
even responsible post-program follow up to complete the unfinished
bits).
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-18 22:37 UTC (permalink / raw)
To: Jeff King
Cc: Ramkumar Ramachandra, Jonathan Nieder, Thomas Rast, git,
Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218210709.GC27308@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is not related to GSoC anymore, but I think handling multiple
> versions is already pretty easy. You can just install to
> "$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git"
> binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
> already takes care of the messy bits, like making sure sub-programs are
> invoked from the same git version.
>
> I already do this automagically with this script:
>
> https://github.com/peff/git/blob/meta/install/prefix
>
> I just set "prefix" in the Makefile based on the script, and when I
> "make install" tags or topic branches, they go to the right place (and
> the "links" script in the same directory maintains the symlinks for me).
>
> I never bothered to even submit those scripts to contrib, because I
> figured they were so specific to my setup, and to keeping dozens of git
> versions around (when debugging, it's nice to be able to check an old
> version's behavior without even having to build it).
Yeah, I have been using the Make (in the todo branch, to be checked
out in Meta/ subdirectory of the working tree) script for exactly
this. After tagging a release, I'd do
git checkout -B snap v1.8.1.3
Meta/Make install install-doc
to install them in $inst_prefix/git-snap-v1.8.1.3. A "rungit"
script can then be used like:
rungit v1.7.0 checkout blah
-- rungit script -- >8 -- rungit script --
#!/bin/sh
# Run various vintage of git
variant="${0##*/}" &&
: ${RUNGIT_BASE=$HOME/g/$(getarch)} &&
case "$variant" in
rungit)
case $# in
0)
echo >&2 "which version?"
exit 1
;;
esac
variant=$1
shift
;;
esac &&
case "$variant" in
-l)
for d in "$RUNGIT_BASE/"git-*/bin/git
do
d=$(basename ${d%/bin/git})
d=${d#git-}
d=${d#snap-}
echo "$d"
done
exit
;;
git-*)
variant=${variant#git-} ;;
v[0-9]*)
variant=snap-$variant ;;
esac &&
d="$RUNGIT_BASE/git-$variant" &&
if test -f "$d/bin/git"
then
exec "$d/bin/git" "$@"
else
echo >&2 "$variant: No such variant for $a"
exit 1
fi
^ permalink raw reply
* Re: [PATCH 1/8] contrib/subtree: Use %B for split subject/body
From: Junio C Hamano @ 2013-02-18 22:43 UTC (permalink / raw)
To: David A. Greene; +Cc: git, Techlive Zheng, James Nylen
In-Reply-To: <1361221013-12756-2-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: Techlive Zheng <techlivezheng@gmail.com>
>
> Use %B to format the commit message and body to avoid an extra newline
> if a commit only has a subject line.
>
> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
> contrib/subtree/t/t7900-subtree.sh | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Huh?
This seems to be a repeat of the test added in a5b8e28e4eb5
(contrib/subtree: use %B for split subject/body, 2013-02-04) and
nothing else, excluding the actual change to git-subtree itself.
Confused....
>
> diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
> index 80d3399..8dd6a82 100755
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -226,6 +226,17 @@ test_expect_success 'check hash of split' '
> check_equal ''"$new_hash"'' "$subdir_hash"
> '
>
> +test_expect_success 'check hash of split' '
> + spl1=$(git subtree split --prefix subdir) &&
> + undo &&
> + git subtree split --prefix subdir --branch splitbr1test &&
> + check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1"
> + git checkout splitbr1test &&
> + new_hash=$(git rev-parse HEAD~2) &&
> + git checkout mainline &&
> + check_equal ''"$new_hash"'' "$subdir_hash"
> +'
> +
> test_expect_success 'check split with --branch for an existing branch' '
> spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
> undo &&
^ permalink raw reply
* Re: [PATCH 3/8] contrib/subtree: Ignore testing directory
From: Junio C Hamano @ 2013-02-18 22:51 UTC (permalink / raw)
To: David A. Greene; +Cc: git, Techlive Zheng, James Nylen
In-Reply-To: <1361221013-12756-4-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: Techlive Zheng <techlivezheng@gmail.com>
>
> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
> contrib/subtree/.gitignore | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore
> index 91360a3..59aeeb4 100644
> --- a/contrib/subtree/.gitignore
> +++ b/contrib/subtree/.gitignore
> @@ -1,6 +1,5 @@
> *~
> git-subtree
> -git-subtree.xml
> git-subtree.1
> -mainline
> -subproj
> +git-subtree.xml
> +t/trash\ directory.*
The title explains t/trash* but not mainline/subproj lines. Why can
they go now?
Also git-subtree.xml seems to be moved without justification
(perhaps making the list alphabetical)?
^ permalink raw reply
* Re: [PATCH 4/8] contrib/subtree: Code cleaning and refactoring
From: Junio C Hamano @ 2013-02-18 22:55 UTC (permalink / raw)
To: David A. Greene; +Cc: git, Techlive Zheng, James Nylen
In-Reply-To: <1361221013-12756-5-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: Techlive Zheng <techlivezheng@gmail.com>
>
> Mostly prepare for the later tests refactoring.
>
> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
Applying: contrib/subtree: Code cleaning and refactoring
/srv/project/git/git.git/.git/rebase-apply/patch:219: space before tab in indent.
git branch spl1 "$spl1" &&
/srv/project/git/git.git/.git/rebase-apply/patch:222: space before tab in indent.
undo
/srv/project/git/git.git/.git/rebase-apply/patch:239: space before tab in indent.
undo &&
/srv/project/git/git.git/.git/rebase-apply/patch:269: space before tab in indent.
git subtree split --unannotate="subproj:" --prefix subdir --onto FETCH_HEAD --branch splitunann &&
> contrib/subtree/t/t7900-subtree.sh | 256 +++++++++++++++++++-----------------
> 1 file changed, 136 insertions(+), 120 deletions(-)
>
> diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
> index c7f9e1a..3787408 100755
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -4,7 +4,7 @@
> #
> test_description='Basic porcelain support for subtrees
>
> -This test verifies the basic operation of the merge, pull, add
> +This test verifies the basic operation of the add, pull, merge
Why this change? The new list does not match the order of things
that are tested ("add" is not the first thing that gets tested), it
is not alphabetical either ("pull" sorts earlier than "merge"), nor
it is the natural progression of operation users would expect (it
would be more like "add" to start working with subtree, then "merge"
locally and finally "pull" to interact with others, no?)
^ permalink raw reply
* Re: [PATCH] shell-prompt: clean up nested if-then
From: Martin Erik Werner @ 2013-02-18 22:56 UTC (permalink / raw)
To: Simon vanaf Telefoon
Cc: Jonathan Nieder, gitster, git, trsten, Felipe Contreras
In-Reply-To: <0c94f24b-f7ee-4699-87a7-6861b927cea4@email.android.com>
On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote:
> Hi all, sorry for top posting :-( blame the phone and k9
>
> I have a small issue with the use of test instead of [
> If that only applies to this section of the entire file.
> Coding style has some value.
>
> Combining nested ifs with && seems harmless enough, though should be
> well tested.
>
> Cheers
> Simon
>
Ah, indeed, I looked around a bit more, and as per
http://mywiki.wooledge.org/BashPitfalls it seems like 'test' is bad to use with multiple &&'s anyways.
I've changed to using [] && [] and rerolled the patch.
> Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Martin,
>
> Martin Erik Werner wrote:
>
> Minor clean up of if-then nesting in checks for environment variables
> and config options. No functional changes.
>
> Yeah, the nesting was getting a little deep. Thanks for the cleanup.
> May we have your sign-off?
>
> Once this is signed off,
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Meh, I keep on missing that :/
Old (and new) patch is:
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
>
> Patch left unsnipped for reference.
>
> ---
> contrib/completion/git-prompt.sh | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git
> a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 9b2eec2..e29694d 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -320,26 +320,25 @@ __git_ps1 ()
> b="GIT_DIR!"
> fi
> elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
> - if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> - if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
> - git diff --no-ext-diff --quiet --exit-code || w="*"
> - if git rev-parse --quiet --verify HEAD >/dev/null; then
> - git diff-index --cached --quiet HEAD -- || i="+"
> - else
> - i="#"
> - fi
> + if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
> + test "$(git config --bool bash.showDirtyState)" !=
> "false"
> + then
> + git diff --no-ext-diff --quiet --exit-code || w="*"
> + if git rev-parse --quiet --verify HEAD >/dev/null; then
> + git diff-index --cached --quiet HEAD -- || i="+"
> + else
> + i="#"
> fi
> fi
> if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
> git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
> fi
>
> - if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
> - if [ "$(git config --bool bash.showUntrackedFiles)" != "false" ]; then
> - if [ -n "$(git ls-files --others --exclude-standard)" ]; then
> - u="%"
> - fi
> - fi
> + if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
> + test "$(git config --bool bash.showUntrackedFiles)" != "false" &&
> + test -n "$(git ls-files --others --exclude-standard)"
> + then
> + u="%"
> fi
>
> if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ];!
> then
> --
>
^ permalink raw reply
* [PATCH v2] shell-prompt: clean up nested if-then
From: martinerikwerner @ 2013-02-18 22:59 UTC (permalink / raw)
To: s.oosthoek, jrnieder; +Cc: git, trsten, felipe.contreras, Martin Erik Werner
In-Reply-To: <1361228206.17734.4.camel@mas>
From: Martin Erik Werner <martinerikwerner@gmail.com>
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
---
contrib/completion/git-prompt.sh | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b2eec2..341422a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -320,26 +320,25 @@ __git_ps1 ()
b="GIT_DIR!"
fi
elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
- if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
- if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --quiet --exit-code || w="*"
- if git rev-parse --quiet --verify HEAD >/dev/null; then
- git diff-index --cached --quiet HEAD -- || i="+"
- else
- i="#"
- fi
+ if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ] &&
+ [ "$(git config --bool bash.showDirtyState)" != "false" ]
+ then
+ git diff --no-ext-diff --quiet --exit-code || w="*"
+ if git rev-parse --quiet --verify HEAD >/dev/null; then
+ git diff-index --cached --quiet HEAD -- || i="+"
+ else
+ i="#"
fi
fi
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
fi
- if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ "$(git config --bool bash.showUntrackedFiles)" != "false" ]; then
- if [ -n "$(git ls-files --others --exclude-standard)" ]; then
- u="%"
- fi
- fi
+ if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] &&
+ [ "$(git config --bool bash.showUntrackedFiles)" != "false" ] &&
+ [ -n "$(git ls-files --others --exclude-standard)" ]
+ then
+ u="%"
fi
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
--
1.7.10.4
^ permalink raw reply related
* Re: Google Summer of Code 2013 (GSoC13)
From: Jonathan Nieder @ 2013-02-18 23:03 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218205532.GB27308@sigill.intra.peff.net>
Jeff King wrote:
> On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:
>> Some potential projects (unfiltered --- please take them with a grain
>> of salt):
>> [...]
>> - collaborative notes editing: fix the default notes refspec,
>> make sure the "notes pull" workflow works well and is documented
>> well, offer an easy way to hide private notes after the fact
>> without disrupting public history
>
> I know you said a grain of salt, so please don't feel like I'm beating
> up on your idea. I'm picking this one because I think it has some
> characteristics of projects that have not gone well in the past, so it's
> a good illustrative example.
>
> IMHO, this is the type of project that is likely to fail, because most
> of the work is not technical at all, but political. Changing the default
> refspecs is a few lines of code. But the hard part is figuring out where
> they should go, the implications of doing so, and how people are going
> to react.
I think I agree, if by "likely to fail" you mean "easy to underestimate
the difficulty of". I actually think it would be a pretty good summer
student project, for a few related reasons:
* Years of evidence show it is a hard problem. It would be a good
notch in the belt of whoever takes the project on.
* It does not require a deep understanding of git internals. A good
familiarity with the git user interface, on the other hand, would
be essential, but I hope that is becoming more common among
students these days.
* It requires good taste and design sense, which are something it
would be nice to cultivate and encourage.
* The change is necessary and the satisfaction of helping a student
through the process might be enough to finally get it done.
* If an amazing candidate finishes the "make collaboration possible"
task early, there's plenty of valuable, interesting, and technically
complicated follow-on work regarding the related "share some notes
while hiding others" to fill the rest of the summer.
The code change for the most basic subset of "make collaboration
possible" would presumably be a changed refspec, some documentation,
and some tests. On top of that there is presumably some automagic
incorporation of upstream notes to be cooked into "git pull". Some
better conflict-resolution magic. Example scripts to generate notes.
Support for the format-patch / am workflow. gitweb support for
showing notes.
It's a good example of when it's useful to not be afraid of failing to
please everybody and just get something done.
I also can't think of any examples of such technically straightforward
student projects being tried before.
Jonathan
^ permalink raw reply
* Re: [PATCH] shell-prompt: clean up nested if-then
From: Junio C Hamano @ 2013-02-18 23:07 UTC (permalink / raw)
To: Martin Erik Werner
Cc: Simon vanaf Telefoon, Jonathan Nieder, git, trsten,
Felipe Contreras
In-Reply-To: <1361228206.17734.4.camel@mas>
Martin Erik Werner <martinerikwerner@gmail.com> writes:
> On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote:
>> Hi all, sorry for top posting :-( blame the phone and k9
>>
>> I have a small issue with the use of test instead of [
>> If that only applies to this section of the entire file.
>> Coding style has some value.
>>
>> Combining nested ifs with && seems harmless enough, though should be
>> well tested.
>>
>> Cheers
>> Simon
>>
>
> Ah, indeed, I looked around a bit more, and as per
> http://mywiki.wooledge.org/BashPitfalls it seems like 'test' is bad to use with multiple &&'s anyways.
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.
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.
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc0
From: Junio C Hamano @ 2013-02-18 23:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Linux Kernel
In-Reply-To: <vpq4nh9v5an.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Git v1.8.2 Release Notes (draft)
>> ========================
>>
>> Backward compatibility notes
>> ----------------------------
>>
>> In the upcoming major release (tentatively called 1.8.2), we will
>> change the behavior of the "git push" command.
>>
>> When "git push [$there]" does not say what to push, we have used the
>> traditional "matching" semantics so far (all your branches were sent
>> to the remote as long as there already are branches of the same name
>> over there). We will use the "simple" semantics
>
> I don't understand: wasn't this supposed to happen in Git 2.0? Did you
> mean "In the upcoming major release (tentatively called *2.0*)"?
Thanks. I am not sure what I was thinking. Perhaps when we started
this cycle we did want to merge the push-2.0-default-to-simple series
Will update.
> Also, you may want to mention the argumentless "git add -u" change too.
> It currently has an item below, but this is a future
> backward-incompatible change so it may deserve to appear in this section
> too.
Quite right. Care to do the honors as the proposer to the new
direction?
^ permalink raw reply
* Re: [PATCH v2] shell-prompt: clean up nested if-then
From: Jonathan Nieder @ 2013-02-18 23:28 UTC (permalink / raw)
To: martinerikwerner; +Cc: s.oosthoek, git, trsten, felipe.contreras
In-Reply-To: <5122b23b.512e980a.32b9.ffffa580@mx.google.com>
Martin Erik Werner wrote:
> Minor clean up of if-then nesting in checks for environment variables
> and config options. No functional changes.
>
> Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
> ---
> contrib/completion/git-prompt.sh | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks for the quick turnaround.
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc0
From: Junio C Hamano @ 2013-02-18 23:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Linux Kernel
In-Reply-To: <7vobfh8bjc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> I don't understand: wasn't this supposed to happen in Git 2.0? Did you
>> mean "In the upcoming major release (tentatively called *2.0*)"?
>
> Thanks. I am not sure what I was thinking. Perhaps when we started
> this cycle we did want to merge the push-2.0-default-to-simple series
>
> Will update.
>
>> Also, you may want to mention the argumentless "git add -u" change too.
>> It currently has an item below, but this is a future
>> backward-incompatible change so it may deserve to appear in this section
>> too.
OK, let's do this. Thanks for sharp eyes.
Documentation/RelNotes/1.8.2.txt | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt
index a5a1d4e..a287f24 100644
--- a/Documentation/RelNotes/1.8.2.txt
+++ b/Documentation/RelNotes/1.8.2.txt
@@ -4,8 +4,8 @@ Git v1.8.2 Release Notes
Backward compatibility notes
----------------------------
-In the upcoming major release (tentatively called 1.8.2), we will
-change the behavior of the "git push" command.
+In the next major release Git 2.0 (not *this* one), we will change the
+behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
@@ -22,6 +22,18 @@ that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
+When "git add -u" and "git add -A", that does not specify what paths
+to add on the command line, is run from inside a subdirectory, the
+scope of the operation has always been limited to the subirectory.
+Many users found this counter-intuitive, given that "git commit -a"
+and other commands operate on the entire tree regardless of where you
+are. In this release, these commands give warning in such a case and
+encourage the user to say "git add -u/-A ." instead when restricting
+the scope to the current directory. At Git 2.0 (not *this* one), we
+plan to change these commands without pathspec to operate on the
+entire tree, and training your fingers to type "." will protect you
+against the future change.
+
Updates since v1.8.1
--------------------
^ permalink raw reply related
* Re: Google Summer of Code 2013 (GSoC13)
From: Duy Nguyen @ 2013-02-19 1:17 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann
In-Reply-To: <87ehgd1qq2.fsf@pctrast.inf.ethz.ch>
On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> * Naturally that ideas page is a bit stale now, and three projects
> shorter. Please propose new ideas and refresh or delete the old ones!
> In particular some projects spawned long discussions on the list, and
> the results of those discussions should be integrated to avoid deja
> vus.
A proposal from what I've been involved lately: inotify support to
eliminate lstat and readdir syscalls. The scope may be small. But we
could aim to get it merged in master or at least next by the end of
GSoC. Or extend to another platform besides Linux, it helps ensure we
have good abstraction. My free time goes up and down unexpectedly, not
sure if I can commit to be a mentor. But I'm definitely interested and
will support whenever I can.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox