* Re: how to omit rename file when commit
From: Junio C Hamano @ 2009-01-19 9:16 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901190113l5407f108lff8f37d9a8331f58@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> For example there are a file a.c at git repository.
> use
> git mv a.c b.c
>
> git status:
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # renamed: a.c -> b.c
>
> If we don't want to stage this change at this commit, what can I do?
I may be misunderstanding what you want to do, but wouldn't "git mv b.c
a.c" undo whatever you did?
^ permalink raw reply
* Re: [PATCH] git-svn: fix SVN 1.1.x compatibility
From: Tom G. Christensen @ 2009-01-19 9:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090119004556.GA25038@dcvr.yhbt.net>
Eric Wong wrote:
> The get_log() function in the Perl SVN API introduced the limit
> parameter in 1.2.0. However, this got discarded in our SVN::Ra
> compatibility layer when used with SVN 1.1.x. We now emulate
> the limit functionality in older SVN versions by preventing the
> original callback from being called if the given limit has been
> reached. This emulation is less bandwidth efficient, but SVN
> 1.1.x is becoming rarer now.
>
> Additionally, the --limit parameter in svn(1) uses the
> aforementioned get_log() functionality change in SVN 1.2.x.
> t9129 no longer depends on --limit to work and instead uses
> Perl to parse out the commit message.
>
> Thanks to Tom G. Christensen for the bug report.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
I applied this to 1.6.1 and the testsuite now passes using SVN 1.1.4 on
RHEL 4/i386 (t9106 still fails on RHEL 4/x86_64).
-tgc
^ permalink raw reply
* Re: how to omit rename file when commit
From: Frank Li @ 2009-01-19 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63kbr6zc.fsf@gitster.siamese.dyndns.org>
For example:
there are 2 file. a.c and e.c
I modify e.c.
and git mv a.c b.c
git update-index e.c
I just want to commit e.c and don't commit rename(a.c -> b.c)
I am debuging a tortoisegit. at commit dialog, there will be show all
changed as
[x] rename (a.c => b.c)
[x] modify (e.c)
button [OK]
assume user uncheck rename
[]rename (a.c=>b.c)
[x]modify (e.c)
then click okay.
I don't know use which git command to handle this case.
if git mv b.c a.c, local working copy will be changed.
2009/1/19 Junio C Hamano <gitster@pobox.com>:
> "Frank Li" <lznuaa@gmail.com> writes:
>
>> For example there are a file a.c at git repository.
>> use
>> git mv a.c b.c
>>
>> git status:
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # renamed: a.c -> b.c
>>
>> If we don't want to stage this change at this commit, what can I do?
>
> I may be misunderstanding what you want to do, but wouldn't "git mv b.c
> a.c" undo whatever you did?
>
>
^ permalink raw reply
* Syncing with CVS
From: Christian von Kietzell @ 2009-01-19 9:39 UTC (permalink / raw)
To: git
Hi,
I have a project I started in git. After a while I exported that to
CVS via git cvsexportcommit which worked quite nicely. Now, a
colleague made changes to the project - in CVS. What's the best way to
get those back into my git repository so that I'll be able to sync
back and forth between git and CVS? I had a quick look at the wiki but
couldn't find anything appropriate.
I know of git cvsimport, of course, but that doesn't work on my
original repository. Or does it? I didn't find anything on how to
limit what to import. After all, some of the commits are already in my
repository (the ones I exported).
Hope any of you can help. Thanks in advance.
Chris
^ permalink raw reply
* Re: Syncing with CVS
From: Johan Herland @ 2009-01-19 10:28 UTC (permalink / raw)
To: Christian von Kietzell; +Cc: git
In-Reply-To: <f31e50960901190139w65b69fd1k752973a23c40f384@mail.gmail.com>
On Monday 19 January 2009, Christian von Kietzell wrote:
> Hi,
>
> I have a project I started in git. After a while I exported that to
> CVS via git cvsexportcommit which worked quite nicely. Now, a
> colleague made changes to the project - in CVS. What's the best way
> to get those back into my git repository so that I'll be able to sync
> back and forth between git and CVS? I had a quick look at the wiki
> but couldn't find anything appropriate.
>
> I know of git cvsimport, of course, but that doesn't work on my
> original repository. Or does it? I didn't find anything on how to
> limit what to import. After all, some of the commits are already in
> my repository (the ones I exported).
>
> Hope any of you can help. Thanks in advance.
Unfortunately bidirectional syncing between CVS and Git is pretty much
impossible in the general case, because CVS's structure is so different
from Git's. For one, it is very easy to (re)move tags and branches in
CVS, with no record of where it was moved from. (Also, as anybody
involved in proper CVS-to-Git converters ("git cvsimport" does _not_
fall into this category) will tell you, recreating history from CVS is
a highly non-trivial task in itself.) This means that even if you have
imported some CVS state into Git, you cannot guarantee that the CVS
state has not changed the next time you try to import. Therefore, it is
very hard to determine whether you're importing a whole new branch from
CVS, or whether you are just incrementally importing patches on top of
a previously imported branch.
I have a similar situation at $dayjob, where we have a central CVS
server with the official version, and I use Git for working locally. In
this case, I use "git cvsexportcommit" to propagate my local changes to
the CVS server. I only use this approach on branches where nobody else
is allowed to commit (of course CVS does not enforce this rule, so I
have to manually make sure that does not happen). If someone else were
to commit to my branch in CVS, I would have to redo a full CVS-to-Git
conversion, in order to get a new Git repo that is in sync with CVS. I
can then resume "git cvsexportcommit" to propagate my changes from Git
to CVS.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Syncing with CVS
From: Boaz Harrosh @ 2009-01-19 10:58 UTC (permalink / raw)
To: Christian von Kietzell; +Cc: git
In-Reply-To: <f31e50960901190139w65b69fd1k752973a23c40f384@mail.gmail.com>
Christian von Kietzell wrote:
> Hi,
>
> I have a project I started in git. After a while I exported that to
> CVS via git cvsexportcommit which worked quite nicely. Now, a
> colleague made changes to the project - in CVS. What's the best way to
> get those back into my git repository so that I'll be able to sync
> back and forth between git and CVS? I had a quick look at the wiki but
> couldn't find anything appropriate.
>
> I know of git cvsimport, of course, but that doesn't work on my
> original repository. Or does it? I didn't find anything on how to
> limit what to import. After all, some of the commits are already in my
> repository (the ones I exported).
>
> Hope any of you can help. Thanks in advance.
>
> Chris
I would "git cvsimport" into temporary new git.
Then "git remote add cvs_import that_temp_git" into the main git
Then find the point of the common base, do
"git tag CVS_GIT_BASE that_base_commit_uid"
"git checkout -b cvs_import cvs_import/master"
"git rebase --onto master CVS_GIT_BASE"
So in fact I'm just cherry-picking the additions from CVS
and reapplying on to original git tree. If you want it more
automatic you'll need to do the above in a script with some
kind of naming conventions for your git tags and CVS's tags
at points of sync.
Boaz
^ permalink raw reply
* Re: how to omit rename file when commit
From: Jakub Narebski @ 2009-01-19 11:01 UTC (permalink / raw)
To: Frank Li; +Cc: Junio C Hamano, git
In-Reply-To: <1976ea660901190135k71087673p85e995878e539a8f@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> For example:
> there are 2 file. a.c and e.c
> I modify e.c.
> and git mv a.c b.c
>
> git update-index e.c
>
> I just want to commit e.c and don't commit rename(a.c -> b.c)
The simplest way (but I'm not sure if it is what you want) would be
$ git commit e.c
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: meaning of --8<--
From: Samuel Tardieu @ 2009-01-19 11:36 UTC (permalink / raw)
To: Peter Harris; +Cc: markus.heidelberg, git
In-Reply-To: <eaa105840901180804k64a745f9q1a092fe3915db868@mail.gmail.com>
>>>>> "Peter" == Peter Harris <git@peter.is-a-geek.org> writes:
Peter> Scissors 8<
One can also use the Unicode character 0x2702: ✂
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-19 10:16 UTC (permalink / raw)
To: git list
Hi,
..I recently install GIT on Ubuntu (hardy) box....I am able to use
'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
not found'
-- DM
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Kjetil Barvik @ 2009-01-19 11:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
<snipp>
> ----------------------------------------------------------------
> [Actively cooking]
>
> * kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
> + lstat_cache(): introduce clear_lstat_cache() function
> + lstat_cache(): introduce invalidate_lstat_cache() function
> + lstat_cache(): introduce has_dirs_only_path() function
> + lstat_cache(): introduce has_symlink_or_noent_leading_path()
> function
> + lstat_cache(): more cache effective symlink/directory detection
>
> This is the tenth round, now in 'next'.
Thanks!! Nice to see that the patch is going forward. And I have to
admit that it was very fun to make that patch.
How long is the 'merge window' in Linux Kernel terms for this round
(to the next release of GIT)?
I have a second idea to an improvement, which also looks quite good
for the moment, and I am sort of wondering how fast I must work. :-)
-- kjetil
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Reece Dunn @ 2009-01-19 11:59 UTC (permalink / raw)
To: Dilip M; +Cc: git list
In-Reply-To: <c94f8e120901190216x246589ebwc4a44dd85bb655d2@mail.gmail.com>
2009/1/19 Dilip M <dilipm79@gmail.com>:
> Hi,
>
> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> not found'
Who is the owner of the repository directory (and the .git directory)
and what are the permissions on the directory? You can run (on the
command line from the Terminal program):
ls -lh directory
to find this out (where directory is the directory you are interested
in) and run:
sudo chown user -R directory
to change ownership of that directory (and all of its content) to the
specified user (i.e. the one you are currently logged in as). This
will make it so that you own that directory and can make changes to
it. This should allow you to run gitk without using sudo.
HTH,
- Reece
^ permalink raw reply
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Adeodato Simó @ 2009-01-19 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskngwfko.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:
> Adeodato Simó <dato@net.com.org.es> writes:
> > However, I've as of late directly created bare repositories knowing that
> > I wanted to work just with workdirs against it. In this case, the logs
> > for each checkout'ed branch will be stored in the workdirs and not the
> > repo, so deleting the workdir will make you lose those logs. Which is
> > bad, since workdirs should always be safe to delete.
> I had to think about the above for a while, but after realizing that you
> have a strict distinction between a "workdir" and a normal "repository
> with a work tree" in mind, I can see where you are coming from. A workdir
> is transient in nature and you should be able to dismiss it safely as long
> as the repository it borrows from is intact.
The thing, for me, is that a workdir should result in effects as close
as possible as doing the work in the repository with the workdir itself.
I normally use workdirs when it's not feasible to do the work in the
repo itself (eg., there's work in progress I'd rather have around,
rather than committing it to a temporary branch, to leave the repo
"clean" for further work).
> A workdir is a new work area that is not a normal "work tree with a
> full repository", but borrows from an existing repository. Any side
> effect from the work you do in a workdir will be saved in the original
> repository, and removing one would lose only the three kind of
> information listed above. Creating a new workdir has the side effect
> of enabling reflogs and rerere in the original repository.
> But the last sentence somehow feels dirty.
I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
*enable* reflogs and rerere at all? Or, rather, it just gives an empty
space for the workdirs "connecting" to it to save their reflogs and
rerere stuff iff they are configured to do so?
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
-- Oscar Hammerstein II
^ permalink raw reply
* [PATCH] parsecvs: produce tagger fields acceptable to newer git versions
From: Lennert Buytenhek @ 2009-01-19 12:02 UTC (permalink / raw)
To: keithp; +Cc: git, jay, jim, kedars
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
diff --git a/git.c b/git.c
index da320d1..8f94d1b 100644
--- a/git.c
+++ b/git.c
@@ -371,11 +371,13 @@ git_mktag (rev_commit *commit, char *name)
"object %s\n"
"type commit\n"
"tag %s\n"
- "tagger %s\n"
+ "tagger %s <%s> %lu +0000\n"
"\n",
commit->sha1,
name,
- author ? author->full : commit->author);
+ author ? author->full : commit->author,
+ author ? author->email : commit->author,
+ commit->date);
if (rv < 1) {
fprintf (stderr, "%s: %s\n", filename, strerror (errno));
fclose (f);
^ permalink raw reply related
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Johannes Schindelin @ 2009-01-19 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vljt7r9mq.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Well, I would rather be in favor of something like this.
> >
> > -- >8 --
> > Subject: interpret_nth_last_branch(): avoid traversing the reflog twice
> >
> > You can have quite a many reflog entries, but you typically won't recall
> > which branch you were on after switching branches for more than several
> > times.
> >
> > Instead of reading the reflog twice, this reads the branch switching event
> > and keeps the latest 16 (which is an arbitrary limitation that should be
> > plenty) such entry, to switch back to the branch we were recently on.
> >
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> > sha1_name.c | 48 +++++++++++++++++++++------------------------
> > t/t2012-checkout-last.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 66 insertions(+), 26 deletions(-)
> >
> > diff --git a/sha1_name.c b/sha1_name.c
> > index 9e1538e..d6622f2 100644
> > --- a/sha1_name.c
> > +++ b/sha1_name.c
> > @@ -750,19 +746,19 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
> > nth = strtol(name+3, &num_end, 10);
> > if (num_end != brace)
> > return -1;
> > ...
> > - if (cb.nth < nth)
> > - return 0;
> > ...
> > + if (cb.cnt < nth)
> > + return -1;
>
> This should (obviously) be "return 0".
This, together with a removal of the hard-coded limit of 16 could be
squashed with this patch:
-- snipsnap --
diff --git a/sha1_name.c b/sha1_name.c
index 2c5461e..9e5f444 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -691,11 +691,9 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
-#define MAX_PREVIOUS_BRANCH 16
-
struct grab_nth_branch_switch_cbdata {
- long cnt;
- struct strbuf buf[MAX_PREVIOUS_BRANCH];
+ long cnt, alloc;
+ struct strbuf *buf;
};
static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -720,7 +718,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (target[len] == '\n' && !strncmp(match, target, len))
return 0;
- nth = cb->cnt++ % MAX_PREVIOUS_BRANCH;
+ nth = cb->cnt++ % cb->alloc;
strbuf_reset(&cb->buf[nth]);
strbuf_add(&cb->buf[nth], match, len);
return 0;
@@ -753,19 +751,22 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
nth = strtol(name+3, &num_end, 10);
if (num_end != brace)
return -1;
- if (nth <= 0 || MAX_PREVIOUS_BRANCH < nth)
+ if (nth <= 0)
return -1;
- for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ cb.alloc = nth;
+ cb.buf = xmalloc(nth * sizeof(struct strbuf));
+ for (i = 0; i < nth; i++)
strbuf_init(&cb.buf[i], 20);
cb.cnt = 0;
for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
if (cb.cnt < nth)
- return -1;
- i = (cb.cnt + MAX_PREVIOUS_BRANCH - nth) % MAX_PREVIOUS_BRANCH;
+ return 0;
+ i = cb.cnt % nth;
strbuf_reset(buf);
strbuf_add(buf, cb.buf[i].buf, cb.buf[i].len);
- for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ for (i = 0; i < nth; i++)
strbuf_release(&cb.buf[i]);
+ free(cb.buf);
return brace-name+1;
}
--
1.6.1.347.g7b62749
^ permalink raw reply related
* [PATCH] @{-<n>}: avoid crash with corrupt reflog
From: Johannes Schindelin @ 2009-01-19 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vljt7r9mq.fsf@gitster.siamese.dyndns.org>
The earlier code checked if a " to " was found after "checkout: Moving
from ". However, it then went on to access the pointer to " to ",
regardless if it was still NULL (if no " to " was found) or not.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
You might want to squash this into "sha1_name: tweak @{-N}
lookup", just as a safety belt.
sha1_name.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 9e5f444..853bac6 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -705,18 +705,18 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
size_t len;
int nth;
- if (!prefixcmp(message, "checkout: moving from ")) {
- match = message + strlen("checkout: moving from ");
- if ((target = strstr(match, " to ")) != NULL)
- target += 4;
- }
-
- if (!match)
+ if (prefixcmp(message, "checkout: moving from "))
return 0;
- len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
- return 0;
+ match = message + strlen("checkout: moving from ");
+ if ((target = strstr(match, " to ")) != NULL) {
+ len = target - match - 4;
+ target += 4;
+ if (target[len] == '\n' && !strncmp(match, target, len))
+ return 0;
+ }
+ else
+ len = strchrnul(match, ' ') - match;
nth = cb->cnt++ % cb->alloc;
strbuf_reset(&cb->buf[nth]);
--
1.6.1.347.g7b62749
^ permalink raw reply related
* Re: [PATCH] parsecvs: produce tagger fields acceptable to newer git versions
From: Jim Meyering @ 2009-01-19 12:44 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: keithp, git, jay, kedars
In-Reply-To: <20090119120217.GD4390@xi.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote:
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
>
> diff --git a/git.c b/git.c
> index da320d1..8f94d1b 100644
> --- a/git.c
> +++ b/git.c
> @@ -371,11 +371,13 @@ git_mktag (rev_commit *commit, char *name)
> "object %s\n"
> "type commit\n"
> "tag %s\n"
> - "tagger %s\n"
> + "tagger %s <%s> %lu +0000\n"
> "\n",
> commit->sha1,
> name,
> - author ? author->full : commit->author);
> + author ? author->full : commit->author,
> + author ? author->email : commit->author,
> + commit->date);
> if (rv < 1) {
> fprintf (stderr, "%s: %s\n", filename, strerror (errno));
> fclose (f);
Hi Lennert,
I posted the same patch a while back.
http://markmail.org/message/cebh7suc7ejpayos
However, I never heard back.
You'll also need the patch below, if you're building
against a newer version of git.
>From 93bc277dff113f1133ef25b8bb985af80f1fbe0e Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Thu, 6 Nov 2008 11:35:09 +0100
Subject: [PATCH 2/2] * tree.c (init_tree): Adapt to new git_config API.
---
tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tree.c b/tree.c
index a76f27c..e2a041c 100644
--- a/tree.c
+++ b/tree.c
@@ -177,7 +177,7 @@ rev_commit *create_tree(rev_commit *leader)
void init_tree(int n)
{
- git_config(git_default_config);
+ git_config(git_default_config, NULL);
strip = n;
}
--
1.6.1.331.g9c367
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-19 13:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> * js/diff-color-words (Sat Jan 17 17:29:48 2009 +0100) 7 commits
> - color-words: make regex configurable via attributes
> - color-words: expand docs with precise semantics
> - color-words: enable REG_NEWLINE to help user
> - color-words: take an optional regular expression describing words
> - color-words: change algorithm to allow for 0-character word
> boundaries
> - color-words: refactor word splitting and use ALLOC_GROW()
> - Add color_fwrite_lines(), a function coloring each line
> individually
>
> Dscho's series that was done in response to Thomas's original; two agreed
> to work together on this codebase.
I am actually pretty comfortable with this series now.
> * jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
> . valgrind: ignore ldso errors
> . add valgrind support in test scripts
Could you put this in pu, at least, please?
Thanks,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-19 13:09 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <864ozvv7d3.fsf@broadpark.no>
Hi,
On Mon, 19 Jan 2009, Kjetil Barvik wrote:
> How long is the 'merge window' in Linux Kernel terms for this round
> (to the next release of GIT)?
There is no "merge window", but rather an "-rc" period for 1.x versions.
Which has been largely ignored :-)
Ciao,
Dscho
^ permalink raw reply
* Re: after first git clone of linux kernel repository there are changed files in working dir
From: Hannu Koivisto @ 2009-01-19 13:36 UTC (permalink / raw)
To: rdkrsr; +Cc: git
In-Reply-To: <d304880b0812101022u2abe5d68ub3bda68ed39f830b@mail.gmail.com>
rdkrsr <rdkrsr@googlemail.com> writes:
> I just fetched the sources without changing anything, but git diff
> shows, that there are changes that are not yet updated (changed but not
> updated: use git add to ...). Why is it like that?
>
> I use msysgit on windows, maybe that is one reason?
Kernel source contains pairs of files whose names differ only by
case. Windows cannot store such pairs (at least by default) and
apparently there is no support for such a situation in git so
you'll only get one file from each pair to your workspace and the
other file is shown as modified.
--
Hannu
^ permalink raw reply
* Re: [PATCH] parsecvs: produce tagger fields acceptable to newer git versions
From: Lennert Buytenhek @ 2009-01-19 13:39 UTC (permalink / raw)
To: Jim Meyering; +Cc: keithp, git, jay, kedars
In-Reply-To: <87ab9nbh49.fsf@meyering.net>
On Mon, Jan 19, 2009 at 01:44:06PM +0100, Jim Meyering wrote:
> > Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> >
> > diff --git a/git.c b/git.c
> > index da320d1..8f94d1b 100644
> > --- a/git.c
> > +++ b/git.c
> > @@ -371,11 +371,13 @@ git_mktag (rev_commit *commit, char *name)
> > "object %s\n"
> > "type commit\n"
> > "tag %s\n"
> > - "tagger %s\n"
> > + "tagger %s <%s> %lu +0000\n"
> > "\n",
> > commit->sha1,
> > name,
> > - author ? author->full : commit->author);
> > + author ? author->full : commit->author,
> > + author ? author->email : commit->author,
> > + commit->date);
> > if (rv < 1) {
> > fprintf (stderr, "%s: %s\n", filename, strerror (errno));
> > fclose (f);
>
> Hi Lennert,
Hey Jim,
> I posted the same patch a while back.
>
> http://markmail.org/message/cebh7suc7ejpayos
>
> However, I never heard back.
> You'll also need the patch below, if you're building
> against a newer version of git.
Can you make your parsecvs repository available somewhere?
thanks,
Lennert
^ permalink raw reply
* Re: [PATCH/RFC] shortlog: add option to group together different names/emails of an author
From: Adeodato Simó @ 2009-01-19 13:43 UTC (permalink / raw)
To: git
In-Reply-To: <1231600589-11811-1-git-send-email-dato@net.com.org.es>
Ping? I realize this may be seen as a big patch dropped out of the blue,
but I would very much like to hear some comments on at least the feature
itself, which should not take more than reading the commit message.
(Hints as to what to do to get people to comment on the code also
welcome, of course.)
--- Adeodato Simó [Sat, 10 Jan 2009 16:16:29 +0100]:
> It's common for repositories to contain commits with different spellings of
> an author name, or different email addresses. The shortlog command tries to
> alleviate this by using .mailmap files. However, maintaining a .mailmap file
> up to date is a manual process, and it does not help when shortlog is
> invoked with the -e option and different email addresses for an author are
> involved.
> This commit introduces a -j/--join-uids option that uses a very dumb logic
> to detect different spellings and addresses of a same author. In particular,
> it just joins commits when either the name or the address had been
> previously seen, attaching the commit to that previous id. In other words,
> these three ids will be joined:
> Author: Joe Developer <joe@example.com>
> Author: Joe R. Developer <joe_r@example.com>
> Author: Joe R. Developer <joe@example.com>
> but only because of the third spelling. The first two alone would be left
> separate. When the names and addresses are printed, the most common spelling
> and address are used.
> Incidentally, there is f817546 in git.git which has this author information:
> Author: Wincent Colaiuta <gitster@pobox.com>
> Which makes all of Wincent's commits to be assigned to Junio with -j. This
> is easily fixed with an entry for gitster@pobox.com in .mailmap, which this
> commit includes. (And then, only f817546 is be assigned to Junio.)
> Signed-off-by: Adeodato Simó <dato@net.com.org.es>
> ---
> This is my scratching of my own itch: I was used to `bzr author-stats`,
> which is equivalent to `git shortlog -jsne`. I realize -sn comes close,
> but I like having the email address listed. Please let me know what you
> think.
> Tests and a mention in git-shortlog.txt are missing. That'll come next
> when/if I'm told this has a chance of inclusion. :-)
> The code is valgrind'ed. I'm not completely confident, though, bugs will
> not be hiding in corner cases. Also, I don't see any appreciable
> slowdown with this version in git.git, particularly not between the
> current git-shortlog and this new when run without -j (not when run with
> -j either, but that's less critical).
> This patch applies on top of my as/maint-shortlog-cleanup branch.
> .mailmap | 1 +
> builtin-shortlog.c | 280 +++++++++++++++++++++++++++++++++++++++++++++-------
> shortlog.h | 14 ++-
> 3 files changed, 256 insertions(+), 39 deletions(-)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Don't be irreplaceable, if you can't be replaced, you can't be promoted.
^ permalink raw reply
* Re: [PATCH/RFC] shortlog: add option to group together different names/emails of an author
From: Johannes Schindelin @ 2009-01-19 13:49 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090119134346.GA27509@chistera.yi.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 730 bytes --]
Hi,
On Mon, 19 Jan 2009, Adeodato Simó wrote:
> Ping? I realize this may be seen as a big patch dropped out of the blue,
> but I would very much like to hear some comments on at least the feature
> itself, which should not take more than reading the commit message.
This is such a huge change, for something that not many people want.
Actually, you seem to be the first.
And you could just as well write a script that takes the output of
$ git log --pretty=format:%an\ %ae --all | sort | uniq
and constructs a valid .mailmap. That would also have the advantage that
you do not need to perform the analysis each time you call Git.
All these reasons make me believe that your patch should not be applied.
Sorry,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] shortlog: add option to group together different names/emails of an author
From: Adeodato Simó @ 2009-01-19 14:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901191445340.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Mon, 19 Jan 2009 14:49:39 +0100]:
> > Ping? I realize this may be seen as a big patch dropped out of the blue,
> > but I would very much like to hear some comments on at least the feature
> > itself, which should not take more than reading the commit message.
> This is such a huge change, for something that not many people want.
> Actually, you seem to be the first.
That's, uhm, sad. (I don't really buy the "not many people want it,
hence we should not include it" argument, unless by people you mean
"people who could do a review". No hard feelings, though.)
> And you could just as well write a script that takes the output of
> $ git log --pretty=format:%an\ %ae --all | sort | uniq
> and constructs a valid .mailmap. That would also have the advantage that
> you do not need to perform the analysis each time you call Git.
No, not really. As mentioned in the commit message, .mailmap files don't
help when you invoke shortlog with -e, and different email addresses for
an author are involved.
> All these reasons make me believe that your patch should not be applied.
Okay, I'll let go.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Mankind are very odd creatures: one half censure what they practice, the
other half practice what they censure; the rest always say and do as
they ought.
-- Michel de Montaigne
^ permalink raw reply
* Re: [PATCH/RFC] shortlog: add option to group together different names/emails of an author
From: Johannes Schindelin @ 2009-01-19 14:29 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090119141107.GA27992@chistera.yi.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1129 bytes --]
Hi,
On Mon, 19 Jan 2009, Adeodato Simó wrote:
> * Johannes Schindelin [Mon, 19 Jan 2009 14:49:39 +0100]:
>
> > > Ping? I realize this may be seen as a big patch dropped out of the blue,
> > > but I would very much like to hear some comments on at least the feature
> > > itself, which should not take more than reading the commit message.
>
> > And you could just as well write a script that takes the output of
>
> > $ git log --pretty=format:%an\ %ae --all | sort | uniq
>
> > and constructs a valid .mailmap. That would also have the advantage that
> > you do not need to perform the analysis each time you call Git.
>
> No, not really. As mentioned in the commit message, .mailmap files don't
> help when you invoke shortlog with -e, and different email addresses for
> an author are involved.
Well, the whole point of -e is that you want to see the email addresses,
too. So I am not really convinced it would be a good idea to mangle them.
But hey, I only expressed a personal opinion; If you can convince others,
you still might bring that feature in. You'll have to convince them,
though.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Jing Xue @ 2009-01-19 14:48 UTC (permalink / raw)
To: Dilip M; +Cc: git list
In-Reply-To: <c94f8e120901190216x246589ebwc4a44dd85bb655d2@mail.gmail.com>
On Mon, Jan 19, 2009 at 03:46:41PM +0530, Dilip M wrote:
> Hi,
>
> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> not found'
Do you have a 0027 umask?
http://www.digizenstudio.com/blog/2008/11/09/weird-git-gui-startup-problem/
HTH.
--
Jing Xue
^ 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