[git-users] Re: Looking for C# Git library

[P Rouleau]

Personnaly, I use a pre-build script to update the version before the 
compilation. The version itself is not committed back to the project since 
it is generated from the repository and it would modify the output of the 
pre-build script.

In git, we can use "git describe" to generate a version. Basically, it 
count the number of commits since a tag matching some regex. See 
https://www.kernel.org/pub/software/scm/git/docs/git-describe.html

You can look how git use it itself:
https://github.com/git/git/blob/master/GIT-VERSION-GEN


On Sunday, December 16, 2012 12:00:53 PM UTC-5, Michael wrote:
>
> Hello,
>
> I am writing a tool to keep version numbers synced up within our projects, 
> bump AssemblyInfo versions, installer versions, and potentially also commit 
> / push back to repository for safe keeping.
>
> I've written Subversion-based solutions before, there's fairly strong 
> support for Svn, I'm reading also for Mercurial (Hg), along these lines.
>
> Is there anything comparable for Git that I can pull from NuGet or some 
> other source?
>
> Regards,
>
> Michael
>

-- 

[git-users] Re: git hook with version string

[P Rouleau]

Would it be fine if the "version file" was only created in the working 
directory and not push on the server? And instead of using the date of the 
last checkout it was the date of the last commit? You use the term "push" 
in your reply but I get the felling it could be replaced with "written".

I suggest a simple script, ie update_version.sh, or maybe you already have 
a script to generate the documentation, so you can add the commands in it.

You can have the name of the current branch with this command:
git symbolic-ref HEAD 2>/dev/null

and the date of the last commit with:
git log -n1 --tformat="%cd"

If you absolutely want the checkout date, I do not see how it can be made. 
I though about cheating and use the date of .git/HEAD but it do not change 
on a pull. It only change on checkout.

git offers the command "describe" who can be used to generate a version 
string, but it needs a tag and it is not confined to one branch. I do not 
think it is want you want, but I mention it just in case. Said you have a 
tag v1.0 and 13 commits since then, describe will returns v1.0.13.


On Sunday, October 28, 2012 8:57:37 AM UTC-4, Philipp Kraus wrote:
>
> Thanks for your answer
>
> Am Sonntag, 28. Oktober 2012 12:50:15 UTC+1 schrieb Thomas Ferris 
> Nicolaisen:
>>
>> This reminds me of a similar but related question: How can we get SVN's 
>> keyword substitution in Git.
>>
>> The short answer is: you can't. But when you think about it, this file 
>> you want to create is actually just duplicating information which exists 
>> elsewhere. The right way to go about it is to find some step in your 
>> build/deployment mechanism, and create this file on the fly. We build our 
>> products using Maven and Gradle, and both these build-tools have places 
>> where we can hook in and generate a version.txt file with interesting 
>> information from Git.
>>
>>
> I think it is not a real keyword subsitution, because Git does not store 
> any information about numbering or anything else. In my depolyment process 
> it should be used for creating the documentation, so I need the "date of 
> the checkout" and the branch / tag name. This information are in the repo 
> all time, so I need only to push them into a code file on the checkout.
>
> Another way is to create it on checkout, as suggested in the git-scm.combook:
>>
>> From http://git-scm.com/book/ch7-2.html:
>>
>> SVN- or CVS-style keyword expansion is often requested by developers used 
>> to those systems. The main problem with this in Git is that you can’t 
>> modify a file with information about the commit after you’ve committed, 
>> because Git checksums the file first. However, you can inject text into a 
>> file when it’s checked out and remove it again before it’s added to a 
>> commit. Git attributes offers you two ways to do this.[...]
>>
>>
> I have read this chapter and I don't want modify the file on commiting. I 
> have a central repo in which each local repo is pushed, the documentation 
> is created on the server. I have create a post-received hook for doing 
> this, but I would like to add some information of the actually code before 
> the documentation is created
>

-- 
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/-/QPMYhfRo_qIJ.
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] Process of branching

[P Rouleau]

And Thanks to you for your feed-back.

On Monday, September 10, 2012 4:18:38 PM UTC-4, Patrick wrote:
>
> Now that I have done both methods and I confirmed that the state of the 
> local repo is pretty much the same, either method will work fine for me.  I 
> have done this on my working local repo (using way 2) and even pushed it up 
> to the remote just to test it completely.  The first method moves (renames) 
> the branch master to parser and then recreates and connects to the remote 
> master branch.  The second creates the parser branch and then does a hard 
> reset of the local master branch to the remote master branch.  If I'd have 
> known that git branch  takes all current local commits 
> into account (which now that I think about it makes sense but I was 
> thinking about it from a remote point of view...) then I might have been 
> able to come up either process.  It might have been just a matter of 
> creating the parser branch and then look at the histories of master and 
> parser.  
>
> Just have to make sure you local is all checked in or use stash to pop it 
> in later.  
>
> Thanks RubyRedRick and P Rouleau for your ideas!
>
> On Monday, September 10, 2012 10:31:26 AM UTC-7, Patrick wrote:
>>
>> ... 
>>
> # way 1
>> 1. git branch -m master parser
>> 2. git fetch origin
>> 3. git branch --track master origin/master
>> 4. git checkout parser
>>
>> # way 2
>> 1. git branch parser
>> 2. git fetch
>> 3. git reset --hard origin/master
>> 4. git checkout parser
>> ...
>>
>

-- 
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/-/VQ7eYIknrQEJ.
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] Process of branching

[P Rouleau]

Yes I know the OP already made 12 commits. Like I say in my explication: 
"First we create a feature_branch_name on the tip of the local master, 
since it is ahead of the origin's one." The new feature_branch will include 
these 12 commits. I included the stash step because I do not know the 
status of his working directory. 

The OP also pointed out that his remote is working fine with GitHub, so his 
master branch should already track the remote master branch. We only have 
to reset the local master branch to the tip of the remote one.


On Monday, September 10, 2012 8:14:59 AM UTC-4, RubyRedRick wrote:
>
>
> On Mon, Sep 10, 2012 at 7:25 AM, P Rouleau 
> > wrote:
>
>> Your steps seem to imply he must use the same new_branch_name in 1) and 
>> in 5). We can simplify this by avoiding renaming the master branch. I 
>> believe it is already tracking the github's origin.
>>
>> So the steps can be rewritten like this:
>> 1) git branch feature_branch_name
>> 2) git stash
>> 3) git fetch
>> 4) git reset --hard origin/master
>> 5) git push origin feature_branch_name
>> 6) git co feature_branch_name
>> 7) git stash pop
>>
>> First we create a feature_branch_name on the tip of the local master, 
>> since it is ahead of the origin's one.
>> Then we stash the local changes and we reset the master branch to the 
>> same commit than the origin (3 & 4). The fetch is required when 
>> many developers push to the same remote. (Always use reset with care, since 
>> we can loose work. In doubt, create a temporarily branch as a safety net.)
>> Then we create the feature branch on the remote (5). It does not need to 
>> be the current branch.
>> Then we switch to the feature branch (6) and we recover the stashed 
>> modifications to continue the work on the feature branch. We can skip 5 if 
>> we do not want to publish it now and want to add more commits before. 
>>
>> After that, we simply push to origin to update it with the new commits, 
>> ie: git push. If we commited on many tracked branches but want to push only 
>> one, we have to specify the branch name, ie: git push origin branch_name.
>>
>>
> The problem is he said that he already made 12 commits to master in his 
> local repo.  So that stash will only save any uncommitted changes since the 
> last commit.
>
> I believe that my suggestion will leave him in the same state as if he had 
> started the branch at the 'right' time in the past.
>
> -- 
> Rick DeNatale
>
> Google+: +Rick DeNatale <https://plus.google.com/10254117893106790>
> Blog: http://talklikeaduck.denhaven2.com/
> Github: http://github.com/rubyredrick
> Twitter: @RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
>

-- 
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/-/Q5xhKhi_46UJ.
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] Process of branching

[P Rouleau]

Your steps seem to imply he must use the same new_branch_name in 1) and in 
5). We can simplify this by avoiding renaming the master branch. I believe 
it is already tracking the github's origin.

So the steps can be rewritten like this:
1) git branch feature_branch_name
2) git stash
3) git fetch
4) git reset --hard origin/master
5) git push origin feature_branch_name
6) git co feature_branch_name
7) git stash pop

First we create a feature_branch_name on the tip of the local master, since 
it is ahead of the origin's one.
Then we stash the local changes and we reset the master branch to the same 
commit than the origin (3 & 4). The fetch is required when 
many developers push to the same remote. (Always use reset with care, since 
we can loose work. In doubt, create a temporarily branch as a safety net.)
Then we create the feature branch on the remote (5). It does not need to be 
the current branch.
Then we switch to the feature branch (6) and we recover the stashed 
modifications to continue the work on the feature branch. We can skip 5 if 
we do not want to publish it now and want to add more commits before. 

After that, we simply push to origin to update it with the new commits, ie: 
git push. If we commited on many tracked branches but want to push only 
one, we have to specify the branch name, ie: git push origin branch_name.


On Sunday, September 9, 2012 3:04:46 PM UTC-4, RubyRedRick wrote:
>
> On Sun, Sep 9, 2012 at 12:53 PM, Patrick  >wrote:
>
>> Local Repo
>> 12 commits ahead of origin/master
>>
>> How do I take those 12 commits and pull them off on a branch?
>>
>
> I haven't tried this completely but since you haven't pushed the branch,I 
> think something like
>
> 1) git branch -m master new_branch_name
> 2) git fetch origin
> 3) git branch --track master origin/master
> 4) git checkout master
> 5) git branch -f new_branch_name master
> 6) git config branch.new_branch_namel.merge refs/heads/new_branch_name
> 7) git checkout new_branch_name
> 8) git push origin new_branch_name:refs/heads/new_branch_name
>
>
> First we give the local master branch the new name (1).
> Then we make sure we have the latest changes from master (2).
> Then we create a new local master branch which tracks the remote master 
> (3).
> We then checkout the master branch(4) to allow us to set the starting 
> point of the new branch(5)
> Next we tell the new branch to merge changes to the right branch on origin 
> (6) Note this remote branch won't exist yet.
> Finally we checkout the new local branch(7) and push it to the remote repo.
>
> -- 
> Rick DeNatale
>
> Google+: +Rick DeNatale 
> Blog: http://talklikeaduck.denhaven2.com/
> Github: http://github.com/rubyredrick
> Twitter: @RickDeNatale
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale
> LinkedIn: http://www.linkedin.com/in/rickdenatale
>  

-- 
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/-/EaUut-bfetkJ.
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] Re: Creating an initial git repository

[P Rouleau]

I suggest to read http://hginit.org.

The first section title is "Subversion Re-education". You can also read the 
rest; mercurial and git are very similar.

In Subversion, tags and branhes are really just specially named 
directories. In git, they are two different things. It does not take long 
to fall in love with them as they work better than in Subversion. (ie: they 
do not change the repository revision number just because you create a tag 
or a branch)

To begin with git, start with a very simple workflow. The book git-pro 
gives very good starting points. In my team (2 to 5 developers), we are 
still using a single branch during development (named dev) who exist only 
on the developer PC and we rebase it on the tip of master before pushing 
the commits on the server. That way, the history is made of a single line. 
We are pulling every day to reduce the risk of conflicts during the pull 
and we push as soon the code is stable. If you work directly on the master 
branch, you will get parallel lines each time you do a pull. It is not a 
problem per-see, but you may find it ugly and confusing at first.

For the release, we use tags like "vX.Y.Z". If we have to fix something in 
a specific version, we create a branch named "bX.Y". We use a different 
name to avoid confusion. If you choose to use feature branches, give them 
meaningful name. I suggest to look at the git history itself to see one 
example of heavily branched development 
(https://github.com/gitster/git.git).  


P.Rouleau

On Thursday, July 19, 2012 12:14:17 AM UTC-4, PeterSteele wrote:
>
> We're starting a new project and will be using git for our source code 
> management system. We're all previous SVN users and have not used git 
> before. I'm sure this question has been asked many times before and I 
> apologize for asking it again: What is the convention for setting up a new 
> project in git? In SVN, the convention is to call the main branch "trunk" 
> and branches are created under a directory called "branches" (e.g. 
> branches/1.0 for the first release branch). There is also a "tags" 
> directory used for labeling key snapshots of the trunk (or even release 
> branches), without actually creating a branch.
>
> From what I've read, it appears that the convention is to call the main 
> trunk "master". Is this correct? What's the convention for release branches 
> and tags? Are there any other git specific repository conventions that we 
> should follow?
>
>

-- 
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/-/Io_FbPaahQ4J.
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] Re: Applying licence (eg. GPL) to Git history

[P Rouleau]

Hi,

To add the LICENSE file in the root folder, it may be easier to commit the 
file to a new orphan branch (see git checkout --help) or you can checkout 
the first commit (with checkout -b) and amend it to add the LICENSE file. 
You may want to force a specific date to that commit so it appears to 
always been there. Then rebase the master branch on it.

To add the header license to every files, you can use git filter-branch. 
You have to write a rule to detect new files and add the header license. 
filter-branch is a bit hard to grasp, but if the history is long and have 
many files, it will pay off.

P.Rouleau

On Thursday, June 14, 2012 6:14:19 AM UTC-4, chrism0dwk wrote:
>
> Great news, thanks for the advice!
>
> 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/-/U40FuQkj9bwJ.
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] Re: Git & source code for productivity measurement, using semi-auto half-hourly commits.

[P Rouleau]

Ho! I should add that with a strategy like that, no body would want to
work on bugs because their "apparent code production" would go down
big time. It's a loose-loose situation.

They should read about the Agile Methodology:
http://en.wikipedia.org/wiki/Agile_software_development

Programming is not like building a car. We cannot compare a line-
production with software development, unless you look how the line-
production itself is build. Once it is build, it doesn't change any
more. A working line-production is like a boxed software: done and
ready to work.

Good luck

On Sep 8, 7:28 pm, P Rouleau  wrote:
> That's also what my thinking.
>
> that remember me a story about a company, maybe IBM, that switched to
> a strategy of giving bonus to the developers based on the number of
> code line created. It was supposedly a mean to measure productivity.
> It only resulted in code-duplication. The developers copy-pasted the
> code instead of creating nice functions and re-using them. They went
> back a few years later. Sadly, they wasn't alone to do that mistake.
> It discouraging to see something similar in >2010.
>
> Anyway, what's the value of 1000 lines of code per hour if they
> contains bugs that take days to find later. I prefer 100 lines that
> works. That's left more time to do more test.
>
> Really, you should update your CV.
>
> On Sep 8, 10:48 am, Cathy Shapiro  wrote:
>
>
>
>
>
>
>
> > My solution would be to find a new job!
> > That's ridiculous. Obviously someone came up with the policy who has no idea
> > about programming.
>
> > On Thu, Sep 8, 2011 at 7:38 AM, Andy  wrote:
> > > Clive,
>
> > > On Sep 8, 12:42 pm, Clive Crous  wrote:
>
> > > > The company I work for sent out an email this morning instructing us
> > > > to, from now on, commit all source code changes for whatever we're
> > > > currently working on and push (to central
> > > > company git repository), regardless of the progress, status or state
> > > > every half-an-hour so that they see the
> > > > changes being made and can monitor productivity. Thoughts on this?
>
> > > Tee hee! Welcome to the 18th century and the joys of piece-work!
>
> > > Perhaps you should suggest that they install keyboard loggers instead
> > > so that they could count how many keys are being pressed!
>
> > > Unfortunately, it sounds like the idiot who came up with this idea
> > > wouldn't understand a rational discussion about the logic behind this,
> > > so I'd just go with the flow and create a script that modifies and
> > > checks in the same file every few minutes and then bask in the glory
> > > of being 'productive'!
>
> > > --
> > > 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.
>
> > --
> > Flash Pro Design
> > 4646 Poplar, Suite 517
> > Memphis, TN 38117
>
> > Phone: (901) 767-8767
> > Fax: (901) 685-9054
>
> >http://www.flashprodesign.com

-- 
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] Re: Git & source code for productivity measurement, using semi-auto half-hourly commits.

[P Rouleau]

That's also what my thinking.

that remember me a story about a company, maybe IBM, that switched to
a strategy of giving bonus to the developers based on the number of
code line created. It was supposedly a mean to measure productivity.
It only resulted in code-duplication. The developers copy-pasted the
code instead of creating nice functions and re-using them. They went
back a few years later. Sadly, they wasn't alone to do that mistake.
It discouraging to see something similar in >2010.

Anyway, what's the value of 1000 lines of code per hour if they
contains bugs that take days to find later. I prefer 100 lines that
works. That's left more time to do more test.

Really, you should update your CV.

On Sep 8, 10:48 am, Cathy Shapiro  wrote:
> My solution would be to find a new job!
> That's ridiculous. Obviously someone came up with the policy who has no idea
> about programming.
>
>
>
>
>
>
>
>
>
> On Thu, Sep 8, 2011 at 7:38 AM, Andy  wrote:
> > Clive,
>
> > On Sep 8, 12:42 pm, Clive Crous  wrote:
>
> > > The company I work for sent out an email this morning instructing us
> > > to, from now on, commit all source code changes for whatever we're
> > > currently working on and push (to central
> > > company git repository), regardless of the progress, status or state
> > > every half-an-hour so that they see the
> > > changes being made and can monitor productivity. Thoughts on this?
>
> > Tee hee! Welcome to the 18th century and the joys of piece-work!
>
> > Perhaps you should suggest that they install keyboard loggers instead
> > so that they could count how many keys are being pressed!
>
> > Unfortunately, it sounds like the idiot who came up with this idea
> > wouldn't understand a rational discussion about the logic behind this,
> > so I'd just go with the flow and create a script that modifies and
> > checks in the same file every few minutes and then bask in the glory
> > of being 'productive'!
>
> > --
> > 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.
>
> --
> Flash Pro Design
> 4646 Poplar, Suite 517
> Memphis, TN 38117
>
> Phone: (901) 767-8767
> Fax: (901) 685-9054
>
> http://www.flashprodesign.com

-- 
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] Re: get rid of old commits

[P Rouleau]

rebase -i is a manual operation. I think you would have to squash all
the commit you want to remove.

You can rewrite your initial commit with filter-branch:
› Remove all commits before a particular one, and make that one (ID or
TAG) the initial

$ echo ID > .git/info/grafts
$ git filter-branch
(source: http://documentation.debian-projects.org/software/git-core/)

But I don't see how you can easily backup the removed part and still
keep a connection with what you keep. In six months, you would
probably be able to push the new history to the backuped one and
rewrite the history there to reconnect the sequence of changesets
(probably with another graph point, see 
https://git.wiki.kernel.org/index.php/GraftPoint).

Also, because you rewrite the history, all the commit IDs will change.
You will have to match the local branching points to the new commit ID
to rebase the local work on each workstation.


On Oct 3, 9:23 am, canna  wrote:
> sorry to get back to you only now, holidays
>
> I do git gc all the time but I don't see any improvement afterwards
>
> Peter - I never used rebase, so I'm sorry if my question sound a bit
> naive, is rebase something that you can do in one local repo and than
> push the changes to the main repo, and than pull the changes to all
> the other developers repos?
>
> On Sep 30, 10:49 am, Peter  wrote:
>
>
>
> > If you really want to remove old commit, you can just use "git rebase -i"
>
> >http://book.git-scm.com/4_interactive_rebasing.html
>
> > pick fc62e55 added file_size
> > pick 9824bf4 fixed little thing
> > pick 21d80a5 added number to log
> > pick 76b9da6 added the apply command
> > pick c264051 Revert "added file_size" - not implemented correctly
>
> > # Rebase f408319..b04dc3d onto f408319
> > #
> > # Commands:
> > #  p, pick = use commit
> > #  e, edit = use commit, but stop for amending
> > #  s, squash = use commit, but meld into previous commit
> > #
> > # If you remove a line here THAT COMMIT WILL BE LOST.
> > # However, if you remove everything, the rebase will be aborted.
> > #
>
> > "The last useful thing
> > that interactive rebase can do is drop commits for you. If instead of
> > choosing 'pick', 'squash' or 'edit' for the commit line, you simply remove
> > the line, it will remove the commit from the history."
>
> > On Thu, Sep 30, 2010 at 3:47 PM, Peter  wrote:
> > > You could try to  run "git config --global gc.auto 100" on your repo
> > > machine and work machine.
>
> > > "If the number of loose objects exceeds the value of the gc.auto 
> > > configuration
> > > variable, then all loose objects are combined into a single pack usinggit
> > > repack -d -l."
>
> > > On Thu, Sep 30, 2010 at 2:08 AM, Adam Prescott 
> > > wrote:
>
> > >> My understanding is that git will handle running "git gc" for you when
> > >> you have a fair amount of stuff it can clear up (I've seen it do this
> > >> automatically, personally, but I could be wrong). So even if the
> > >> answer is "no", it might not be the answer to the question, "has 'git
> > >> gc' ever been run?"
>
> > >> --
> > >> 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-us...@googlegroups.com.
> > >> To unsubscribe from this group, send email to
> > >> git-users+unsubscr...@googlegroups.com > >>  .com>
> > >> .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/git-users?hl=en.
>
> > > --
> > > liuhui998 bloghttp://liuhui998.com
>
> > --
> > liuhui998 bloghttp://liuhui998.com

-- 
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-us...@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] Re: change another branch

[P Rouleau]

Are you the only one to work on these branches? If not, you loose the
work other have done.

-*--*--*--*--< master
   \-*--*--*--< work

A "reset --hard work" with branches like above loose the 3 commits
made on master and simply make master to refer to the same commit than
work.

If you are alone, you can work directly on master if you want to save
some manual operations.
if you are not alone, you should use merge instead of reset or,
better, you should rebase your work on the new master's state, then
merge it to master.

On Sep 16, 6:57 am, ruud  wrote:
> Hi Michael,
>
> I forgot to mention the work branch is based on master. It is one or
> more commits ahead. I only  want to move the master head to the work
> head.
>
> regards, Ruud

-- 
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-us...@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] Re: How to migrate to git from two SVN repositories?

[P Rouleau]

Well, that's the kind of pearls git contains and I still have to
discover.

Thanks.

On Sep 7, 4:45 am, David Aguilar  wrote:
> On 9/6/10, Mark Kharitonov  wrote:
>
> > @Rouleau: Thanks for the reply.
>
> >  Nope. I have two SVN repositories, where:
> >  - the first repository is the repository before the old VCS crashed.
> >  - the second repository contains all the dev code since the crash with
> >  the history starting from the crash day onwards.
>
> >  I wish to have a single GIT repository containing the merge of the two
> >  SVN repositories, so that the crash incident does not manifest itself
> >  in anyway. In other words, if a file is present in two SVN
> >  repositories, then it has two distinct histories - the one from its
> >  creation until the crash (in the first repo) and the other  - from the
> >  crash until now (in the new repo). I want this file to have a single
> >  history in the GIT, which is from its creation until now.
>
> You should read up on "grafts" in git.
>
> http://stackoverflow.com/questions/161928/what-are-git-info-grafts-forhttps://git.wiki.kernel.org/index.php/GraftPoint
>
> "Merge" in git parlance means something different then how you are
> using it, which may be part of the confusion.  Once you've grafted the
> histories together you should be able to filter-branch the graft point
> away.  The basic idea is to start from two separate git repositories.
> Go into the one with the post-crash history and graft the initial
> commit so that its parent is the last commit from the pre-crash
> history.  Once the graft is setup you can use filter-branch to make
> the graft permanent.
>
> In order to have the pre-crash history available in the post-crash
> repo you'll need to add it as a remote to your post-crash repo.
>
> git remote add old path/to/pre-crash
> git fetch old
>
> The pre-crash SHA1s will then become available from your post-crash
> repo.  'git branch -a' will show its branches, etc.
>
> >  On Sep 5, 6:31 pm, P Rouleau  wrote:
> >  > I'm not an expert, but it looks like you now have two branches in SVN
> >  > and you want to merge them back, but in git instead. And the hardest
> >  > step will be "finding the time to do it"...
>
> >  > I understand you want to keep the pre-crash history and the post-crash
> >  > one too. I suggest these steps (look at the doc for the options'
> >  > description):
> >  > 1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
> >  > 2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
> >  > 3. cd mergeCrash
> >  > 4. git remote add postCrash ../postCrash
> >  > 5. git fetch [--tags] postCrash master
> >  > 6. git merge postCrash/master
>
> I don't think this is what we are trying to accomplish.
>
>
>
> >  > On Sep 5, 3:42 am, Mark Kharitonov  wrote:
>
> >  > > Dear ladies and sirs.
>
> >  > > We use SVN as our VCS, but wish to migrate to git. All is good, but a
> >  > > few months ago our SVN server had a serious RAID problems (so much
> >  > > that it became unusable) plus at the same day no IT person was
> >  > > available to restore the repository from the backups. So, we have
> >  > > setup a temporary SVN server on a certain workstation from the most
> >  > > recent version that we had. The net result is:
>
> >  > >    1. We have a few months of work on the temporary SVN server (the
> >  > > revisions there start from 1, of course)
> >  > >    2. There is a new VCS server machine with the pre-crash SVN
> >  > > repository restored there, but no one uses it yet, because someone has
> >  > > to merge the temporary repository there somehow and no one has the
> >  > > time.
> >  > >    3. In addition, we want to migrate to git, because SVN is just too
> >  > > much pain to work with - merges are killing us.
>
> >  > > Can anyone advice on the best process to end up with a git repository,
> >  > > which would contain the old SVN repository merged with the temporary
> >  > > one?
>
> >  > > BTW, the new VCS server is a linux machine.
>
> >  > > Thanks a lot in advance.
>
> --
>     David

-- 
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-us...@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] Re: How to migrate to git from two SVN repositories?

[P Rouleau]

Well, that's the kind of pearls git contains and I still have to
discover.

Thanks.

On Sep 7, 4:45 am, David Aguilar  wrote:
> On 9/6/10, Mark Kharitonov  wrote:
>
> > @Rouleau: Thanks for the reply.
>
> >  Nope. I have two SVN repositories, where:
> >  - the first repository is the repository before the old VCS crashed.
> >  - the second repository contains all the dev code since the crash with
> >  the history starting from the crash day onwards.
>
> >  I wish to have a single GIT repository containing the merge of the two
> >  SVN repositories, so that the crash incident does not manifest itself
> >  in anyway. In other words, if a file is present in two SVN
> >  repositories, then it has two distinct histories - the one from its
> >  creation until the crash (in the first repo) and the other  - from the
> >  crash until now (in the new repo). I want this file to have a single
> >  history in the GIT, which is from its creation until now.
>
> You should read up on "grafts" in git.
>
> http://stackoverflow.com/questions/161928/what-are-git-info-grafts-forhttps://git.wiki.kernel.org/index.php/GraftPoint
>
> "Merge" in git parlance means something different then how you are
> using it, which may be part of the confusion.  Once you've grafted the
> histories together you should be able to filter-branch the graft point
> away.  The basic idea is to start from two separate git repositories.
> Go into the one with the post-crash history and graft the initial
> commit so that its parent is the last commit from the pre-crash
> history.  Once the graft is setup you can use filter-branch to make
> the graft permanent.
>
> In order to have the pre-crash history available in the post-crash
> repo you'll need to add it as a remote to your post-crash repo.
>
> git remote add old path/to/pre-crash
> git fetch old
>
> The pre-crash SHA1s will then become available from your post-crash
> repo.  'git branch -a' will show its branches, etc.
>
> >  On Sep 5, 6:31 pm, P Rouleau  wrote:
> >  > I'm not an expert, but it looks like you now have two branches in SVN
> >  > and you want to merge them back, but in git instead. And the hardest
> >  > step will be "finding the time to do it"...
>
> >  > I understand you want to keep the pre-crash history and the post-crash
> >  > one too. I suggest these steps (look at the doc for the options'
> >  > description):
> >  > 1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
> >  > 2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
> >  > 3. cd mergeCrash
> >  > 4. git remote add postCrash ../postCrash
> >  > 5. git fetch [--tags] postCrash master
> >  > 6. git merge postCrash/master
>
> I don't think this is what we are trying to accomplish.
>
>
>
> >  > On Sep 5, 3:42 am, Mark Kharitonov  wrote:
>
> >  > > Dear ladies and sirs.
>
> >  > > We use SVN as our VCS, but wish to migrate to git. All is good, but a
> >  > > few months ago our SVN server had a serious RAID problems (so much
> >  > > that it became unusable) plus at the same day no IT person was
> >  > > available to restore the repository from the backups. So, we have
> >  > > setup a temporary SVN server on a certain workstation from the most
> >  > > recent version that we had. The net result is:
>
> >  > >    1. We have a few months of work on the temporary SVN server (the
> >  > > revisions there start from 1, of course)
> >  > >    2. There is a new VCS server machine with the pre-crash SVN
> >  > > repository restored there, but no one uses it yet, because someone has
> >  > > to merge the temporary repository there somehow and no one has the
> >  > > time.
> >  > >    3. In addition, we want to migrate to git, because SVN is just too
> >  > > much pain to work with - merges are killing us.
>
> >  > > Can anyone advice on the best process to end up with a git repository,
> >  > > which would contain the old SVN repository merged with the temporary
> >  > > one?
>
> >  > > BTW, the new VCS server is a linux machine.
>
> >  > > Thanks a lot in advance.
>
> --
>     David

-- 
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-us...@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] Re: How to migrate to git from two SVN repositories?

[P Rouleau]

Ok, when I said you had two branches, I want to mean we can look at
your two SVN repositories as two separate branches. My mistake.

If you do not want the crash to be visible in the history, you can try
to replace the step 6 with a rebase on the mergeCrash's postCrash
branch, followed by the merge on the mergeCrash's master branch. This
will make the history linear, and the postCrash branch will not be
visible in the master history. I'm not sure the rebase will work, as
the two branches don't share a common parent.

If the rebase doesn't work, you can try to extract each commit from
the postCrash repository as patches and apply them on the mergeCrash
repository.


On Sep 6, 3:47 pm, Mark Kharitonov  wrote:
> @Rouleau: Thanks for the reply.
>
> Nope. I have two SVN repositories, where:
> - the first repository is the repository before the old VCS crashed.
> - the second repository contains all the dev code since the crash with
> the history starting from the crash day onwards.
>
> I wish to have a single GIT repository containing the merge of the two
> SVN repositories, so that the crash incident does not manifest itself
> in anyway. In other words, if a file is present in two SVN
> repositories, then it has two distinct histories - the one from its
> creation until the crash (in the first repo) and the other  - from the
> crash until now (in the new repo). I want this file to have a single
> history in the GIT, which is from its creation until now.
>
> On Sep 5, 6:31 pm, P Rouleau  wrote:
>
> > I'm not an expert, but it looks like you now have two branches in SVN
> > and you want to merge them back, but in git instead. And the hardest
> > step will be "finding the time to do it"...
>
> > I understand you want to keep the pre-crash history and the post-crash
> > one too. I suggest these steps (look at the doc for the options'
> > description):
> > 1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
> > 2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
> > 3. cd mergeCrash
> > 4. git remote add postCrash ../postCrash
> > 5. git fetch [--tags] postCrash master
> > 6. git merge postCrash/master
> >     If you did a lot of modifications in the post-crash branch, this
> > is where you will regret it. You will probably use --continue alot.
> > 7. git add {conflictedFiles}
> > 8. git commit -m "Back to one history, at last"
> > 9. git remote add origin g...@thegitserver:project.git
> > 10. git push [--tags] origin master
> > 11. // start working with the new server and shutdown the SVN ones to
> > avoid creating a new mess.
>
> > If step 6 is too challenging, you can simply push the preCrash history
> > into a preCrash branch on the new server and simply push the postCrash
> > history to the master branch and continue to work from there. You will
> > have access to the old history, but it will not be very useful. I'm
> > not sure, but if you have many branches, you will have to push them
> > also.
>
> > PS: I did not try the steps myself. I have only writed the steps I
> > would have plan to do. We have switched from SVN to git not long ago
> > and it went very well, but we only had to do step 1, 9 and 10.
>
> > On Sep 5, 3:42 am, Mark Kharitonov  wrote:
>
> > > Dear ladies and sirs.
>
> > > We use SVN as our VCS, but wish to migrate to git. All is good, but a
> > > few months ago our SVN server had a serious RAID problems (so much
> > > that it became unusable) plus at the same day no IT person was
> > > available to restore the repository from the backups. So, we have
> > > setup a temporary SVN server on a certain workstation from the most
> > > recent version that we had. The net result is:
>
> > >    1. We have a few months of work on the temporary SVN server (the
> > > revisions there start from 1, of course)
> > >    2. There is a new VCS server machine with the pre-crash SVN
> > > repository restored there, but no one uses it yet, because someone has
> > > to merge the temporary repository there somehow and no one has the
> > > time.
> > >    3. In addition, we want to migrate to git, because SVN is just too
> > > much pain to work with - merges are killing us.
>
> > > Can anyone advice on the best process to end up with a git repository,
> > > which would contain the old SVN repository merged with the temporary
> > > one?
>
> > > BTW, the new VCS server is a linux machine.
>
> > > Thanks a lot in advance.

-- 
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-us...@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] Re: How to migrate to git from two SVN repositories?

[P Rouleau]

I'm not an expert, but it looks like you now have two branches in SVN
and you want to merge them back, but in git instead. And the hardest
step will be "finding the time to do it"...

I understand you want to keep the pre-crash history and the post-crash
one too. I suggest these steps (look at the doc for the options'
description):
1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
3. cd mergeCrash
4. git remote add postCrash ../postCrash
5. git fetch [--tags] postCrash master
6. git merge postCrash/master
If you did a lot of modifications in the post-crash branch, this
is where you will regret it. You will probably use --continue alot.
7. git add {conflictedFiles}
8. git commit -m "Back to one history, at last"
9. git remote add origin g...@thegitserver:project.git
10. git push [--tags] origin master
11. // start working with the new server and shutdown the SVN ones to
avoid creating a new mess.

If step 6 is too challenging, you can simply push the preCrash history
into a preCrash branch on the new server and simply push the postCrash
history to the master branch and continue to work from there. You will
have access to the old history, but it will not be very useful. I'm
not sure, but if you have many branches, you will have to push them
also.

PS: I did not try the steps myself. I have only writed the steps I
would have plan to do. We have switched from SVN to git not long ago
and it went very well, but we only had to do step 1, 9 and 10.

On Sep 5, 3:42 am, Mark Kharitonov  wrote:
> Dear ladies and sirs.
>
> We use SVN as our VCS, but wish to migrate to git. All is good, but a
> few months ago our SVN server had a serious RAID problems (so much
> that it became unusable) plus at the same day no IT person was
> available to restore the repository from the backups. So, we have
> setup a temporary SVN server on a certain workstation from the most
> recent version that we had. The net result is:
>
>    1. We have a few months of work on the temporary SVN server (the
> revisions there start from 1, of course)
>    2. There is a new VCS server machine with the pre-crash SVN
> repository restored there, but no one uses it yet, because someone has
> to merge the temporary repository there somehow and no one has the
> time.
>    3. In addition, we want to migrate to git, because SVN is just too
> much pain to work with - merges are killing us.
>
> Can anyone advice on the best process to end up with a git repository,
> which would contain the old SVN repository merged with the temporary
> one?
>
> BTW, the new VCS server is a linux machine.
>
> Thanks a lot in advance.

-- 
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-us...@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] Re: Use Git to manage .NET assembly version

[P Rouleau]

At my place, we use an AssemblyInfo-Custom.template which contains the
common attributs, like the company' name and copyrights. That file is
keep in a template/ directory and it is shared with all the projects
of a solution. The standard AssemblyInfo.cs is cleaned to only
contains the attributs specific to the project, like its name. The
file also contains the version's attributs, but they have MACRO
instead of version X.Y.Z.W.

The macros are replaced with the help of an script called from the pre-
build event. The script copies the template from the template/
directory to the properties's project directory and replace the macros
with a version generated with the help of "git describe". You can
search for GIT-VERSION-GEN for an example how to use "git describe" to
have a version string. The generated AssemblyInfo-Custom.cs is not
commited.

On Aug 19, 4:10 am, Ido Ran  wrote:
> Hi,
> I'm using git to manage my .NET solution which contain 4 C# projects.
> .NET assemblies have version of schema major.minor.build.revision.
> I manage the major and minor manually.
>
> I would like to hook git into my help by increasing the build number
> of each project that is part of this commit.
>
> I think I can use git hooks (pre-commit) to run an MSBuild task that
> will change the version of the assembly or any other command line to
> change the version of the assembly.
>
> I would like to know if anyone does something like this?
>
> Thank you,
> Ido

-- 
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-us...@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.