Hi,
I don't have an /etc/gitconfig on Ubuntu and I can't remember if a
.gitconfig was created in my home directory, I don't think it was. You'll
soon have a .gitconfig file once you start setting properties via git
config --global as Git will create the file for you. I think you'll most
I think this question on stackoverflow might help... -
http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git
Basically the problems stems to you using the same physical repo with two
different types of Git client, one built to use Windows EOL and the other
IMHO I don't think a third partition will have any effect, but I could be
very wrong.
I think the problem is a consequence of a couple of things, apologies if
I'm covering things you already know. There are two things to consider,
your local repository (Git internal storage) and your local
Hi Anatoly,
Hopefully I've understood your questions...
So each time you do a commit on your branch those become
revisions/versions in your local repository. If you're not committing
changes as you go then your local repository isn't changed. When you merge
your branch back into trunk it
Hi Ryan,
Your Git Tutorial has been well and truly cemented into my bookmarks. I'm
often recommending it to others as it has proven to be an excellent
resource. Thank you!!
Cheers,
Alex
On Thursday, 10 January 2013 00:03:40 UTC, Ryan Hodson wrote:
Hey Git Users!
I wrote a Git book
Technically Git doesn't need a central location, in fact that's the point.
In reality Git is often used with a central repository to share changes but
this is more about administration, enterprise engineering policies, etc.
and to make collaboration a bit easier. This is not a bad list of the
Hi,
Typically *submodules* are used; however, you have to be careful how you
use them so I'd do some reading before diving in.
There is also the *subtree merging,* which has an example here -
http://git-scm.com/book/en/Git-Tools-Subtree-Merging
Another option is the *subtree* command,
Hi,
I use gitg on Ubuntu and it works nicely. It's not a full blown Git
client but I don't need it for that and usually the command line is enough.
I just use it for history, branch and sometimes diff viewing when the
command line is just not quite enough and I need to see something a bit
://www.emacswiki.org/emacs/Git
On Friday, May 17, 2013 9:11:15 PM UTC+1, Dale Worley wrote:
From: Alex Lewis alex.l...@gmail.com javascript:
Is Fugitive.vim any help?
http://www.vim.org/scripts/script.php?script_id=2975
I'm a little bit lost as to what you're environment is :)
Can you
Hi,
Ok with your change to the GitFlow process in step 3 you'll have to be
careful about doing that merge back to master in step 4, in fact I'd say
just don't do it. The reason is that you'll be diverging mater from develop
and it'll soon become difficult if not impossible to manage and I
Yes it really is a decision about the size of the project, the complexity
of the features, the dependencies between those features etc. So
essentially *Feature Branching* won't fit every situation and I think
branching in general is more of a tool than a necessity and I think it
becomes a
, May 23, 2013 11:30:58 AM UTC+1, Roddie wrote:
Thanks Alex - that's good to hear. In another thread I've just come
across the concept of feature toggle and I'm wondering if that might
be more appropriate for me.
Roddie
On 23/05/2013 11:01, Alex Lewis wrote:
Yes it really is a decision
I'd agree branching is all that and should be the way to do development,
it's more of a question of *how many* branches you go with and being
sensible about it. As your branch count proliferates then it can become
more complicated to keep track of what is going on, what's being done
where,
So if I had branches...
master
|- develop
| |- proposed-feature
Is there a way to have proposed-feature always a branch of the last commit
on develop automatically I.e. so I don't have to keep rebasing it on top of
develop as develop is being rebased?
---Detail---
I'm currently using git-svn
it fits with what
you want to do but it might be useful so I thought I'd mention it.
Cheers,
Alex
On Friday, 2 August 2013 22:12:36 UTC+1, Dale Worley wrote:
From: Alex Lewis alex.l...@gmail.com javascript:
Does http://www.emacswiki.org/emacs/Git do what you want?
No, nothing I found listed
Thanks Sam. That's a great tip about naming it git-xyz so you can use
git xyz!
I assume you're suggesting I use the git commands I posted rather than
using plumbing commands?
Cheers,
Alex
On Thursday, 8 August 2013 18:14:39 UTC+1, Sam Roberts wrote:
/bin/sh script with no bash specifics...
If you want to keep your process relatively similar then I think it might
look something like...
development (repo)
- master (= trunk)
- branches from master.
- tags on master.
de (repo)
- master (= trunk)
- branches from master (if necessary, probably a good practice to create
a
The first thing I'd like to say is nice one for considering VCS from day
one, even many real programmers have not considered it up front. As for
your choice of Git, I don't think you'll regret it :)
In short I think the answer is sadly a bit of a) and b) and that's the art
of writing good
puzzle-piece: rebase :-)
Thanks a lot guys, this was exactly the kind of information I was looking
for!
Michael
Am Mittwoch, 25. September 2013 12:16:33 UTC+2 schrieb Alex Lewis:
The first thing I'd like to say is nice one for considering VCS from day
one, even many real programmers
From what you've said your assumption is correct, it should just be a
fast-forward pull/merge on the desktop at the end. Is there any chance you
could provide the Git commands you're using at each stage? It might also be
useful to know how you set up the repositories in the first place.
20 matches
Mail list logo
