* 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
* Re: [PATCH] git-submodule should obey --quiet for subcommands
From: Nanako Shiraishi @ 2009-09-24 5:31 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <57518fd10909231433i773aff78kae6b763d0a533279@mail.gmail.com>
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?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/3] print_wrapped_text(): allow hard newlines
From: Johannes Schindelin @ 2009-09-24 0:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Johannes Gilger, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0909231659010.3303@localhost.localdomain>
Hi,
On Wed, 23 Sep 2009, Linus Torvalds wrote:
> On Wed, 23 Sep 2009, Johannes Schindelin wrote:
> >
> > print_wrapped_text() will insert its own newlines. Up until now, if the
> > text passed to it contained newlines, they would not be handled properly
> > (the wrapping got confused after that).
> >
> > The strategy is to replace a single new-line with a space, but keep double
> > new-lines so that already-wrapped text with empty lines between paragraphs
> > will be handled properly.
>
> May I suggest doing this _only_ if the newline is followed by an
> alphanumeric characer?
>
> If the thing is indented ("newline + space") or quoted ("newline + ">" or
> whatever) then reflowing it is likely wrong and will result in an unholy
> mess.
It seems Junio is dead-set on ignoring my patches, so I will probably just
keep the patch as-is in my tree for the time being. The other Johannes'
patch is too limited for me to use, so I _will_ keep my patch, but I have
way too little time to fight an uphill battle to get my patch in. And
since it stays a private patch (just like my strbuf_vaddf() patch) I will
have to refrain from putting more work and time into it than I already
have.
Sorry,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] print_wrapped_text(): allow hard newlines
From: Linus Torvalds @ 2009-09-24 0:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Johannes Gilger, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0909232232560.4985@pacific.mpi-cbg.de>
On Wed, 23 Sep 2009, Johannes Schindelin wrote:
>
> print_wrapped_text() will insert its own newlines. Up until now, if the
> text passed to it contained newlines, they would not be handled properly
> (the wrapping got confused after that).
>
> The strategy is to replace a single new-line with a space, but keep double
> new-lines so that already-wrapped text with empty lines between paragraphs
> will be handled properly.
May I suggest doing this _only_ if the newline is followed by an
alphanumeric characer?
If the thing is indented ("newline + space") or quoted ("newline + ">" or
whatever) then reflowing it is likely wrong and will result in an unholy
mess.
Linus
^ permalink raw reply
* Re: 'git am' doubt
From: David Aguilar @ 2009-09-23 23:54 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List
In-Reply-To: <a4c8a6d00909231520s53be6654ibf74d4430e7e82f@mail.gmail.com>
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'.
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.
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.
Here's the git wiki page about msmtp, gmail, and
git-send-email:
http://git-scm.org/gitwiki/GitTips#Usingmsmtptosendyourpatches
--
David
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Johan Herland @ 2009-09-23 23:19 UTC (permalink / raw)
To: Ciprian Dorin, Craciun; +Cc: Deon George, git
In-Reply-To: <8e04b5820909231117k401e7500h822a61cb41db5c0@mail.gmail.com>
On Wednesday 23 September 2009, Ciprian Dorin, Craciun wrote:
> Practically you want something like unionfs [1] but for git. Right?
>
> But probably you could settle for something like Hg Queues [2]. Is
> there similar for Git?
TopGit, StGit, Guilt?
Not sure they (or Hg Queues) solve Deon's problem though...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 3/3] Add "%w" to pretty formats, which rewraps the commit message
From: Junio C Hamano @ 2009-09-23 23:19 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <20090923210055.GA25197@dualtron.vpn.rwth-aachen.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> ... One thing that bothers
> me about the %w flag is that is includes subject and body, when we
> already have atoms for both of these flags. So having a subject(x,y) and
> body(x,y) tag (where x is indent and y is textwidth to be rewrapped)
> would be nicer and more in the spirit of the existing format options
> imho.
I do not particularly like this %w() either, and would prefer to see an
equivalent solution using combination of %S(i,j,w) and %B(i,j,w). Your
%B(n) can be extended to do the same as Johannes's wrapping variant when
given three parameters and you can trivially do the same for %s to produce
%S(n) and %S(i,j,w).
One issue %w() sidesteps is handing of single liner commit log messages
(this is not a new issue your %B(n) introduces). "%s%n%b" will give us
the original message only when the log has some contents in addition to
the single-line summary. Otherwise we will get an extra blank line.
Perhaps we could extend the pretty-printer so that it understands %+x
notation, which expands to %n%x when %x expands to a non-empty result, and
otherwise it expands to empty, as a generic extension applicable to any
format specifier 'x'. If we have such a notation, "%s%+b", would be a
reasonable way to say "give us the original commit log message here", and
we won't need %w(i,j,w) -- we can instead say %S(i,j,w)%+B(i,j,w), or
%s%+B(i,j,w) depending on what you want.
^ permalink raw reply
* 'git am' doubt
From: Thiago Farina @ 2009-09-23 22:20 UTC (permalink / raw)
To: Git Mailing List
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.
Sorry if this is already answered before in this mailing list, but I
couldn't find it.
Thanks anyway for the time and help.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #05; Wed, 23)
From: Nick Edelen @ 2009-09-23 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbuui1ys.fsf@alter.siamese.dyndns.org>
> * ne/rev-cache (2009-09-07) 7 commits
> - support for commit grafts, slight change to general mechanism
> - support for path name caching in rev-cache
> - full integration of rev-cache into git, completed test suite
> - administrative functions for rev-cache, start of integration into git
> - support for non-commit object caching in rev-cache
> - basic revision cache system, no integration or features
> - man page and technical discussion for rev-cache
>
> Tonight's 'pu' ships with this and this series seems to break a few
> tests. I didn't debug.
Ack, I see your hesitation now... Sorry, so many tests are borked on
cygwin I didn't catch it, and I hadn't gotten around to booting into
*nix. Will fix these soon.
- Nick
^ permalink raw reply
* Re: [PATCH] git-submodule should obey --quiet for subcommands
From: Jonathan del Strother @ 2009-09-23 21:33 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <57518fd10909210946p425d275fy76362a4b2ccc0e05@mail.gmail.com>
On Mon, Sep 21, 2009 at 5:46 PM, Jonathan del Strother
<maillist@steelskies.com> wrote:
> Make sure that --quiet is passed through to git-clone & git-fetch.
>
> Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
> ---
> clone & fetch are extremely noisy - perhaps something like the following?
>
> git-submodule.sh | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index bfbd36b..1e1066e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -106,9 +106,9 @@ module_clone()
>
> if test -n "$reference"
> then
> - git-clone "$reference" -n "$url" "$path"
> + git-clone ${GIT_QUIET:+-q} "$reference" -n "$url" "$path"
> else
> - git-clone -n "$url" "$path"
> + git-clone ${GIT_QUIET:+-q} -n "$url" "$path"
> fi ||
> die "Clone of '$url' into submodule path '$path' failed"
> }
> @@ -450,7 +450,7 @@ cmd_update()
> if test -z "$nofetch"
> then
> (unset GIT_DIR; cd "$path" &&
> - git-fetch) ||
> + git-fetch ${GIT_QUIET:+-q}) ||
> die "Unable to fetch in submodule path '$path'"
> fi
>
> --
> 1.6.5.rc1.44.ga1675.dirty
>
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
....
..
.
all the way up to 100% to the console. Currently we're just directing
stdout to /dev/null, since --quiet failed to accomplish much, but it
seems like something along the lines of this patch would be useful.
Unless someone has a better implementation...?
^ permalink raw reply
* [JGIT PATCH 8/9] renamed the PathSuffixFilter test to JUnit conventions, so it gets executed via maven test.
From: Mark Struberg @ 2009-09-23 21:16 UTC (permalink / raw)
To: git, spearce; +Cc: Mark Struberg
In-Reply-To: <1253740570-10718-7-git-send-email-struberg@yahoo.de>
Signed-off-by: Mark Struberg <struberg@yahoo.de>
---
...lterTestCase.java => PathSuffixFilterTest.java} | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
rename org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/{PathSuffixFilterTestCase.java => PathSuffixFilterTest.java} (98%)
diff --git a/org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTestCase.java b/org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTest.java
similarity index 98%
rename from org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTestCase.java
rename to org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTest.java
index 56d9765..0043a7d 100644
--- a/org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTestCase.java
+++ b/org.spearce.jgit/src/test/java/org/spearce/jgit/treewalk/filter/PathSuffixFilterTest.java
@@ -50,7 +50,7 @@
import org.spearce.jgit.lib.RepositoryTestCase;
import org.spearce.jgit.treewalk.TreeWalk;
-public class PathSuffixFilterTestCase extends RepositoryTestCase {
+public class PathSuffixFilterTest extends RepositoryTestCase {
public void testNonRecursiveFiltering() throws IOException {
final ObjectWriter ow = new ObjectWriter(db);
--
1.6.2.5
^ 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