* 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
* Re: TortoiseGit
From: Tim Visher @ 2008-12-14 17:00 UTC (permalink / raw)
To: Alcides Fonseca; +Cc: Li Frank, git
In-Reply-To: <937EE54D-1FC0-4FFA-B273-C98C7CF321D4@alcidesfonseca.com>
On Sun, Dec 14, 2008 at 7:26 AM, Alcides Fonseca <me@alcidesfonseca.com> wrote:
> have your main git repo in github.com
+1
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Marcin Slusarz @ 2008-12-14 17:33 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
On Fri, Dec 12, 2008 at 06:28:27PM +0000, David Howells wrote:
> +REVERTING COMMITTED CHANGES
> +---------------------------
> +
> +And sometimes you'll want to revert changes that you've committed, but that are
> +now buried beneath other commits. Short of discarding and reapplying commits,
> +you have to apply a reverse patch:
> +
> + git diff %COMMIT_ID | patch -p1 -R
> +
> +and then commit it. Both the original application and the reversion will be
> +retained by GIT.
"git revert $commit" is a bit shorter.
Marcin
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Tim Visher @ 2008-12-14 17:45 UTC (permalink / raw)
To: Li Frank; +Cc: sverre, Jakub Narebski, git
In-Reply-To: <1976ea660812140548k940a73buf307cd331b775f31@mail.gmail.com>
On Sun, Dec 14, 2008 at 8:48 AM, Li Frank <lznuaa@gmail.com> wrote:
> I think TortoiseGit can make git popular at windows enviroment.
> Window user is waiting for the good UI. Porting from TortoiseSVN is
> fastest way.
I think you nailed it on the head there, Li. I had a hell of a time
trying to convince my team to use Subversion over (*gasp*) VSS,
despite the abominable network performance that we were getting with
VSS _and_ all of its obvious flaws (which they freely admitted), until
I finally showed them Tortoise (which I don't personally use) and then
they were all for it. Something like Tortoise for Git on Windows
would remove a __huge__ barrier to entry for most people that aren't
already comfortable with the command line. As simple as git is from
the command line, certain people just don't want to bother.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Junio C Hamano @ 2008-12-14 19:33 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix>
Nix <nix@esperi.org.uk> writes:
> Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
> this:
> ...
> 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?)
In git timescale 1.5.4 is not recent at all ;-)
Ancient git, whose "git merge" was a scripted command, refreshed the index
before starting, but it lost that when the command was rewritten in C soon
after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other
words, the tip of 'master' (and upcoming 1.6.1) already has the fix.
The fix should have been cherry-picked to 'maint' to be part of 1.6.0.X
series, but it apparently was forgotten. Fault of mine and Shawn ;-)
^ permalink raw reply
* [PATCH] Documentation: Describe git-gui Tools menu configuration options.
From: Alexander Gavrilov @ 2008-12-14 19:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Now git gui has a customizable Tools menu, so this adds
information about variables that are used to configure it.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Documentation/config.txt | 51 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b233fe5..2a06a3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -839,6 +839,57 @@ gui.blamehistoryctx::
Context` menu item is invoked from 'git gui blame'. If this
variable is set to zero, the whole history is shown.
+guitool.<name>.cmd::
+ Specifies the shell command line to execute when the corresponding item
+ of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
+ mandatory for every tool. The command is executed from the root of
+ the working directory, and in the environment it receives the name of
+ the tool as 'GIT_GUITOOL', the name of the currently selected file as
+ 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
+ the head is detached, 'CUR_BRANCH' is empty).
+
+guitool.<name>.needsfile::
+ Run the tool only if a diff is selected in the GUI. It guarantees
+ that 'FILENAME' is not empty.
+
+guitool.<name>.noconsole::
+ Run the command silently, without creating a window to display its
+ output.
+
+guitool.<name>.norescan::
+ Don't rescan the working directory for changes after the tool
+ finishes execution.
+
+guitool.<name>.confirm::
+ Show a confirmation dialog before actually running the tool.
+
+guitool.<name>.argprompt::
+ Request a string argument from the user, and pass it to the tool
+ through the 'ARGS' environment variable. Since requesting an
+ argument implies confirmation, the 'confirm' option has no effect
+ if this is enabled. If the option is set to 'true', 'yes', or '1',
+ the dialog uses a built-in generic prompt; otherwise the exact
+ value of the variable is used.
+
+guitool.<name>.revprompt::
+ Request a single valid revision from the user, and set the
+ 'REVISION' environment variable. In other aspects this option
+ is similar to 'argprompt', and can be used together with it.
+
+guitool.<name>.revunmerged::
+ Show only unmerged branches in the 'revprompt' subdialog.
+ This is useful for tools similar to merge or rebase, but not
+ for things like checkout or reset.
+
+guitool.<name>.title::
+ Specifies the title to use for the prompt dialog. The default
+ is the tool name.
+
+guitool.<name>.prompt::
+ Specifies the general prompt string to display at the top of
+ the dialog, before subsections for 'argprompt' and 'revprompt'.
+ The default value includes the actual command.
+
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
--
1.6.0.4.30.gf4240
^ permalink raw reply related
* [BUG] The description of pickaxe in git-blame(1) is wrong
From: Jakub Narebski @ 2008-12-14 21:33 UTC (permalink / raw)
To: git
I think that the description of how 'pickaxe' feature works in
Documentation/git-blame.txt is wrong. It says:
Apart from supporting file annotation, git also supports searching the
development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. _It works by searching for
a text string in the diff_. A small example:
The part "It works by searching for a text string in the diff" is,
if I remember correctly, wrong. Actually it (I think) compares how
many matches are in pre-image and in post-image, and shows these
commits where those number differ.
This for example means that pickaxe would not pick commit which
moved a fragment from one place to other without change, I think.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Johannes Schindelin @ 2008-12-14 22:10 UTC (permalink / raw)
To: git, gitster
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
config.c | 5 +----
git-svn.perl | 3 +--
t/t5400-send-pack.sh | 2 +-
t/test-lib.sh | 1 -
4 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/config.c b/config.c
index 8bd6106..8ff2b4b 100644
--- a/config.c
+++ b/config.c
@@ -640,10 +640,7 @@ int git_config(config_fn_t fn, void *data)
char *repo_config = NULL;
const char *home = NULL;
- /* $GIT_CONFIG makes git read _only_ the given config file,
- * $GIT_CONFIG_LOCAL will make it process it in addition to the
- * global config file, the same way it would the per-repository
- * config file otherwise. */
+ /* Setting $GIT_CONFIG makes git read _only_ the given config file. */
if (config_exclusive_filename)
return git_config_from_file(fn, config_exclusive_filename, data);
if (git_config_system() && !access(git_etc_gitconfig(), R_OK))
diff --git a/git-svn.perl b/git-svn.perl
index 914c707..efda5c1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5007,8 +5007,7 @@ sub minimize_connections {
}
}
if (@emptied) {
- my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
- "$ENV{GIT_DIR}/config";
+ my $file = $ENV{GIT_CONFIG} || "$ENV{GIT_DIR}/config";
print STDERR <<EOF;
The following [svn-remote] sections in your config file ($file) are empty
and can be safely removed:
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index da69f08..b21317d 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -99,7 +99,7 @@ test_expect_success \
! test -f victim/.git/refs/heads/extra
'
-unset GIT_CONFIG GIT_CONFIG_LOCAL
+unset GIT_CONFIG
HOME=`pwd`/no-such-directory
export HOME ;# this way we force the victim/.git/config to be used.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 8936173..22ed448 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -471,7 +471,6 @@ PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
-unset GIT_CONFIG_LOCAL
GIT_CONFIG_NOSYSTEM=1
GIT_CONFIG_NOGLOBAL=1
export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_CONFIG_NOGLOBAL
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* [PATCH] git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Johannes Schindelin @ 2008-12-14 22:12 UTC (permalink / raw)
To: git, spearce
In-Reply-To: <alpine.DEB.1.00.0812142310210.25197@racer>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
You might want to hold off on that, as git-gui is supposed to be
less tightly coupled to git.git than, say, git-svn.
The commit removing support for GIT_CONFIG_LOCAL is from Mon Jun
30 03:37:47 2008 -0400...
git-gui.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 8a4b42d..bab66bd 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3315,7 +3315,6 @@ by %s:
{^GIT_PAGER$} -
{^GIT_TRACE$} -
{^GIT_CONFIG$} -
- {^GIT_CONFIG_LOCAL$} -
{^GIT_(AUTHOR|COMMITTER)_DATE$} {
append msg " - $name\n"
incr ignored_env
--
1.6.0.4.1189.g8876f
^ 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