[git-users] Re: Looking for C# Git library
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 --
Re: [git-users] Process of branching
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 pn1@gmail.com javascript: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 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/-/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.
Re: [git-users] Process of branching
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 new branch name 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.
[git-users] Re: Applying licence (eg. GPL) to Git history
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.
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 cathyshap...@gmail.com 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 a...@hardyfamily.org.uk wrote: Clive, On Sep 8, 12:42 pm, Clive Crous clive.cr...@gmail.com 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.
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 proulea...@gmail.com 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 cathyshap...@gmail.com 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 a...@hardyfamily.org.uk wrote: Clive, On Sep 8, 12:42 pm, Clive Crous clive.cr...@gmail.com 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
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 c.ne...@gmail.com 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 liuhui...@gmail.com 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. # http://book.git-scm.com/4_interactive_rebasing.htmlThe 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 liuhui...@gmail.com 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 mention...@gmail.comwrote: 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.comgit-users%2bunsubscr...@googlegroups .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
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 r.grosm...@gmail.com 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?
Well, that's the kind of pearls git contains and I still have to
discover.
Thanks.
On Sep 7, 4:45 am, David Aguilar dav...@gmail.com wrote:
On 9/6/10, Mark Kharitonov mark.kharito...@gmail.com 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 proulea...@gmail.com 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 mark.kharito...@gmail.com 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?
Well, that's the kind of pearls git contains and I still have to
discover.
Thanks.
On Sep 7, 4:45 am, David Aguilar dav...@gmail.com wrote:
On 9/6/10, Mark Kharitonov mark.kharito...@gmail.com 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 proulea...@gmail.com 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 mark.kharito...@gmail.com 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?
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 mark.kharito...@gmail.com 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 proulea...@gmail.com 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 mark.kharito...@gmail.com 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
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 ido@gmail.com 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.
