* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Jeff King @ 2008-11-14 16:21 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <491D7C38.7070906@hashpling.org>
On Fri, Nov 14, 2008 at 01:25:12PM +0000, Charles Bailey wrote:
> Previously, if you aborted a merge, you were left with the
> base/local/remote temporaries for the merge that you aborted.
>
> To be honest, I found this a little irritating. The base, local and
> remote temporaries are inputs so are accessible from slots 1,2 and 3 of
> the index, and any intermediate output will be in the target file. You
> can git clean, but if you have other temporaries you need to keep, you
> end up having to manually clean them up in any case.
>
> With --keep-going, the problem is compounded. If you make several passes
> through a list of complex merges you end up with fistfuls of these
> temporary trios in your working tree. It goes from slightly annoying to
> very irritating.
I agree; I have never found the temporary files left by mergetool from a
failed merge to be useful, and get a little annoyed that I have to "git
clean" them away afterwards. Even without --keep-going, I would often
look at and abort a merge several times before resolving it and end up
with several copies.
But I definitely think that is an issue for a separate patch, and one
that needs input from Ted and from other mergetool users.
-Peff
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-14 16:11 UTC (permalink / raw)
To: Chris Frey
Cc: Johannes Schindelin, Alex Riesen, Junio C Hamano, Miles Bader,
git
In-Reply-To: <20081114050822.GA23963@foursquare.net>
On Fri, 14 Nov 2008, Chris Frey wrote:
>
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
It would be better to just extend the SHA-1 arithmetic. We could do it, no
problem. It's just a SMOP.
For example, right now the arithmetic is entirely "flat", with no
precedence, no nesting, nothing but a single level of set operations. We
could extend it to be hierarchical.
So we _could_ do something like
git log {a..b} {c..d ^e}
and just declare that { $args } is a self-contained "subset", and
effectively becomes the same thing as "$(git rev-list $args)" but with
magic no-walking semantics (ie all walking is done only _within_ the { },
not between different groups.
You literally _can_ do it right now that way:
git log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list HEAD~1..)
actually works, but that will hit argument size limits on many platforms
really quickly.
So we could make a '{ }' in the argument space basically do a SHA1
expansion of the range inside, and imply --no-walk. It's _not_ entirely
trivial, because we'd need to handle the fact that object flags are
sticky, and clear them in between invocations of multiple ranges, but it's
not _fundmanetally_ difficult. It's just that somebody would need to do
it.
Linus
^ permalink raw reply
* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Sverre Rabbelier @ 2008-11-14 15:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811141533.15427.jnareb@gmail.com>
On Fri, Nov 14, 2008 at 15:33, Jakub Narebski <jnareb@gmail.com> wrote:
> Note that on GMane NNTP (news) interface I can see only two last
> patches. Could anyone not CC-ed confirm or deny if this is VGER
> anti-SPAM filter at work, or some GMane archive hiccup?
I got all of the patches just fine, and I'm not CC-ed ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Error in git-cherry-pick manpage?
From: Jens Seidel @ 2008-11-14 15:14 UTC (permalink / raw)
To: git
Hi,
I try to use git cherry-pick to combine multiple commits but I'm confused
about the second sentence of the description:
"Given one existing commit, apply the change the patch introduces, and
record a new commit that records it. This requires your working tree to be
clean (no modifications from the HEAD commit)."
I intent to use it as follows:
git cherry-pick -x --no-commit 2e855ae
git cherry-pick -x --no-commit 0c1151
...
After the first invocation my working tree will not be clean but contain
changes in the index.
Does this mean that's a wrong usage of cherry-pick?
Jens
^ permalink raw reply
* Re: git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 14:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <491D82F3.2090807@op5.se>
Hi,
On Fri, 14 Nov 2008, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 13 Nov 2008, Andreas Ericsson wrote:
> >
> > > Evgeniy Ivanov wrote:
> > >
> > > > But this is the same things Shawn has suggested to my mentor and
> > > > me at the beginning of SoC...
> > > Oh? I didn't know libgit2 started as a SoC project.
> >
> > It did not. It started as a request from GitHub, and following
> > discussion, at the GitTogether '08.
> >
> > There _was_ a SoC project last year, libgit-thin, but the problem as
> > far as GitHub is concerned was that it was a tear-down approach: it
> > took git.git and tried to make a small library of it, and by this
> > approach was bound to the GPL.
> >
>
> Oh. I was under the impression that libgit2 would also be able to reuse
> code from git.git, since there was that huge license thread a couple of
> months ago. Did I misinterpret that thread, and everything in libgit2
> has to be implemented from scratch?
You misinterpreted.
A lot can be reused, because the original authors agree to let the code be
relicensed (including Shawn and me, for example). But a few others have
raised concerns with everything non-GPL (and that includes GPL+gcc
exception), and even stated explicitely that they are not okay with their
code being reused (or adapted) to something as permissive as BSD, for
example.
However, let's not revive the license wars. The topic is kinda boring.
Ciao,
Dscho
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Farrukh Najmi @ 2008-11-14 14:45 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <f73f7ab80811140638m4045cf83p311c593aff066002@mail.gmail.com>
Kyle Moffett wrote:
> On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
>
>> The problem I am trying to solve is this. In my service I need to store
>> metadata in a relational db and content in git such that both either commit
>> or not in a single transaction. If one commits and the other does not that
>> is a serious integrity issue. Seems to me, two phase commit would be the
>> right solution for that in the long run. This what JDBC + JMS topologies do.
>>
>
> That's really easy! First tweak jgit so that *instead* of using
> .git/refs, it uses your database to store references and exports them
> on a routine basis to .git/refs for debugging purposes.
Wow! This does sound simple in theory. Of course I have much to learn
about jgit code base first.
Any pointers on what parts of the code are involved that I should start
looking at? I would hate to
keep a fork of gjit around. Would this work be of interest to the
project if it could be done in a way
that a few properties control whether to use database or not?
Thanks Kyle!
> Then, for
> each database update:
>
> (1) Start transaction
> (2) Commit the change to GIT (adds ref update to the transaction)
> (3) Make other metadata updates
> (4) Commit transaction
>
> Then set up periodic garbage collection and you're done! If the
> transaction is aborted, there will simply be a bunch of random loose
> objects in the git repository, which will be cleaned up the next time
> you garbage collect. The ref update will be atomic and conditional
> with the rest of the transaction, and in git the *only* part that
> really matters for atomicity is the ref.
>
> Cheers,
> Kyle Moffett
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Kyle Moffett @ 2008-11-14 14:38 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Robin Rosenberg, git
In-Reply-To: <491C8DBE.9080105@wellfleetsoftware.com>
On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
> The problem I am trying to solve is this. In my service I need to store
> metadata in a relational db and content in git such that both either commit
> or not in a single transaction. If one commits and the other does not that
> is a serious integrity issue. Seems to me, two phase commit would be the
> right solution for that in the long run. This what JDBC + JMS topologies do.
That's really easy! First tweak jgit so that *instead* of using
.git/refs, it uses your database to store references and exports them
on a routine basis to .git/refs for debugging purposes. Then, for
each database update:
(1) Start transaction
(2) Commit the change to GIT (adds ref update to the transaction)
(3) Make other metadata updates
(4) Commit transaction
Then set up periodic garbage collection and you're done! If the
transaction is aborted, there will simply be a bunch of random loose
objects in the git repository, which will be cleaned up the next time
you garbage collect. The ref update will be atomic and conditional
with the rest of the transaction, and in git the *only* part that
really matters for atomicity is the ref.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Jakub Narebski @ 2008-11-14 14:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-1-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
> This is a patchset I presented about a year ago or so, but after a lively
> discussion it dropped into silence. I'm now presenting it again, with minor
> cleanups and adjustements.
That is very nice of you to resend this series. If you could provide
link to earlier discussion of this series...
> Giuseppe Bilotta (11):
> gitweb: introduce remote_heads feature
> gitweb: git_get_heads_list accepts an optional list of refs.
> gitweb: separate heads and remotes list in summary view
> gitweb: optional custom name for refs in git_heads_body
> gitweb: git_split_heads_body function.
> gitweb: use CSS to style split head lists.
> gitweb: add 'remotes' action
> gitweb: display HEAD in heads list when detached
> gitweb: git_is_head_detached() function
> gitweb: add HEAD to list of shortlog refs if detached
> gitweb: CSS style and refs mark for detached HEAD
I'll try to review individual patches, but I haven't examined them
yet, so perhaps there is a reason why there are so many patches in
this series?
Note that on GMane NNTP (news) interface I can see only two last
patches. Could anyone not CC-ed confirm or deny if this is VGER
anti-SPAM filter at work, or some GMane archive hiccup?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: hosting git on a nfs
From: Kyle Moffett @ 2008-11-14 14:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brandon Casey, James Pickens, Bruce Fields, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131707090.3468@nehalem.linux-foundation.org>
On Thu, Nov 13, 2008 at 8:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> - It would be really cool to find some way to automatically notice when
> the tree is hot-cached and we might as well just be linear. I don't
> know exactly what it might be, but one of the nice things is that the
> preloading is _entirely_ optimistic, and we could just stop it in the
> middle if we notice that there's no upside.
Perhaps, rather... notice when the tree is *cold*-cached. At that
point you're already in a pseudo-slowpath and starting several threads
won't be noticeable at all compared to the time savings. You could
probably very easily do that by keeping track of the time as you start
with the normal single-threaded scan of directory entries. If the
entries are all equally slow/fast, there most likely won't be any
benefit at all to spawning extra threads. You might use some cutoff
on number of entries to test before you assume everything is hot and
stop worrying about the time. If there's a lot of variability in the
first few thousand then it means some caches are cold and spawning
extra threads will probably help.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: getting started with git
From: Lars Hoss @ 2008-11-14 14:29 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Ivan Senji, git
In-Reply-To: <1a6be5fa0811140456j10fd8703w74e485571e3c70af@mail.gmail.com>
>
> Well, if it were me, I think I would commit that eclipse config file
> under a different name... Say, ".classpath.defaults" instead of
> ".classpath". Then your README file could tell your users to start by
> copying the .classpath.defaults to .classpath, and update its contents
> as necessary. Put .classpath in your .gitignore file, so it won't be
> committed to the repository.
Template files (x.default) is a good idea. But regarding your example
with .classpath: it's safe to add it to git since it's developer
independent and project oriented. Therefore it's useful for every
developer in the project who uses eclipse :-)
Yours,
Lars
^ permalink raw reply
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-14 13:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811141429040.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 13 Nov 2008, Andreas Ericsson wrote:
>
>> Evgeniy Ivanov wrote:
>>
>>> But this is the same things Shawn has suggested to my mentor and me at
>>> the beginning of SoC...
>> Oh? I didn't know libgit2 started as a SoC project.
>
> It did not. It started as a request from GitHub, and following
> discussion, at the GitTogether '08.
>
> There _was_ a SoC project last year, libgit-thin, but the problem as far
> as GitHub is concerned was that it was a tear-down approach: it took
> git.git and tried to make a small library of it, and by this approach was
> bound to the GPL.
>
Oh. I was under the impression that libgit2 would also be able to reuse
code from git.git, since there was that huge license thread a couple of
months ago. Did I misinterpret that thread, and everything in libgit2
has to be implemented from scratch?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-14 14:00 UTC (permalink / raw)
To: Chris Frey; +Cc: Alex Riesen, Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <20081114050822.GA23963@foursquare.net>
Hi,
On Fri, 14 Nov 2008, Chris Frey wrote:
> On Mon, Nov 10, 2008 at 10:31:32PM +0100, Johannes Schindelin wrote:
> > On Mon, 10 Nov 2008, Alex Riesen wrote:
> > > for cs in HEAD^..HEAD HEAD~10; do
> > > case "$cs"; in
> > > *..*)
> > > git format-patch --stdout "$cs"
> > > ;;
> > > *)
> > > git show --pretty=email "$cs"
> > > ;;
> > > esac
> > > done
> > >
> > > At least, this is what I have in mind and how I expect it to work.
> >
> > That is not the way git-show is implemented (it uses setup_revisions() to
> > check for validity and to parse the arguments), and I cannot think of any
> > way to make this work without ugly workarounds.
>
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
>
> Hypothetical, pie-in-the-sky idea:
>
> git range HEAD^..HEAD HEAD~10 -- show --pretty=email
> git range HEAD^..HEAD HEAD~10 -- log
> git range HEAD^..HEAD HEAD~10 -- cherry-pick
This is not really well defined is it? What about
git range HEAD -- log makefile
Where should it insert the "HEAD" argument?
Besides, I do not like how this muddies the semantics: if git range as you
proposed it became part of Git, people _would_ get confused why "git range
HEAD^..HEAD HEAD~10" interprets the range _differently_ from "git log
HEAD^..HEAD HEAD~10".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-11-14 13:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <20081114064756.GB11907@coredump.intra.peff.net>
Jeff King wrote:
>> Documentation/config.txt | 4 +++
>> Documentation/git-mergetool.txt | 12 +++++++++-
>> git-mergetool.sh | 46
++++++++++++++++++++++++++++++--------
>> 3 files changed, 51 insertions(+), 11 deletions(-)
>
> This patch in particular changes some of the innards of mergetool, and
> while the changes look good to me via reading, I would feel even more
> comfortable if there were some tests (it looks like your previous t7610
> gives at least a basic sanity check, but it might be nice to test to
> make sure we detect merge failures, too).
I had a little difficulty thinking of some decently robust tests. git
mergetool is, by its nature, more interactive than many git commands.
With --no-prompt it should be easier to make some tests that don't just
hang when it goes wrong. I'll have a further think on this.
>> [...]
>> - exit 1
>> + cleanup_temp_files
>> + return 1
>
> One of these is not like the others. Is there a reason to add a
> cleanup_temp_files here (and if so, should it be noted in the commit
> message, and/or be in a separate commit?).
Ah yes, it's definitely worthy of at least a comment. This is something
that I changed right at the end of testing and I should really have made
it into a separate commit.
Previously, if you aborted a merge, you were left with the
base/local/remote temporaries for the merge that you aborted.
To be honest, I found this a little irritating. The base, local and
remote temporaries are inputs so are accessible from slots 1,2 and 3 of
the index, and any intermediate output will be in the target file. You
can git clean, but if you have other temporaries you need to keep, you
end up having to manually clean them up in any case.
With --keep-going, the problem is compounded. If you make several passes
through a list of complex merges you end up with fistfuls of these
temporary trios in your working tree. It goes from slightly annoying to
very irritating.
Charles.
^ permalink raw reply
* Re: git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 13:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <491BD532.9090200@op5.se>
Hi,
On Thu, 13 Nov 2008, Andreas Ericsson wrote:
> Evgeniy Ivanov wrote:
>
> > But this is the same things Shawn has suggested to my mentor and me at
> > the beginning of SoC...
>
> Oh? I didn't know libgit2 started as a SoC project.
It did not. It started as a request from GitHub, and following
discussion, at the GitTogether '08.
There _was_ a SoC project last year, libgit-thin, but the problem as far
as GitHub is concerned was that it was a tear-down approach: it took
git.git and tried to make a small library of it, and by this approach was
bound to the GPL.
Ciao,
Dscho
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 13:26 UTC (permalink / raw)
To: Miguel de Icaza
Cc: Jakub Narebski, Andreas Ericsson, Git Mailing List, Shawn Pearce,
monodevelop-list, Michael Hutchinson
In-Reply-To: <1226540535.4483.203.camel@erandi.site>
Hi,
On Wed, 12 Nov 2008, Miguel de Icaza wrote:
> > I assume that results of Mono's Google Summer of Code 2008 projects to
> > create managed git implementation in C# (git#)[1][2] were not very
> > successfull? Taking into account that JGit isn't yet full git
> > implementation, after much longer development...
>
> They were a complete disaster, one student was going to focus on the
> front-end, the other on the back-end.
I kinda followed the last few weeks via your svn repository (which was not
helped by the commits being a complete mix of the individual projects).
I was a bit disappointed that nobody asked things on the Git mailing list;
quite a number of very important lessons were learnt during the first
implementation of jgit, and you guys could have benefitted tremendously by
hearing them.
By the time I got aware of your effort, it was too late; for example, the
code already relied on the fact that every blob's contents were read into
memory at once (IIU the code correctly).
Note: personally, I do not like C# all that much, so I am not that
interested in the port myself. However, we get quite a number of
questions in that direction ("do you support .NET yet?"), so I am quite
interested to know what's available.
May I suggest respectfully, that the next time communication channels
between the Mono-mentor and at least one knowledgable Git guy are
established early in the project? IIRC there was a GSoC project to
reimplement Git in C# last year, too, which failed, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-14 13:02 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081112000445.GB17662@diku.dk>
I've investigated it a little.
It seems that this newet version of asciidoc (I'm running 8.2.2) has
the global asciidoc.conf file (placed in /etc/asciidoc/asciidoc.conf
on my computer) containing the previously cited section:
# -- Spaced and unspaced em dashes (entity reference —)
# But disallow unspaced in man pages because double-dash option
name prefixes
# are pervasive.
ifndef::doctype-manpage[]
(^|[^-\\])--($|[^-])=\1—\2
endif::doctype-manpage[]
ifdef::doctype-manpage[]
(^|\s*[^\S\\])--($|\s+)=\1—\2
endif::doctype-manpage[]
\\--(?!-)=--
Those replacements are run *before* any replacements defined in
user-provided files are taken into consideration. You can disable them
only by disabling all replacements, I think.
So the only thing we can do about automatic conversion "--" to "—" is putting
[replacements]
&8212;=--
in Documentation/asciidoc.conf file or similar. (8212 = x2014,
"\u2014" = "—"). This way the unwanted replacement is reverted.
However, this forbids literal "&8212;" in the source .txt files and
there is no way to enable it. This seems only little probable that
anyone would want to write "&8212;" until someone writes "writing
Documentation guide" where she would state that "&8212;" is
prohibited.
If this is good solution and we want to replace punctuation "--" with
unicode "—", I will do this.
However, this seems a bit messy -- fighting against asciidoc instead
of using it as it's designed to be used. IMHO, it's better to
explicitly escape non-punctuation "--" with "\" and write punctuation
"--" with spaces on both sides. Please note, writing literal "—" isn't
so simple -- there is no such key on the keyboard :)
Best regards,
Piotr
On Wed, Nov 12, 2008 at 01:04, Jonas Fonseca <fonseca@diku.dk> wrote:
> Piotr Findeisen <piotr.findeisen@gmail.com> wrote Mon, Nov 10, 2008:
>> > This would also fix the usage of "--" in the manpages, e.g.
>> >
>> > You've now initialized the working directory--you may notice ...
>> >
>> > in gittutorial(7). On my setup, with "--" replaced with "—", I get the
>> > following nroff code:
>>
>> On my machine, make gittutorial.7 produces manpage that displays "--"
>> in this place :)
>
> At least you don't loose anything compared to the current behavior. ;)
>
>> > You've now initialized the working directory\(emyou may notice
>>
>> Anyway, this may be a good idea to use unambiguous "—" (though people
>> writing docs may be used to using "--" as a punctuation). I can run
>> through the Documentation replacing "\w--\w" with m-dash, if you want.
>
> I would like to see such a patch.
>
> --
> Jonas Fonseca
>
^ permalink raw reply
* Re: hosting git on a nfs
From: Michael J Gruber @ 2008-11-14 13:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brandon Casey, James Pickens, Bruce Fields, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131707090.3468@nehalem.linux-foundation.org>
Linus Torvalds venit, vidit, dixit 14.11.2008 02:15:
>
> On Thu, 13 Nov 2008, Linus Torvalds wrote:
>> I'll clean it up a bit and make a less hacky version. And I'll try to make
>> it work for "git status" and friends too.
>
> Ok, this is a no-longer-totally-hacky thing, which also adds support for
> doing the same for "git status". I haven't actually done any timings, but
> the preload algorithm is all the same. The interface is just a much more
> natural one.
>
> NOTE NOTE NOTE! It may not be totally hacky, but it's still not
> "finished". There's a few more things to look at:
Doing nicely already. Over here, cold cache (i.e. sleep 70) "git status"
goes from 0.8s to around 0.4s. Nice. Hot cache goes from 0.18s to 0.23s.
This is really worthwhile if you hack for more than 60s between
diffs/stats ;)
This is already with the server doing some caching (first status was 8s
or so; hardly reproducible), which I can't control.
Michael
^ permalink raw reply
* Re: getting started with git
From: Tor Arvid Lund @ 2008-11-14 12:56 UTC (permalink / raw)
To: Ivan Senji; +Cc: git
In-Reply-To: <20497802.post@talk.nabble.com>
On Fri, Nov 14, 2008 at 11:16 AM, Ivan Senji <ivan.senji@gmail.com> wrote:
> On each location that i develop some project and configuration files are
> different. But i would like them to be in the repository as a starting point
> when checking out a project (example: opening a project on a dfferent OS in
> eclipse... eclipse will find an error in the path to jdk and ask me to fix
> that error by selecting a different jdk).
>
> How to achieve that these files are in the repository but that any further
> changes to them are not commited (or are commited localy but not pushed to a
> remote repository)?
Hi,
Well, if it were me, I think I would commit that eclipse config file
under a different name... Say, ".classpath.defaults" instead of
".classpath". Then your README file could tell your users to start by
copying the .classpath.defaults to .classpath, and update its contents
as necessary. Put .classpath in your .gitignore file, so it won't be
committed to the repository.
-Tor Arvid-
^ permalink raw reply
* [PATCH 3/3] Documentation: tutorial: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-14 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 1 +
Documentation/gittutorial-2.txt | 1 +
Documentation/gittutorial.txt | 14 ++++++++++++++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 61fc5d7..96bf353 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1693,6 +1693,7 @@ SEE ALSO
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index bab0f34..a057b50 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -425,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 384972c..2859a21 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -23,9 +23,22 @@ First, note that you can get documentation for a command such as
`git log --graph` with:
------------------------------------------------
+$ git help log
+------------------------------------------------
+
+or:
+
+------------------------------------------------
$ man git-log
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +666,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* [PATCH 2/3] Documentation: user-manual: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-14 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..48f7189 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -17,13 +17,27 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
-Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
+Comprehensive reference documentation is available through either the
+linkgit:git-help[1] command or the man pages. For a command such as
+"git clone <repo>", you can use:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+or:
------------------------------------------------
$ man git-clone
------------------------------------------------
+linkgit:git-help[1] has a few more features and is self-documenting
+using:
+
+------------------------------------------------
+$ git help help
+------------------------------------------------
+
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* [PATCH 1/3] Documentation: fix links to "everyday.html"
From: Christian Couder @ 2008-11-14 12:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In some places the links are wrong. They should be:
"link:everyday.html", instead of: "linkgit:everyday[7]".
This patch fixes that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 6 ++++--
Documentation/gitglossary.txt | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
The purpose of this patch series is to make "git help"
more visible in the tutorials.
"git help" was discussed during the GitTogether'08 and
many people said that "git help" should be improved to
have more newby friendly features. The problem is that
if it is not visible in the first place, there is no
point of improving it.
The first patch in this series is just a link fix.
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index a417e59..61fc5d7 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1690,8 +1690,10 @@ to follow, not easier.
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
index 565719e..d77a45a 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/gitglossary.txt
@@ -16,8 +16,10 @@ include::glossary-content.txt[]
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* getting started with git
From: Ivan Senji @ 2008-11-14 10:16 UTC (permalink / raw)
To: git
Hello everyone!
I started using git recently to manage my personal projects and I really
like it. I develop on several different locations and have a little problem
that i couldn't find a way to solve.
On each location that i develop some project and configuration files are
different. But i would like them to be in the repository as a starting point
when checking out a project (example: opening a project on a dfferent OS in
eclipse... eclipse will find an error in the path to jdk and ask me to fix
that error by selecting a different jdk).
How to achieve that these files are in the repository but that any further
changes to them are not commited (or are commited localy but not pushed to a
remote repository)?
Is that even possible?
Thanks!
--
View this message in context: http://www.nabble.com/getting-started-with-git-tp20497802p20497802.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Paolo Bonzini @ 2008-11-14 10:03 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200811141034.06282.chriscool@tuxfamily.org>
>> users could also set up a few
>> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
>> that you could use for purposes other than ensuring known bugs are fixed.
>
> In this case it is similar to Junio's proposal. But I think that for changes
> like set-debug-to-1 and remove-cflags-o2, using the right make command
> should be enough.
Yeah, I couldn't think of a better usecase, but you got the idea.
>> Finally, you could have a [bisect] configuration section with entries
>> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
>> FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
>
> Yes, but how do you share this between members of a team?
That's a common problem with stuff that goes in .gitconfig. It does not
belong in the repository, though...
Paolo
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Sam Vilain @ 2008-11-14 9:41 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811140844.58746.fge@one2team.com>
On Fri, 2008-11-14 at 08:44 +0100, Francis Galiegue wrote:
> > So, if the mkstemp() fails with EPERM, don't try to create the
> > directory - return straight away.
> Are you sure you didn't mean EACCESS?
Ah, you're right there. Well, maybe this one should be as well:
Subject: sha1_file: accept EACCESS as equivalent to EPERM
This was testing for 'Operation not permitted' rather than any kind
of 'Permission Denied' error; prefer EACCESS.
Signed-off-by: Sam Vilain <sam@vilain.net>
--
Sorry for the inevitable wrapping/whitespace fail :(
diff --git a/sha1_file.c b/sha1_file.c
index 7662330..cd422e6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t
bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen && (errno != EPERM)) {
+ if (fd < 0 && dirlen && (errno != EACCESS)) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
@@ -2257,7 +2257,7 @@ static int write_loose_object(const unsigned char
*sha1, char *hdr, int hdrlen,
filename = sha1_file_name(sha1);
fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
if (fd < 0) {
- if (errno == EPERM)
+ if (errno == EACCESS || errno == EPERM)
return error("insufficient permission for adding an object to
repository database %s\n", get_object_directory());
else
return error("unable to create temporary sha1 filename %s: %s\n",
tmpfile, strerror(errno));
^ permalink raw reply related
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-14 9:34 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <491C58A3.2000609@gnu.org>
Le jeudi 13 novembre 2008, Paolo Bonzini a écrit :
> > Of course it also depends on how often people use "git bisect", but it
> > seems that there are people out there bisecting very frequently and
> > that these people care very much about bisectability of the tree.
>
> What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick
> -n" of COMMIT after every bisection unless COMMIT is in the ancestry of
> the current revision? So if you have to bisect between A and B, and you
> know that a bug present between A and B was fixed by C, you could do
>
> git bisect good A
> git bisect bad B
> git bisect cherry-pick C
>
> This would subsume Junio's proposal:
Yes, it looks better than Junio's, except when there is no existing commit
that perfectly works.
> users could also set up a few
> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
> that you could use for purposes other than ensuring known bugs are fixed.
In this case it is similar to Junio's proposal. But I think that for changes
like set-debug-to-1 and remove-cflags-o2, using the right make command
should be enough.
> Finally, you could have a [bisect] configuration section with entries
> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
> FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.
Yes, but how do you share this between members of a team?
Your proposal and Junio's proposal also don't use real sha1 names for
commits that are tested, so it's more difficult to talk about them, share
them, use them, ...
Regards,
Christian.
^ 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