* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Jakub Narebski @ 2008-12-14 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0812141142300.2014@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 14 Dec 2008, Junio C Hamano wrote:
>
> > * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> > - Add support for a pdf version of the user manual
> >
> > I do not have a new enough combination of dblatex and asciidoc myself
> > but this would help interested people.
>
> I haven't had a look at the patches, but isn't "pdflatex" supposed to be
> the common way to get .pdf files from LaTeX sources?
The problem is that AsciiDoc, from what I understand, by itself
generates only XML-ish formats, namely HTML, XHTML and DocBook, and
the rest of formats are generated in postprocessing step by extra
tools from DocBook format:
* manpages require xmlto
* info requires docbook2X and makeinfo
* PDF requires dblatex (db = DocBook), or FOP and xmlto
So the answer is that AsciiDoc does not generate LaTeX, so pdflatex
would be not enough.
By the way, from the AsciiDoc page:
NOTE: Owning to to other commitments, Benjamin is unable to maintain
this backend. I don't have the expertise or time to take this
on consequently the LaTeX backend has not been tested or
updated since AsciiDoc version 8.2.7 and is currently
unsupported.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Jeff King @ 2008-12-14 11:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <alpine.DEB.1.00.0812141216120.2014@eeepc-johanness>
On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
> > Which annoyingly has no discussion about _why_ it no longer has an
> > effect. But I suspect it has something to do with 25ee973 (gc: call
> > "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
>
> Oops.
>
> But I thought that git gc --prune does expire _all_ dangling loose
> objects _now_, not with --expire 2.weeks.ago.
Nope, see 25ee973. You explicitly wrote:
Note that this new behaviour makes "--prune" be a no-op.
That being said, I think that is perhaps a reasonable thing for --prune
to do (and I don't think there is any conflict with the name, because
that is what it _used_ to do before becoming a no-op). But nobody has
actually implemented it.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Johannes Schindelin @ 2008-12-14 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081214111548.GB6499@coredump.intra.peff.net>
Hi,
On Sun, 14 Dec 2008, Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:44:23AM +0100, Johannes Schindelin wrote:
>
> > > * mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
> > > - Add support for a pdf version of the user manual
> > >
> > > I do not have a new enough combination of dblatex and asciidoc myself
> > > but this would help interested people.
> >
> > I haven't had a look at the patches, but isn't "pdflatex" supposed to be
> > the common way to get .pdf files from LaTeX sources?
>
> But we don't have latex sources; we have docbook sources. Hence dblatex
> (which does the conversion to PDF internally, so it is a bit of a
> misnomer).
Indeed, I was fooled.
Thanks for the clarification,
Dscho
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Jakub Narebski @ 2008-12-14 11:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <alpine.DEB.1.00.0812141137350.2014@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 13 Dec 2008, Markus Heidelberg wrote:
>
> > - __gitcomp "--prune --aggressive"
> > + __gitcomp "--aggressive"
>
> git gc --prune is deprecated? That's news to me.
More like "git gc --prune" is no-op now.
> How would you suggest, then, to remove the loose objects you always get
> with conflicts in a merge?
"git gc" does pruning of loose objects, but protected by grace period
for loose objects with gc.pruneexpire
You always have (admittedly lowe level) git-prune.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Let git remote accept up as alias to update
From: Jeff King @ 2008-12-14 11:25 UTC (permalink / raw)
To: Alexey Zaytsev; +Cc: git
In-Reply-To: <20081213181704.20126.4200.stgit@zaytsev.su>
On Sat, Dec 13, 2008 at 09:18:56PM +0300, Alexey Zaytsev wrote:
> Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> ---
>
> Don't know why, but I keep typing remote up instead of
> remote update. As update is probably by far the most
> used remote action, can we please have this alias?
Hmm. The usual answer for requests like this is "make your own alias".
But usually they are for primary command aliases (e.g., "co" for
"checkout"), and this is a sub-command. So you are actually stuck doing:
git config alias.rup "remote update"
which is maybe better (even less typing) but is not exactly what you
asked for.
I think even nicer than an explicit "up" alias would be to accept any
prefix as long as it was unique. However, I think a scheme like that
would only make sense if it was used fairly universally, and the current
code is not amenable to doing it for regular commands (it doesn't
actually have a complete list of commands -- it just tries to exec what
you tell it). However, it could be refactored to do so.
-Peff
^ permalink raw reply
* Re: is gitosis secure?
From: Sitaram Chamarty @ 2008-12-14 11:42 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.10.0812140304320.17688@asgard.lang.hm>
On 2008-12-14, david@lang.hm <david@lang.hm> wrote:
> On Sun, 14 Dec 2008, martin wrote:
>> Why do you trust VPN more than the SSH?
> in part it's that a VPN is a single point of control for all remote
> access.
>
> If you use ssh you end up exposing all the individual machines
Need not be true. None of my internal servers aer even
accessible from the outside world; they're all in RFC1918
space and there's only one gateway. This *is* my single
point of control.
I can setup different port numbers to forward to different
internal servers (ssh, http, whatever I wish); that may
sound like a form of "exposing" but in reality it's a lot
*more* restrictive than setting up a VPN and granting access
to it.
I actually don't like VPNs; they imply that you're "inside"
the network in some way, and I hate blurring that
distinction. If I'm outside, I want to be acutely aware of
it, and the fact that I can't even ping one of the inside
hosts or see what's on it, or do anything other than what is
specifically allowed by the gateway, is one way of ensuring
this.
^ permalink raw reply
* Re: TortoiseGit
From: Alcides Fonseca @ 2008-12-14 12:26 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <1976ea660812140147o40e014cbn46d920781db029a1@mail.gmail.com>
Em 2008/12/14, às 09:47, Li Frank escreveu:
> You post nothing!
I'm used to send a first email to subscribe to some mailing list. I'm
sorry for that.
I wanted to suggest you to have your main git repo in github.com, that
is like a social network of opensource projects. It's also free, and
it will give the project more exposition, that may mean more
contributors.
Just a suggestion ;)
Alcides Fonseca
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Li Frank @ 2008-12-14 12:27 UTC (permalink / raw)
To: Tim Visher, git
In-Reply-To: <c115fd3c0812130621p5df742ffs98d69cd922ebc972@mail.gmail.com>
Thank you for interesting this project. This release is very early stage.
Weclome contribute anything, including coding, testing, document and so on.
2008/12/13 Tim Visher <tim.visher@gmail.com>:
> On Sat, Dec 13, 2008 at 3:33 AM, 李智 <lznuaa@gmail.com> wrote:
>
>> TortoiseGit is porting from TortoiseSVN.
>
> Thanks so much for this!
>
> My team and I were just talking about how the biggest barrier to entry
> at this point for _some_ of us has been the lack of a great tool like
> Tortoise for Git. My opinion was that someone would soon write it.
> And lo-and-behold, here it is!
>
> I'll look forward to watching this progress, and continue happily
> using my cli version the same.
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
>
^ permalink raw reply
* Followup: management of OO files - warning about "rezip" approach
From: Sergio Callegari @ 2008-12-14 13:08 UTC (permalink / raw)
To: git
Hi, some times ago, i considered ways to achieve a smarter management of
openoffice files with git.
The thread started at:
http://article.gmane.org/gmane.comp.version-control.git/95951
There, a "rezip" script was proposed to store OO files uncompressed into git
repos, so that the compression and delta machinery of git could operate at its
best with them.
Appartently, the script rose some interest. In the following days I received
quite a few corrections/enhancements proposals for which all the posters I thank.
Also I was asked to upload the script and instructions relative to its adoption
together with .gitattributes to the git wiki.
This I didn't do (I do not know if someone else might have done it) because I
first wanted to be absolutely sure that the script would cause no problems to
anybody.
Unfortunately, I now see that there is an issue, so I am sending a warning.
The problem stems from the fact that ODF files, due to the zip compression also
might store pieces of info that are completely irrelevant. For instance zip
stores ownership of member files. This is why in the rezip script I initially
started to unzip files with -X.
Now, this seems to be looking for trouble when repos are passed from one user to
another one.
When we uncompress and ODF file for storing we should probably scrap away the
member ownership info alltogether. Note that this is not equivalent to not using
-X. Not using -X would mean "changing" member owernership when an ODF file is
passed from one user to another one. Using -X seemed to me the correct thing to
do as it allowed to leave untouched the member ownership. However, -X fails
when user A has no permission to create files as user B.
I found out about this issue by having accounts on many hosts, where my
alphanumeric user ID maps to different numeric IDs.
I will look better at this as soon as I have time. So far, please just be
careful. My guess is that we should not use -X on "unzip" but use it on "zip".
E.g. patch the rezip script so that
PROFILE_UNZIP_ODF_UNCOMPRESS='-b -qq'
PROFILE_ZIP_ODF_UNCOMPRESS='-q -r -D -0 -X'
PROFILE_UNZIP_ODF_COMPRESS='-b -qq'
PROFILE_ZIP_ODF_COMPRESS='-q -r -D -6 -X'
Sergio
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Jakub Narebski @ 2008-12-14 13:09 UTC (permalink / raw)
To: 李智; +Cc: git
In-Reply-To: <1976ea660812130033m2d54cc57tfe134fab0d687d71@mail.gmail.com>
"李智" <lznuaa@gmail.com> writes:
> TortoiseGit is porting from TortoiseSVN. It is explore extension.
> This version just finish a minimum set of TortoiseSVN porting
How it differs from GitCheetah project?
[...]
> Project Home Page at:
> http://code.google.com/p/tortoisegit/
>
> Source code at
> http://repo.or.cz/w/TortoiseGit.git
>
> It need msysgit 1.6.0.2.
Do you feel it is mature enough to be added to git wiki page
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
just above "Git Extensions" entry? Would you do it, or should
I do this?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: New script to convert p4 repositories to git - git-p4c version 1.
From: Jakub Narebski @ 2008-12-14 13:11 UTC (permalink / raw)
To: John Chapman; +Cc: Git Mailing List
In-Reply-To: <1228818317.5504.23.camel@localhost>
John Chapman <thestar@fussycoder.id.au> writes:
> It is called git-p4c, because 'git-p4' was taken, and I intended to
> write it in C++. I may still rewrite it in C++ if it is found
> neccessary to use it on windows. (The Perforce C++ ABI will remove the
> need to fork so many processes), but I won't be doing that before I
> implement the write to perforce support.
>
> Consider this to be experimental, not yet worthy of a version number.
Do you feel it would be worth adding it below git-p4 (and other
Perforce importers) on git wiki page:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Or would you rather wait a bit to at least version 0.1?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Miklos Vajna @ 2008-12-14 13:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <m3ljujdn2k.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On Sun, Dec 14, 2008 at 03:17:05AM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> So the answer is that AsciiDoc does not generate LaTeX, so pdflatex
> would be not enough.
>
> By the way, from the AsciiDoc page:
>
> NOTE: Owning to to other commitments, Benjamin is unable to maintain
> this backend. I don't have the expertise or time to take this
> on consequently the LaTeX backend has not been tested or
> updated since AsciiDoc version 8.2.7 and is currently
> unsupported.
Yes, this is the LaTeX backend, which would allow not to use dblatex,
but generate tex directly from asciidoc. That's why my patch uses
dblatex instead.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Sverre Rabbelier @ 2008-12-14 13:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: 李智, git
In-Reply-To: <m3d4fuewe0.fsf@localhost.localdomain>
2008/12/14 Jakub Narebski <jnareb@gmail.com>:
> How it differs from GitCheetah project?
I really think it's a shame if this does not get integrated with
GitCheetah. We need a good client not just on Windows, but on all
platforms, with shell integration of course.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Li Frank @ 2008-12-14 13:29 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <m3d4fuewe0.fsf@localhost.localdomain>
GitCheetah just show git-gui &git-bash at context menu!
TortoiseGit is full porting from TortoiseSVN. Overlay icon can show
modified file, add file and conflicted file whith different icon.
TortoiseGit can commit change, show log, checkout ... at Context menu!
It is full git fontend.
TortoiseGit is in very early stage. I just implement min set feature
and not mature . I hope there are more and more people involve this
project and make it mature as TortoiseSVN.
2008/12/14 Jakub Narebski <jnareb@gmail.com>:
> "李智" <lznuaa@gmail.com> writes:
>
>> TortoiseGit is porting from TortoiseSVN. It is explore extension.
>> This version just finish a minimum set of TortoiseSVN porting
>
> How it differs from GitCheetah project?
>
> [...]
>> Project Home Page at:
>> http://code.google.com/p/tortoisegit/
>>
>> Source code at
>> http://repo.or.cz/w/TortoiseGit.git
>>
>> It need msysgit 1.6.0.2.
>
> Do you feel it is mature enough to be added to git wiki page
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> just above "Git Extensions" entry? Would you do it, or should
> I do this?
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Li Frank @ 2008-12-14 13:48 UTC (permalink / raw)
To: sverre; +Cc: Jakub Narebski, git
In-Reply-To: <bd6139dc0812140528w4591ee03h9723ba66a967051b@mail.gmail.com>
I really want to make cross platforms!
But there are difference at difference platform.
At linux enviroment, user has been used to command line. I was worked
at linux project before. I also like it.
At windows enviroment is difference. User like GUI. SVN is typical
example. Why it is used popular at windows enviroment, that is
tortoiseSVN.
We have to face the fact, there are differences at different platform.
I like core server is cross platform. But we can have difference
fontends at difference platform according special platform features.
For example, windows user like Visual Studio plug-in. But Linux user
like eclipse plug-in more.
I think TortoiseGit can make git popular at windows enviroment.
Window user is waiting for the good UI. Porting from TortoiseSVN is
fastest way.
2008/12/14 Sverre Rabbelier <alturin@gmail.com>:
> 2008/12/14 Jakub Narebski <jnareb@gmail.com>:
>> How it differs from GitCheetah project?
>
> I really think it's a shame if this does not get integrated with
> GitCheetah. We need a good client not just on Windows, but on all
> platforms, with shell integration of course.
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* How to maintain private/secret/confidential branch.
From: Łukasz Lew @ 2008-12-14 13:49 UTC (permalink / raw)
To: git
Hi,
I don't know how to make such a scenario work:
- two repositories: pub, priv
- priv is clone/branch of pub
- there is some constant developement both in pub and priv
- there are regular syncs with pub in priv
Problem:
Occasionally I want to push some changes from priv to pub.
Then after syncing with pub I want to get as few conflicts as possible.
Is it possible to do with git?
Thanks
Lukasz
^ permalink raw reply
* Re: [PATCH] Add support for an info version of the user manual
From: Kalle Olavi Niemitalo @ 2008-12-14 14:30 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ir7tc5xk.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> posted to the git mailing list in 2007:
> awk is used for patching up sub-par file and directory information in
> the Texinfo file. It would be cleaner to place the respective info
> straight into user-manual.txt or the conversion configurations, but I
> find myself unable to find out how to do this with Asciidoc/Texinfo.
I found how to do this, but it's not worth the trouble.
Apparently, there are two ways to specify the description for the
Info directory entry generated by docbook2X 0.8.3:
(a) Set it in the docbook2x-texi command line, with the option:
-g description="A fast distributed revision control system"
This could easily be placed in the Makefile.
(b) Add a /book/bookinfo/abstract[@role="texinfo-node"] element:
<abstract role="texinfo-node"><simpara>A fast distributed
revision control system</simpara></abstract>
docbook2x-0.8.3/xslt/texi/menudescrip.xsl claims that the role
should be "make-texinfo-node", but the template in that file
actually looks for role="texinfo-node". docbook2X 0.8.8
documents the role correctly.
The /book/bookinfo element currently comes from the [header]
section in docbook.conf of AsciiDoc. That docbook.conf does
not currently provide a way to add an abstract like that.
So, Git would have to override the whole header, unless
such a feature were added to AsciiDoc.
Then, docbook2x-texi would take the title "Git User's Manual (for
version 1.5.3 or newer)" and convert it to "Git User_s Manual
[for version 1_5_3 or newer]", presumably to avoid some reserved
characters in Info. To get a prettier title like "Git" in the
Info directory entry:
(a) A Git-specific XSL template could read the entry title from
/book/bookinfo/titleabbrev, which would also have to be added
to the header in the AsciiDoc configuration.
(b) Alternatively, the template could use a command-line parameter.
Makefile would provide -g info-dir-title="Git", and the
template would then use $info-dir-title.
Finally, to make the Info directory entry link to the right file,
one would have to add -g output-file=git to the docbook2x-texi
invocation.
In summary, it is certainly possible to make AsciiDoc and
docbook2X together generate the right kind of directory entry,
but I suspect the current Perl hack is more likely to survive
toolchain upgrades than a more proper implementation would be.
If the necessary features were added to the upstream AsciiDoc
and docbook2X, then things would be different, but I guess Git
wouldn't dare require new versions until after a year or so.
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Nick Andrew @ 2008-12-14 14:55 UTC (permalink / raw)
To: Łukasz Lew; +Cc: git
In-Reply-To: <c55009e70812140549t6547c1d6jf7780f91b5074e73@mail.gmail.com>
On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
> I don't know how to make such a scenario work:
> - two repositories: pub, priv
> - priv is clone/branch of pub
> - there is some constant developement both in pub and priv
> - there are regular syncs with pub in priv
>
> Problem:
> Occasionally I want to push some changes from priv to pub.
> Then after syncing with pub I want to get as few conflicts as possible.
>
> Is it possible to do with git?
Git can do almost anything. One should instead ask "How to do this
with git?" :-)
If I understand your problem, you could solve it with git cherry-pick
and rebase. On priv, make a for-public branch from a pub branch. Then
cherry-pick the commits you want from your private branch into the
for-public branch. Push your for-public branch to pub, then rebase
your private branch.
Nick.
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Łukasz Lew @ 2008-12-14 15:38 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20081214145518.GA26380@mail.local.tull.net>
Thanks Nick, thats really helpful (and surprisingly simple).
I have a couple more questions:
On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
> On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
>> I don't know how to make such a scenario work:
>> - two repositories: pub, priv
>> - priv is clone/branch of pub
>> - there is some constant developement both in pub and priv
>> - there are regular syncs with pub in priv
>>
>> Problem:
>> Occasionally I want to push some changes from priv to pub.
>> Then after syncing with pub I want to get as few conflicts as possible.
>>
>> Is it possible to do with git?
>
> Git can do almost anything. One should instead ask "How to do this
> with git?" :-)
So I've heard, but not yet experienced it myself. I'm thrilled to try.
>
> If I understand your problem, you could solve it with git cherry-pick
> and rebase. On priv, make a for-public branch from a pub branch. Then
> cherry-pick the commits you want from your private branch into the
> for-public branch.
That almost works. Can I somehow split existing commits just like in git-add -p?
> Push your for-public branch to pub,
> then rebase your private branch.
Rebase to the tip of master? Is it needed? Ie. cherry-pick does not
remove the patch from
the master in priv.
If I now pull from pub, I will get the same change and it mereges nicely :D
Can I get away without creating for_pub branch? maybe cherry pick in
pub from priv somehow?
>
> Nick.
>
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Alexander Potashev @ 2008-12-14 16:06 UTC (permalink / raw)
To: Łukasz Lew; +Cc: Nick Andrew, git
In-Reply-To: <c55009e70812140738l8b51adax77cc6e507971554e@mail.gmail.com>
Hello, Łukasz!
On 16:38 Sun 14 Dec , Łukasz Lew wrote:
> Thanks Nick, thats really helpful (and surprisingly simple).
> I have a couple more questions:
>
> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
> >> I don't know how to make such a scenario work:
> >> - two repositories: pub, priv
> >> - priv is clone/branch of pub
> >> - there is some constant developement both in pub and priv
> >> - there are regular syncs with pub in priv
> >>
> >> Problem:
> >> Occasionally I want to push some changes from priv to pub.
> >> Then after syncing with pub I want to get as few conflicts as possible.
> >>
> >> Is it possible to do with git?
> >
> > Git can do almost anything. One should instead ask "How to do this
> > with git?" :-)
>
> So I've heard, but not yet experienced it myself. I'm thrilled to try.
>
> >
> > If I understand your problem, you could solve it with git cherry-pick
> > and rebase. On priv, make a for-public branch from a pub branch. Then
> > cherry-pick the commits you want from your private branch into the
> > for-public branch.
>
> That almost works. Can I somehow split existing commits just like in git-add -p?
It's, however, better to make more commits to not experience the need of
commit splitting.
But you can use '--no-commit' option of 'git cherry-pick' and 'git merge'
(and 'git pull' as well as 'git merge'). For example:
git cherry-pick --no-commit <sha1> # cherry-pick without commiting
git reset -- # unstage all changes
git add -p # patch update
You can also use 'git add -i' (interative mode) instead of 'git add -p'.
>
> > Push your for-public branch to pub,
> > then rebase your private branch.
>
> Rebase to the tip of master? Is it needed? Ie. cherry-pick does not
> remove the patch from
> the master in priv.
>
> If I now pull from pub, I will get the same change and it mereges nicely :D
>
> Can I get away without creating for_pub branch? maybe cherry pick in
> pub from priv somehow?
>
> >
> > Nick.
> >
Alexander
^ permalink raw reply
* [RFC] gitweb: Incremental blame - suggestions for improvements
From: Jakub Narebski @ 2008-12-14 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <1229213850-12787-1-git-send-email-jnareb@gmail.com>
A few suggestions for further improvement of blame_incremental:
* Better support for data mining in 'blame_incremental' view,
(for "lineno" links to (approximately) lead to previous version of
line) would probably require for gitweb to accept "<rev>^" for 'hb'
parameter (and perhaps resolve/parse it before saving to
$hash_base). This would also help performance of 'blame' view.
* Move some of processing to server, to 'blame_data' action, and for
example send whole saved and processed info for a group of lines as
JSON or as variation of "git blame --incremental" output.
* Better error checking: not only check if scripting is turned on,
but also if required methods like document.getElementById are
available. Probably would require falback to *ugh* document.write.
* Perhaps fallback on (slower) DOM methods if innerHTML is not
available or doesn't work, which is the case for some versions of
some browsers in strict XHTML (application/xml+html + XHTML DTD)
mode.
* Fallback on DOM Core methods of deleting cell if DOM HTML
deleteCell method is not available; check that DOM Core way does
not lead to memory leaks (by deleting element, but not its
children).
* Use 'one second spotlight' or other similar user interface patter
to signal in more visible way than reaching 100% in progress info,
and changing colors from 3-coloring to 2-color zebra in blame table
that all blame data was received and entered.
* Check in handleResponse if browser calls it on [each] server flush,
by checking if it is called more than once with http.readyState == 3
and with different http.responseText, and disable poll timer then.
* Mark boundary commits (this applies both to 'blame' and
'blame_incremental' views), using UNDOCUMENTED "boundary" header.
* A toy. Make progress bar indicator more smooth by interpolating
changes between updates, so it moves smoothly. This would make it
provide impression for user, not an accurate measure of blamed
percentage.
* A toy. Make sure that 3-coloring during updating blame table use
all three colors with similar frequency, for example by using the
following implementation of chooseColorNoFrom function:
// return one of given possible colors
// example: chooseColorNoFrom(2, 3) might be 2 or 3
var colorsFreq = [0, 0, 0];
// assumes that 1 <= arguments[i] <= colorsFreq.length
function chooseColorNoFrom() {
// choose the color which is least used
var colorNo = arguments[0];
for (var i = 1; i < arguments.length; i++) {
if (colorsFreq[arguments[i]-1] < colorsFreq[colorNo-1]) {
colorNo = arguments[i];
}
}
colorsFreq[colorNo-1]++;
return colorNo;
}
Do you have your own suggestions? Comments?
Would incremental blame help git-instaweb use?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Sitaram Chamarty @ 2008-12-14 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <c55009e70812140738l8b51adax77cc6e507971554e@mail.gmail.com>
On 2008-12-14, Łukasz Lew <lukasz.lew@gmail.com> wrote:
> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
>> If I understand your problem, you could solve it with git cherry-pick
>> and rebase. On priv, make a for-public branch from a pub branch. Then
>> cherry-pick the commits you want from your private branch into the
>> for-public branch.
>
> That almost works. Can I somehow split existing commits
> just like in git-add -p?
This is going to sound weird to some seasoned folks, and I'm
hoping to hear better ways of doing this. But having done
stuff like this, I once wrote it up and here're my notes:
To split just the top commit into multiple commits:
* start git gui
* choose "amend last commit" from the commit menu
* unstage all files (meaning you click on the little
icons so they move from the left-bottom panel to the
left-top panel)
* pick files or hunks in files to stage and commit the
usual way
* continue all changes are committed
To split a commit that is *not* the top one:
* start an interactive rebase that includes that commit
* mark that commit as "edit" and start the rebase
* when the rebase pauses, use git gui as described above
To combine a set of commits and split the result in some
other way (meaning you have commits A B P Q C D R E S and you
want to make them A B C D X Y Z where X+Y+Z = P+Q+R+S!)
* start an interactive rebase
* move lines as appropriate (in the editor) so the
commits P,Q,R,S are together
* choose "squash" on the second and subsequent ones and
start the rebase
* (dirty trick warning) when the editor for the combined
commit message pops up, delete ALL the lines and save
* use git gui as above
* then continue the rebase
Hope this helps...
^ permalink raw reply
* Re: [PATCH] remove unnecessary 'if'
From: Alexander Potashev @ 2008-12-14 16:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1228918156-3953-1-git-send-email-aspotashev@gmail.com>
Hello all!
What happened with this patch? Is it wrong or breaks comprehensibility?
On 17:09 Wed 10 Dec , Alexander Potashev wrote:
> 'patch->is_new' is always <= 0 at this point (look at 'assert' at the
> beginning of the function). In both cases ('is_new < 0' and 'is_new == 0')
> the result of those two lines is zeroing of 'is_new'.
>
> Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
> ---
> builtin-apply.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 4c4d1e1..904a748 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -2440,8 +2440,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
> if (!cached)
> st_mode = ce_mode_from_stat(*ce, st->st_mode);
>
> - if (patch->is_new < 0)
> - patch->is_new = 0;
> + patch->is_new = 0;
> if (!patch->old_mode)
> patch->old_mode = st_mode;
> if ((st_mode ^ patch->old_mode) & S_IFMT)
> --
> 1.6.0.4
>
Alexander
^ permalink raw reply
* Possibly-spurious 'not uptodate. Cannot merge'
From: Nix @ 2008-12-14 16:47 UTC (permalink / raw)
To: git
Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
this:
loki 504 /usr/packages/linux/linux% git pull
remote: Counting objects: 638, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 517 (delta 430), reused 516 (delta 430)
Receiving objects: 100% (517/517), 74.91 KiB, done.
Resolving deltas: 100% (430/430), completed with 120 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y
078bb16..5defaf8 master -> 2.6.27-stable/master
* [new tag] v2.6.27.9 -> v2.6.27.9
error: Entry 'Makefile' not uptodate. Cannot merge.
fatal: merging of trees 34f70ec1fadcaad7de6979491e2dea9da735e6f9 and ded3f44559ce050e0ef014ebce093c5d9295ede8 failed
Merge with strategy recursive failed.
In this situation, 'git diff' reports no changes at all, but 'git reset
--hard' gets the tree back into a state where merging succeeds, as does
'git update-index --refresh'.
I suspect the 'problem' is that I've hardlinked a bunch of build trees
to this tree in the interim via 'cp -al', then applied patches to each
of those trees with quilt, then deleted all those trees prior to the git
pull. This doesn't change the original files at all, but *does* update
their link count: is git getting annoyed by the corresponding change in
ctime? (If so, why did it start happening only fairly recently?)
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Łukasz Lew @ 2008-12-14 16:48 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Nick Andrew, git
In-Reply-To: <20081214160645.GA21358@myhost>
Hi Alexander,
On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
> Hello, Łukasz!
>
> On 16:38 Sun 14 Dec , Łukasz Lew wrote:
>> Thanks Nick, thats really helpful (and surprisingly simple).
>> I have a couple more questions:
>>
>> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
>> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
>> >> I don't know how to make such a scenario work:
>> >> - two repositories: pub, priv
>> >> - priv is clone/branch of pub
>> >> - there is some constant developement both in pub and priv
>> >> - there are regular syncs with pub in priv
>> >>
>> >> Problem:
>> >> Occasionally I want to push some changes from priv to pub.
>> >> Then after syncing with pub I want to get as few conflicts as possible.
>> >>
>> >> Is it possible to do with git?
>> >
>> > Git can do almost anything. One should instead ask "How to do this
>> > with git?" :-)
>>
>> So I've heard, but not yet experienced it myself. I'm thrilled to try.
>>
>> >
>> > If I understand your problem, you could solve it with git cherry-pick
>> > and rebase. On priv, make a for-public branch from a pub branch. Then
>> > cherry-pick the commits you want from your private branch into the
>> > for-public branch.
>>
>> That almost works. Can I somehow split existing commits just like in git-add -p?
> It's, however, better to make more commits to not experience the need of
> commit splitting.
Indeed good advice and best practice, but another best practice is to
not commit not compiling state.
My common scenario is that I code a big change in priv repository, and
after that I find that some of its parts can and should be moved to
pub.
>
> But you can use '--no-commit' option of 'git cherry-pick' and 'git merge'
> (and 'git pull' as well as 'git merge'). For example:
>
> git cherry-pick --no-commit <sha1> # cherry-pick without commiting
> git reset -- # unstage all changes
> git add -p # patch update
>
> You can also use 'git add -i' (interative mode) instead of 'git add -p'.
That's a possible solution indeed.
Now I see that the right "plumbing" I need is splitting a commit into
smaller parts and merging several commits into a larger one.
I think that would be nice functionality.
Do you know any tool that would allow such a manipulation on commits
in history?
Thanks
Lukasz
>
>>
>> > Push your for-public branch to pub,
>> > then rebase your private branch.
>>
>> Rebase to the tip of master? Is it needed? Ie. cherry-pick does not
>> remove the patch from
>> the master in priv.
>>
>> If I now pull from pub, I will get the same change and it mereges nicely :D
>>
>> Can I get away without creating for_pub branch? maybe cherry pick in
>> pub from priv somehow?
>>
>> >
>> > Nick.
>> >
>
> Alexander
>
^ 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