* Re: 'git am' doubt
From: Thiago Farina @ 2009-09-24 14:09 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List
In-Reply-To: <20090923235433.GB80337@gmail.com>
On Wed, Sep 23, 2009 at 8:54 PM, David Aguilar <davvid@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 07:20:53PM -0300, Thiago Farina wrote:
>> Hi,
>>
>> I'm trying to apply a patch from the mailing list using 'git am'.
>>
>> What I'm doing is:
>>
>> - In gmail:
>> - Save original, then I copied the content to a text editor.
>> - In text editor:
>> - Remove the first empty line.
>> - Save the file in the same directory where I have the git source.
>> - In git directory:
>> - $ git am -s ./filename.mbox
>>
>> Of course I'm doing something wrong here, but I don't know what.
>> The error is:
>> cat: /home/tfarina/git/.git/rebase-apply/next: No such file or directory
>> previous rebase directory /home/tfarina/git/.git/rebase-apply still
>> exists but mbox given.
>
>
> Perhaps you tried this previously and 'git am' failed?
> In which case, run 'git am --abort'.
I didn't try before.
>
>
> Now.. I've _never_ had luck saving patches out of gmail.
> But, I've had good luck with its imap interface.
> I use mutt, save emails to an mbox file, and use 'git am'
> on them. This has worked great for me.
Yeah, I tried with Evolution, and it worked for me, so the problem was
with Gmail.
>
> For sending emails to the list, I use msmtp and a
> ~/.gitconfig setting:
>
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
>
>
> Then it's simply 'git send-email <patch-file>'.
>
>
> Here's a random page explaining how to use mutt with gmail.
> http://shreevatsa.wordpress.com/2007/07/31/using-gmail-with-mutt-the-minimal-way/
>
> I can send you my .muttrc if that helps.
I'm using send-email to send my patches too. If you could, send me
your .muttrc, I will appreciate, may be I can try to use it instead of
Evolution.
Thanks for your help. ;)
^ permalink raw reply
* [PATCHv2] bash: teach 'git checkout' options
From: SZEDER Gábor @ 2009-09-24 12:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, SZEDER Gábor
In-Reply-To: <20090922152846.GQ14660@spearce.org>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8c268a1..a08e471 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -809,7 +809,21 @@ _git_checkout ()
{
__git_has_doubledash && return
- __gitcomp "$(__git_refs)"
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --conflict=*)
+ __gitcomp "diff3 merge" "" "${cur##--conflict=}"
+ ;;
+ --*)
+ __gitcomp "
+ --quiet --ours --theirs --track --no-track --merge
+ --conflict= --patch
+ "
+ ;;
+ *)
+ __gitcomp "$(__git_refs)"
+ ;;
+ esac
}
_git_cherry ()
--
1.6.5.rc2.85.gd02ad
^ permalink raw reply related
* RE: [JGIT PATCH 7/9] removing eclipse project files
From: Mark Struberg @ 2009-09-24 11:50 UTC (permalink / raw)
To: MatthiasSohn; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <C89280B882467443A695734861B942B296767534@DEWDFECCR09.wdf.sap.corp>
Hi Matthias!
the answer is a clear yes and no - a 'jein' for german speaking people like you ;)
yes: we have the same settings for the compiler as used before: jdk 1.5 for source and target. This is exactly what has been taken in the ant build which was used prior to maven.
Please note that the settings in org.eclipse.jdt.core.prefs never had (and must not have) any impact on the created jar!
and no: currently the very file you mentioned contains a lot more stuff. In fact most of this are only editor settings, preferred formattings etc which has nothing to do with the build per se. Eclipse has the ability to import/export all those settings in a XML file which is version independent. We should go this way and also supply similar setting-files for Idea and NetBeans. But forcing those settings via an internal Eclipse plugin config file is imho bad practice.
LieGrue,
strub
--- On Thu, 9/24/09, Sohn, Matthias <matthias.sohn@sap.com> wrote:
> From: Sohn, Matthias <matthias.sohn@sap.com>
> Subject: RE: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "git@vger.kernel.org" <git@vger.kernel.org>, "spearce@spearce.org" <spearce@spearce.org>
> Date: Thursday, September 24, 2009, 1:24 PM
> Can Maven control compiler settings
> on the same level as we do currently with
> .settings/org.eclipse.jdt.core.prefs ?
>
^ permalink raw reply
* Re: Per-remote tracking branch
From: Björn Steinbrink @ 2009-09-24 11:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <20090924112550.GA6540@atjola.homenet>
On 2009.09.24 13:25:50 +0200, Björn Steinbrink wrote:
> On 2009.09.15 17:29:58 +0200, Matthieu Moy wrote:
> > At the moment, I can configure a tracking branch to let me just type
> >
> > $ git pull
> >
> > when I want to say
> >
> > $ git pull origin master
> >
> > Now, assume I have another remote "foo", I'd like to be able to just
> > say
> >
> > $ git pull foo
> >
> > and put something in my .git/config so that Git knows I mean
> >
> > $ git pull foo master
> >
> > Is there a simple way to do that?
>
> Setup "foo" so that it fetches "master" only, i.e. have
> remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
>
> You get that setup with: git remote add -t master foo git://...
>
> Then there's only one possible choice for "git pull", and it will take
> that.
Ah, crap, spoke too soon. That works only when branch.<name>.merge is
not set. Though that's not that much of a problem. When your "primary"
remote (the one set for branch.<name>.remote) also fetches just a single
branch, "git pull" will still work, even if branch.<name>.merge is not
set.
Björn
^ permalink raw reply
* Re: Per-remote tracking branch
From: Björn Steinbrink @ 2009-09-24 11:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4or48bux.fsf@bauges.imag.fr>
On 2009.09.15 17:29:58 +0200, Matthieu Moy wrote:
> Hi,
>
> Is there a way, with Git, to specify a tracking branch on a per-remote
> basis?
>
> At the moment, I can configure a tracking branch to let me just type
>
> $ git pull
>
> when I want to say
>
> $ git pull origin master
>
> Now, assume I have another remote "foo", I'd like to be able to just
> say
>
> $ git pull foo
>
> and put something in my .git/config so that Git knows I mean
>
> $ git pull foo master
>
> Is there a simple way to do that?
Setup "foo" so that it fetches "master" only, i.e. have
remote.foo.fetch = refs/heads/master:refs/remotes/foo/master
You get that setup with: git remote add -t master foo git://...
Then there's only one possible choice for "git pull", and it will take
that.
Björn
^ permalink raw reply
* RE: [JGIT PATCH 7/9] removing eclipse project files
From: Sohn, Matthias @ 2009-09-24 11:24 UTC (permalink / raw)
To: Mark Struberg; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <1253740570-10718-7-git-send-email-struberg@yahoo.de>
Can Maven control compiler settings on the same level as we do currently with
.settings/org.eclipse.jdt.core.prefs ?
^ permalink raw reply
* Re: Per-remote tracking branch
From: Matthieu Moy @ 2009-09-24 11:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090924062911.GC24486@coredump.intra.peff.net>
Hi, and thanks for your answer,
Jeff King <peff@peff.net> writes:
> On Tue, Sep 15, 2009 at 05:29:58PM +0200, Matthieu Moy wrote:
>
>> Is there a way, with Git, to specify a tracking branch on a per-remote
>> basis?
>
> I don't think so, and I'm not sure there is an easy way to extend the
> current configuration scheme. Adding multiple config options like this:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> remote = alternate
> merge = refs/heads/master
I had tried this in case it would have worked ;-).
> And it feels a little backwards. When I say "git pull foo", I would find
> it equally likely to discover the pulled branch under "remote.foo" as it
> would to find it under "branch.master". Of course, in either case, you
> have to combine the context (current branch _and_ selected remote)
> to come up with the actual information.
Actually, for my particular use case (aka "almost always only one
branch per repo"), I could as well have a remote.foo.defaultBranch
regardless of the current local branch. Then, if I say "git pull foo",
it would understand it as "git pull foo <remote.foo.defaultBranch>".
If other people would be interested in such feature, say so, I may
give it a try when I have time. If I'm the only one, I guess I'll let
my fingers type the extra " master" instead ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Deon George @ 2009-09-24 9:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bpl0c2cf.fsf@localhost.localdomain>
Jakub Narebski wrote:
> First, I assume there that you do not allow for the same file to
> belong to different repositories.
Well, no, I cant see why a file cannot belong to both repositories.
I'm sure it would be easier if a file did belong to a unique
repository, but given that GIT operates at a content layer (from what
I've read anyway), I cant see why it couldnt belong to more than one.
> you can try either submodules
> (git-submodule), or subtree (subtree merge, or third-party git-subtree
> helper).
I had a quick look at submodule - I dont think it helps me anyway,
since I want the flexibility for files to belong to many
sub-directories - not all under 1 sub directory hierarchy.
> Third, if the above isn't what you want, then you can manually
> intermingle working directories of different git repositories
> (probably requiring decouplig of bare git repository (git-dir)
> from working area (work-tree)).
Ahh, now this sounds like it might be what I want to do - I think I'll
explore this. I can see that it would provide file level autonomy
only, but as a starting point I think it will help heaps...
I'll work on it as time permits and come up with some scripts to
provide what I am after (need to learn more on the workings of GIT
first - everyday I learn a new feature :)
Thanks for your idea...
...deon
^ permalink raw reply
* Re: [PATCH] git-submodule should obey --quiet for subcommands
From: Jonathan del Strother @ 2009-09-24 9:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Git Mailing List
In-Reply-To: <57518fd10909240034p668f858bh17fc20715b4838c3@mail.gmail.com>
On Thu, Sep 24, 2009 at 8:34 AM, Jonathan del Strother
<maillist@steelskies.com> wrote:
> On Thu, Sep 24, 2009 at 6:31 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting Jonathan del Strother <maillist@steelskies.com>
>>
>>> No takers? Perhaps I should explain my interest in this patch : we
>>> use Capistrano to deploy our Rails app which contains a bunch of
>>> submodules. It's done over ssh, so the 'git submodule update' step
>>> during deployment spews something along the lines of :
>>>
>>> Receiving objects: 0% (0/401), 1.55 MiB | 424 KiB/s
>>> Receiving objects: 1% (4/401), 2.15 MiB | 612 KiB/s
>>> Receiving objects: 2% (8/401), 2.90 MiB | 510 KiB/s
>>> ....
>>> ..
>>
>> Does 'git clone' itself do that to you, too, or do you see these output on separate lines only when running 'git submodule clone'? I never used 'git submodule clone' but with 'git clone' these lines seem to overwrite one after another and they never bothered me. Could your terminal emulator be broken?
>>
>
> No, git clone has the same problem when run under Capistrano, but it
> obeys --quiet.
>
> That said, I always assumed that, say, 'ssh -t myhost git clone foo'
> would have the same problem (ie printing each progress update on a new
> line), but I see it works correctly. Looks like Capistrano is eating
> the \r somewhere. I still think my patch is valid, but I'll
> investigate into Capistrano some more & see if I can fix it there.
>
> Jonathan
>
... thinking about it, it's obvious why Capistrano doesn't handle the
\r properly - it's running commands in parallel on multiple machines,
and echoing any output from the commands (prefixed with the machine
name) back to the user in realtime. So it would be kinda tricky for
\r to work as expected there.
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 8:57 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <430881.64091.qm@web27803.mail.ukl.yahoo.com>
On Thu, September 24, 2009 10:24, Mark Struberg wrote:
> Hi again and txs 4 your comments!
ok. thanks. much enlightening :-)
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 8:57 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <430881.64091.qm@web27803.mail.ukl.yahoo.com>
On Thu, September 24, 2009 10:24, Mark Struberg wrote:
> Hi again and txs 4 your comments!
ok. thanks. much enlightening :-)
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Mark Struberg @ 2009-09-24 8:24 UTC (permalink / raw)
To: Ferry Huberts; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <34819.77.61.241.211.1253779041.squirrel@hupie.xs4all.nl>
Hi again and txs 4 your comments!
There are a few problems with dirty files:
a) one cannot automated make sure that all builds well and the build is reproducable if there are dirty files lying around. A build script cannot judge which changes doesn't affect the build in a bad way and thus may be ignored.
b) therefore the maven-release-plugin will refuse to build a release if you have something dirty or not up2date.
c) if people get used to have dirty files, they will simply refuse to merge them because they don't like to apply their local settings every time
d) there are a lot of people working with Idea, NetBeans, vi, emacs, etc. All those people would not be forced by the settings in the eclipse config files.
e) having all the rules in the underlying build system will allow us to easily enable continuous integration tools like e.g. Hudson.
ad the JVM settings: I have up to 4 different JVMs installed on my boxes: 1.4.2, 1.5.x, 1.6.x stable and 1.6.x previews
So I have to tell eclipse what exact JVM to use.
Please note that the jdk1.5++ rule is already forced in the pom.xml maven-compiler-plugin settings.
ad different plugin versions config: having only the settings for a new plugin doesn't do anything (beside crashing/breaking eclipse) if you don't have the right versions of the plugins itself installed actually ;) This is imho only enforcable in a company and not in an OSS project.
LieGrue,
strub
--- On Thu, 9/24/09, Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> From: Ferry Huberts <ferry.huberts@pelagic.nl>
> Subject: Re: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Ferry Huberts" <ferry.huberts@pelagic.nl>, git@vger.kernel.org, spearce@spearce.org
> Date: Thursday, September 24, 2009, 9:57 AM
>
> > I work on a lot of projects and having eclipse (or any
> other IDEs) project files in the SCM is
> > almost ever causing a problem. In praxis those files
> are always dirty. There are so many settings
> > which may be different from user to user
>
> true. however, those problems can easily be avoided by the
> policy of not ever checking in those eclipse files unless
> coordinated within the project.
>
> we have many big java projects here internally and _do_
> have
> the eclipse settings in git. it makes life so much easier
> for
> everyone to start work and we have many more settings in
> there that we actually want enforced.
>
> for example: we enforce a coding standard through eclipse
> by automatically formatting the source code and organising
> imports on file save. also, we want everybody to use the
> same
> settings when cleaning up the code. we want them to use
> the
> same findbugs settings, the same settings for xxx/yyy/....
>
> > * different JVM settings
>
> if specified correctly this is actually an advantage: you
> can
> standardise your projects on a (minimum) JVM platform, like
> 1.5
>
> > * using different version of various plugins
>
> we see that as an advantage so that we can standardise the
> development setup, or at least define some sort of minimum
> setup
>
>
> > You can easily create the project files for a few IDEs
> with maven e.g.:
> > $> mvn eclipse:eclipse for
> creating the eclipse project files
> > $> mvn idea:idea
> for creating the idea project files
>
> I know, quite handy :-)
>
> Think I have more questions now than before by discussing
> it :-)
>
>
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 7:57 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <314006.37617.qm@web27808.mail.ukl.yahoo.com>
> I work on a lot of projects and having eclipse (or any other IDEs) project files in the SCM is
> almost ever causing a problem. In praxis those files are always dirty. There are so many settings
> which may be different from user to user
true. however, those problems can easily be avoided by the
policy of not ever checking in those eclipse files unless
coordinated within the project.
we have many big java projects here internally and _do_ have
the eclipse settings in git. it makes life so much easier for
everyone to start work and we have many more settings in
there that we actually want enforced.
for example: we enforce a coding standard through eclipse
by automatically formatting the source code and organising
imports on file save. also, we want everybody to use the same
settings when cleaning up the code. we want them to use the
same findbugs settings, the same settings for xxx/yyy/....
> * different JVM settings
if specified correctly this is actually an advantage: you can
standardise your projects on a (minimum) JVM platform, like 1.5
> * using different version of various plugins
we see that as an advantage so that we can standardise the
development setup, or at least define some sort of minimum
setup
> You can easily create the project files for a few IDEs with maven e.g.:
> $> mvn eclipse:eclipse for creating the eclipse project files
> $> mvn idea:idea for creating the idea project files
I know, quite handy :-)
Think I have more questions now than before by discussing it :-)
^ permalink raw reply
* Re: [PATCH] git-submodule should obey --quiet for subcommands
From: Jonathan del Strother @ 2009-09-24 7:34 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Git Mailing List
In-Reply-To: <20090924143130.6117@nanako3.lavabit.com>
On Thu, Sep 24, 2009 at 6:31 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Jonathan del Strother <maillist@steelskies.com>
>
>> No takers? Perhaps I should explain my interest in this patch : we
>> use Capistrano to deploy our Rails app which contains a bunch of
>> submodules. It's done over ssh, so the 'git submodule update' step
>> during deployment spews something along the lines of :
>>
>> Receiving objects: 0% (0/401), 1.55 MiB | 424 KiB/s
>> Receiving objects: 1% (4/401), 2.15 MiB | 612 KiB/s
>> Receiving objects: 2% (8/401), 2.90 MiB | 510 KiB/s
>> ....
>> ..
>
> Does 'git clone' itself do that to you, too, or do you see these output on separate lines only when running 'git submodule clone'? I never used 'git submodule clone' but with 'git clone' these lines seem to overwrite one after another and they never bothered me. Could your terminal emulator be broken?
>
No, git clone has the same problem when run under Capistrano, but it
obeys --quiet.
That said, I always assumed that, say, 'ssh -t myhost git clone foo'
would have the same problem (ie printing each progress update on a new
line), but I see it works correctly. Looks like Capistrano is eating
the \r somewhere. I still think my patch is valid, but I'll
investigate into Capistrano some more & see if I can fix it there.
Jonathan
^ permalink raw reply
* Re: System wide gitattributes
From: Jeff King @ 2009-09-24 7:08 UTC (permalink / raw)
To: David Förster; +Cc: git
In-Reply-To: <4AB0D0EB.5080105@andrena.de>
On Wed, Sep 16, 2009 at 01:50:03PM +0200, David Förster wrote:
> from the documentation I understand that things like external diff
> tools can be set up in a gitattributes file per repository (or
> subfolder).
>
> Why is there no support for a ~/.gitattributes file? This would be
> very handy, for example to always get a textual diff of OpenDocument
> files.
I think it is simply that nobody found it particularly useful until now,
and so nobody implemented it. Gitattributes tend to be somewhat tied to
the project files themselves. However, I can certainly see the use of
something like "*.doc diff=word" in your ~/.gitattributes.
So I think it is a sound concept; it just needs somebody to volunteer to
write it.
-Peff
^ permalink raw reply
* Re: git stash list shows timestamp in stead of "stash number", when setting date = local for log in config
From: Jeff King @ 2009-09-24 7:01 UTC (permalink / raw)
To: Alf Kristian Støyle; +Cc: Shawn O. Pearce, git
In-Reply-To: <49578b170909150756k3c19912dv28615053a6bd0f7d@mail.gmail.com>
On Tue, Sep 15, 2009 at 04:56:41PM +0200, Alf Kristian Støyle wrote:
> Hi. Searched the lists, but haven't found anyone reporting this problem.
>
> When doing a "git stash list" I get this strange stash record:
> stash@{Tue Sep 15 16:28:12 2009}: WIP on master: 2262276 ...
>
> I have a global config setting on log:
>
> [log]
> date = local
>
> If setting the date config to default or removing the setting, the
> stash record looks correct:
> stash@{0}: WIP on master: 2262276 ...
>
> I might be missing something here, but I do find this a bit strange.
> Is this a bug or a feature, and is there a setting I can use (for
> stash) to always show the latter line? I kind of like having local
> timestamps in log.
It's both. :) The stash is just a reflog, which is basically a linear
list of events that changed the ref. So "git stash list" is really just
"git reflog show stash".
When we show reflogs, we usually just number them sequentially, as that
is the way that people generally refer to them. But if you specify a
date format, then we figure you want to see the date (especially
--date=relative), so we show that. But of course in your case, you have
set a config option that is about showing the date in general, so it
doesn't really imply the same "I want to see the date".
So I think it is a feature that is being turned on by a bug.
And I think the right solution is to differentiate between command-line
--date and config log.date. The other option would be for "git-stash" to
explicitly pass "--date=default" to turn off date-printing. But I think
this is a general problem with log.date and showing reflogs, not just
stash.
The patch below implements the former. The only downside I can think of
is if somebody is relying on "log.date" to set the output format for
reflogs, because they really like the date version better. In that case,
I think we should wait for them to complain (which I doubt will happen),
and then add a log.reflogDates config option to appease them.
Shawn, reflogs are your thing. Any comments?
diff --git a/log-tree.c b/log-tree.c
index 1c9eefe..1618f3c 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -390,7 +390,9 @@ void show_log(struct rev_info *opt)
*/
show_reflog_message(opt->reflog_info,
opt->commit_format == CMIT_FMT_ONELINE,
- opt->date_mode);
+ opt->date_mode_explicit ?
+ opt->date_mode :
+ DATE_NORMAL);
if (opt->commit_format == CMIT_FMT_ONELINE)
return;
}
diff --git a/revision.c b/revision.c
index 9eb7951..5988b6c 100644
--- a/revision.c
+++ b/revision.c
@@ -1159,8 +1159,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->simplify_history = 0;
} else if (!strcmp(arg, "--relative-date")) {
revs->date_mode = DATE_RELATIVE;
+ revs->date_mode_explicit = 1;
} else if (!strncmp(arg, "--date=", 7)) {
revs->date_mode = parse_date_format(arg + 7);
+ revs->date_mode_explicit = 1;
} else if (!strcmp(arg, "--log-size")) {
revs->show_log_size = 1;
}
diff --git a/revision.h b/revision.h
index 9d0dddb..b6421a6 100644
--- a/revision.h
+++ b/revision.h
@@ -81,7 +81,8 @@ struct rev_info {
show_merge:1,
abbrev_commit:1,
use_terminator:1,
- missing_newline:1;
+ missing_newline:1,
+ date_mode_explicit:1;
enum date_mode date_mode;
unsigned int abbrev;
^ permalink raw reply related
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Mark Struberg @ 2009-09-24 6:55 UTC (permalink / raw)
To: Ferry Huberts; +Cc: git, spearce
In-Reply-To: <20734.77.61.241.211.1253773799.squirrel@hupie.xs4all.nl>
Hi Ferry!
I work on a lot of projects and having eclipse (or any other IDEs) project files in the SCM is almost ever causing a problem. In praxis those files are always dirty. There are so many settings which may be different from user to user
* different versions of eclipse create different project settings
* different JVM settings
* changing profiler settings
* using different version of various plugins
etc, etc
And with maven in place we don't need to have them in our SCM anymore. Plus: it works for a lot of IDEs
You can easily create the project files for a few IDEs with maven e.g.:
$> mvn eclipse:eclipse for creating the eclipse project files
$> mvn idea:idea for creating the idea project files
Additionally, plugins are available for Eclipse [1], Intellij Idea (native, builtin) and NetBeans (native, builtin).
So most of the time it is enough to simply import the parent pom.xml and you get all things setup properly in your IDE.
Or is there anything missing?
LieGrue,
strub
[1] http://m2eclipse.sonatype.org
--- On Thu, 9/24/09, Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> From: Ferry Huberts <ferry.huberts@pelagic.nl>
> Subject: Re: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: git@vger.kernel.org, spearce@spearce.org
> Date: Thursday, September 24, 2009, 8:29 AM
> Mark Struberg wrote:
> > All information necessary to build jgit is already
> available in
> > the maven pom.xmls.
> >
>
> just out of curiosity, why would you remove the eclipse
> files?
> I for one - and I think many others - use Eclipse to work
> on the code...
>
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Ferry Huberts @ 2009-09-24 6:29 UTC (permalink / raw)
To: Mark Struberg; +Cc: git, spearce
In-Reply-To: <1253740570-10718-7-git-send-email-struberg@yahoo.de>
Mark Struberg wrote:
> All information necessary to build jgit is already available in
> the maven pom.xmls.
>
just out of curiosity, why would you remove the eclipse files?
I for one - and I think many others - use Eclipse to work on the code...
^ permalink raw reply
* Re: Per-remote tracking branch
From: Jeff King @ 2009-09-24 6:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4or48bux.fsf@bauges.imag.fr>
On Tue, Sep 15, 2009 at 05:29:58PM +0200, Matthieu Moy wrote:
> Is there a way, with Git, to specify a tracking branch on a per-remote
> basis?
I don't think so, and I'm not sure there is an easy way to extend the
current configuration scheme. Adding multiple config options like this:
[branch "master"]
remote = origin
merge = refs/heads/master
remote = alternate
merge = refs/heads/master
looks a bit hack-ish to me, as there is an implicit correlation between
the ordering of 'merge' entries and 'remote' entries.
And it feels a little backwards. When I say "git pull foo", I would find
it equally likely to discover the pulled branch under "remote.foo" as it
would to find it under "branch.master". Of course, in either case, you
have to combine the context (current branch _and_ selected remote)
to come up with the actual information. So I guess either is "equally
correct" in a sense.
Anyway, mostly just my idle speculation.
-Peff
^ permalink raw reply
* Re: [BUG?] git-cvsimport: path to cvspsfile
From: Jeff King @ 2009-09-24 6:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4ABB0ACF.5040508@viscovery.net>
On Thu, Sep 24, 2009 at 07:59:43AM +0200, Johannes Sixt wrote:
> Jeff King schrieb:
> > Bug. The script does a chdir() and then looks at the cvspsfile later. I
> > think "-A" would have the same problem. Here is a totally untested patch
> > to address the issue. Johannes, will this is_absolute_path actually work
> > on Windows? I think The Right Way would be to use
> > File::Spec::file_name_is_absolute, but I haven't checked whether that is
> > part of core perl and if so, which version it appeared in.
>
> We have File::Spec::file_name_is_absolute in the msysgit installation. I
> suggest you use it. It sounds like a very basic feature, and I'd be
> surprised if it were not part of core perl.
Looks like File::Spec at least goes back to perl 5.004, and we are
already using it. I'll assume file_name_is_absolute has been there a
while, then. Thanks.
-Peff
^ permalink raw reply
* Re: Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Marius Storm-Olsen @ 2009-09-24 6:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sebastian Schuberth, msysGit, git, gitster, j6t, lznuaa, raa.lkml,
snaury
In-Reply-To: <alpine.DEB.1.00.0909232236490.4985@pacific.mpi-cbg.de>
Johannes Schindelin said the following on 23.09.2009 22:37:
> Hi,
>
> On Wed, 23 Sep 2009, Sebastian Schuberth wrote:
>
>> On Sep 16, 10:20 am, Marius Storm-Olsen <mstormo@gmail.com> wrote:
>>
>>> These scripts generate projects for the MSVC IDE (.vcproj files) or
>>> QMake (.pro files), based on the output of a 'make -n MSVC=1 V=1' run.
>>>
>>> This enables us to simply do the necesarry changes in the Makefile, and you
>>> can update the other buildsystems by regenerating the files. Keeping the
>>> other buildsystems up-to-date with main development.
>> I know I'm a little late with my comments as this patch set has
>> already been merged to master. However, for future reference I'd like
>> to point out that something similar could be archived by using e.g.
>> CMake, and only maintaining the CMake project file. I'm not suggesting
>> to actually switch to CMake at this time, but I wanted to point out
>> that a guy called Pau Garcia i Quiles already seems to have created a
>> preliminary CMakeLists.txt file for Git [1], and also tried to build
>> Git for Windows using his CMake-generated MSVC project files.
>>
>> [1] "CMake-ifying git", http://www.elpauer.org/?p=324
>
> We actually discussed this, and I challenged Pau to provide a recipe (a la
> /src/openssl/release.sh) that builds, installs and commits CMake.
>
> There was no response after that challenge.
Also, the buildsystem scripts I added to contrib/buildsystem is made
in such a way that creating a CMake generator would be very little
overhead. And since it's very unlikely that any other buildsystem will
replace the default Makefile anytime soon, I think that is the way to
go, to generate files for all the other buildsystems based on the
output of the Makefile. Not optimal, sure, but follows main development.
Note that the contrib/buildsystem scripts could need a major overhaul
by a Perl guru, as they are currently tuned only for Windows
consumption (and Msys Perl being the only Perl distribution tested).
But they work as intended for the use-case in mind.
--
.marius
^ permalink raw reply
* Re: [BUG?] git-cvsimport: path to cvspsfile
From: Johannes Sixt @ 2009-09-24 5:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090923191428.GA30104@coredump.intra.peff.net>
Jeff King schrieb:
> Bug. The script does a chdir() and then looks at the cvspsfile later. I
> think "-A" would have the same problem. Here is a totally untested patch
> to address the issue. Johannes, will this is_absolute_path actually work
> on Windows? I think The Right Way would be to use
> File::Spec::file_name_is_absolute, but I haven't checked whether that is
> part of core perl and if so, which version it appeared in.
We have File::Spec::file_name_is_absolute in the msysgit installation. I
suggest you use it. It sounds like a very basic feature, and I'd be
surprised if it were not part of core perl.
-- Hannes
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Jakub Narebski @ 2009-09-24 5:56 UTC (permalink / raw)
To: Deon George; +Cc: git
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
Deon George <deon.george@gmail.com> writes:
> I'm not sure if this is the right place, but I thought I'd post my
> idea and maybe somebody will either redirect me to the right place, or
> give me that "that won't happen".
>
> Im fairly new to GIT (wish I had discovered it long ago), and I really
> like using it - great work guys/garls :)
>
> My idea is to enhance GIT to support (I'll call it) development
> "layers". The current design of GIT is that the working repository and
> working directory assume that all files belong together in the same
> project. I would like to see GIT go 3D and support layers, so that
> files (and/or file content) can belong to multiple repositories (or
> considered unique projects), even though the working tree presents all
> files as if they were one.
[cut very long description]
> Could this be included as part of GITs functionality (or is it
> possible already) ?
First, I assume there that you do not allow for the same file to
belong to different repositories.
Second, if all parts that you want to belong to other repository are
in separate subdirectories, and all files in those subdirectories
belong to this other repository, you can try either submodules
(git-submodule), or subtree (subtree merge, or third-party git-subtree
helper). Note also that this assume that you want to have 'master'
repository which indirectly or directly has al the files.
Third, if the above isn't what you want, then you can manually
intermingle working directories of different git repositories
(probably requiring decouplig of bare git repository (git-dir)
from working area (work-tree)). Git repository know what files
it tracks, so you would only need to take care to ignore files
that belong to other repositories.
If it is to manual for you, and to error prone, you are welcome
to come up with set of scripts implementing "layers" feature you
want. That is how initial version of submodule feature was done...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] pre-commit.sample: don't use [...] around a tr range
From: Jeff King @ 2009-09-24 5:55 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jim Meyering, Alex Riesen, git list
In-Reply-To: <n2z47RdNjxVbPeRfgJuY54nJrfzDfn43bzv8HoH6cEuAzQ6fB1MaBg@cipher.nrlssc.navy.mil>
On Mon, Sep 21, 2009 at 10:58:51AM -0500, Brandon Casey wrote:
> >> I had my doubts, but have just confirmed that Solaris 10's
> >> /usr/bin/tr is still doing it the SYSV way:
> >>
> >> $ echo foo | LC_ALL=C /usr/bin/tr a-z A-Z
> >> foo
> >>
> >> There, you have to use /usr/xpg4/bin/tr to get the expected behavior:
> >>
> >> $ echo foo | LC_ALL=C /usr/xpg4/bin/tr a-z A-Z
> >> FOO
> >>
> >> So you're right. Thanks!
>
> By the way, modern git inserts /usr/xpg4/bin into PATH before /usr/bin on
> Solaris. So /usr/xpg4/bin/tr should always be used on that platform.
Ah, I forgot about that patch. So it may not matter on Solaris. Are
there other platforms which want the brackets? Maybe HP-UX, but I no
longer have access to a box and I've used deep hypnosis to suppress any
memories of ever having used it.
Anyway, I think Jim's patch is the right fix if there are still
platforms that want the brackets.
-Peff
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Deon George @ 2009-09-24 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab0lh1an.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I think the primary scenario your itch comes from is (I am writing this
> down to make sure I understand where you are trying to go):
>
> - you would want to build your changes on top of somebody else's code;
Yes - more correctly, I want to enhance an application, where I am (or
different person - it doesnt matter) is responsible for that code.
Thus I want to source code manage my enhancement, and (for whatever
reason), the other components of the application dont want my part in
their "base".
> - while doing so it is often more convenient if you do not have to think
> about which pieces of changes should go to upstream, and which other
> pieces of changes should stay local;
Not strictly true, but yes - I am aware that my modules might be
completely autonomous to the base code (thus I source control manage
everything that my module requires), or I discover bugs in the base
code, that I believe upstream should have. There may also be a case,
where I want to modify some code in the base, but I know that it
shouldnt never be included in the base code (and thus I would need my
commit to be stored in my SCM, not the base's SCM) - eg: Modifying a
Makefile...
So while I would commit to a layer, I should make a conscious decision
of where the commit should go (I own the commit work, or I want to
send the commit upstream as a contribution enhancement/fix) - because
the default assumption may be wrong.
>
> - git allows you to do this with topic branch workflow, with selective
> adding with "add -p", stashing and branch switching.
I dont know about topic branches "git add -p"? (I havent got that
advanced yet, looks like I need to do some more research on the
features of GIT :)
> Am I following you Ok so far?
Yes, but one more important criteria - my working tree is made up of
files (or content) managed in more than once source control management
repository - I use an SCM to manage and track changes, and I use
multiple repository because any one owner of one repository may not
want the code from another as part of their "base". IE: It could be I
write a custom driver for a widget device, that Linus doesnt want that
code in the base kernel (for whatever reason) and I maintain that part
of the code, or (in my case), I want to maintain (and encourage others
to contribute) to a module (or set of modules) for an existing web
application framework.
Additionally, each layer should be able to switch between its own
branches (ie: My driver 1.0 works well with kernel "N", now Linus
publishes "N+1", I want to switch that (base) layer to "N+1" and
test/fix my module to work with that release - and then commit/tag it
as such - ie: my driver (now 1.1) works with "N+1"). Further a bug is
now found in my 1.0 driver, so I want to switch back the kernel layer
to "N", and my driver layer to 1.0, make the fix, and release
1.0.1)... Kinda get the idea Im working towards...?
Additionally, it should not necessarily be "one base" and "my layer",
it may be multiple layers (and hence multiple repositories), but all
layers make up an application with multiple features, each
individually source control managed. Each layer would have a
dependency to another (otherwise they could be developed in their own
repository entirely - and the dependency may be needed to be know for
merge conflict resolution (where do the conflicts need to be
commited), when pulling from the upstream owners of that layer)
Thus, when I package up my module - it shouldnt include the base
(since the base may already be installed), and the base developers
want to keep their application more like a framework - so they are
responsible for the core workings of the code, and the module
developers are responsible for their components.
To achieve what I want today, I think I would need to have:
master
master-mycontribs (branched from master, and merged from master)
mymodule (branched from master-mycontribs and merge from there - this
is pushed to my SCM repository)
mymodule-working (where I test and commit - and merge back to my module)
(this comes stuck, when I want to switch master to a previous version...)
And thus, the diff between "master" and "master-mycontribs", are my
contributions to go upstream. The diff between "master" and "mymodule"
is what I would package to make my module as an enhancement to anyone
already using "master" (at release "N").
If upstream accepts my enhancements, then "master" =
"master-mycontribs" (and master is now release "N+1"), and the next
release of my module (1.2) would still be the diff between
"master-mycontribs" and "mymodule" (but would be excluding my code
that I added to master-mycontribs (since master now equals that),
because the end user who is already running N+1 has those
enhancements.
I'll research git "topics" and see if that does what I am dreaming of :)
...deon
^ 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