Re: [git-users] Using git-svn to follow a branch: detached

[Daniel P. Wright]

Chris Stankevitz ( 9月25日（火）) >>
> Hello,
> 
> Please consider the attached steps which create an SVN repo and setup git 
> to track it.
> 
> 1. Why do "local-newbranch" and "master" not share a common ancestor?

I think the reason is that the method you've used to add the branch to
git-svn treats that branch as a separate remote repository.  git-svn
doesn't realise it should be treating it as a branch and so doesn't try
and trace back beyond the first commit to that branch to find the
parent.

> 
> 2. How do I make them share a common ancestor?

Add the svn branches directory to the branches parameter for the
existing "svn" remote, rather than adding a new remote.  The recommended
way of doing this is to pass --branches or --stdlayout on clone/init,
but if this is impossible, you could try modifying your sequence of
steps thus:

-- >8 --
--- a/steps.txt   2012-09-26 12:09:33.331806620 +0900
+++ b/steps.txt   2012-09-26 12:08:34.383604192 +0900
@@ -23,9 +23,9 @@

 # Update the GIT repo to follow the SVN branch
 cd ${ROOT}/repo.git
-git config --add svn-remote.newbranch.url 
file://${ROOT}/repo.svn/branches/newbranch
-git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch
-git svn fetch newbranch
+git config --add svn-remote.svn.branches "branches/*:refs/remotes/*"
+rm .git/svn/.metadata
+git svn fetch
 git checkout -b local-newbranch -t newbranch
 git svn rebase newbranch
 gitk --all
-- 8< --

Note the removal of the ".git/svn/.metadata" file.  When I tried it
without doing that, git-svn didn't notice the new branch settings and
didn't try to fetch the branches.  deleting this file forces git-svn to
regenerate it with the latest settings.

> 
> 3. Assuming (2) is possible, will I be able to rebase "master" changes onto 
> "local-newbranch"

You need to be careful about this, as you can't rewrite history on the
svn side.  Essentially svn has no "rebase", only "merge".

What this means is you can use all the git functionality on local
branches, as far back as the last svn commit.  As soon as you reach
something that has been committed to svn, though, you have to limit
yourself to svn functionality.

Taking your example, here is the state at the end of steps.txt (with the
patch above applied).  I will mark svn branches in caps, and git
branches in lower-case.

--A--BTRUNK, master
  \
   -C NEWBRANCH, local-newbranch

Say you work on local-newbranch, and other people work on the trunk.
If you do "git svn pull" on master the graph might look like this
(commits which have been committed to SVN in caps, those which only
exist in your local git repo in lower case):

master, TRUNK
  |
  v
--A--B--F--G--H
  \
   -C--d--e
^ ^
| |
 NEWBRANCH   local-newbranch

In this case, commits D and E only exist in git, but everything else has
already been committed to svn.  If you want to have access to commits
F-H on the local-newbranch branch, you will need to do it the svn way;
ie by creating a merge commit on NEWBRANCH which pulls in those changes.
You can do that by passing the --squash option to "git merge", thus:-

$ git checkout local-newbranch
$ git merge --squash trunk

Resulting in:

master, TRUNK
  |
  v
--A--B--F--G--H
  \
   -C--d--e--m
^^
||
 NEWBRANCH  local-newbranch

Here M is a single commit containing all of the changes held in commits
F-H.  Subversion doesn't support the git concept of "multiple parent
commits", so you lose that element of merge history on the graph.  The
merge is marked as having taken place after D and E were written in the
history.  Since you said you wanted to rebase, perhaps that isn't what
you want; you might want the merge to have been performed before your
changes.  You can accomplish that, provided you haven't dcommitted
local-newbranch:-

$ git checkout -b newbranch-merge newbranch
$ git merge --squash trunk
$ git rebase newbranch-merge local-newbranch
$ git branch -D newbranch-merge

master, TRUNK
  |
  v
--A--B--F--G--H
  \
   -C--m--d--e
^^
||
 NEWBRANCH  local-newbranch

Since newbranch-merge hadn't been committed to svn yet, the rebase was
possible and the merge will go down in history as having happened before
the changes on local-newbranch.

> 4. Assuming (3) is possible, will I be able to dcommit "local-newbranch"?

Running a "git svn dcommit" while "local-newbranch" is checked out
should update the newbranch branch on the SVN side, and running it on
"master" should update "trunk".

I would only recommend doing all this if you need to share these
branches with other users of svn, though.  Since branching is so easy
and natural in git, people tend to find themselves making a lot of
local, short-liv

Re: [git-users] Forcing a "push" from one branch to another

[PJ Weisberg]

On Tue, Sep 25, 2012 at 12:01 PM, Chris Stankevitz
 wrote:

> At this point, I'd be happy with whichever method will be easiest for you to
> type on this list.  Currently I am using the series of laborious steps in my
> original post.

I would just do this:

git checkout b# Switch to the branch we want to change
git reset --hard a# Make 'b' point where 'a' points, forcing
all files to match 'a'
git reset --soft HEAD@{1} # Move the 'b' pointer back, but leave the
files as they were
git commit# Index and working tree are the same as in 'a'

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Forcing a "push" from one branch to another

[Philip Oakley]

From: Chris Stankevitz 
  To: git-users@googlegroups.com 
  Cc: Chris Stankevitz ; Philip Oakley 
  Sent: Tuesday, September 25, 2012 8:01 PM
  Subject: Re: [git-users] Forcing a "push" from one branch to another



  On Tuesday, September 25, 2012 11:48:25 AM UTC-7, Philip Oakley wrote:
Do you mean you want Branch 'b' drop its old line of development and become 
the same as Branch 'a'.
Or you want Branch 'b' to gain a fresh commit who's content is identical to 
that on the tip of Branch 'a', but it would have a different history?


  Philip,


  Thank you for your help!


  My intention is for branch 'b' to gain a single commit whose diffs result in 
branch 'b' looking just like 'a'.  I attempted to say this by describing a 
series of laborious steps in my original post.

There are a few different methods


  At this point, I'd be happy with whichever method will be easiest for you to 
type on this list.  Currently I am using the series of laborious steps in my 
original post.

At the plumbing level you can simply create a commit on 'b' that simply 
uses the top tree from 'a', then do a `reset --hard` to make your worktree 
match that commit.


  Unfortunately I am not skilled enough to translate this sentence into a 
series of git commands.  Could you please either refer me to the documentation 
for the "top tree" command (as you call it) or just type out the commands that 
might do what I want?
The place to look for those internal details is:
http://git-scm.com/book/en/Git-Internals-Git-Objects

Using it as a template we see that you should be able to use:
 
The master^{tree} syntax specifies the tree object that is pointed to by the 
last commit on yourmaster branch.

and

To create a commit object, you call commit-tree and specify a single tree SHA-1 
and which commit objects, if any, directly preceded it. Start with the first 
tree you wrote:

$ echo 'first commit' | git commit-tree d8329fyou'll write the other two commit 
objects, each referencing the commit that came directly before it:

$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3

You already have the tree on branch 'A', so it should be as simple as:

git update-ref refs/heads/B $(echo 'Copied from Branch A' | git commit-tree 
A^{tree} -p B)

Which is three steps in one:
1.   git commit-tree A^{tree} -p B# create the commit with branch B as the 
parent
2.   echo 'Copied from Branch A' |  # give it a message
3.   git update-ref refs/heads/B $(...)  # and update Branch B with the answer 
(sha1) from the commit created at 1.

I tested this on a simple dummy repo and it worked while I was on branch A. 

And Thanks for making me look properly ;-)


  Thank you again,


  Chris

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Forcing a "push" from one branch to another

[Chris Stankevitz]

On Tuesday, September 25, 2012 11:48:25 AM UTC-7, Philip Oakley wrote:
>
> Do you mean you want Branch 'b' drop its old line of development and 
> become the same as Branch 'a'.
> Or you want Branch 'b' to gain a fresh commit who's content is identical 
> to that on the tip of Branch 'a', but it would have a different history?
>

Philip,

Thank you for your help!

My intention is for branch 'b' to gain a single commit whose diffs result 
in branch 'b' looking just like 'a'.  I attempted to say this by describing 
a series of laborious steps in my original post.
  

> There are a few different methods
>

At this point, I'd be happy with whichever method will be easiest for you 
to type on this list.  Currently I am using the series of laborious steps 
in my original post.
 

> At the plumbing level you can simply create a commit on 'b' that simply 
> uses the top tree from 'a', then do a `reset --hard` to make your worktree 
> match that commit.
>

Unfortunately I am not skilled enough to translate this sentence into a 
series of git commands.  Could you please either refer me to the 
documentation for the "top tree" command (as you call it) or just type out 
the commands that might do what I want?

Thank you again,

Chris

>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/5T9mRBmV7nQJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Forcing a "push" from one branch to another

[Philip Oakley]

  From: Chris Stankevitz 
  To: git-users@googlegroups.com 
  Sent: Tuesday, September 25, 2012 7:31 PM
  Subject: [git-users] Forcing a "push" from one branch to another


  Hello,


  If possible please humor me and attempt to answer this question:


  How do I make "b" look exactly like "a" using one commit?  Here is the manual 
approach:
Do you mean you want Branch 'b' drop its old line of development and become the 
same as Branch 'a'.
Or you want Branch 'b' to gain a fresh commit who's content is identical to 
that on the tip of Branch 'a', but it would have a different history?

In both case the top commit of b is the same, but the two variants would have 
different history.

There are a few different methods, and which one to use depends on what level 
of sophistication or plumbing commands you want.
At the plumbing level you can simply create a commit on 'b' that simply uses 
the top tree from 'a', then do a `reset --hard` to make your worktree match 
that commit. 


  - git checkout a.  Recursively copy all files in to /tmp
  - git checkout b
  - recursively copy all files from /tmp into cwd
  - git add [as appropriate]
  - git rm any files from cwd that are not in /tmp
  - git commit -am "Made b look just like a"



  Thank you,


  Chris

  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/z72DnZzvWyMJ.
  To post to this group, send email to git-users@googlegroups.com.
  To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

  No virus found in this message.
  Checked by AVG - www.avg.com
  Version: 2012.0.2221 / Virus Database: 2441/5290 - Release Date: 09/24/12

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] Forcing a "push" from one branch to another

[Chris Stankevitz]

Hello,

If possible please humor me and attempt to answer this question:

How do I make "b" look exactly like "a" using one commit?  Here is the 
manual approach:

- git checkout a.  Recursively copy all files in to /tmp
- git checkout b
- recursively copy all files from /tmp into cwd
- git add [as appropriate]
- git rm any files from cwd that are not in /tmp
- git commit -am "Made b look just like a"

Thank you,

Chris

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/z72DnZzvWyMJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] a generalization of git blame

[Konstantin Khomoutov]

On Tue, 25 Sep 2012 10:14:03 -0700 (PDT)
Xiaozhu Meng  wrote:

[...]
> PS: I was trying to send an email to mailing list
> git at vger.kernel.org. But it always replied with 
[...]
> The error that the other server returned was: 550 550 5.7.1
> Content-Policy reject msg: The message contains HTML subpart,
> therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is
> accepted.! BF:; S1753454Ab2IYRLL (state 17).

This one.  vger.kernel.org does not accept mails with HTML crap embedded
in them, and for good.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] a generalization of git blame

[Xiaozhu Meng]

Hi,

I have been developing my git tool (based on the git internal API) that can 
find out all the commits that have changed a line for better authorship. 

The reason is for my binary code authorship research, I use machine 
learning to classify code authorship. To produce training data, I start 
with a source code repository with well-known author labels for each line 
and then compiling the project into binary. So, I am able to know the 
authorship for binary code and then apply some machine learning techniques. 

To get ground truth of authorship for each line, I start with git-blame. 
But later I find this is not sufficient because the last commit may only 
add comments or may only change a small part of the line, so that I 
shouldn't attribute the line of code to the last author. Of course, there 
must be some debates on who can be the representative of a line of code. So 
what I would like to do is find out all the commits that have ever changed 
a line, then I can try different approaches to summarize over all these 
commits to produce my final authorship label (or even tuple). 

I was wondering whether there have been similar debates over accurate 
authorship in this community before and whether there may be other people 
interested in this work. 

PS: I was trying to send an email to mailing list g...@vger.kernel.org. But 
it always replied with 
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient 
domain. We recommend contacting the other email provider for further 
information about the cause of this error. The error that the other server 
returned was: 550 550 5.7.1 Content-Policy reject msg: The message contains 
HTML subpart, therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN 
is accepted.! BF:; S1753454Ab2IYRLL (state 17).

Thanks

Xiaozhu

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/4yuBELlc8lUJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] Using git-svn to follow a branch: detached

[Chris Stankevitz]

Hello,

Please consider the attached steps which create an SVN repo and setup git 
to track it.

1. Why do "local-newbranch" and "master" not share a common ancestor?

2. How do I make them share a common ancestor?

3. Assuming (2) is possible, will I be able to rebase "master" changes onto 
"local-newbranch"

4. Assuming (3) is possible, will I be able to dcommit "local-newbranch"?

Thank you,

Chris

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/en82rDDjUz8J.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

# Init and create SVN repo
ROOT=/home/cstankevitz/Delete
cd ${ROOT}
rm -rf repo.git/ repo.svn svn-repo-checkout/
svnadmin create repo.svn
svn checkout file://${ROOT}/repo.svn svn-repo-checkout
cd ${ROOT}/svn-repo-checkout/
mkdir trunk
echo "line 1" > trunk/a.txt
svn add trunk/ branches/
svn commit -m "Initial commit"
echo "line 2" >> trunk/a.txt
svn commit -m "Added a second line"

# Create a GIT repo that follows the SVN trunk
cd ${ROOT}
git svn clone file://${ROOT}/repo.svn/ --trunk=file://${ROOT}/repo.svn/trunk/ 
repo.git

# Create the SVN branch
cd ${ROOT}/svn-repo-checkout
svn cp --parents file://${ROOT}/repo.svn/trunk/ 
file://${ROOT}/repo.svn/branches/newbranch -m "Created a branch newbranch"
svn up

# Update the GIT repo to follow the SVN branch
cd ${ROOT}/repo.git
git config --add svn-remote.newbranch.url 
file://${ROOT}/repo.svn/branches/newbranch
git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch
git svn fetch newbranch
git checkout -b local-newbranch -t newbranch
git svn rebase newbranch
gitk --all

Re: [git-users] Suitable GIT feature for common artifacts

[Gadget/Steve]

On 25/09/2012 1:35 PM, Anand Krishnan wrote:
> Hi
> Our project has a requirement: We are developing project in c++ for
> long time and now we started development in java too. Both our c++ and
> java source code is residing in different repo paths. There are some
> artifacts which are common for both c++ and Java. As of now we are
> duplicating those in both the repositories. Is there a way to avoid
> this duplication by keeping the common artifact in a single place and
> referring/using them in both c++ and java? Any suggestions?
> Thank you
> Anand Krishnan
> -- 
> You received this message because you are subscribed to the Google
> Groups "Git for human beings" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/git-users/-/b2bNxbBIiJsJ.
> To post to this group, send email to git-users@googlegroups.com.
> To unsubscribe from this group, send email to
> git-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/git-users?hl=en.
Anand,

I think that you need to read the section on sub-modules in the git
manuals, git help submodule should display it for you.

Gadget/Steve

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] Suitable GIT feature for common artifacts

[Anand Krishnan]

Hi
Our project has a requirement: We are developing project in c++ for long 
time and now we started development in java too. Both our c++ and java 
source code is residing in different repo paths. There are some artifacts 
which are common for both c++ and Java. As of now we are duplicating those 
in both the repositories. Is there a way to avoid this duplication by 
keeping the common artifact in a single place and referring/using them in 
both c++ and java? Any suggestions?
Thank you
Anand Krishnan

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/b2bNxbBIiJsJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] avoid pulling binaries

[Konstantin Khomoutov]

On Tue, 25 Sep 2012 02:11:14 -0700 (PDT)
Angelo Borsotti  wrote:

> Suppose I have a private repository and a public one. I develop using
> my private repository, and at significant steps I do a commit in
> which I save all, sources] and binaries. The reason for saving
> binaries is to allow to recover a previously committed version
> without having then to rebuild all binaries. When I have completed
> the development of a feature, I push it to a public repository, one
> that is accessed by an integrator, that takes my contributes and
> other developers' as well, and integrates all of them. After having
> pulled all the contributed, the integrator always rebuilds the
> binaries. Therefore, there is no need for me to push binaries from my
> private repository to the public one, and for him to pull them. Is
> there a way in git to avoid to push and pull binaries in this
> workflow?

One way I can imagine, is using `git filter-branch` [1] with
its --three-filter option to drop the binaries matching certain
patttern from a branch which is ready to be proposed upstream.
Basically, when your feature branch is ready, you "clone" it (by means
of saying `git checkout -b newbranch thatbranch`) and then run
`git filter-branch --tree-filter ...` on the new branch to re-write it
dropping all the cruft from the commits.  Then you check if it looks OK,
propose it to upstream or replace the original branch with its
rewritten copy.

One other approach I might imagine is juggling with two branches -- one
"clean", on which you just do the regular work and commit only the
relevant (that is, source) files, and another one -- a "dirty" branch,
which you check out from time to time, merge the "clean" branch in and
then commit the built cruft.  That is, you'll do continuous periodical
re-integration of the "clean" branch to the "dirty" branch with
commits of the binaries after each reintegration.

You can also have it backwards: do normal work on a "dirty" branch" but
implement a simple policy about what you commit: commits touching
relevant files must be done separately from the commits touching
binary cruft (these can even be marked by something like "[binary]"
prefix in their commit messages).  You then periodically switch to a
"clean" branch and perform cherry-picks [2] from the "dirty" branch,
picking only the "clean" commits.

1. http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
2. http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] avoid pulling binaries

[Daniel P. Wright]

The SHA-1 hash which identifies each commit in git is generated from the
state of the tree at that point and thus having a version of that commit
with binaries and a version without results in -- as far as git is
concerned -- entirely separate commits.  It is really useful when the
same commit maps to the same SHA-1 on everyone's copy of the repo, so in
general I would say this is a bad idea.

What I would possibly do in your situation is to have a separate,
binaries-only repository.  You could put it in a subdirectory of your
main repo if you liked, and stop it spamming `git status` output by
adding it to .git/info/excludes.  Then, you could write a post-commit
hook which could automatically commit the binaries into the binaries
repo, perhaps inserting the commit hash on the main repository which
that binary corresponds to in order to help you map them later on.

There may be a better way around it, but that's probably how I'd go
about it.

 -- Dani.

Angelo Borsotti (Tue, Sep 25, 2012 at 02:11:14AM -0700) >>
> Suppose I have a private repository and a public one. I develop using my 
> private repository, and at significant steps I do a commit in which I save 
> all, sources] and binaries. The reason for saving binaries is to allow to 
> recover a previously committed version without having then to rebuild all 
> binaries. When I have completed the development of a feature, I push it to 
> a public repository, one that is accessed by an integrator, that takes my 
> contributes and other developers' as well, and integrates all of them. 
> After having pulled all the contributed, the integrator always rebuilds the 
> binaries. Therefore, there is no need for me to push binaries from my 
> private repository to the public one, and for him to pull them. Is there a 
> way in git to avoid to push and pull binaries in this workflow?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Git for human beings" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/git-users/-/txZDxAw_laEJ.
> To post to this group, send email to git-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> git-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/git-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] avoid pulling binaries

[Angelo Borsotti]

Suppose I have a private repository and a public one. I develop using my 
private repository, and at significant steps I do a commit in which I save 
all, sources] and binaries. The reason for saving binaries is to allow to 
recover a previously committed version without having then to rebuild all 
binaries. When I have completed the development of a feature, I push it to 
a public repository, one that is accessed by an integrator, that takes my 
contributes and other developers' as well, and integrates all of them. 
After having pulled all the contributed, the integrator always rebuilds the 
binaries. Therefore, there is no need for me to push binaries from my 
private repository to the public one, and for him to pull them. Is there a 
way in git to avoid to push and pull binaries in this workflow?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/txZDxAw_laEJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.