* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-07 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vd44zt1nf.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 7 Oct 2009, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> > So i took a live repo from my dayjob containing 8 submodules. In each
> > submodule i did a "git checkout HEAD^" to simulate one change.
>
> It appears that your "simulation" is to have changes in all submodules
> and nowhere else in the tree. I have to wonder how common would that
> be. If I have been working in the subprojects without changing the
> superproject at all, I would likely to be in one of the subproject
> directories and my "git diff" would not even have to trigger this
> codepath. If we have on the other hand changes in the superproject,
> showing them would cost us equally in both approaches.
>
> > then i got:
> >
> > without fork : real 0m0.203s
> > with fork : real 0m0.453s
> >
> > This is a degradation of more than 120% because of the fork()s. And
> > just for fun i ran the scripted submodule summary too:
> >
> > scripted : real 0m3.437s
> >
> > So the forked version outperforms the scripted version by a factor of
> > 7, while the speedup from Dscho's original proposal is almost 17fold.
>
> Thanks. I was worried if the forking to ensure correctness may sactifice
> performance so much to be unusable, but it does not seem to be the case,
> given the above comparision.
>
> I didn't look at the code but presumably it uses the run_command()
> interface and cleanly written?
You seem to be rather unconvinced by rather convincing numbers.
Therefore, I will continue working on the --submodule-summary stuff in
4msysgit.git.
Ciao,
Dscho
^ permalink raw reply
* Re: Alles wurde Git
From: Johannes Schindelin @ 2009-10-07 22:15 UTC (permalink / raw)
To: Phil Lawrence; +Cc: git, msysgit
In-Reply-To: <4ACD076B.3000902@gmail.com>
Hi,
On Wed, 7 Oct 2009, Phil Lawrence wrote:
> On 10/04/2009 07:09 AM, Johannes Schindelin wrote:
> >
> > ...Steffen also described some of the issues with working on a large
> > number of topic branches that need to be integrated/cleaned
> > up/rebased: Git lacks good tools for working collaboratively with
> > topic branches that need to be rebased frequently. He also showed a
> > rather complicated script that is necessary to coordinate work between
> > 3 different maintainers (at 3 different locations). ...
>
> Steffen, any chance you would share that script with the list? It
> sounds very interesting.
I fear that the script is rather specific to the company's environment,
and I fear further that Steffen might not be allowed to share it due to IP
issues.
Ciao,
Dscho
^ permalink raw reply
* Re: Alles wurde Git
From: Phil Lawrence @ 2009-10-07 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0910041310520.4985@pacific.mpi-cbg.de>
On 10/04/2009 07:09 AM, Johannes Schindelin wrote:
>
> ...Steffen also described some of the issues with
> working on a large number of topic branches that need to be
> integrated/cleaned up/rebased: Git lacks good tools for working
> collaboratively with topic branches that need to be rebased frequently.
> He also showed a rather complicated script that is necessary to coordinate
> work between 3 different maintainers (at 3 different locations).
> ...
Steffen, any chance you would share that script with the list? It
sounds very interesting.
Phil Lawrence
^ permalink raw reply
* Re: Code reuse
From: Florian Weimer @ 2009-10-07 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <2e24e5b90910070530p757b3651ne0f7e4a6e8bc8825@mail.gmail.com>
* Sitaram Chamarty:
> It would seem to me that, if you changed them significantly, and going
> by the above logic, you don't need to do *anything* regarding
> attribution.
Note that applicable laws may impose additional restrictions, like
crediting authors in the way they require.
My personal approach is to include the copyright header of the file
I'm quoting from, together with a comment which explains where the
code came from (project, version, path).
^ permalink raw reply
* Re: Code reuse
From: Philip Herron @ 2009-10-07 20:12 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90910070530p757b3651ne0f7e4a6e8bc8825@mail.gmail.com>
Thanks for that i am no legalese speaker so yeah ;). Its only really
the alloc_nr but its renamed is nearly the same the other really isnt
the same only just 2 statements with different identifiers remain.
Thanks anyways git-core is nice :)
--Phil
2009/10/7 Sitaram Chamarty <sitaramc@gmail.com>:
> On Wed, Oct 7, 2009 at 12:48 AM, Philip Herron
> <herron.philip@googlemail.com> wrote:
>
>> I am not sure if this is the right place to ask this question, but
>> I've been working on a personal project a programming language
>> interpreter for some time now, but i took 2 code snippets from
>> git-core namely:
>
> [snip]
>
>> I've changed it a good bit (probably doesn't resemble much of what it
>> was) to fit in with the way my stuff works but is there anything i
>> need to like put in my source code to say hey this is based of
>> git-core, so far is just a comment to say 'based of git-core hash.c'.
>> Its an open source (GPL) program but i haven't released or made much
>> noise about it yet because i want to work on it more myself.
>
> In general, the GPL's main requirement is that whoever gets the binary
> should also get the code (I'm over simplifying but that's basically
> it). It actually doesn't say much about giving credit, except (from
> <HEAD:COPYING>):
>
> "If the software is modified by someone else and passed on, we want
> its recipients to know that what they have is not the original, so
> that any problems introduced by others will not reflect on the
> original authors' reputations"
>
> and
>
> "a) You must cause the modified files to carry prominent notices
> stating that you changed the files and the date of any change."
>
> That's basically it...
>
> It would seem to me that, if you changed them significantly, and going
> by the above logic, you don't need to do *anything* regarding
> attribution.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: gitweb calls the project ".git"
From: Daniele Segato @ 2009-10-07 20:01 UTC (permalink / raw)
To: Lars Rasmusson; +Cc: git
In-Reply-To: <E66B0797-4EF0-49FC-AA01-8FD4C884A7E9@sics.se>
Il giorno mer, 07/10/2009 alle 18.31 +0200, Lars Rasmusson ha scritto:
> Hi, I am serving a repository with "git instaweb".
>
> In the web browser, the name in the Project column is only ".git", and
> not the "myrepo.git"
> which I would like to have, and as it is on http://repo.or.cz/ (which
> is a site that also uses gitweb).
>
> How do I configure it to serve the project directory (or even better,
> all the repos in a directory), and name them appropriately?
>
> (Is it possible to do with instaweb, or can it only be done with a
> more heavy approach like using apache?)
as for I know by default you should create a simbolic link to your .git
directory in /var/cache/git/
the name of the project depends of the name of the symbolic link
example: /var/cache/git/yourproject.git --> /your/project/path/.git/
Bye,
Daniele
^ permalink raw reply
* Re: [PATCH/RFC] New date format: local_original
From: Junio C Hamano @ 2009-10-07 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: Tuomas Suutari, git
In-Reply-To: <20091007125427.GA20067@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If the former, then should the options be orthogonal? That is, should it
> be a new format combining the two, or should it be an option to show, in
> your preferred format, the time in both local and original time zones?
> E.g., something like:
>
> $ git log --date=iso --local-dates-too
> commit bf01a69ed40e1afcf56aff143f7523da2ce263ed
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: 2009-10-04 00:41:55 +0200
> Local: 2009-10-03 17:41:55 -0500
>
> And then you can use it with "normal" dates, iso dates, rfc2822 dates,
> etc.
Thanks for comments.
I think "--date=iso --local-dates-too" is still not orthogonal enough, let
alone "local_original" which invites "Why is this combination supported
and not this, that, and 47 others?" questions.
I however do not think it is so bad an idea to allow something like:
git log --date='custom:%Y-%m-%d ...'
git log --date=custom ;# looks at "date.custom" config
You (not Peff, but figuratively whoever wants to implement it) can add a
mechanism to specify in which timezone (original or local) you would want
the timestring to be given, and make what Tuomas's RFC patch does a mere
special case. For example, we could reuse 'date "+format"' string with
our own extension %{magic}, with two magic tokens initially defined:
%{local} interpret timestamp in local zone from now on
%{original} interpret timestamp in the original zone from now on
With such a mechanism Tuomas can define:
[date]
custom=%{local}%a %Y-%m-%d %H:%M:%S %{original}(%a %H:%M:%S %z)
and ask "git log --date=custom" to get what his patch does.
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Junio C Hamano @ 2009-10-07 20:00 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Schindelin, git
In-Reply-To: <4ACCECE6.1030508@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> So i took a live repo from my dayjob containing 8 submodules. In each
> submodule i did a "git checkout HEAD^" to simulate one change.
It appears that your "simulation" is to have changes in all submodules and
nowhere else in the tree. I have to wonder how common would that be. If
I have been working in the subprojects without changing the superproject
at all, I would likely to be in one of the subproject directories and my
"git diff" would not even have to trigger this codepath. If we have on
the other hand changes in the superproject, showing them would cost us
equally in both approaches.
> then i got:
>
> without fork : real 0m0.203s
> with fork : real 0m0.453s
>
> This is a degradation of more than 120% because of the fork()s. And
> just for fun i ran the scripted submodule summary too:
>
> scripted : real 0m3.437s
>
> So the forked version outperforms the scripted version by a factor of
> 7, while the speedup from Dscho's original proposal is almost 17fold.
Thanks. I was worried if the forking to ensure correctness may sactifice
performance so much to be unusable, but it does not seem to be the case,
given the above comparision.
I didn't look at the code but presumably it uses the run_command()
interface and cleanly written?
^ permalink raw reply
* Re: [PATCH 3/3] completion: add dirstat and friends to diff options
From: Junio C Hamano @ 2009-10-07 19:45 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
No objection from me, but I am not a completion expert ;-)
^ permalink raw reply
* Re: [PATCH 2/3] completion: update am, commit, and log
From: Junio C Hamano @ 2009-10-07 19:45 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-2-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> git am learned --scissors, git commit learned --dry-run and git log
> learned --decorate=long|short recently.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
No objection from me, but I am not a completion expert ;-)
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-07 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vocok21pw.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>>> But I really, really, really want to avoid a fork() in the common case. I
>>> do have some users on Windows, and I do have a few submodules in that
>>> project. Having too many fork() calls there would just give Git a bad
>>> reputation. And it has enough of that, it does not need more.
>> Me too thinks performance matters here. We do have a repo at my dayjob
>> with more than a handful of submodules and its main target platform is
>> windows ... so having that perform nicely is a win for us.
>
> Numbers?
Here they are:
First i did them with the repo at hand, current msysgit master with
Dscho's git-repo checked out:
without fork : real 0m0.672s
with fork : real 0m0.781s
So here it's a about 16% slower when using fork() (and both are
generating about 7270 shortlog entries).
But i thought this to be a rather unusual situation, having only one
submodule being changed by 7270 commits ...
So i took a live repo from my dayjob containing 8 submodules. In each
submodule i did a "git checkout HEAD^" to simulate one change. And
then i got:
without fork : real 0m0.203s
with fork : real 0m0.453s
This is a degradation of more than 120% because of the fork()s. And
just for fun i ran the scripted submodule summary too:
scripted : real 0m3.437s
So the forked version outperforms the scripted version by a factor of
7, while the speedup from Dscho's original proposal is almost 17fold.
(If i did my computations right, the extra costs for each changed
submodule are a bit more than 30ms when fork()ing. Dscho's version
doesn't seem to suffer from changed submodules at all, i measured
0.203s for both versions before i did the submodule init and update).
(Best of three, "time git diff --submodule-summary". My system is an
Athlon64x2 4600+ with WindowsXP)
Jens
^ permalink raw reply
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-07 18:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4ACC6055.1070204@viscovery.net>
Johannes Sixt wrote:
> Is it necessary to change the body of the loop? Your version spawns two
> processes on each iteration, while the original spawned no processes.
>
> You can avoid the pipeline (i.e. yet another process) using a "here-string":
>
> local i aliases=$(git --git-dir="$(__gitdir)" config -z \
> --get-regexp "alias\..*" 2>/dev/null)
> while IFS= read -rd '' i; do
> i="${i#alias.}"
> echo "${i/ */}" # could be: echo "${i%% *}"
> done <<< "$aliases"
>
> but I don't know how well bash handles variable values with embedded NULs.
I can't get the above snippet to work, but maybe I'm doing something wrong.
I had a problem with the newline between the key and the value. bash
gives me the whole line in the loop, but when I try to trim it $i is
treated as two values. I couldn't figure out any other way to do it,
besides piping $i to cut or tr.
Maybe a better solution would be to add --keys-only or something to
git-config?
^ permalink raw reply
* gitweb calls the project ".git"
From: Lars Rasmusson @ 2009-10-07 16:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
Hi, I am serving a repository with "git instaweb".
In the web browser, the name in the Project column is only ".git", and
not the "myrepo.git"
which I would like to have, and as it is on http://repo.or.cz/ (which
is a site that also uses gitweb).
How do I configure it to serve the project directory (or even better,
all the repos in a directory), and name them appropriately?
(Is it possible to do with instaweb, or can it only be done with a
more heavy approach like using apache?)
Thanks for any quick ideas, cheers,
/Lars
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2427 bytes --]
^ permalink raw reply
* [JGIT PATCH v2] The default encoding for reading commits is UTF-8 rather than system default
From: Constantine Plotnikov @ 2009-10-07 16:26 UTC (permalink / raw)
To: git; +Cc: Constantine Plotnikov
When reading commits the system default encoding was used if no encoding
was specified in the commit. The patch modifies test to add a check that
commit message was encoded correctly (the test fails on old implementation
if system encoding is not UTF-8) and fixes Commit.decode() method to use
UTF-8 is encoding is not specified in the commit object.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
This version is over eclipse.org packages.
See man git-commit (the section "DISCUSSION"), for justification why
UTF-8 should be used. Note that this was already correctly implemented
in ObjectWriter.writeCommit(...) method. But Commit.decode() was not
implemented in the same way for some reason.
.../tst/org/eclipse/jgit/lib/T0003_Basic.java | 3 +++
.../src/org/eclipse/jgit/lib/Commit.java | 18 +++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
index 98fb794..f3bc9b1 100644
--- a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
+++ b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java
@@ -348,6 +348,9 @@ public void test023_createCommitNonAnullii() throws IOException {
commit.setMessage("\u00dcbergeeks");
ObjectId cid = new ObjectWriter(db).writeCommit(commit);
assertEquals("4680908112778718f37e686cbebcc912730b3154", cid.name());
+ Commit loadedCommit = db.mapCommit(cid);
+ assertNotSame(loadedCommit, commit);
+ assertEquals(commit.getMessage(), loadedCommit.getMessage());
}
public void test024_createCommitNonAscii() throws IOException {
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
index b2cf9b1..430cddc 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java
@@ -299,17 +299,13 @@ private void decode() {
br.read(readBuf);
int msgstart = readBuf.length != 0 ? ( readBuf[0] == '\n' ? 1 : 0 ) : 0;
- if (encoding != null) {
- // TODO: this isn't reliable so we need to guess the encoding from the actual content
- author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
- committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
- message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
- } else {
- // TODO: use config setting / platform / ascii / iso-latin
- author = new PersonIdent(new String(rawAuthor.getBytes()));
- committer = new PersonIdent(new String(rawCommitter.getBytes()));
- message = new String(readBuf, msgstart, readBuf.length-msgstart);
- }
+ // If encoding is not specified, the default for commit is UTF-8
+ if (encoding == null) encoding = Constants.CHARSET;
+
+ // TODO: this isn't reliable so we need to guess the encoding from the actual content
+ author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
+ committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
+ message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
} catch (IOException e) {
e.printStackTrace();
} finally {
--
1.6.1.2
^ permalink raw reply related
* [JGIT PATCH] The default encoding for reading commits is UTF-8 rather than system default
From: Constantine Plotnikov @ 2009-10-07 15:44 UTC (permalink / raw)
To: git; +Cc: Constantine Plotnikov
When reading commits the system default encoding was used if no encoding
was specified in the commit. The patch modifies test to add a check that
commit message was encoded correctly (the test fails on old implementation
if system encoding is not UTF-8) and fixes Commit.decode() method to use
UTF-8 is encoding is not specified in the commit object.
Signed-off-by: Constantine Plotnikov <constantine.plotnikov@gmail.com>
---
See man git-commit (the section "DISCUSSION"), for justification why
UTF-8 should be used. Note that this was already correctly implemented
in ObjectWriter.writeCommit(...) method. But Commit.decode() was not
implemented in the same way for some reason.
.../tst/org/spearce/jgit/lib/T0003_Basic.java | 3 +++
.../src/org/spearce/jgit/lib/Commit.java | 18 +++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
index c2b1b91..4702aaf 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0003_Basic.java
@@ -348,6 +348,9 @@ public void test023_createCommitNonAnullii() throws IOException {
commit.setMessage("\u00dcbergeeks");
ObjectId cid = new ObjectWriter(db).writeCommit(commit);
assertEquals("4680908112778718f37e686cbebcc912730b3154", cid.name());
+ Commit loadedCommit = db.mapCommit(cid);
+ assertNotSame(loadedCommit, commit);
+ assertEquals(commit.getMessage(), loadedCommit.getMessage());
}
public void test024_createCommitNonAscii() throws IOException {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
index 030d4a4..933b929 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
@@ -299,17 +299,13 @@ private void decode() {
br.read(readBuf);
int msgstart = readBuf.length != 0 ? ( readBuf[0] == '\n' ? 1 : 0 ) : 0;
- if (encoding != null) {
- // TODO: this isn't reliable so we need to guess the encoding from the actual content
- author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
- committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
- message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
- } else {
- // TODO: use config setting / platform / ascii / iso-latin
- author = new PersonIdent(new String(rawAuthor.getBytes()));
- committer = new PersonIdent(new String(rawCommitter.getBytes()));
- message = new String(readBuf, msgstart, readBuf.length-msgstart);
- }
+ // If encoding is not specified, the default for commit is UTF-8
+ if (encoding == null) encoding = Constants.CHARSET;
+
+ // TODO: this isn't reliable so we need to guess the encoding from the actual content
+ author = new PersonIdent(new String(rawAuthor.getBytes(),encoding.name()));
+ committer = new PersonIdent(new String(rawCommitter.getBytes(),encoding.name()));
+ message = new String(readBuf,msgstart, readBuf.length-msgstart, encoding.name());
} catch (IOException e) {
e.printStackTrace();
} finally {
--
1.6.1.2
^ permalink raw reply related
* Re: [RFC PATCH] bash completion: complete refs for git-grep
From: Thomas Rast @ 2009-10-07 15:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091006154555.GN9261@spearce.org>
Shawn O. Pearce wrote:
>
> Thomas Rast <trast@student.ethz.ch> wrote:
> > + local i c=1 have_regex=""
> > + while [ $c -lt $COMP_CWORD ]; do
> > + i="${COMP_WORDS[c]}"
> > + case "$i" in
> > + -e) ;;
> > + -e*) have_regex="$c" ; break ;;
> > + -*) ;;
> > + *) have_regex="$c"; break ;;
> > + esac
> > + c=$((++c))
> > + done
>
> What happens with `git grep -e a -e b`? Do we trigger into ref
> completion too early when we should still be doing the regex
> completion?
Hmm, true, I would also have to check for the last argument (before
completion) being -e.
However, that is kind of moot because we currently complete filenames
anyway, and you said I can't stop that:
> > This is still RFC because, as you can see in the code below, I tried
> > to avoid completing at all while the user still needs to supply a
> > regex. Sadly, bash turns the COMPREPLY=() into filename completion
> > anyway. Is there a way to prevent this?
>
> Not that I know of. You can turn off default filename completion
> when you register the completion function, but that then breaks
> like every other git command for completion support because a lot
> of them do want to complete filenames.
So I'll roll a simpler patch that just always (before --) completes
refs instead, if that's ok.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] New date format: local_original
From: Jeff King @ 2009-10-07 12:54 UTC (permalink / raw)
To: Tuomas Suutari; +Cc: git
In-Reply-To: <200910062209.47606.tuomas.suutari@gmail.com>
On Tue, Oct 06, 2009 at 10:09:47PM +0300, Tuomas Suutari wrote:
> Formats date and time with local and original timezone representation
> in same string. They both can be useful at the same time: local
> timezone for relating timestamp to local events, and original timezone
> to see the author's time of the day.
>
> [...]
>
> It was hard to decide whether to use --date=local or --date=iso
> with git log, so I though that maybe I could have them both.
It's not clear to me. Do you really _like_ seeing them both, or did you
simply want to see local dates in the iso format, but those two options
(which are conceptually orthogonal) could not be used at the same time?
If the latter, then maybe we should resurrect the patch that allows
"--date=local --date=iso" to do what you want. From this thread:
http://thread.gmane.org/gmane.comp.version-control.git/112026
If the former, then should the options be orthogonal? That is, should it
be a new format combining the two, or should it be an option to show, in
your preferred format, the time in both local and original time zones?
E.g., something like:
$ git log --date=iso --local-dates-too
commit bf01a69ed40e1afcf56aff143f7523da2ce263ed
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: 2009-10-04 00:41:55 +0200
Local: 2009-10-03 17:41:55 -0500
And then you can use it with "normal" dates, iso dates, rfc2822 dates,
etc.
I dunno. I have to admit I never personally really wanted anything
except the default date format, unless I was parsing it for something
special.
-Peff
^ permalink raw reply
* Re: Code reuse
From: Sitaram Chamarty @ 2009-10-07 12:30 UTC (permalink / raw)
To: Philip Herron; +Cc: git
In-Reply-To: <ac07bcaf0910061218x148374d0u66b36fae1466ea98@mail.gmail.com>
On Wed, Oct 7, 2009 at 12:48 AM, Philip Herron
<herron.philip@googlemail.com> wrote:
> I am not sure if this is the right place to ask this question, but
> I've been working on a personal project a programming language
> interpreter for some time now, but i took 2 code snippets from
> git-core namely:
[snip]
> I've changed it a good bit (probably doesn't resemble much of what it
> was) to fit in with the way my stuff works but is there anything i
> need to like put in my source code to say hey this is based of
> git-core, so far is just a comment to say 'based of git-core hash.c'.
> Its an open source (GPL) program but i haven't released or made much
> noise about it yet because i want to work on it more myself.
In general, the GPL's main requirement is that whoever gets the binary
should also get the code (I'm over simplifying but that's basically
it). It actually doesn't say much about giving credit, except (from
<HEAD:COPYING>):
"If the software is modified by someone else and passed on, we want
its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the
original authors' reputations"
and
"a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change."
That's basically it...
It would seem to me that, if you changed them significantly, and going
by the above logic, you don't need to do *anything* regarding
attribution.
^ permalink raw reply
* [PATCH] README: git lives at http://git-scm.com these days
From: Stefan Naewe @ 2009-10-07 12:14 UTC (permalink / raw)
To: git; +Cc: gitster, Stefan Naewe
Signed-off-by: Stefan Naewe <stefan.naewe+git@gmail.com>
---
README | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/README b/README
index c932ab3..67cfeb2 100644
--- a/README
+++ b/README
@@ -37,7 +37,7 @@ CVS users may also want to read Documentation/gitcvs-migration.txt
("man gitcvs-migration" or "git help cvs-migration" if git is
installed).
-Many Git online resources are accessible from http://git.or.cz/
+Many Git online resources are accessible from http://git-scm.com/
including full documentation and Git related tools.
The user discussion and development of Git take place on the Git
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 1/3] completion: fix alias listings with newlines
From: Johannes Sixt @ 2009-10-07 9:33 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <1254905331-29516-1-git-send-email-bebarino@gmail.com>
Stephen Boyd schrieb:
> __git_aliases ()
> {
> - local i IFS=$'\n'
> - for i in $(git --git-dir="$(__gitdir)" config --get-regexp "alias\..*" 2>/dev/null); do
> - i="${i#alias.}"
> - echo "${i/ */}"
> + local i
> + git --git-dir="$(__gitdir)" config -z --get-regexp "alias\..*" 2>/dev/null |
> + while IFS= read -rd '' i; do
> + echo ${i#alias.} | cut -d' ' -f1
> done
> }
Is it necessary to change the body of the loop? Your version spawns two
processes on each iteration, while the original spawned no processes.
You can avoid the pipeline (i.e. yet another process) using a "here-string":
local i aliases=$(git --git-dir="$(__gitdir)" config -z \
--get-regexp "alias\..*" 2>/dev/null)
while IFS= read -rd '' i; do
i="${i#alias.}"
echo "${i/ */}" # could be: echo "${i%% *}"
done <<< "$aliases"
but I don't know how well bash handles variable values with embedded NULs.
-- Hannes
^ permalink raw reply
* Question: Odd merging behaviour with copied/moved files
From: Michael Harbeck @ 2009-10-07 8:52 UTC (permalink / raw)
To: git
Hello,
I'd just had the following situation:
A repository with a file: File1
A clone of this repository.
I made some changes to File1 in this repository and checked them in
Now someone decide to to rename and copy the File1 in the first repository and
checked those changes in. Now there is no File1 any more in the first repository.
After a while I pulled from this first repository. My changes are only merged in
one file! I think this behavior is strange.
In the second case its also strange, that if there is a copy in the first
repository, after a pull my changes in the copied file are also missing.
Is there a possibility to get warned about these situations, or better is there
an automatic way to merge my changes to both pulled files?
Thanks,
Michael
^ permalink raw reply
* [PATCH 2/3] completion: update am, commit, and log
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1254905331-29516-1-git-send-email-bebarino@gmail.com>
git am learned --scissors, git commit learned --dry-run and git log
learned --decorate=long|short recently.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 332be99..2ab8c5e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -668,7 +668,7 @@ _git_am ()
--3way --committer-date-is-author-date --ignore-date
--ignore-whitespace --ignore-space-change
--interactive --keep --no-utf8 --signoff --utf8
- --whitespace=
+ --whitespace= --scissors
"
return
esac
@@ -894,6 +894,7 @@ _git_commit ()
__gitcomp "
--all --author= --signoff --verify --no-verify
--edit --amend --include --only --interactive
+ --dry-run
"
return
esac
@@ -1179,6 +1180,10 @@ _git_log ()
__gitcomp "$__git_log_date_formats" "" "${cur##--date=}"
return
;;
+ --decorate=*)
+ __gitcomp "long short" "" "${cur##--decorate=}"
+ return
+ ;;
--*)
__gitcomp "
$__git_log_common_options
@@ -1191,7 +1196,7 @@ _git_log ()
--pretty= --format= --oneline
--cherry-pick
--graph
- --decorate
+ --decorate --decorate=
--walk-reflogs
--parents --children
$merge
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH 1/3] completion: fix alias listings with newlines
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
Since commit 518ef8f (completion: Replace config --list with
--get-regexp, 2009-09-11) an alias config value containing a newline
would break the completion of aliases. Instead of setting the IFS to the
newline, use git-config's null termination to separate aliases with the
null character.
An example .gitconfig causing the breakage.
[alias]
whowhat = "log -1 --pretty='format:%an <%ae>\n%s'"
wont-complete = ...
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This is the best I can come up with. I'm not sure about using the
d option of read though.
contrib/completion/git-completion.bash | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2c2a0d4..332be99 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -600,10 +600,10 @@ __git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
- local i IFS=$'\n'
- for i in $(git --git-dir="$(__gitdir)" config --get-regexp "alias\..*" 2>/dev/null); do
- i="${i#alias.}"
- echo "${i/ */}"
+ local i
+ git --git-dir="$(__gitdir)" config -z --get-regexp "alias\..*" 2>/dev/null |
+ while IFS= read -rd '' i; do
+ echo ${i#alias.} | cut -d' ' -f1
done
}
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH 3/3] completion: add dirstat and friends to diff options
From: Stephen Boyd @ 2009-10-07 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1254905331-29516-2-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
I sent this a while back, no response. If no response again I'll drop.
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2ab8c5e..a5fe1df 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -927,6 +927,8 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--inter-hunk-context=
--patience
--raw
+ --dirstat --dirstat= --dirstat-by-file
+ --dirstat-by-file= --cumulative
"
_git_diff ()
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* [PATCH] Teach 'rebase -i' the command "reword"
From: Björn Gustavsson @ 2009-10-07 6:13 UTC (permalink / raw)
To: gitster; +Cc: git
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Re-roll of my patch with improvements to the documentation
and help text suggested by Johannes Sixt and Stephen Boyd.
Documentation/git-rebase.txt | 9 ++++++---
git-rebase--interactive.sh | 9 +++++++++
t/lib-rebase.sh | 6 +++---
t/t3404-rebase-interactive.sh | 14 ++++++++++++++
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0aefc34..33e0ef1 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -368,14 +368,17 @@ By replacing the command "pick" with the command "edit", you can tell
the files and/or the commit message, amend the commit, and continue
rebasing.
+If you just want to edit the commit message for a commit, replace the
+command "pick" with the command "reword".
+
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
the author of the first commit.
-In both cases, or when a "pick" does not succeed (because of merge
-errors), the loop will stop to let you fix things, and you can continue
-the loop with `git rebase --continue`.
+'git-rebase' will stop when "pick" has been replaced with "edit" or
+when a command fails due to merge errors. When you are done editing
+and/or resolving conflicts you can continue with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..a43ee22 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -340,6 +340,14 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
;;
+ reword|r)
+ comment_for_reflog reword
+
+ mark_action_done
+ pick_one $sha1 ||
+ die_with_patch $sha1 "Could not apply $sha1... $rest"
+ output git commit --amend
+ ;;
edit|e)
comment_for_reflog edit
@@ -752,6 +760,7 @@ first and then run 'git rebase --continue' again."
#
# Commands:
# p, pick = use commit
+# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 260a231..62f452c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -9,8 +9,8 @@
#
# "[<lineno1>] [<lineno2>]..."
#
-# If a line number is prefixed with "squash" or "edit", the respective line's
-# command will be replaced with the specified one.
+# If a line number is prefixed with "squash", "edit", or "reword", the
+# respective line's command will be replaced with the specified one.
set_fake_editor () {
echo "#!$SHELL_PATH" >fake-editor.sh
@@ -32,7 +32,7 @@ cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
- squash|edit)
+ squash|edit|reword)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 4cae019..3a37793 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -470,4 +470,18 @@ test_expect_success 'avoid unnecessary reset' '
test 123456789 = $MTIME
'
+test_expect_success 'reword' '
+ git checkout -b reword-branch master &&
+ FAKE_LINES="1 2 3 reword 4" FAKE_COMMIT_MESSAGE="E changed" git rebase -i A &&
+ git show HEAD | grep "E changed" &&
+ test $(git rev-parse master) != $(git rev-parse HEAD) &&
+ test $(git rev-parse master^) = $(git rev-parse HEAD^) &&
+ FAKE_LINES="1 2 reword 3 4" FAKE_COMMIT_MESSAGE="D changed" git rebase -i A &&
+ git show HEAD^ | grep "D changed" &&
+ FAKE_LINES="reword 1 2 3 4" FAKE_COMMIT_MESSAGE="B changed" git rebase -i A &&
+ git show HEAD~3 | grep "B changed" &&
+ FAKE_LINES="1 reword 2 3 4" FAKE_COMMIT_MESSAGE="C changed" git rebase -i A &&
+ git show HEAD~2 | grep "C changed"
+'
+
test_done
--
1.6.4.4
^ permalink raw reply related
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