* Re: can't create a branch on remote
From: Jakub Narebski @ 2009-10-09 22:08 UTC (permalink / raw)
To: Auguste Mome; +Cc: git
In-Reply-To: <17cb70ee0910091435l4c4d1736hf4d403a2fe6331a2@mail.gmail.com>
Auguste Mome <augustmome@gmail.com> writes:
> Hi,
> I have two repositories /home/user/linux and /home/user/dev/linux,
> same user on same machine.
> Here is how I create a local branch at v2.6.21.7 in /home/user/dev/linux,
> #pwd
> /home/user/dev/linux
> # git remote add l2621
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
> # git fetch l2621
> # git branch mylocal26217 v2.6.21.7
>
> Now I would like to do the same from the other repository /home/user/linux:
> # pwd
> /home/user/linux
> # git remote add other /home/guerin/dev/git/linux-2.6
> # git fetch other
> # git push /home/user/dev/git/linux-2.6
> v2.6.21.7:refs/heads/new_feature_name26217
> Total 0 (delta 0), reused 0 (delta 0)
> error: Trying to write non-commit object
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 170684ef0557d4b711a86595d31dcbebcb9d4ba2 to branch
> refs/heads/new_feature_name26217
> To /home/user/dev/git/linux-2.6
> ! [remote rejected] v2.6.21.7 -> new_feature_name26217 (failed to write)
> error: failed to push some refs to '/home/user/dev/git/linux-2.6'
>
> Maybe something to configure to authorize the creation of branch?
You can't push tag to branch.
I'm not sure if what you are trying to do makes sense at all, but the
commit pointed by v2.6.21.7 is v2.6.21.7^{}
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Jakub Narebski @ 2009-10-09 22:07 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910091350o5cd90d3dobe2a21c18fa56dfd@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Here is another issue with gitweb integration which i think might be
> considered as a feature proposal:
>
> I have a central place where bare repos are. They're owned by the user
> under which we are serving them, let's say “git”. So, gitweb is going
> to show me
>
> Repo1 owner git etc…
>
> In order to show a real owner I have to rebuild gitweb.cgi, to tell it
> to use the file for GITWEB_LIST and edit the file… In fact I think
> gitweb shouldn’t carry this info, but bare repos should.
It is not gitweb that carries this info, but file with list of
repositories (GITWEB_LIST). And you can pre-generate this file using
gitweb.
>
> So my idea is:
>
> Either provide a key to
> $ git clone –bare –u “owner/email”
>
> or take the user.email parameter from .gitconfig.
>
> in both cases the info can go to description file of bare repo, so it
> can look like:
>
> $owner=owner@server.com
>
> $description=”very long description”
RTFM (in this case gitweb/README). gitweb.owner and gitweb.description
configuration variables in per-repository config.
>
> Or in xml form…
Aaaaaaaaaaaaaaaaaaaaaaaa...
%
"To be fair, there are uses for XML. On Halloween, for example."
- Johannes Schindelin, on git@vger.kernel.org
%
>
>
> Yes, description file might become a bit more complicated in its
> layout. But, the benefits are obvious:
>
> - No need to support multiple lists/files
> - Bare repo carries all info about itself (together with –d feature I
> described earlier).
>
> I this circumstances gitweb’s GITWEB_LIST will be only filter (only
> repo path is necessary to show/not show), and it seems that narrowed
> functionality here is a good thing...
GITWEB_LIST is meant for the case when you want to avoid scanning
filesystem for git repositories. And you can filter out repositories
without using GITWEB_LIST (see documentation).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash: add support for 'git replace'
From: Shawn O. Pearce @ 2009-10-09 22:19 UTC (permalink / raw)
To: Bj??rn Gustavsson; +Cc: git
In-Reply-To: <4ACFA1C2.6020001@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> +_git_replace ()
> +{
> + __gitcomp "$(__git_refs)"
> +}
> +
> _git_reset ()
> {
> __git_has_doubledash && return
> @@ -2162,6 +2167,7 @@ _git ()
> push) _git_push ;;
> rebase) _git_rebase ;;
> remote) _git_remote ;;
> + replace) _git_replace ;;
--
Shawn.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-09 22:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ab00gr25.fsf@localhost.localdomain>
>
> RTFM (in this case gitweb/README). gitweb.owner and gitweb.description
> configuration variables in per-repository config.
>
Ok, my bad, didn't get there;)It is good to know there are places
where to keep the info. But it is not the point. The point is to
integrate gitweb with bare repo creation more than it is right now by
providing keys which will help filling out this info at the bare repo
creation stage.
shortly i'm talking about command like this (the key names are for sample only):
$ git clone --bare repo repo.git -desc "description" -gwowner
"gitwebowner@server.com" -cloneurl "git://host/repo.git"
seems to me quite comfy, and no headache...
> %
> "To be fair, there are uses for XML. On Halloween, for example."
>
> - Johannes Schindelin, on git@vger.kernel.org
> %
yeah, to show kids xml print outs as an answer to "trick or treat!".
Can save on candies;)
Thanks,
Eugene
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Avery Pennarun @ 2009-10-09 22:43 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910091433v2c959a70g9bfc6c54382f370d@mail.gmail.com>
On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I'm missing the point here though. Where/when do I actually add the
> new pristine code? If I checkout, as you suggest, my initial commit I
> just have (say) v1.0 of the vendor's code. I can't just copy (say)
> version 1.2 on top as the files probably won't match one-one.
>
> Sorry - I'm probably completely failing to understand.
Try this:
cd mygitproject
git rm -rf .
cp -a /tmp/wherever/vendor-1.2/. .
git add .
git commit
Don't worry, git won't double-store files that are identical between
the old 1.0 and new 1.2 versions.
Avery
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Brandon Casey @ 2009-10-09 22:37 UTC (permalink / raw)
To: Junio C Hamano, Brandon Casey, git, drizzd, peff
In-Reply-To: <7vhbu8s151.fsf@alter.siamese.dyndns.org>
I'm away from a computer right now. Junio, if gmail is showing me the
entirety of your workaround, then no, I don't think that will work.
Your code will always exit non-zero, but there are cases where 'exit
0' is called and a '0' exit status is desired. e.g. when test_done is
called.
I'll look more closely at the suggestions when I get back to a computer.
-brandon
On 10/9/09, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> Commit 6e7b5aaf introduced the concept of GIT_EXIT_OK as a way to indicate
>> to die(), the exit handler, whether the exit was initiated by the test
>> harness, or whether it was unexpected. die() expects $? to contain the
>> value passed to exit(), and when GIT_EXIT_OK is set, die() calls exit with
>> the value in $?. This works as expected when using the Bash shell. For
>> the Korn shell, $? has the value of the last executed statement _before_
>> the call to exit. If that statement completed successfully, then die()
>> would incorrectly exit with a successful status when GIT_EXIT_OK is set.
>
> That's somewhat unexpected, as I did not think this was an anomaly in
> bash. FWIW, dash seems to behave the same way.
>
> The environment in which the shell executes a trap on EXIT shall be
> identical to the environment immediately after the last command executed
> before the trap on EXIT was taken.
>
> If the trap action was triggered because somebody called "exit 13", $? is
> expected to contain that value, because that is the last command executed
> before the trap on EXIT was taken, no?
>
>> So, rather than relying on the behavior of Bash in order to get the exit
>> code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
>> it to the code that we want to exit with. This allows the test suite to
>> be run with the Korn shell.
>
> I wonder if the attached is a more clear and contained workaround for this
> issue.
>
> ---
> t/test-lib.sh | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index f2ca536..c47a295 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -185,7 +185,14 @@ die () {
> code=$?
> if test -n "$GIT_EXIT_OK"
> then
> - exit $code
> + # Korn does not update $? when "exit 47" triggers
> + # the EXIT trap.
> + if test $code = 0
> + then
> + exit 1
> + else
> + exit $code
> + fi
> else
> echo >&5 "FATAL: Unexpected exit with code $code"
> exit 1
>
--
Sent from my mobile device
^ permalink raw reply
* [PATCH 5/9 v2] Documentation: clone: clarify discussion of initial branch
From: Jonathan Nieder @ 2009-10-09 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskdsqlvh.fsf@alter.siamese.dyndns.org>
When saying the initial branch is equal to the currently active
remote branch, it is probably intended that the branch heads
point to the same commit. Maybe it would be more useful to a
new user to emphasize that the tree contents and history are the
same.
More important, probably, is that this new branch is set up so
that "git pull" merges changes from the corresponding remote
branch. The next paragraph addresses that directly. What the
reader needs to know to begin with is that (1) the initial branch
is your own; if you do not pull, it won't get updated, and that
(2) the initial branch starts out at the same commit as the
upstream.
Thanks to Junio C Hamano for the wording.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Perhaps
>
> ... creates and checks out an initial branch that is forked from the
> cloned repository's currently active branch.
>
> would convey that (1) the initial branch is your own; if you do not pull,
> you won't get updated, and that (2) the initial branch starts out at the
> same commit as the upstream.
That does work better. Explanation stolen for the commit message ---
I hope you don't mind.
Thanks,
Jonathan
Documentation/git-clone.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index aacf4fd..5ebcba1 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -19,8 +19,9 @@ DESCRIPTION
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
-(visible using `git branch -r`), and creates and checks out an initial
-branch equal to the cloned repository's currently active branch.
+(visible using `git branch -r`), and creates and checks out an
+initial branch that is forked from the cloned repository's
+currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* Re: [PATCH 6/9] Documentation: branch: update --merged description
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101858.GF16558@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Update the documentation for --merged and --no-merged to explain
> the meaning of the optional parameter introduced in commit 049716b
> (branch --merged/--no-merged: allow specifying arbitrary commit,
> 2008-07-08).
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
I most often use --no-merged this way:
$ git branch --no-merged pu
to see topics that are queued but not merged anywhere. This is not about
"do not list", but "do show the ones that are not merged", so I reworded
the description of the latter in your patch.
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index aad71dc..e8b32a2 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -134,11 +134,13 @@ start-point is either a local or remote branch.
> --contains <commit>::
> Only list branches which contain the specified commit.
>
> ---merged::
> - Only list branches which are fully contained by HEAD.
> +--merged [<commit>]::
> + Only list branches whose tips are reachable from the
> + specified commit (HEAD if not specified).
>
> ---no-merged::
> - Do not list branches which are fully contained by HEAD.
> +--no-merged [<commit>]::
> + Only list branches whose tips are not reachable from the
> + specified commit (HEAD if not specified).
>
> <branchname>::
> The name of the branch to create or delete.
> --
> 1.6.5.rc1.199.g596ec
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 9/9] racy-git.txt: explain nsec problem in more detail
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009102554.GI16558@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Am I understanding the problem here correctly?
I think so ;-).
^ permalink raw reply
* [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-10 0:59 UTC (permalink / raw)
To: spearce; +Cc: git
When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
_main window_ should be hide the _Push button_ and _Status bar_.
Signed-off-by: Vietor Liu <vietor.liu@gmail.com>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5.rc3
^ permalink raw reply related
* Re: Confusing git pull error message
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Johannes Sixt, John Tapsell, Git List
In-Reply-To: <7vy6nl10fg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Jeff King <peff@peff.net>
>>
>>> Subject: [PATCH] pull: improve advice for unconfigured error case
>>> ...
>> Junio, may I ask what happened to this patch?
>
> Thanks for prodding. Unfortunately I lost track. Will look at it again
> but probably not tonight.
Applied the patch as-is, as it looked quite good.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Erik Faye-Lund, git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <fabb9a1e0910090821n67c86d0kb4eef1b9ff4bdff1@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter)..
Thanks.
^ permalink raw reply
* Re: [PATCHv4] git-log --format: Add %B tag with %B(n) option
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <1253655038-20335-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> diff --git a/pretty.c b/pretty.c
> index f5983f8..dafa8e0 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -605,13 +605,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
> int h1, h2;
>
> /* these are independent of the commit */
> +
> + const char *body = msg + c->body_off;
> + const char *end = NULL;
Unfortunately, c->body_off is not valid until you make a call to
parse_commit_message(). Obviously, body is used only after such a call is
made in the original, so I fixed this initialization into an explicit
assignment after the call.
^ permalink raw reply
* Re: [PATCH v2 (amend)] gitweb: Do not show 'patch' link for merge commits
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jeff King, Junio Hamano
In-Reply-To: <200910091426.44976.jnareb@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v2] git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Joe Perches; +Cc: git, Jay Soffian
In-Reply-To: <1255021406.2056.122.camel@Joe-Laptop.home>
This breaks t9001 since it expects an old (and probably incorrect) RCPT TO:
lines. I fixed them up.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, git, drizzd, peff
In-Reply-To: <ee63ef30910091537i40a8cc68y2513f07c91fb35b@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> I'm away from a computer right now. Junio, if gmail is showing me the
> entirety of your workaround, then no, I don't think that will work.
> Your code will always exit non-zero, but there are cases where 'exit
> 0' is called and a '0' exit status is desired. e.g. when test_done is
> called.
Ah, of course you are right.
^ permalink raw reply
* Re: [PATCH 7/9] Documentation: clarify branch creation
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Sean Estabrooks, git
In-Reply-To: <20091009183408.GB2477@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> So this page should probably point to the what-is-a-branch section of
> the User's Manual. Maybe something like this?
Sounds good. Thanks
> -- %< --
> Subject: Documentation: clarify branch creation
>
> The documentation seems to assume that the starting point for a new
> branch is the tip of an existing (ordinary) branch, but that is not
> the most common case. More often, "git branch" is used to begin
> a branch from a remote-tracking branch, a tag, or an interesting
> commit (e.g. origin/pu^2). Clarify the language so it can apply
> to these cases. Thanks to Sean Estabrooks for the wording.
>
> Also add a pointer to the user's manual for the bewildered.
> ...
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Kirill Smelkov, Ted Pavlic, git
In-Reply-To: <20091009161443.GX9261@spearce.org>
Thanks for this, and all the other acks and patches.
^ permalink raw reply
* Re: [PATCH 0/9] Documentation tweaks
From: Junio C Hamano @ 2009-10-10 0:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101400.GA16549@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Here are some small documentation patches that have been sitting in
> my tree for a while. Most important is the first one, which makes it
> easier to find the appropriate options for building documentation
> from source on a new machine.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn: hide find_parent_branch output in double quiet mode
From: Eric Wong @ 2009-10-10 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Simon Arlott
In-Reply-To: <b01cac406b93d5c67e3ae2e9a7aaa498a52dd9fc@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid>
Simon Arlott <simon@fire.lp0.eu> wrote:
> Hide find_parent_branch logging when -qq is specified.
> This eliminates more unnecessary output when run from cron, e.g.:
>
> Found possible branch point:
> http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/trunk =>
> http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/branches/authz,
> 1919
> Found branch parent: (authz) ea061d76aea985dc0208d36fa5e0b2249b698557
> Following parent with do_switch
> Successfully followed parent
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Thanks Simon,
Acked-by: Eric Wong <normalperson@yhbt.net>
and pushed out to git://git.bogomips.org/git-svn
--
Eric Wong
^ permalink raw reply
* git svn with non-standard svn layout
From: Fabian Molder @ 2009-10-09 22:24 UTC (permalink / raw)
To: git
Hello,
- want to use git inside an huge SVN project
--> so git-svn could do the job ..
- I struggle with two things:
A) - the SVN project has an non-standard layout
B) - want to have (several) git's for just the (few) peaces I work on
for A)
======
- svn layout looks like this (simplified):
- trunk (not really used, all interesting work in branches)
- branches
- r1.2
- development
- integration
- r1.3
- development
- integration
...
- inside development and integration is:
- xapplication1
- xapplication2
- xapplication3
...
- aa
-bb
-cc
- zapplication1
- zapplication2
- zapplication3
...
- I created an simplified svn test (from scratch; import/repo/workdir)
via this bash-script: http://pastebin.ca/1608231
for B)
======
- the svn repo is very huge, but I'm only interested in these dirs:
xapplication2/
aa/bb/cc/zapplication1
- my objectives:
- have several local git's, just the ones I need:
--> xapplication2/.git
--> aa/bb/cc/zapplication1/.git
I tried to use "git config svn-remote.svn.branches" to do this,
please see in function "do_git_svn" in bash-script - but no success
any hints appreciated
regards,
Fabian
^ permalink raw reply
* Re: [PATCH] git-svn: hide find_parent_branch output in double quiet mode
From: Junio C Hamano @ 2009-10-10 7:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Simon Arlott
In-Reply-To: <20091010010843.GA30258@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Thanks Simon,
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> and pushed out to git://git.bogomips.org/git-svn
Thanks; you seem to have rebased the history in this repository, and
merging from you will duplicate Alexander's "Avoid spurious errors", which
I already pulled, so I'll cherry pick this one from your tree.
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Peter Baumann @ 2009-10-10 8:47 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Howard Miller, git
In-Reply-To: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com>
On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
> On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
> > I'm missing the point here though. Where/when do I actually add the
> > new pristine code? If I checkout, as you suggest, my initial commit I
> > just have (say) v1.0 of the vendor's code. I can't just copy (say)
> > version 1.2 on top as the files probably won't match one-one.
> >
> > Sorry - I'm probably completely failing to understand.
>
> Try this:
>
> cd mygitproject
> git rm -rf .
> cp -a /tmp/wherever/vendor-1.2/. .
> git add .
This won't commit deleted files from v1.0 - v1.2. Use git add -A to stage all
modified and deleted files for the next commit.
> git commit
>
> Don't worry, git won't double-store files that are identical between
> the old 1.0 and new 1.2 versions.
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Howard Miller @ 2009-10-10 8:58 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com>
2009/10/9 Avery Pennarun <apenwarr@gmail.com>:
> On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> I'm missing the point here though. Where/when do I actually add the
>> new pristine code? If I checkout, as you suggest, my initial commit I
>> just have (say) v1.0 of the vendor's code. I can't just copy (say)
>> version 1.2 on top as the files probably won't match one-one.
>>
>> Sorry - I'm probably completely failing to understand.
>
> Try this:
>
> cd mygitproject
> git rm -rf .
> cp -a /tmp/wherever/vendor-1.2/. .
> git add .
> git commit
>
> Don't worry, git won't double-store files that are identical between
> the old 1.0 and new 1.2 versions.
>
> Avery
>
Adding Unix ignorance to git ignorance... doesn't that delete the .git
directory too?
I don't have cp -a (on a mac) but, IIRC, that's just -rp or somesuch?
But I see, basic idea is to ditch the files, replace them with the new
vendor release a commit. I did think of that but it seemed too simple
:-)
Cheers.
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Björn Steinbrink @ 2009-10-10 9:00 UTC (permalink / raw)
To: Peter Baumann; +Cc: Avery Pennarun, Howard Miller, git
In-Reply-To: <20091010084742.GB17220@m62s10.vlinux.de>
On 2009.10.10 10:47:42 +0200, Peter Baumann wrote:
> On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
> > Try this:
> >
> > cd mygitproject
> > git rm -rf .
> > cp -a /tmp/wherever/vendor-1.2/. .
> > git add .
>
> This won't commit deleted files from v1.0 - v1.2. Use git add -A to stage all
> modified and deleted files for the next commit.
It will, the "git rm" already cleans the index.
Björn
^ 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